|Summary:||CRL validation fails if CRL is missing|
|Product:||Apache httpd-2||Reporter:||David Sansome <me>|
|Component:||mod_ssl||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
|Attachments:||Add a SSLCARevocationAllowMissing option|
Description David Sansome 2012-04-27 13:53:08 UTC
Created attachment 28688 [details] Add a SSLCARevocationAllowMissing option In Apache 2.3.15 the CRL validation behaviour was changed to fail with an "unable to get certificate CRL" error if a client tried to connect with a certificate that was signed by a CA that did not have a CRL configured. I've attached a patch that adds a SSLCARevocationAllowMissing option to restore the old behaviour.
Comment 1 Ruediger Pluem 2012-04-27 14:50:58 UTC
Why doesn't SSLCARevocationCheck none solve your problem (which is the default value btw)?
Comment 2 David Sansome 2012-04-27 15:10:25 UTC
If I have CRLs for some CAs in the chain but not others then SSLCARevocationCheck none/chain will only let me either allow everything or deny everything - I can't tell it to check the ones that I have CRLs for but ignore the rest. The long answer is that I'm working on an embedded appliance that uses Apache - we want to upgrade it from 2.2 to 2.4, but some users might have already added CRLs to their systems. We could default the SSLCARevocationCheck option to None, which would lower security for the people who were using CRLs, or we could default it to Chain, which would completely lock out people who were using client certificate checking without CRLs. Adding this option back in makes sure we don't break anybody.
Comment 3 Kaspar Brand 2012-04-29 08:26:08 UTC
There's room for improvement with regards to revocation checking settings in mod_ssl, that's true. Re-introducing an additional directive which restores the behavior from 2.2 seems like the wrong approach, however. Making revocation checking optional (like the SSLCARevocationAllowMissing boolean would do) is pretty nonsensical, IMO - either you insist on clients having an unrevoked cert or you don't. Configuring revocation setting options basically amounts to enforcing a security policy - that's why I added a separate CARevocationCheck directive in r1165056 (which no longer relies on the implicit effects of CARevocationFile/CARevocationPath as in 2.2). Instead of introducing yet another directive, we should consider extending the syntax/options of SSLCARevocationCheck. One thing I was thinking about when working on r1165056 was to make revocation checking succeed if the "unrevoked" status can be determined from either the CRL or an OCSP response. Currently, if CRL and OCSP checking is enabled, *both* have to succeed. Finally, let me point out that there's an inherent issue with the proposed patch: if mod_ssl unconditionally ignores X509_V_ERR_UNABLE_TO_GET_CRL errors when "AllowMissing" is enabled, then it's no longer possible to reliably enforce revocation checking for those CAs which do have CRLs (mod_ssl wouldn't complain when the CRL can't be found, it would just silently proceed).