On Wed, Sep 16, 2009 at 01:45:30PM +0100, Joe Orton wrote: > On Wed, Sep 16, 2009 at 01:38:50PM +0100, Dr Stephen Henson wrote: > > I may have missed something here but the OCSP stapling code doesn't appear > > to be > > in trunk. The patch in: > > > > https://issues.apache.org/bugzilla/show_bug.cgi?id=43822 > > > > doesn't apply cleanly any more, though the changes needed to get it working > > are > > fairly trivial. I'm in the process of including an updated patch. > > I'm working on merging this right now, your patch did apply fine, I've > committed the one part separately which you alude to below.
I finally got round to finishing this off, holidays and similar excuses now out of the way. First of all: thanks a lot for the patch, and sorry it took so long to merge! I made a few changes relative to your latest patch: - minor syntax/style cleanups - renamed the new C file to ssl_util_stapling.c - updated the handling of "SSLStaplingCache" as per changes to "SSLSessionCache", to allow "SSLStaplingCache default" to DTRT - moved up the call to ssl_stapling_ex_init() so it took effect before the ex_data index was used and have two questions: 1) the use of an ex_data structure attached to the X509 * to store the stapling-specific state seems unnecessary. Was there a reason why you did this rather than simply extending the modssl_pk_server_t structure? (The ex_data indices have historically been a nightmare with mod_ssl due to the fact that OpenSSL might get unloaded from memory during startup, and any cached copies of the index values outside of OpenSSL may or may not be reliable. Global state == bad!) 2) the error case where there's no SSLStaplingForceURL configured and no responder specified in the cert - this is currently logged but no more. I'm wondering whether this should be an ssl_abort(); if someone enables stapling for a vhost but there is no responder known, it seems like that should be a config error? I've done basic testing using openssl s_client/ocsp as client/responder such that I can see an OCSP response being passed through, but it didn't seem to get cached correctly which I haven't looked into further (maybe I broke that with my changes). Regards, Joe
