Why ADSS CRL Monitor may not start?
By default, CRL Monitor remains stopped when there are no registered CAs in Trust Manager OR if one or more CAs are registered but none of them have enabled the option to "Enable automated polling".
To start CRL Monitor,
- Register at least one CA within Trust Manager.
- In at least one CA tick the "Enable automated polling" check box from Trust Manager > CRL Settings.
- Start the CRL Monitor > Service Manager.
How to configure a new CA in CRL Monitor?
These are the high level steps required to configure a new CA for CRL monitoring:
- Register the CA certificate in the Trust Manager module with the purpose "CA (will be used to verify other certificates and CRLs)".
- Configure the appropriate CRL resource addresses using HTTP(S) or LDAP(S) protocols (these addresses can be automatically read from an issued certificate) and also enable polling for this CA, see Trust Manager for details.
- Restart the CRL Monitor service from CRL Monitor > Service Manager if this is the first CA being registered in Trust Manager; or you can go to the CRL Monitor > CRL Monitoring page and start polling for the new CA if the CRL Monitoring service is already running and polling for CRLs for some of the configured CA(s).
Why might ADSS CRL Monitor not download CRLs for a configured CA?
ADSS CRL Monitor can only fetch CRLs when the configuration details are correct. Check the following configurations:
- Test the connection using internet/ LDAP browser to ensure configured HTTP(S)/ LDAP(S) address is working properly, see Trust Manager > CRL Settings.
If ADSS CRL Monitor is running behind a proxy server, then configure an appropriate proxy settings, see Global Settings > Miscellaneous.
Ensure that the SSL Server certificate issuer (for the server where the CRL is published) is registered in Trust Manager with the purpose "CA (will be used to verify other certificates and CRLs)".
Browse CRL Monitor > CRL Details to see whether a new CRL was received or not?
Browse CRL Monitor > CRL Logs to see the processing of ADSS CRL Monitor for the relevant CA.
View the log file from "Help > Debug Logs > service > crlmanager > crlmanager.log" to get an idea of the problem being encountered.
However, if you still face any problem, then contact support with the following information:
- Version of ADSS Server being used in your environment.
- A description of what action was performed, what was expected and what was experienced.
- The log files within "[ADSS-Server-Installation-Directory/logs/service/crlmanager]".
- A screenshot of the CRL polling configurations in Trust Manager > CRL Settings.
- Details of the CA for which CRL polling is unsuccessful (including the CA’s certificate, CRL address and information like whether the CRL is publicly available).
What is meant by CRL Monitor High Availability?
How to run CRL Monitor in a High Availability configuration?
Are very large CRLs (e.g. 10MB or more) supported by ADSS Server?
Yes large CRLs of 10MB or more are supported by ADSS Server. Your should ensure that sufficient memory and disk space are available on both the ADSS Server machine and the database system. 1GB of Java memory is adequate to handle 10MB CRLs. Within ADSS Server there is a maximum limit of 1 MB for PEM encoded CRLs and any that exceed this limit are rejected. This is because PEM encoded CRLs consume a lot of system memory, however CRLs are rarely encoded in PEM format because they are much larger in size than normal DER format.
Does ADSS Server support X.509 v1 and v2 CRLs, PEM encoded CRLs or indirect CRLs?
Yes all of these CRL formats are supported.
What is the difference between Logs Archiving settings provided in Trust Manager and CRL Logs?
Does ADSS Server support segmented CRLs? How can these be imported?
How to implement real time revocation?
When a certificate status is updated (revoked, suspended or reinstated), the CA does not publish the CRL right away. The publishing of CRL is usually scheduled after defined (configurable) intervals, according to the CA's CRL publishing policy. This means that there could be a possible time delay between a certificate being revoked, and the availability of revocation information to the relying parties (unless the CRLs are issued immediately upon every revocation, which is not a common practice).
In the up-mentioned scenario, when a certificate revocation status is updated right after the publication of the CRL, its information will not be updated in the ADSS Server database, until the next CRL is successfully processed by ADSS Server. This implies, if ADSS Server receives a signature/ certification/ OCSP request within that time period, the revocation status will be determined on the basis of the current valid CRL, however, the actual status could be different.
To cope with this potential scenario, ADSS Server provides the real-time revocation information feature within ADSS CRL Monitor, i.e. Revocation Publishing Utility (RPU). This utility can work in two different ways:
- For UniCERT CAs: The UniCERT CA generates a (.rev) file upon performing any change activity in the certificate status, and saves this file on a shared location. The RPU is configured to monitor the shared location, and immediately process the (.rev) file on arrival, and save the processed information in the RPU database.
- For other CAs: The CA does not generate (.rev) file for each change in certificate status, but directly triggers this information in the RPU database.
Now when ADSS Server receives a signature/ certification/ OCSP request, it will first check the current valid CRL (in ADSS database) and will then look into the RPU database (if certificate status is good or on hold), before determining the certificate status. This configuration can be set from Global Settings> Real Time Revocation
How to change the CRL polling schedule from polling on nextUpdate to polling at a configurable period?
How to reset the CRL information for a CA before moving from a pre-production environment into production?
How to configure ADSS Server to only retain the latest CRL and drop old CRLs for the registered CAs?
How are segmented CRLs different from partitioned CRLs?
How to configure and manage partitioned CRLs in ADSS Server?
I can not download the Delta CRL for Microsoft CA
It is a known limitation in the ADSS Server that it fails to download the CRLs when the CRL file name contains a + sign. You can tune the MS CA configurations so that it doesn't include the + sign in the delta CRL file name. Follow these instructions to make the required configurations in the MS CA:
- Go to the Start Menu > Control Panel > Administrative Tools and launch the Certification Authority
- Right click on the CA certificate node and click on the Properties
- In the Properties dialog, go to the Extensions tab
- For the CRL Distribution Point (CDP) extension, by default a CRL file publishing address is configured like this: C:\WINDOWS\system32\CertSrv\CertEnroll\.crl
- By default the options to publish both the CRL and the delta CRL to above location are selected. Note the variable is the reason why MS CA adds a + sign in the delta CRL file name while it doesn't add any such character in the full CRL file name.
- Remove the default address and add two separate addresses out of which one is for publishing the full CRL and the other is for publishing for Delta CRL. The example addresses are listed below:
- As in the second address listed above, the fixed string "_DELTA" is used instead of the variable "" to avoid inclusion of + sign in the CRL file name as well as CDP URL.
- Apart from the CRL publishing path currently there is a default CRL Distribution Point configured for both the full and delta CRLs like http:///CertEnroll/.crl
- It should also be removed and two new CRL addresses should be added likewise:
http:///CertEnroll/.crl (used as the CDP Extension within issued certificates)
http:///CertEnroll/_DELTA.crl (used as Freshest CRL Extension within the issued CRLs)
- Configure the new CRL URL in the ADSS Server Trust Manager for the respective CA, it will successfully download the Delta CRL.