a caching ocsp proxy
If your servers are configured to do ocsp stapling, the server checks whether or not it has a valid (aka: signed) ocsp response for the requested certificate and, if so, attaches that ocsp-response to its certificate on each client request.
That ocsp response can be and usually is cached by the server. Unfortunately, some server's caching mechanisms aren't meant to survive a server reboot, not even a service restart, and it happens that the server asks for a fresh ocsp response when the cached ocsp response has expired. If, in this situation, the ocsp responder is down (hi, letsencrypt), bad things happen. Worst case: the website is no longer reachable.
ocsp-proxy sits between the ocsp requestor and the ocsp responder, caching both the request and the response in a redis db.
ocsp-proxy is a simple perl-driven http server which accepts ocsp requests, which usually are something like:
POST / HTTP/1.1 Host: ocsp.yourcahere.example:80 Content-Type: application/ocsp-request Content-Length: 123 $asn1encodedocsprequest
and forwards them to the corresponding servers, storing the ocsp response in the database and passing it to the client.
Once in a while (i.e. every 30mins)
ocsp-proxy checks its cache for freshness. It re-requests the ocsp responses from the ocsp responders every day and, if we're past the validity's half time, every hour.
This way we (should) always have a fresh ocsp response in our cache. Yay.
install all dependent perl modules, install redis, take a look at
perldoc ./ocsp-proxy.pl and have fun.
apache httpd use the proxy, add this to your ssl config:
ocsp responses with NONCEs are, for obvious reasons, not cached, neither are requests/responses with multiple certificates. It doesn't really matter, because all ocsp responders I've seen in the wild won't return NONCEs or multiple responses.