![Intermediate Certificate Authorities to Be Revoked for Revocation Errors [Ironically] - cover graphic](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2Fdf9ea4c4-05ab-4b8e-8bd4-fe7c41352a7c%2Faid_field_img__25f067eaa70af6601201aaa19d01b40e.png%3Fw%3D864%26h%3D370%26fm%3Dwebp%26q%3D75%26fit%3Dcrop&w=3840&q=75&dpl=dpl_H1HoLru8zbnj4wwarzUVadLRmxGZ){kind=small}
Early this month security researcher, Ryan Sleevi reported that a number of intermediate Certificate Authority (CA) certificates were issued incorrectly. While nominally, these certificates appeared to be intended as issuing CAs, they could be used as OCSP Responder Certificates. According to Sleevi, “in the cases where a third-party, other than the Issuing CA, operates such a certificate, the Issuing CA has delegated the ability to mint arbitrary OCSP responses to this third-party!”
According to CA/B Forum rules, these intermediate CA certificates should be revoked within 7 days. However, because revoking the intermediate CA also invalidates all certificates that have been issued by that CA, the impact is exponential. In fact, DigiCert announced that on Saturday, July 11, it will revoke tens of thousands of encryption certificates issued by intermediaries that were not properly audited. So organizations may be forced to rotate large numbers of certificates in a very short timeframe.
Hardenize explains the problem in simple terms:
“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.
SSL/TLS Certificates and Their Prevalence on the Dark Web
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.”
The potential impact of this error, according to Hardenize, “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.”
Revocation alone may not be enough to fix this problem.
Sleevi noted that “this Sub-CA COULD provide OCSP for itself that would successfully validate, AND provide OCSP for other revoked sub-CAs, even if it was revoked. That is, if this Sub-CA's key was maliciously used to sign a GOOD response for itself, it would be accepted.”
Also, here’s some additional impact that I’m seeing given the severity of mis-issued certificates in this case. Besides being in compliance with the CA/B Forum Baseline Requirements for OCSP signing on a CA’s behalf, certificates marked with the id-pkix-ocsp-nocheck extension are also pivotal players when it comes to setups that involve the usage of an authorized responder (delegated by the CA) for OCSP signing but which are also plagued by a well-known issue. Even though this setup is considered quite scalable and maintainable, it also has a tendency to cause a circular dependency problem where the relying parties (clients) may want to determine the revocation status of the responder certificate before accepting the signature of the OCSP response. A certificate marked with this extension would help in such instances as it will indicate to relying parties / clients to not attempt that determination.
Organizations may also use certificates with such extensions for scenarios where a TLS certificate needs to be deployed on a centralized server to help mitigate load issues.
Take key compromise seriously
Additionally, in this responder setup, the responder's key is a highly critical component and so any compromise of it needs to be taken as seriously by a CA as the compromise of a CA key used to sign CRLs—at the very least for the validity period of the certificate. This also makes it logical that the OCSP signing certificate normally has a short duration but it also means the certificate needs to be renewed frequently.
Now a scenario that has been seen in the past and could also arise is where browsers do not consider the id-pkix-ocsp-nocheck extension in the decision-making process to determine whether to trust an OCSP responder. This could have disastrous consequences as it could lead to an incorrect decision to accept a compromised and revoked certificate due to the rejection of “Revoked” and even “Unknown” certificate status codes that the OCSP responder returns in its signed response. The “Unknown” status code would mean that the responder is unable to answer the request for any reason such as for example not being clear about the CA that issued the certificate, etc. This could further open up a possibility for any remote attacker to obtain any potentially sensitive information through the means of network sniffing during a session.
No one knows when a situation like this will occur. So organizations need to be prepared to quickly rotate any certificates that are found to be compromised or non-compliant. It’s the best way to minimize risk and avoid the impact of invalidated certificates.
How quickly can your organization replace large numbers of certificates?
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related posts