https://bz.apache.org/bugzilla/show_bug.cgi?id=60182
--- Comment #11 from gmoni...@gmail.com --- So, then we have to accept that OCSP stapling in 2.4 mod_ssl is fundamentally broken? I spent some more time looking at the mod_ssl stapling code. Unfortunately this did not improve my outlook of finding a robust stapling config for 2.4. I had somewhat adopted the feeling that running with `ReturnResponderErrors off` and `FakeTryLater` would be a configuration that was nearly *good*. Just fix the sending out of a TryLater if the OCSP responder was not reachable and it stays up when the OCSP responder is blocked from answering and all clients that I know of can reach the site and actually show it to the user, unless they have set it to mandatory revocation checking and the client locally also cannot find another source of revocation info. However, I have now noticed that if you run with `ReturnResponderErrors off`, then if a OCSP responder answers with a authoritative revocation, then it is handled by the code as if it was an error that needs to be suppressed, and it stops the revocation from reaching the client. Well............ That means running with responder errors of, becomes pointless. If you never return a revocation, then it is completely useless. So for 2.4 mod_ssl, two things must be fixed. Not send out a faketrylater AND NOT keep perfectly good revocations from going out. And sending out responses that can't be parsed as basic OCSP responses should also be stopped. For the hosting operator with a run of the mill production server, this leaves little options. Running with `ResponderErrors off` means that cosmetically it ticks the security boxes of delivering OCSP stapling, but it will never send out revocations it received, cache an outage unnecessarily long and dupe Firefox users when the OCSP responder is blocked. Running with `ResponderErrors on` means that an OCSP responder that is blocked from responding also delivers a much less responsive website because for each new TLS connection it will try again to get an OCSP response cached. And in both settings, it will also return OCSP responses that can't be parsed by openSSL at all. So, for the moment the hosting operator with Apache can only look to external OCSP caching proxies, to have meaning OCSP stapling, until such moment that mod_md becomes available in 2.2 or higher. And incidentally, if I look at trunk, the situation is not improving. In trunk, a renewal failure will be translated into a TLS Fatal hangup. So, if you run with OCSP stapling enabled with just mod_ssl then if an OCSP responder is unreachable or produces garbage just when the cached response expired, then from that moment until an OCSP response becomes available, NO client will be able to reach the site. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
