It was reported recently that due to a technical flaw, it is possible for some Certificate Authorities (CAs) to create valid OCSP responses for certificates that they did not issue and do not control. This creates an issue for the CAs that operate and maintain these certificates.

While this is a complicated issue, this blog will help you determine the impact for different situations. Before we get started in the details, let’s take a look from the top down.

Why do delegated responders exist?

Delegated responders exist to create OCSP responses (i.e., the responsibility to create responses is delegated to them) on behalf of their parent. For example, if you want to use a content delivery network (CDN) to create and deliver OCSP responses, you probably don’t want the parent key in multiple datacenters.

What is a delegated responder?

A delegated responder is an OCSP responder that uses the delegated responder certificate instead of the parent certificate. Originally, OCSP responses were signed directly by the parent of the certificate, instead of using delegated responders.

How do they work?

An OCSP responder certificate (a delegated responder certificate) is a certificate that can only sign OCSP responses on behalf of its parent. You would use that certificate on your CDN instead of the more valuable parent.

The way to tell if the certificate is able to act as an OCSP responder certificate is if it has the OCSPSigning EKU.

EKU chaining

EKUs originally only existed in end-entity certificates. However, some folks found it useful to constrain intermediates to only issue certain types of certificates by putting all possible EKUs for end-entity certificates in the intermediate certificate. This works well for EKUs that specify end-entity certificate use cases (e.g., code signing, email protection), but not so well for EKUs that give the certificate itself new capabilities (e.g., OCSP signing).

For example:

An intermediate CA that issues certificates that have either the serverauth or clientauth EKUs or both, would have both the serverauth and clientauth EKU. The intermediate has all the combinations of the union of the EKUs of the end-entity certificates.

Because of this, some CA software insists that if a certificate contains an EKU, then the parent must also contain the EKU.

Accidents often happen at intersections

What happens at the intersection of Delegated Responder Street and EKU Avenue? It is tempting to put the OCSP signing EKU onto the parent of the delegated responder to satisfy EKU chaining; however, that gives the parent the technical capability to act as an OCSP responder for its parent. This is the error that can create problems.

The correct thing to do is to not put the OCSP signing EKU on the parent. Exactly how to do this depends on your CA software and can require some hacks to make the software not complain about the EKU chaining.

The erroneous certificates

With this background on the tech and the error, here are the implications of the erroneous certificates:

Anyone who has access to the private key of an intermediate certificate that has the OCSP signing EKU can create valid OCSP responses for any of that certificate’s siblings. When the same group or organization operates both, there is no security impact because that group can directly create the same OCSP responses using the parent. However, if the siblings are owned by different organizations, then one organization can create valid OCSP responses for the other. This could allow them to make a third-party believe that the other party is either revoked or un-revoked.

Note that the only people who can do this are people who have access to the private key of one or more of the affected intermediate certificate authorities. In most cases, these private keys are also able to issue new certificates that would be trusted by browsers. For that reason, these keys are kept in military-grade hardware security modules and unlikely to have been compromised by external parties (if they were, there are problems much bigger than potentially forged signatures on OCSP responses).

Wrapping it up

In some circumstances, the presence of the OCSPSigning EKU on an intermediate CA can create unforeseen security issues.

Most DigiCert certificate hierarchies are unaffected, since DigiCert itself does not use delegated responders; however, some of our partners and customers do.

For current info on this, see the DigiCert MDSP post for our action plan.

Call to action

Operators of certificate infrastructures should search their hierarchies for ICAs that contain the OCSPSigning EKU, carefully examine the severity of the situation, and develop a plan to transition to correctly issued ICAs.