MustGather information for CRL problems

Things to check first

CRL uploaded under wrong baseDN

As of GSKit version 7.0.3.17, CRL checking will follow the URIDistributionPoint field in the Client Certificate as well as trying the DN constructed from the issuer of the client certificate
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). A value specified for SSLCRLHostname will only be used if the certificate does not contain any useful values. The SSLCRLHostname directive is a last resort value.
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=test,c=US
objectclass: pkiCA
objectclass: crldistributionpoint
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

ldapsearch -t -D cn=YOURUSERID -L -w YOURPASSWORD -b "cn=YOURISSUERINFO" "(certificateRevocationList=*)" certificateRevocationList\;binary::

Configuration Issues