Skip to main content
banner image
venafi logo

Intermediate Certificate Authorities to Be Revoked for Revocation Errors [Ironically]

Intermediate Certificate Authorities to Be Revoked for Revocation Errors [Ironically]

image of a young blonde woman in a turquoise blouse looking up in a confused expression
July 10, 2020 | Pratik Savla


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.
 

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?



 

Related posts

 

Like this blog? We think you will love this.
Shot of man's hands folded behind a wooden chess set. Man is wearing business attire.
Featured Blog

How Frequently Should You Rotate PKI Certificates and Keys?

Certificate Validity Periods

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

CIO Study: Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

Machine Identity Protection for Dummies
eBook

Machine Identity Protection for Dummies

About the author

Pratik Savla
Pratik Savla

Pratik is a Principal Security Engineer at Venafi. Formerly the Threat Intelligence Lead at VMware, he is a member of ISACA, ISSA, CSA, The Internet Society and The Electronic Frontier Foundation.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat