> Am 13.06.2017 um 00:48 schrieb Hanno Böck <[email protected]>: > > What I think needs also be handled: > * There's > https://bz.apache.org/bugzilla/show_bug.cgi?id=59049 > which indicates that faulty responses from the OCSP server may bring > the server into a faulty state from which it doesn't recover. I > haven't tried to reproduce this, but it certianly should be fixed as > well, probably just some missing error check tough.
I would expect to catch that with the change in handling responses. If we never replace an existing OCSP response one with an error, the problem should disappear. As I read the code, we currently use the response cache to signal communication errors to other connections to avoid spamming the OCSP responder. If we have only one mod_watchdog thread querying responders, there no longer is need for that, it seems. > * Some of the existing options imho don't make any sense and should > default to off and maybe even be forced off (so that setting them to > "on" doesn't do anything). That includes SSLStaplingFakeTryLater and > SSLStaplingReturnResponderErrors. Unless I'm missing something I > don't see any situation in which stapling OCSP errors is desirable. I think we want any enhancements to be applicable to 2.4.x and there we cannot silently change the defaults. I propose to add a new stapling directive that changes to a different default set for the other ones. SSLStaplingResilience on|off|enforce with "on" and "off" to change defaults to new/old ones. And "enforce" to only allow new ones and log warnings when old are ignored. Something to detect/verify settings in a large configuration.
