Apache 2.3 and later support a feature called OCSP stapling. When enabled a server pre-fetches the OCSP response for its own certificate and delivers it to the user’s browser during the TLS handshake. This approach offers a privacy advantage. But, the main benefit is the browser doesn’t have to make a separate connection to the CA’s revocation service before it can display the Web page. This gives better performance and reliability.
For this pre-fetching to work the web-server certificate needs to contain a pointer to the OCSP responder, this is a best practice and a recommendation of the CA/Browser Forums baseline requirements so it’s almost certain your certificate has it.
Chances are you have a firewall between your webservers and the internet; it’s also likely that firewall disallows outbound connections from your servers unless explicitly allowed. So before you enable OCSP stapling you are going to need to allow your web servers to communicate with the OCSP responder.
To figure out what host and port you will need to open you will need to look at the certificates you use on your webserver; one way to do that is via OpenSSL, for example:
1. Get the certificate using s_client
openssl.exe s_client -connect www.globalsign.com:443
…
…
—–BEGIN CERTIFICATE—–
—–END CERTIFICATE—–
…
…
You need to copy the PEM header and footer (“—–BEGIN/END CERTIFICATE—–“) and the Base64 between them into a file.
2. Identify the OCSP responders within the server certificate
openssl.exe x509 -in globalsign.com.cer -text
…
…
X509v3 extensions:
..
Authority Information Access:
CA Issuers – URI:
http://secure.globalsign.com/cacert/gsextendvalg2.crt
OCSP – URI:
http://ocsp2.globalsign.com/gsextendvalg2
…
…
You need to find the “OCSP – URI” section, in the example certificate above the OCSP responder is http://ocsp2.globalsign.com/gsextendvalg2 there may be multiple responders specified, you should allow your servers to initiate outbound traffic to all of them.
Once your servers can request OCSP responses enabling stapling is very straight forward, there are just two directives that need to be added, these directives can be global or specific to a specific to one instance:
SSLUseStapling on
SSLStaplingCache “shmcb:logs/stapling_cache(128000)”
Their purpose is self-evident; SSLUseStapling turns the feature on while SSLStaplingCache specifies where to store the cache and how big it should be.
There are other directives also you can use but you should not need to worry about them.
As long as you are running the most recent stable versions of Apache and OpenSSL enabling this feature is safe. It is only used when the client supports it so there won’t be compatibility issues and if the server for some reason fails to populate its cache with a valid OCSP response the client will typically fall back to doing a live OCSP request on its own.
Ryan
I wonder if you know how to instruct Apache to use a OCSP responder using a proxy, instead of a direct connection.
I think your looking for:
SSLOCSPDefaultResponder “URL”
SSLOCSPOverrideResponder on
the solution is to set up a small local proxy like tinyproxy on port 8888, which redirects to your “real” proxy in the LAN. Test out that the tinyproxy really works.
Then this iptables rule has to be set up:
iptables -t nat -A OUTPUT -p tcp –dport 80 \! –destination 10.10.10.0/24 -j REDIRECT –to-ports 8888
(In this example 10.10.10.0/24 is the local network that this rule should *not* apply to)
WIth that the oscp stapling requests are being succesfully requested via the proxy chain transparently.
Wonderful, what a web site it is! This webpage gives
valuable information to us, keep it up.