MustGather information for CRL problems

Things to check first

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 SSLCRLHost 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 SSLCRLHost. 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. The order in which the information is used is as follows:

  1. CDP LDAP X.500 name
  2. CDP LDAP URI
  3. Issuer name (the value from the SSLCRLHostname directive).
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.
You can also 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