Here is the OCSP Architect Diagram: Here are the guides I used to setup OCSP:
Microsoft Certificate Services Configuring OCSP
OCSP High Availability
Some Questions I came to when setting up OCSP:
Why OCSP HTTP instead of HTTPS?
The CRL's and also the OCSP responses are signed by the CA. This means any kind of manipulation will already be detected even if the CRL or OCSP response is transferred using an insecure transport. Thus the protection against tampering which is offered by https is not needed. The “chicken and egg” problem Tom mentioned in his comment on Steffen's answer is that using HTTPS to check for CRL/OCSP responses when wiring up HTTPS connections would create an infinite loop of HTTPS connections which in turn have to check for CRL/OCSP responses. OCSP over HTTPS is technically non-working solution, because it requires a SSL certificate that is ussued by a another authority, because SSL certificate MUST be checked for revocation. If SSL cert is issued by the same authority as certificate being checked, then you will never reach OCSP service. When usin 3rd party certificate, you will be redirected to a OCSP service provided by a 3rd party authority. If 3rd party OCSP uses SSL, then you are starting over, another authority must be used to provide SSL certificate and this will lead to a infinity request sequence. Thereby, OCSP over HTTPS is really bad solution. Not sure, but apparently CryptoAPI will permanently fails facing SSL handshake request during OCSP query. And the document you provided is about nothing. There is no security risk if someone changes OCSP response by removing response data and modifying it to tryLater status. In any cases when status is not Successful, OCSP service is considered unreliable and revocation provider will move to another OCSP service (that is specified in the AIA extension) or fall back to CRL.
https://security.stackexchange.com/questions/118101/is-using-http-for-ocsp-a-potential-vulnerability https://stackoverflow.com/questions/13336695/ocsp-over-ssl-tls https://social.technet.microsoft.com/Forums/office/en-US/c65e1784-39be-4732-a135-bfba7446ad05/should-the-ocsp-responder-service-be-running-http-80-or-https-443-?forum=winserversecurity
1) You will place the OCSP server itself in the DMZ and create firewall rules to allow: – Domain Membership in the uw.loc domain ( to allow enrollment of the OCSP certificates from the internal CA) – internal access to the OCSP server using TCP 80 (HTTP) – External access from the internet to TCP 80 (HTTP) 2) You will place the OCSP server on the internal network, and place a load balancer in the DMZ (or publish using a product like ISA) – Need to publish TCP 80 from Internet to load balancer – Need to publish TCP 80 from the internal network to the load balancer https://social.technet.microsoft.com/Forums/lync/en-US/e8e3cb56-bfb9-4bab-91b5-de7747361fbb/ocsp-in-dmz?forum=winserversecurity
How to setup OCSP Web Proxy inside DMZ for OCSP Internet Access?
Microsoft Application Request Routing 3.0 (x64)
https://www.microsoft.com/en-us/download/details.aspx?id=47333 https://blogs.sap.com/2014/11/05/how-to-configure-iis-arr-application-request-routing-to-redirect-to-tomcat/ https://support.qlik.com/articles/000043332
If you are on Azure environment, the best and easiest solution is to use Azure App Proxy for OCSP internet access:
Azure App Proxy
Basics about certificates:
Certificate Chaining Engine — how it works
Designing CRL Distribution Points and Authority Information Access locations
Microsoft OCSP responder multiple ca
The OCSP signing certificate can come from one issuing CA or from each individual issuing CA. The MS implementation does not require that the OCSP signing certificate come from the same CA, but must chain to a trusted root CA on the clients
OCSP external / internet