SSLTrace
is enabled
ldapsearch -t -D cn=YOURUSERID -L -w YOURPASSWORD -b "cn=YOURISSUERINFO" "(certificateRevocationList=*)" certificateRevocationList\;binary::
SSL_CLIENT_DN=\"%{SSL_CLIENT_DN}e\" UA\"%{User-Agent}i\"
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. 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 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.
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::