Windows Server 2008 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.
Unlike Apache this feature is enabled by default, it’s possible your servers are already doing OCSP stapling and you do not even know it.
With that said 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 you might need to allow your web servers to communicate with the OCSP responder before it will work.
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 to browse to your current site and view the details of the certificates you are currently using, for example:
The value you want is in the “Authority Information Access” field, you want the ones (there may be multiple) that have the “Access Method” of “On-line Certificate Status Protocol”.
Once these two conditions are met OCSP Stapling will “Just work” there is nothing else you need to do.
Ryan
Pingback: A look at the new Windows Update SSL certificates
Pingback: Administrator Ike » Microsoft Achieves World Domination (in OCSP Stapling)
Is there anyway to verify that OCSP is functioning properly? Check this : http://unmitigatedrisk.com/?p=100