DO NOT REPLY [Bug 45708] CRL verification fails if CA have distinct AKID for CRL and client certificates

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=45708


Markus Wernig <pu...@wernig.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |public@wernig.net




--- Comment #1 from Markus Wernig <pu...@wernig.net>  2008-11-17 04:38:45 PST ---
Confirm + additional info:
- Bug bites as whenever there are 2 or more CRLs to check with the same subject
hash (as given by openssl crl -in file.crl -noout -hash), independent of
lifetime, keyid etc.
- Bug depends on order of CRLs checked. If a client certificate is checked
against a CRL that apache determined applicable for it (most likely by using
the above hash mechanism and looking up accordingly-named files in
SSLCARevocationPath), and if there are more such files, there are two
possibilities:
a) The first file checked is by chance the one signed by the CA key that also
signed the client cert: all OK, verification succeeds
b) The first file checked is by chance signed by another key of the same CA
("same CA" meaning "same subject hash"): mod_ssl seems to compare the issuing
key identifier (AKID) of client certificate and CRL, and if they don't match,
reports the following errors:
[warn] Invalid signature on CRL
[error] Certificate Verification: Error (8): CRL signature failure.

This behaviour seems broken. Apparently, mod_ssl relies on the hash value only
for determining which CRL file to use. This is not enough. In addition, it
should compare the AKID of the client cert and the CRL and only use the CRL if
they match. Thus, it could skip the "wrong" ones until the "correct" one (ie.:
correct hash AND correkt AKID) is found. In case the information is not present
in either one, mod_ssl should probably try to calculate the hash of the signing
certificate's public key.

The "first match wins" algorithm is breaking a lot of CRL checking schemes at
the moment, since nobody is able to check CRLs for CAs in process of renewing
(rekeying) their CAs, which is a process to be expected about every 5 years in
the case of average issuing CAs. With a list of (currently) around 120 CAs in
the NSS CA store, this will lead to one of them being rolled over every 2 weeks
approximately (24 per year for 5 years), creating a failure situation. The only
remedy at the moment is to disable CRL checking for those CAs altogether -
which is most likely not what is inteded.
Actually, I'm pretty confident that next to nobody is able to use CRL checking
coherently because of this.

Please consider changing the CRL matching algorithm in mod_ssl.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org