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