Step 3 - Registering Trusted CAs for OCSP Service

OCSP services are provided only for those CAs which are registered within the ADSS OCSP Service. This is in addition to their registration within the ADSS Trust Manager since the ADSS Trust Manager is used as a general store of trust anchors for any purpose. A CA can be added using the Registered CA option within the ADSS OCSP Service GUI. A list of registered CAs will be shown and to add a new CA click the "+" button in the screen shown below:

The following table explains the different columns on the Registered CAs page:

Items	Description
CA Friendly Name	This is friendly name of the CA added to the OCSP service. The CA Friendly Name is the same as the one registered within the Trust Manager.
Client Communication Certificate	This is the OCSP response signing certificate to be used by the OCSP Service when signing OCSP responses on behalf of the relevant CA. Click on the link for client communication certificate to display the defined certificate for the identified CA.
VA Communication Certificate	OCSP service uses this certificate when signing peer OCSP requests on behalf of the relevant CA. Clicking on the link for VA communication certificate will display the VA communication certificate for the relevant CA.
Status	The status for a CA is either Active or Inactive. CA status can be configured when registering a CA in the Trust Manager or by editing an existing CA. Among the registered CAs in OCSP service, the revocation services are provided for only those CAs which are marked Active in the Trust Manager.

This shows a table of the existing registered CAs. These registered CAs can be sorted in either Ascending or Descending order by selecting a table column from the drop down list. The list can be sorted by status or CA Friendly Name.

In order to register a new CA in OCSP service click "+" button and follow the CA registration wizard. Note the CAs that are already registered in the ADSS Trust Manager will be shown in the drop-down list of available CAs as shown below:

Select a CA certificate from the drop down list CA Details. Also select OCSP certificates for client communication. Note OCSP service will use this certificate when communicating with replying parties on behalf of the CA being registered. The keys existing in the Key Manager will be shown in the drop-down menu. You can select unique keys per CA.

General Settings defines the following:

Items	Description
CA Friendly Name	The selected CA from the list of registered CAs added to the OCSP service.
OCSP Responder Certificate	Selected OCSP response signing certificate will be used to sign OCSP responses received from the peer responders. Note: When operating in FIPS 201 compliant mode, the ADSS Server user must ensure that the length of the OCSP response signing key must be at least as large as, or larger than, the key length used by the CA that issued the target certificate (i.e. certificate being validated).
Hashing Algorithm	Selected hashing algorithm is used to sign the generated OCSP responses. The available options are SHA1, SHA224, SHA256, SHA384, SHA512, SHA3-224, SHA3-256, SHA3-384, SHA3-512, RipeMD128 and RipeMD160. Note: When operating in FIPS 201 compliant mode, the ADSS Server user must ensure that the hash algorithm configured for the OCSP response signing process must be at least as large as, or larger than, the hash algorithm used by the CA in issuing the target certificate (i.e. certificate being validated). Also note RipeMD128 and RipeMD160 are not available when operating in FIPS 201 compliant mode using a FIPS 140-2 evaluated hardware crypto module.
Identify Responder By	The OCSP Service can be configured to either include the responder name (i.e. common name of the OCSP response signing certificate) or the responder key hash.
Include Responder's Certificates in response	Select this option to include the intermediate certificate chain and/or OCSP response signing certificate within the generated OCSP response. Include Responder Certificate Chain By selecting this radio button, full chain of the OCSP response signing certificate will be included in the OCSP response. Include Only Responder Certificate By selecting this radio button, only OCSP response signing certificate will be included in the OCSP response. Note: If this option will be unchecked then neither response signing certificate nor response signing certificate chain will be included in the OCSP response.
Include CRL extension in OCSP responses	If CRL extensions and/or CRL references are available to the OCSP service then these will be included in the OCSP response message. The following CRL Entry Extensions are supported: Invalidity date. Reason code. Hold instruction code. The following CRL references are supported: crlUrl crlNumber crlTime
OCSP requests must have "nonce" extension	Determines whether or not the nonce extension should be present in the OCSP request messages that the ADSS OCSP service receives. If a nonce extension is required then any OCSP requests received without one causes a unauthorized error message to be sent back. Note: Since the ADSS OCSP Server is RFC 8954 compliant, it defines the limit for the value of nonce in an OCSP request i.e. 1 octet to 32 octets. As per RFC 8954, the OCSP responder will only add nonce in response if the value of nonce is minimum 16 octets and maximum 32 octets. If the value of nonce is greater than 32 octets, then an error will be shown upon request. When nonce is enabled in case of request forwarding, then 32 octets will be added in nonce for OCSP request.
Include "certHash" extension in the OCSP Response	If selected, then OCSP service includes this extension which stores hash of the target certificate in OCSP response. This hash serves as evidence that the certificate is known to the OCSP responder and it has been issued by the relevant CA. Note: This option is only available when Full certificate status checking is enabled for the issuer CA in Trust Manager.
Include "Archive Cutoff" extension in the OCSP Response	If selected, then OCSP service will add this extension in the single OCSP response. This extension contains the archive cutoff date, a date used by the OCSP responder for historical revocation of a certificate. An OCSP ArchiveCutoff date contribute to a proof that a digital signature was (or was not) reliable on the date it was produced even if the certificate needed to validate the signature has long since expired. 1. Retention Interval: Define the retention interval up to which OCSP responder can provide revocation information of the target certificate even if the certificate is expired and removed from the CRL. If, for instance, a server is operated with a 3-year retention interval policy and status was produced at time t1 then the value for ArchiveCutoff in the response would be (t1 - 3 years). Note: This option is only available when Full certificate status checking is enabled for the issuer CA in Trust Manager.
Lint OCSP Response	When this checkbox is enabled, the External Script Linter drop-down becomes accessible, allowing the user to select the configured linting tool. Here, selecting the linting tool will enable the user to validate the OCSP responses.

Identrust Extensions defines the following:

Each item in the screenshot is described below:

Items

Description

Add IdenTrust Freshness Proof optimisation extension for client and VA communication certs

If selected, the FP (Freshness Proof) extension is included in the OCSP Response. If enabled, the OCSP service will poll for FP Responses.

FP Cache Period is the time period after which OCSP service will poll for FP responses from the IdenTrust Root. This extension should normally be only used within the Identrust PKI environment for optimisation purposes.

Add IdenTrust CSC optimisation extension

If selected, the CSC (CA Status Cache) extension is included in the OCSP Response. If enabled OCSP service will poll for CSC Responses.
CSC Cache Period is the time period after which OCSP service will poll for CSC responses from the IdenTrust Root. This extension should normally be only used within the IdenTrust PKI environment for optimisation purposes.

OCSP Relay Policy defines the following:

Each item in the screenshot is described below:

Items	Description
Allow OCSP Request forwarding	If selected then the OCSP service is allowed to relay the request to a peer OCSP responder in case it is not authoritative for the target certificate.
Add Nonce extension	If this option is enabled then ADSS Server will add a nonce (i.e. a number used once) extension to the OCSP request message. The OCSP response is checked to ensure that it contains the same nonce value to prevent replay attacks.
Add Service Locator extension	If this option is enabled then ADSS Server will add the responder URL from the target certificate’s AIA extension into the OCSP request as a Service Locator extension. This helps the OCSP Responder to relay the OCSP request to other OCSP responders if the request cannot be handled directly.
Sign OCSP Request	Select this checkbox if the OCSP Responder requires OCSP request messages to be signed. Then select the OCSP Request signing Certificate which pre-exists in the Key Manager.
Hash Algorithm	Specify the hash algorithm to be used to generate OCSP request and furthermore to sign the OCSP request.
Use TLS client Authentication	If this option is enabled then OCSP service will communicate with peer OCSP responder using TLS client authentication. Select the Client TLS Certificate which pre-exists in the Key Manager. Note: It is required to register the Issuer CA of the Client TLS certificate in Trust Manager with the CA for verifying TLS client certificates purpose
Verify OCSP Responder's certificate	Select this checkbox if revocation checking of the OCSP responder certificate is also required. Note: This is considered unusual since OCSP responder certificates are typically configured with a 'NOCHECK' extension.
Verify OCSP Responder is authorised by the CA	If this option is enabled then ADSS Server validates that the OCSP Responder that provides the OCSP response message is certified by the same CA that certified the target certificate; and furthermore that the OCSP responder’s certificate was specifically marked by the CA for “OCSP Signing” in the certificates Extended Key Usage field.
Clock Tolerance	When verifying OCSP responses from peer responder, OCSP Service will compare the time within the OCSP response with its local clock to ensure they are “fresh” responses. System times may not be perfectly synchronized and so a tolerance value is essential. It is recommended that this is set to at least 100 seconds.
Response timeout	Defines how many seconds OCSP Service will wait for the peer OCSP Responder before assuming that there is a communication problem. It is recommended that this is set to at least 10 seconds. Note: Set to zero if the timeout is unlimited

D-OCSP Response Settings defines the following:

D-OCSP settings will only be shown if this option is allowed in the license file.

The Distributed OCSP Response settings are defined in the following screen:

Each items in the screenshot is described below:

Items	Description
Certificates Serial Number (From - To)	Specify the range of certificate serial numbers in numeric sequence for which cached OCSP responses are to be computed.
CertIds in one OCSP response	Configure the number of CertIds to be provided in each OCSP Repeater Response. 20 is the default value. If the serial number range is 1 to 2000 and the value for this field is set to 20 then 100 OCSP responses will be created each with 20 CertIds. Note: Once this value has been set, the value cannot subsequently be changed - so plan carefully!
Check certificate status every	Defines a time in minutes after which the the status of the certificates will be checked for a status update. The pre-computed OCSP responses are re-created only for those that have certificates (CertIDs) whose status has changed.
Re-compute OCSP response before next update	Defines a time in minutes before the nextUpdate time of this CA's CRL at which a new set of pre-computed OCSP responses will be calculated. In this case, OCSP responses are recomputed for the complete range of certificate serial numbers.
OCSP Responses batch size	Pre-computed OCSP responses are transmitted in ZIP files from the main OCSP Server to each OCSP repeater. This value defines how many sets of zip files will be used during the transmission Example: if the serial number range is 1 to 2000, number of CertIds is set to 20 and batch count is 5 then since each OCSP response contain 20 CertIds, therefore each batch will contain 20 OCSP responses (5x20x20 = 2000).

All the OCSP responses will be re-computed if an authorised user changes the value of "Certificate Serial Number (To & From fields)" and "CertIDs in one OCSP response".

Full Certificate Status Checking defines the following:

These settings are available only when real time certificate status checking is enabled in Trust Manager for the target CA .

Each item in the screenshot is described below:

Items	Description
NextUpdate Interval for Issued Certificates	Number of seconds added to the current date and time to be set as next update in OCSP response for issued target certificates when Full certificate status checking is enabled for the issuer CA in Trust Manager. Default Value is "0" (next update not get added).
NextUpdate Interval for Non-Issued Certificates	Number of seconds added to the current date and time to be set as next update in OCSP response for non-issued target certificates when Full certificate status checking is enabled for the issuer CA in Trust Manager. Default Value is "0" (next update not get added).

OCSP Policy as configured above is processed as follows:

The Policy of the target CA is used if there is a single target cert ID in the OCSP request and the issuer of the target certificate is a registered CA in the OCSP service (single local cert ID).
If multiple local cert IDs are passed in the OCSP request, the policy for the issuer of the first target certificate is used.
If any of the cert IDs in OCSP request is a foreign cert ID (i.e. the issuer is not added to OCSP Service registered CAs) then the policy for the relying party is used if the request was signed, The default policy is used if the request was not signed in this case.
If the default policy needs to be used but it has not been configured then "internal error" is returned.