Dirk-Willem van Gulik wrote: > > On Aug 28, 2008, at 9:41 PM, Nicob wrote: > >> Hello, >> >> I'm actually trying to setup a SSL reverse-proxy based on Apache 2.x and >> mod_ssl and it seems there's a bug in the verification of the CRL. >> >> If a CA changes its keys before expiration, the CRL is now signed by the >> new key and include certificates issued by both the new and old keys. >> However, mod_ssl will refuse to work if the AKID of the revoked >> certificate doesn't match the issuer of the CRL. >> >> Browsing Apache archives, I found that somebody posted a patch covering >> this need (http://marc.info/?l=apache-httpd-dev&m=120350484626015), but >> the code haven't been merged. I tested it and it works perfectly well. >> >> Does this patch seems OK to you ? If yes, is it possible to include it ? > > I just tried that patch - and it also matched two of my edge cases. > > But this is a bit too obscure for me to dare to commit it directly. > Could someone else with a good x509 understanding look at it ? > > +1 from me - willing to do the legwork if someone else gives this a good > review as well. > >
While I haven't reviewed this specific patch I have a general comment. There is currently some questionable behaviour in mod_ssl CRL handling. For example it ignores critical CRL extensions, whereas OpenSSL either processes them (if they are recognised) or rejects the CRL (if they are not). This is required by RFC3280 and not doing so raises some security issues. IMHO it would be best if mod_ssl delegated CRL handling to OpenSSL by setting the necessary verification flags instead of duplicating functionality. In the past mod_ssl didn't have much choice but to do it's own thing because then OpenSSL CRL handling was either absent or broken. Things are rather better now. The 0.9.9-dev version of OpenSSL is compliant with all the RFC3280 PKITS tests for example. The 0.9.8 handling isn't quite so complete though. If the OpenSSL CRL handling needs to be made more mod_ssl friendly I'd be happy to coordinate changes to OpenSSL. Steve.
