ADSS Admin Guide

Items

Description

Validation Policy for Non-registered CAs

If intermediate CA certificates are discovered dynamically during path building process, these configurations are used to define the their validation mechanism.

• OCSP (using AIA extension)
  When selected, AIA address from target certificate (certification in question) is used to check the revocation. Additional configuration might be needed and these are explained in next row.
• OCSP (configured address)
  If target certificate does not have a CDP address nor an OCSP address in CDP and AIA extensions then there is no way to check the certificate revocation. In that is the case, OCSP responder address can be specified where issuer of this cert is configured to provide revocation information.
• CRLs (using CDP extension)
  When selected, CRL is downloaded based on URL retrieved from the CDP extension of the target (certification in question) certificate.
• XKMS (for full certificate validation)
  When selected, you have to specify another XKMS Server address where complete chain is registered. Note that in this case, revocation for complete chain will be checked from specified XKMS Server not the partial one like other options.

OCSP Settings

These configurations are shown when OCSP (using AIA extension) or OCSP (configured address) option is selected:

• Add Nonce extension
  If this option is enabled then XKMS Service 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 XKMS Service 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.
• Verify OCSP Responder's certificate
  Enable this option if revocation checking of the OCSP responder certificate is also required. Note that this is considered unusual since OCSP responder certificates are typically configured with a 'NOCHECK' extension, if No Check extension is found in OCSP responder certificate then this option will be ignored.
• Verify OCSP Responder is authorised by the CA
  If this option is enabled then XKMS Service 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.
• Hash Algorithm
  Specify the hash algorithm to be used to generate OCSP request; and furthermore to sign the OCSP request if enabled.
• Clock Tolerance
  When verifying OCSP responses, XKMS 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 XKMS Service will wait for the OCSP Responder before assuming that there is a communication problem. It is recommended that this is set to at least 10 seconds.

OCSP Responder Address

This option is shown when OCSP (configured address) is selected and you have to configure the OCSP responder address. Usually this option is used when AIA or CDP address is not found is target certificate.

XKMS Server Address

This option is shown when XKMS (for full certificate validation) is selected. Another XKMS server address is configured to check the revocation of complete chain. 

Sign XKMS Request

Select this checkbox if the XKMS service requires request messages to be signed. Then select the XKMS Request Signing Certificate which pre-exists in the Key Manager. 

Accepted Certificate Quality Levels

Specify the default certificate quality and independent assurance level for minimum acceptable quality levels for the clients using this profile.

Historical Validation Settings

The checkbox Allow historical verification requests means that the client can check certificate validity in the past by identifying a specific date and time within the request message.
 
For historical verification with basic path validation, two CRLs can also be checked in a certain approach. If CRL available at the time of signing does not contain the revocation information and next CRL also exists then system is going to check the status in next CRL as well. If there is no next CRL in database then system is going to rely on first CRL only as it will be the latest CRL.

If it is required that path validation to strictly follow PKIX guidelines then after creating the profile, then follow these instructions:

1. Launch ADSS Server admin console .
2. Navigate to location Global Settings > Advanced Settings
3. Search for the property PKIX_COMPLIANCE_MODE and set its value to TRUE. 
   Note: By setting the flag to TRUE, PKIX path validation is applied to timestamp and CRL certificates as well as the signer's certificate.
4. Click on Save button.
5. Restart ADSS Server core, Console and Service instances from Windows service panel or Unix daemon to have the changes take effect.