Microsoft OCSP Responders – Trust, Renewals and RFC 6960

Online Certificate Status Protocol (OCSP) provides an efficient mechanism for distributing certificate revocation information. When certificates are exchanged and validated, computers need to determine if the certificate has been revoked – meaning the CA has reason to consider the certificate as untrusted. This often placed in a Certificate Revocation List (CRL). Clients download this potentially large CRL just to find a small serial number of a certificate to determine if it has been revoked. OCSP on the other hand changes the process to a SQL like process where clients send a secure query to an OCSP Responder (server) and ask if the serial number it is looking at has been marked as revoked. The OCSP server sends a response back – think of it as a bespoke CRL for the client. This OCSP response must be from a trusted sources.

So what exactly is a trusted OCSP response and how do you need to design and manage your environment to support OCSP? This question came up last week and it lead me to two common questions I often face.

Question 1: Given a specific PKI architecture, how many OCSP servers do we need? Do we need 1 OCSP server per CA?

Question 2: How do you handle OCSP signing certificates when a CA is renewed.

So lets start with question one – there are several factors that go into determining the number of OCSP Responders you need in your environment. For this discussion, we are going to ignore issues of performance, availability and network access. We are going to focus on whether we need an OCSP Responder for each CA. Take a look at this diagram:

The question present was “In this diagram – if there was to be OCSP responders – could we just use 1 MS OCSP. I know the OCSP cert is signed from the CA so this leads me to think that there would be a need for atleast 2 ocsp responders linked to the 2x Enterprise CAs. Or would there be a need for 3x ocsp responders – one for each 3rd tier CA?”

In short, the answer is that in a pure Windows environment you could use just a single OCSP Responder. You do not need an OCSP Responder for each CA. However, if you have 3rd party clients that will only trust an OCSP response from a certificate signed with the same keypair as the certificate being examined, you would need a Responder for each CA. So the long answer is, “It depends”.

So where does this question come from? Recall in my overview that I said the Responder creates a bespoke CRL for the inquiring client. This response is signed with a certificate that was issued to the OCSP server. This certificate is trusted for the purpose of signing OCSP responses only. But it must come from a trusted PKI. If you review the RFC for OCSP (http://www.ietf.org/rfc/rfc2560.txt) and look at section 2.2 you will find something interesting (emphasis added)

All definitive response messages SHALL be digitally signed. The key used to sign the response MUST belong to one of the following:

— the CA who issued the certificate in question
— a Trusted Responder whose public key is trusted by the requester
— a CA Designated Responder (Authorized Responder) who holds a

specially marked certificate issued directly by the CA, indicating
that the responder may issue OCSP responses for that CA

What does this mean? It means as long as the OCSP Responder is using an OCSP signing certificate from a PKI we trust, it doesn’t matter which CA issued the certificate. So in the diagram above, if we have a single OCSP Responder, we can issue it a single signing certificate and configure it to act as a responder for any/all of our CAs. To be honest, most offline CAs do not have their CRLs handled by OCSP, but they certainly could if you had a need.

So what’s the rub? RFC 2560 has been superseded and the new RFC 6960 (https://tools.ietf.org/html/rfc6960) which has modified Section 4.2.2.2 Authorized Responders to include:

The CA SHOULD use the same issuing key to issue a delegation certificate as that used to sign the certificate being checked for revocation. Systems relying on OCSP responses MUST recognize a delegation certificate as being issued by the CA that issued the certificate in question only if the delegation certificate and the
certificate being checked for revocation were signed by the same key.

Note: For backwards compatibility with RFC 2560 [RFC2560], it is not prohibited to issue a certificate for an Authorized Responder using a different issuing key than the key used to issue the certificate being checked for revocation. However, such a practice is strongly discouraged, since clients are not required to recognize a responder with such a certificate as an Authorized Responder.

So this scenario will work fine and is in compliance with the RFC even by using a new keypair on the CA. The RFC recommends that you do use the same keypair so that clients will trust it for sure, but Windows will support the response from a trusted keypair that is different.

So with this new found knowledge, question two is a little easier to answer. If we know that Windows supports this provision of the RFC, and that they care only if the OCSP response is from a trusted OCSP signing certificate, then we can extrapolate what happens with a renewed CA certificate. If the client trusts the OCSP signing certificate and that certificate is signed with a keypair belonging to a CA that has been renewed, as long as that keypair is trusted, the OCSP response is signed.

That means we do not need to do anything special in our environment to ensure OCSP Responders will work when there is a CA renewal. Now, it is possible to have third party applications and OSes that insist on the OCSP signing certificate chaining to the same keypair that was used to issue the certificate being examined. But this is largely theoretical and I have never seen it in the live.

So why is this even an issue? Well, Microsoft and other sources have done a poor job communicating this. Tale a look at this Technet article https://technet.microsoft.com/en-us/library/cc754774.aspx that explains a setting called UseDefinedCACertInRequest. It effectively enables a CA to renew an OCSP signing certificate using an old keypair. If you look at your CA, you will even find it warning about OCSP renewals with an Event ID 128 (https://technet.microsoft.com/en-us/library/cc774592(v=ws.10).aspx). You will even find articles explaining to turn on this feature: https://blogs.technet.microsoft.com/xdot509/2013/06/06/operating-a-pki-ca-certificate-renewals-and-ocsp/.

But these articles complicate the issue and make the OCSP signing certificate process more complex. There is NOT a need to enable the UseDefinedCACertInRequest setting unless you have 3rd party OCSP trust issues. So there you have it!