I have noticed this behavior as well. Apache is quiet unless it actually finds revocation of the cert being verified.
Perhaps better would be code that checked that for every trusted CA (via SSLCACertificate*) there is a corresponding CRL and if not, post a warning (or error) in the log (according to your selected revocation check method). I don't see that you would need a new directive except for choosing revocation check method. BTW, are coding it to support more than one method in a preferred order? Such as something like SSLRevocationMethod OCSP CRL meaning, try OCSP first and fall back to CRL (if OCSP timeout). As you can see, I am interested in your patch. regards, tt 317-510-5987 -----Original Message----- From: Matthieu Estrade [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 15, 2004 8:45 AM To: [EMAIL PROTECTED] Subject: modssl - ocsp - crl I'm close to finish the ocsp feature on mod_ssl, but when i look the entire client auth system, there is some little point not really clean. For example, when somebody today setup a SSLVerifyClient require and put CA and CRL, with SSLCARevocationPath, if no CRL is correct inside the path, mod_ssl will not find the good one and will bypass CRL check. What i mean is on a misconfigured system, admin can't know if crl check is active or not. Sometimes, the SSLCARevocationPath directive is used with a little daemon updating CRL. Maybe it's a normal behaviour, but i think it could be more clean to choose the way to say the user is authenticated, via a directive: SSLVerifyClient require SSLCACertificatePath /usr/local/apache/conf/ssl.crt/ SSLCARevocationPath /usr/local/apache/conf/ssl.crl/ SSLVerifyClientMethod +CRL (or +OCSP) or -CRL. In this case, the default could be CA + CRL and block if no valid crl is found -CRL could disable the crl check etc... Regards, Matthieu
