Error: Invalid cannot read certificate revocation list

  • 7005790
  • 20-Apr-2010
  • 13-Feb-2017

Environment

GeoTrust 3rd-party certificate
ConsoleOne 1.3.6h
Apache 2.0.52
Apache 2.0.63
eDirectory 8.7.3
eDirectory 8.8

Situation

Error: Invalid cannot read certificate revocation list
Apache not listening on port 443.

Resolution

Ask the 3rd-party certificate provider for a certificate without a Certificate Revocation List (CRL) or with a CRL that is properly extended.  The former isthe easiest to determine if an incorrect CRL DP is being used.

Open or import the .cer file from the 3rd-party certificate provider.  In either Firefox or Internet Explorer (IE) it is possible to view the Certification Path which shows the root certificate that the 3rd-party certificate refers to for trust purposes.  With the customer's certificate the root certificate was "Equifax Secure Certificate Authority" which is present in major browsers today under the browser's security settings.  This root certificate, however, has a Certificate Revocation List which cannot be found because this is the wrong type of certificate.  There are two certificates that are valid from Equifax and they are named "Equifax Secure eBusiness CA-1" and "Equifax Secure Global eBusiness CA-1".  These are GeoTrust certificates in this example.

The fix was obtained by requesting a new certificate from the proper root certificate from the 3rd-party certificate provider.  With this new certificate ConsoleOne and iManager validated the certificate and Apache would start properly.

Although the validation fails using either ConsoleOne or iManager, it does not necessarily mean that the certificate will not work provided the customer is willing to accept lower security.  This certificate may be used provided that clients, e.g. browsers,  are either configured so that they do not check the server certificate's CRL (less secure) or ignore this type of CRL DistributionPoint.  If you do configure the browser to not check the CRL, that is less secure and not compliant with RFC 2459/3280 -- See RFC 3280 Section 6.3 and 6.3.3.a.   So it is up to you to decide if this is acceptable for your environment.


Additional Information

The certificate sent from the certificate provider had a link to its trusted root certificate which had extensions for an X.509 certificate.  Many clients and servers will ignore this type of error but some applications validate the certificates properly and, in doing so, will error in these situations.  The problem is that, while SSL certificates can have various types of extensions, they need to have HTTP extensions to work properly with any validating application, server or client (Apache, or ConsoleOne/iManager).  The trusted root certificate referenced by the 3rd-party certificate had incorrect X.509 extensions (not HTTP).  These types of certificates work for individual trees but do not work properly across the Internet because they are directory or tree specific.  The server or client tries to validate the certificate in your local tree which almost-completely defeats the purpose of a 3rd-party certificate when it comes to trust and usually fails because your tree is not the 3rd-party CA.
Some certificate providers will send a trial certificate to make sure that the customer's system will work with that certificate.  This may be a worthwhile option to ensure that certificates are working properly with your system before spending money and possibly having the solution fail because of invalid certificates.
List of Equifax (and other) Trusted Root Certification Authorities. The one highlighted was eventually used to generated a proper certificate.  This view is available inside Internet Explorer or Firefox under the certificates section:

Details of the invalid certificate showing the Certificate Revocation List Distribution Points.  One way to resolve the error was to have a certificate without this property and whose root certificate (see above) did not have this property.

View of the certification path when opening the 3rd-party certificate.  The selected certificate is the 3rd-party certificate and the one above it is the root certificate.  In this case the root certificate was not valid for a web server because of its extensions including the CRL Distribution Points property (see above).

A valid CRL DP would look like the following from Entrust; notice how it has a URL referring to the Internet against which a client or server can request validation information for the certificate in question:


Formerly known as TID# 10100089