Blog

A number of intermediate CA certificates will be revoked because they were issued incorrectly. This means that all of the certificates issued by these CAs will no longer be trusted. If you have one of the affected certificates in production, you should plan to replace them as a matter of urgency. This issue was first reported by Ryan Sleevi on July 1st; according to the Baseline Requirements, the CAs are obliged to act within 7 days.

What went wrong?

When a system checks the revocation status of a digital certificate, it typically makes use of something called an OCSP token; this is a signed piece of data from the certificate’s issuing authority which contains the revocation status of the certificate at a particular point in time.

The CA can use the same key to sign OCSP that it uses for signing certificates but there are situations where this is not desirable. In these cases, the OCSP specification allows for a CA to delegate OCSP signing to an OCSP responder by issuing a certificate with a special attribute; the id-kp-OCSPSigning EKU. OCSP signers should be used for that single purpose; signing OCSP.

There is an additional requirement for delegation; the CA/B Forum Baseline Requirements specify that these certificates “MUST contain an extension of type id-pkix-ocsp-nocheck”. This is because an OCSP signer must not be valid for checking its own status—otherwise, in the event of key compromise, an attacker could just sign their own “valid” OCSP token even after the authority has revoked the certificate.

To summarise, if a CA wishes for a certificate to be used for signing OCSP responses on its behalf, it must to do the following:

• Set the id-kp-OCSPSigning EKU
• Include the id-pkix-ocsp-nocheck extension

If a CA does not want a certificate to be used for signing OCSP responses on its behalf, it must do the following:

• Leave the id-kp-OCSPSigning EKU unset

The incorrectly issued certificates had the id-kp-OCSPSigning EKU set but were not intended by the issuing CA to be used for signing its OCSP responses. None of these certificates have the id-pkix-ocsp-nocheck extension present (and therefore violate the CA/B Forum Baseline Requirements).

Many of these certificates were for organisations other than the issuing CA meaning that the issuing CA had inadvertently given another organisation the ability to sign OCSP responses on the CAs behalf.

What are Hardenize doing about this?

While the situation is still developing, we are notifying those customers that may be affected by the revocation of misissued CA certificates. We have updated our platform to highlight the affected certificates in the certificate inventory. We will continue to provide updates as more information becomes available.

Additionally, we have extended our assessment to warn about certificates issued from the misissued intermediates. At the time of writing, the warnings can be observed on the report for microsoft.com, for example.

What should you do?

If you are affected, it's best to renew these certificates early, avoiding any potential issues with availability down the line. You should reach out to the CAs that issued the certificates to find out what they're planning to do and when.