(First see "Things to check first" below.)
GSKit Trace gathered from IHS startup through a CRL validation failure. Should be recreated immediately after IHS startup, to avoid GSKit trace wrap overwriting any traffic before the failure that might have been cached by GSKit. Then copy the GSKit trace to a new file immediately after recreating the problem.
IP trace between IHS and LDAP during a CRL validation failure
Source CRL, any intermediate files used in creating LDIF or loading LDAP, description of process used to load LDAP.
KeyFile for IHS system along with the matching .sth file and KDB password
Full certificate chain for Client Certificate in question, along with Signer Certificate.
ErrorLog during failing CRL connection where LDAP_DEBUG=65535 has been set in the environment,
LogLevel has been set to debug, and SSLTrace
is enabled
Determine the baseDN for your CRL search (Issuer Name or explicit CRL Distribution Point extension in signer cert, or observe via IP trace) and send the temporary output files created by the following command
ldapsearch -t -D cn=YOURUSERID -L -w YOURPASSWORD -b "cn=YOURISSUERINFO" "(certificateRevocationList=*)" certificateRevocationList\;binary::
Add the following string to your LogFormat directives to capture the user-agent and CN of the client certificate:
SSL_CLIENT_DN=\"%{SSL_CLIENT_DN}e\" UA\"%{User-Agent}i\"
If OCSP is being used, an IP trace of the communication between IHS and the responder
The recommended minimum level of GSKit for CRL processing is 7.0.4.27
Verify that the client is providing an SSL certificate on the failing request by adding %{SSL_CLIENT_DN}e to your LogFormat directives.
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.
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:
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 need to be configured, as the GSKit security library does not chase the CRLDistributionPoint extension unless the static LDAP repository is 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.
openssl x509 -in signer.crt -noout -text
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.derWhere /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
ldapsearch -t -D cn=YOURUSERID -L -w YOURPASSWORD -b "cn=YOURISSUERINFO" "(certificateRevocationList=*)" certificateRevocationList\;binary::
If the signing certificate specifies a CRLDistributionPoint extension and SSLCRLHostName is configured, then IHS will always attempt to contact the CRL distribution point specified in the signing certificate, and if it cannot access it, will report that it is unable to verify that the certificate is not revoked, even if it can access the SSLCRLHostname LDAP server.
If the customer configuration is such that IHS will not be able to contact the CRL distribution point, we recommend instead using an internal OCSP server:
Confirm with some other piece of software that your responder is functioning correctly
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.
$ openssl crl -in crl.pem -text|grep "Next Update"
Next Update: Jun 23 10:58:45 2009 GMT
GSKit before 7.0.4.21 can crash with CRL support enabled. Usually affected systems will crash 100% of the time during the first CRL lookup, potentially after the CRL hostname has been changed.
GSKit before 7.0.4.11 suffers from a memory leak during CRL processing