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. |
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 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:
|
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. |
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. |
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 |
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). |
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) |
See also