Home > ADSS OCSP Service > Configuring the OCSP Service > Step 3 - Registering Trusted CAs for OCSP Service

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 "Add CA" button in the screen shown below:



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

Item 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 Add CA 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.

OCSP Responder Policy defines the following:

Item Description
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 operator 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, RipeMD128 and RipeMD160.

Note: When operating in FIPS 201 compliant mode, the ADSS Server operator 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 hash (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.
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.

Identrust Extensions
 
defines the following:



Each item in the screenshot is described below:

Item 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:

Item 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 reponder, 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 operator 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:

Item 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:

1. The Policy of the target CA is used if there is a single targert 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).

2. If multiple local cert IDs are passed in the OCSP request, the policy for the issuer of the first target certificate is used.

3. 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.

4. If the default policy needs to be used but it has not been configured then "internal error" is returned. 

See also