MustGather information for CRL and OCSP problems

Things to check first

No client certificate provided

Verify that the client is providing an SSL certificate on the failing request by adding %{SSL_CLIENT_DN}e to your LogFormat directives.

CRL uploaded under wrong baseDN

Prior to GSKit version 7.0.3.17, the only place a CRL is searched for is on the configured SSLCRLHostname with a "base" equal to the DN of the issuer of the certificate being checked.

CRLDistributionPoint support

For GSKit version 7.0.3.17 and later, If an issuing certificate contains the CRLDistributionPoint extension it will be searched for a CRL before the server specified by SSLCRLHostname. The userid and password specified via SSLCRLUserID and SSLCRLStashFile are not used when connecting to servers specified this way in the certificate chain.

If the certificate contains CDP (CRL Distribution Point) that information is given precedence. Certificates which do not contain a CRLDistributionPoint extension must pass CRL checking against the locally configured LDAP Server (SSLCRLHostname), i.e. IHS cannot exclusively use the CRLDistributionPoint and perform no CRL checking if it's absent. The order in which the information is used is as follows:

  1. CDP LDAP X.500 name
  2. CDP LDAP URI (For GSKit 7.0.3.31 and later, file:// and http:// CDP's are also followed)
  3. The DN of the certificate issuer combined with the values of SSLCRLUserID, SSLCRLStashFile, and SSLCRLHostname

If all of your certificates are issued by certificate authorities that provide an LDAP or X.500 CRL link in their certificates, SSLCRLUserID, SSLCRLStashFile, and SSLCRLHostname do not need to be configured.

If you perform an IP trace between IHS and LDAP, a tool like ethereal will show you the baseDN and search filter used by the certificate checking code.

Checking certificate for CRL Distribution Point (CDP) extensions

You can use a tool like ikeyman or openssl to display the CDP or Issuer name from the signer certificate:
openssl x509 -in signer.crt -noout -text

LDIF created from DER encoded CRL

By default openssl will create PEM (base64 encoded text with header and footer) CRLS, but if you feed these into LDIF you end up with your data being base64 encoded twice. If you're creating an LDIF to load your LDAP system, make sure the CRL is in the binary DER format.

An example LDIF:

dn: cn=testCA,o=myorg,c=US
objectclass: cRLDistributionPoint
objectclass: pkiCA
objectclass: entrustNamedObject
caCertificate;binary:< file:///tmp/CA.der
certificateRevocationList;binary:< file:///tmp/crl.der
Where /tmp/crl.der is a DER encoded CRL and can be processed by commands such as openssl crl -inform DER -in /tmp/crl.der -text

LDAP user not authorized to download CRL

Configuration Issues

SSLOCSPResponderURL dos not point to a valid responder

Confirm with some other piece of software that your responder is functioning correctly

OCSP responder is ignored

Make sure GSKit 7.0.4.11 or higher is installed, with some levels after 7.0.3.27 but before 7.0.4.11 OCSP is not processed correctly.

Confirm that CRL is not expired (Next Update: field)

$ openssl crl -in crl.pem -text|grep "Next Update"

Next Update: Jun 23 10:58:45 2009 GMT