Provide feedback on the IBM HTTP Server forum on IBM developerWorks.
Verify that the client is providing an SSL certificate on the failing request by adding %{SSL_CLIENT_DN}e to your LogFormat directives.
One reason for an undetermined revocation status over OCSP, on a seemingly valid OCSP response, is the complicated trust model of who may sign the OCSP response for a given certificate.
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.
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
For GSKit version 7.0.3.17 and later, If an issuing certificate contains the CRLDistributionPoint extension (CDP) 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 a CRLDistributionPoint extension (CDP) that information is given precedence over the statically configured LDAP server (SSLCRLHostname). 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 described in the FAQ topic: 'What is the precedence order for using the various mechanisms for obtaining certificate revocation information?'
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
SSLCRLHostname
to skip checking of the
statically configured LDAP server, but still check CRL Distribution Point when present.
When this option is used, the revocation status of a certificate whose signer has no CRL Distribution Point is undetermined.
CRL over HTTP is limited to 200KB by default. The size can be overridden, in bytes, by environment variable GSK_HTTP_CDP_MAX_RESPONSE_SIZE
GSKit doesn't cache CRL's by default. The internal GSKit CRL cache can be activated by setting native environment varibales in $IHSROOT/bin/envvars such as export GSK_CRL_CACHE_SIZE=10000 (number of entries).
The CRL cache only caches statically configured LDAP CRL's and HTTP forms of CRLDistributionPoint (the latter in V8 and later). The CRL cache is deprecated in GSKit v8 and has never been exposed by IHS directly.
Generally, someone asking about CRL caching should instead be using OCSP.
SSLUnknownRevocationStatus
comes into play. GSKit caches CRL data for the smaller of 12 hours or the "next update time"
encoded in the CRL itself.
Yes, GSKit also expires cached CRL's every 12 hours, in addition to the "next update time" encoded in the CRL itself
The revocation information will be obtained with the following precedence (assuming each is defined and enabled), processing stops at the first source which has a non-expired response:
OCSP responder
SSLOCSPResponderURL
directive
OCSP responder
SSLOCSPEnable
.
CLRDistributionPoint LDAP X.500 name
SSLCRLHostname
, SSLCRLPort
.
SSLCRLHostname
= "URI"
CLRDistributionPoint LDAP URI
SSLCRLHostname
, SSLCRLPort
.
CRL database on LDAP Server
SSLCRLHostname
, SSLCRLPort
,
SSLCRLUserID
, and SSLCRLStashFile
directives. Not used when SSLCRLHostname
= "URI"
SSLCRLHostname
) when CRL is configured?SSLCRLHostname
is checked for connectivity at startup, once per SSL virtualhost
it is configured in.
The following server contacts occur if there is no CRLDistributionPoint defined in the cert, or if a CRLDistributionPoint is defined but can't be accessed, or it returns out-of-date information. They do not occur if a CRLDistributionPoint is defined in the issuer cert and GSKit recieves unexpired data from it:
No, it exists only in memory and is local to each IHS child process.
No, only when a certificate is being checked for an actual handshake.
Since the cache lives independently in memory in each IHS child process, a restart of IHS or graceful restart of IHS will clear the CRL cache.
When IHS is configured to consult LDAP for a CRL, it will also follow CRLDistributionPoint URL's in the certificate chain itself, so this other source of revocation info is being considered (before CRL in the hard-coded LDAP)
OCSP is strongly recommended over CRL, as the loading and parsing of large CRL's can become a source of delay. It is normally administratively easier to frontend your legacy CRL with an OCSP server rather than an LDAP server. OCSP was introduced as the successor to CRL-over-LDAP.
IBM HTTP Server does not use an OCSP cache
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
Provide feedback on the IBM HTTP Server forum on IBM developerWorks.