I'd like to filter/reroute OCSP traffic from regular HTTP traffic to a different back-end. Reviewing Network Analyses of OCSP protocol, if the OCSP request is via POST, I can filter on Content-Type: application/ocsp-request
. The tricky part, is if the OCSP request is via GET, where the OCSP request is DER->Base64 encoded->urlencoded
and appended to the uri. While the PDF does state, you can create a regex on unique values, if you know what's in the request. It becomes cumbersome if you have a lot different certificates.
There are few reasons why I like to do it this way:
- Currently, my OCSP uri point to http://ocsp.example.net:6139. On some networks, that port can be blocked.
- I like to have both CRL and OCSP uri pointing to the same location.
Regarding GET requests, the only solution I could muster is to let it pass to the back-end, if it's a 404, proxy it again to my OCSPd daemon. Although, most examples I've seen in the wild suggest setting up a dedicate unique domain for OCSP request which defeats point 2.
What anyone would suggests would be the better solution to solving this problem?
server {
listen 0.0.0.0:80;
server_name ocsp.example.net;
location /.well-known {
autoindex on;
}
location / {
error_page 418 = @ocspd;
if ($content_type == "application/ocsp-request") {
return 418;
}
proxy_pass https://192.168.101.30:443;
include proxy_params;
}
location @ocspd {
proxy_pass https://192.168.101.19:6139;
include proxy_params;
}
}