ADSS Admin Guide

Items

Description

Validation Policy for Non-registered CAs

If the target certificate chain building should be done up to a registered self-signed Root CA certificate then the intermediate CA certificates may or may not be registered within the Trust Manager module. If the intermediate CA certificates are not pre-registered in Trust Manager then these configurations are used to define 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 Request 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 Verification 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 Verification 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 Verification 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, Verification 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 Verification 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. 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. 

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 Signature and Certificate Quality Levels

The default certificate, independent assurance, hash algorithm and public key quality levels are minimum acceptable quality levels for the clients using this profile. If the option "Allow client application to override these parameters in its request message" is selected then default values are only used for the case where the client has not included any minimum quality levels within the request message. 

Historical Validation Settings

The checkbox Allow historical verification requests means that the client can check digital signature and certificate validity in the past by identifying a specific date and time within the request message. 
For historical verification, 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.

Signature grace period

This will define how long ADSS Verification Service should wait after the signing time indicated in the signature (either by TSA or by the signer's local time) before converting the basic signature to an advanced signature or before verifying a simple signature. The value '0' indicates that do not consider signature grace period while verifying a simple signature or converting it to advanced signature type.

Note: The default value set to '0'

Specify Verification Time

Verification settings configured under this area are only used if the verification request from the client application does not specify the verification time i.e. either a historical time or current time. When the validation time is not specified in the request message, then the preference is given to the timestamp token protecting the signature. If the signature is not protected by a trusted timestamp token, then the following configurations are used.

We can categorize the signatures types into following sections:

• For basic signature without timestamp, we have the following options:
• Return error if trusted timestamp token is not present in long term signature.
• Verify signatures at the current time.
• Verify signatures at the time of signing.
• Verify signatures at current time if signing time not available.
• Use embedded validation data if present.
• For long term signatures with one or more timestamps, we have the following radio buttons: 
• Verify the last timestamp at the current time.
• Verify the last timestamp using timestamp time.

Note: All the above stated verification rules to validate timestamp token for different advanced signature types are mentioned below.  

Return error if trusted timestamp token is not present in long term signature 

This setting is only applicable for long term signatures. When enabled an error is returned in the verification response mentioning that the long-term signature does not contain a trusted timestamp token.

Verify signatures at the current time

When this radio button is selected, the signature will be validated at the current time.

Verify signatures at the time of signing

When selected all signatures are verified at the time of signing. If the signing time is not present in a signature then an error is returned.

Verify signatures at current time if signing time not available

This option can be additionally selected so that verification of the signature can fall back to using current time in case the signing time is absent in the target signature.

Use embedded validation data if present

When the signatures are being validated at the current time then it can be additionally selected to use the embedded validation information in a long-term signature. It is important to note that in this case the embedded validation data is checked to be valid at the current time and if the validation data is not valid at the current time then an error is returned otherwise the signature is verified.

Verify the last timestamp at the current time

When this radio button is enabled, the last timestamp token will be verified using the current time.

Verify the last timestamp using timestamp time

When this radio button is enabled, the last timestamp token will be verified using the timestamp time. 

Allow signature Enhancement

This field enables one or more default TSA servers to be defined that can provide timestamps on demand when a signature needs to be enhanced with a timestamp.

Note: Most of the CA's have their own TSA Service. In order to configure a CA to have its own specific TSA, add TSA details within Trust Manager > Advance Settings. These CA specific setting overrides any Verification Profile settings. 

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