Welcome to the Hardenize blog. This is where we will document our journey as we make the Internet a more secure place and have some fun and excitement along the way.
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.
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
id-kp-OCSPSigning EKU. OCSP signers should be used for that single
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
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:
If a CA does not want a certificate to be used for signing OCSP responses on its behalf, it must do the following:
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.
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.
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.