When registering a CA the method of checking the revocation status of the certificates it issues must be defined. ADSS Server provides the ability to check the status of certificates issued by a particular CA using real-time OCSP calls, regular CRL retrieval and/or via a real-time full certificate status database. Both primary and secondary retrieval method can be specified. In the screenshot below, CRL is chosen as the primary method and OCSP as the secondary methods:



For Local CA

For External CA



The fields of the above screen are:

Items

Description

Revocation Settings

Defines which method to use first to check the target certificate status: 

  • OCSP
    This option defines whether to identify the authoritative OCSP responder using the AIA extension from the target certificate and/or to configure OCSP responder address(es) in ADSS Server.
  • CRL 
    When CRL is selected then operator can configure either Local CRL Cache to retrieve CRLs within the CRL Monitor and/or identify the CRL resource address using the CDP extension from the target certificate.

​​Select the required option(s) and move these to the right-hand side using the “>” arrow button. When both options are selected, the operational order can be changed using the up and down arrow buttons.

The setting can be either OCSP or CRL. The most common settings used are OCSP as a primary mechanism and optionally CRL as secondary method. This is useful in cases when primary mechanism fails e.g external OCSP communications fail then this secondary mechanism provides an automatic backup method allowing ADSS Server to use the secondary mechanism i.e CRLs retrieved within the CRL Monitor. OCSP can be defined as a secondary method to CRLs if required, although this is considered unusual.

Check certificate is issued by CA before responding good status

This option is only available when using a local CA because when a certificate status is returned GOOD after performing check through the CRL then the system will perform another check whether the certificate was issued by the CA or not. If it finds the certificate in the database then the status will be returned as GOOD. If the certificate is not found in the local CA database then its status  will be returned as REVOKED.

Use Real-time certificate status settings 

This option is only shown for external CAs when the Real Time Revocation option is enabled in Global Settings.
If checked then real time revocation checking for this CA will become available. See Real Time Revocation status settings for more details.


OCSP Settings

The following screen is presented in the case that OCSP is selected as the certificate status checking method:



The first section defines the policy for validating the certificates issued by the CA itself - referred to as target certificates. When OCSP is selected as a primary or secondary revocation checking method then there are two options for determining the location of the corresponding OCSP Responder:

  • Using the AIA extension from the certificate.
  • Using a locally configured OCSP Responder address.

Either or both options can be selected.  In the case that a locally configured OCSP Responder address option is selected then the group box Locally Configured OCSP Responder Address(es) will be enabled and one or more OCSP Responder addresses can be entered there. When using multiple OCSP responder addresses the order in which they should be used by ADSS Server can also be set using the up and down buttons to change their position in the list. This option is typically used to create high availability solutions and enables multi-site resilience.

Communication with the OCSP Responder can be checked by clicking the Test button..


Once the options for locating the OCSP Responder have been selected then the fields in the OCSP Settings group box can be edited. These specify the OCSP request structure and also how to process the OCSP response which is returned. The details are as follows:


Items

Description

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. 

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.

Hash Algorithm

Specify the hash algorithm to be used to generate OCSP request; and furthermore to sign the OCSP request if enabled. 

Note: Set the Hash Algorithm to SHA1 to compute the CertID in the OCSP request otherwise Adobe will not detect the embedded revocation from an LTV signature and will not show as an LTV signature (not that this is the limitation of Adobe for which there is no time limit when it will be fixed by them).

Clock Tolerance

When verifying OCSP responses, ADSS Server 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.

Note: Default value is 100 sec.

Response timeout

Defines how many seconds ADSS Server will wait for the OCSP Responder before assuming that there is a communication problem.

Note: Default value is 10 sec. Set to zero if the timeout is unlimited


CRL Settings

The following screen is presented in the case that CRL is selected as the certificate status checking method:



The first section defines the policy for validating the certificates issued by the CA itself - referred to as target certificates. When CRL is selected as a primary or secondary revocation checking method then there are two options available for determining the location of the corresponding CRL:

  • Using the CDP extension from the certificate.
  • Using a locally configured CRL Resource address.

Either or both options can be selected. Both options usually configured to create high availability solutions and enables multi-site resilience. Once the options for locating the CRL Resource have been selected then the following options available for configurations:

Items

Description

Use current CRL for historical validation

If this checkbox is selected then current CRL will be used to check revocation on specified date/time (provided in the request or within the associated timestamp (if present)) instead of searching and using an historical CRL.

This option can only be used with CAs that issue CRLs containing historic CRL data for all certificates issued and the CA does not suspend certificates.



For cases where CRLs are selected as the method for certificate status checking then most of the related settings are made in the next page, as described here.


Real Time Certificate Status Settings For External CAs

If the Real Time Revocation Database is configured under Global Settings then the real time certificate status settings will be available for configurations for External CAs. Following two options will be available for real time certificate status checking:

  1. Full Certificate Status Checking
  2. Extended CRL Status Checking


Full Certificate Status Checking: 

"Full Certificate Status Checking" means that in addition to a check to see if a certificate is revoked or not, another check is made to confirm that it was actually issued by the identified CA. To achieve this ADSS Server needs access to the full set of certificate status information maintained by the target registered CA. Real-time checking of the CA's CRL is not sufficient in this case because it only contains the details of the revoked certificates. To deliver "allowed list" or "real-time full certificate status" checking ADSS Server access to a database of up-to-date status information for all issued certificates.

The Full Certificate Status Database supports multiple CAs. Each CA is responsible for populating and updating its certificate status table, or this can be managed by a separate application written by the certificate service provider. 

To use the Real-Time Certificate Status Settings for a particular External CA, go to the Validation Policy page for the target CA, use the "real-time certificate status settings" option, now click select the "Use real-time certificate status database" tick box.

The following screen is presented:

The fields have these meanings:


Items

Description

Automatically create a table for the CA to publish certificate data

Select this option ONLY if the database table is to be created by ADSS Server (this is not the usual option). This is used when the CA does not have the functionality to create this table. The table is created by ADSS Server when it re-starts after this option has been selected in the Trust Manager Validation Policy for the target CA. The table name defined here must be shared with the external CA utility application so that it can populate the table with the full certificate status information. The name must not exceed 50 characters and must not contain any spaces.

Use existing database table for certificate data

Select this option if the database table is to be created by the external CA (or the separate export utility application). The CA can then populate the database table with the full certificate status information. The ADSS Server administrator must set the same table name when they configure the target CA's Validation Policy in Trust Manager.   
Always select this approach when integrating with Entrust Authority Security Manager.


​If CA creates the table itself then it has to make sure that the table strictly complies with the schema described in the Quick-Guide-for-ADSS-Realtime-Revocation-Database.pdf, also available at location [ADSS Server installation directory]/docs.​The external CA or CA utility application is responsible for obtaining the required data for all issued certificates and inserting the data into this Full Certificate Status Database table and for ensuring the data is always up-to-date.



Extended CRL Status Checking:

However for option Extended CRL status Checking under the CRL revocation checking mechanism is to also check a real-time certificate status database, i.e. first check the current CRL for that CA and then determine if there is more recent certificate status information for the relevant certificate in the real-time database table for that CA. This requires the use of the Ascertia Revocation Publication Utility (RPU) to be installed and also configured within the Global Settings as described here.

When Extended CRL status checking option is select then following screen is presented:

 The fields in Extended CRL status checking settings are as follows:

Items

Description

Revocation database is directly populated by the CA

Select this option if certificate status information is populated in the database table using triggers or through some other mechanism.

Revocation database is populated by the Revocation Publisher Utility

Select this option if the revocation database is populated by the Revocation Publisher Utility (RPU) in which CA publishes the revocation files against every revocation entry before publishing the next CRL. When a new CRL is published and downloaded in the ADSS Server database then real-time revocation database against that CA is cleared.

Input Folder Path

This is the folder path from where the revocation files will be fetched from the CA by the Revocation Publisher Utility (RPU). Multiple paths can be configured by separating them with a comma (in case of a load-balanced CA instance with multiple CAs. The path can be either on local machine or on the network.

Processed Folder Path

This folder is used for storing all the revocation files that are successfully processed by the Revocation Publisher Utility. As an example. The directory structure of ProcessedFolderPath for three instances of CA in load balanced mode is shown below.
The processed folder contains a directory for each CA (when real-time revocation is enabled) and each directory contains sub-directory for each individual instance of this CA which may exist in high availability mode:

ProcessedFolder

  • TestCA1 (The unique name created for the CA)
    • Instance1
    • Instance2
    • Instance3

In the above scenario there is only one CA registered in Trust Manager with real-time revocation checking enabled. If there are two CAs having real-time enabled then a new folder with TestCA2 is created which in turn contains folder for all the instances of that CA. For further details see section Real Time Revocation.

Error Folder Path

The directory structure of ErrorFolderPath is same as that of ProcessedFolderPath.
This folder will contain any revocation files which the Revocation Publisher Utility failed to process.

Temp Folder Path

To ensure a robust mechanism the files from the input folder are copied to this temp folder for processing because the CA may also be using the original input folder and therefore this avoids any overwrite issues.

Idle Sleep Time(Sec)

This time defines after how many seconds RPU will re-check the input folder for any new revocation profiles which may need processing.

Batch Size

Batch size is used to indicate that how many files will be processed by RPU in one go from the input folder. Any files which are left over will be picked up by the RPU when it completes the current batch and returns back to the input folder.

File Extension Filter

This is used for setting the revocation file extension filter. If no filter is mentioned then default is used which is ".rev" filter.

File Name Filter

This is in case only revocation files with a particular name are to be filtered.

Revocation request processing grace period (minutes)

This parameter defines how long a CA takes to process certificate revocation requests.  When a new CRL is retrieved from a CA and successfully inserted into the ADSS Server database then generally speaking this should contain all the latest information so the entries from real-time database table can be deleted. However any revocation requests which were being processed whilst the CRL was being generated will not be included in the CRL.  Hence the use of these parameters instructs the ADSS Server to only delete those records which were inserted before the newly inserted CRL thisUpdate minusN minutes, where N in this configuration that defines how long a CA takes in minutes to actually process a revocation request so that it becomes the part of the upcoming CRL.

Locating status provider

This setting is used while validating a certificate. The validation request may come from the Verification, XKMS and/or SCVP Service.
If CDP is selected then system will get the CDP address within the certificate and download the CRL and verify the certificate's validity.  The CRL is then held in the database and is available for future use including historic validation.
If Local CRL cached is selected then the certificate will be verified against a CRL previously downloaded by CRL Monitor.


​For more details about the database schema see the Quick-Guide-for-ADSS-Realtime-Revocation-Database.pdf, also available at location [ADSS Server installation directory]/docs.



See also

Step 1 - Identifying the TA
Step 3 - CRL Settings
Step 4 - Advanced Settings