One of these requirements is specified in clause 4.9.9 with the MUST mark:
OCSP (Online Certificate Status Protocol) responses MUST conform to RFC 6960 and / or RFC 5019. OCSP responses MUST either:
- Signed by the CA that issued the certificates whose revocation status is being checked, or
- Have a signature OCSP Responder whose certificate is signed by the CA that issued the certificates, whose revocation status is checked
In the latter case, the OCSP certificate signing MUST contain an extension of type id-pkix-ocsp-nocheck as specified in RFC 6960.
This rule is violated by almost all certification authorities (CA), which has some consequences.
Here is a screenshot from Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (latest version 1.7.0, May 4, 2020, pdf ):
RFC6960 standard in section 4.2.2.2 defines "OCSP Delegated Responder" by the presence of id-kp- OCSPSigning.
Developer Ryan Sleevi, whose company specializes in working with certificates, has proven that CAs massively violate rule 4.9.9.
After examining the crt.sh data, Ryan Slavy found 293 intermediate certificates without the pkix-nocheck extension, of which 180 are currently valid and 113 revoked.
Filtering on Census.io issues 276 certificatesmatching these conditions.
Thus, these certificates violate the basic requirements of CA / Browser, moreover, mandatory requirements.
According to Ryan Slavy, CAs should take a closer look at the CA / Browser rules. Probably, some CAs are not familiar with RFC 6960 requirements. The
lack of a corresponding extension is not just a formality. There is no problem here in the sense that an intermediate CA cannot revoke the certificate of another intermediate CA from the same root CA.
The real problem is that in the absence of an extension, the intermediate CA can theoretically cancel the revocation of the certificateanother intermediate CA or the root CA itself. This is really a problem. In fact, the certification authority in such a situation does not have a reliable option for complete and irreversible revocation of certificates. The revocation process does not work as expected, which opens the door for attackers who could potentially conduct an attack to restore the revoked certificate.
To fix this problem, it is suggested that when revoking a certificate, permanently delete all copies of the keys so that revocation also becomes irreversible.
To justify the CA, we can say that even without this drawback, the certificate revocation procedure does not work as expected. For example, major browsers maintain their own copies of CRLs — and do not always check that they are up to date. These CRLs contain only basic, most important information, but they are far from complete. For example, Chrome doesn't bother checking to see if each specific TLS certificate has been revoked, whereas Firefox does. That is, sometimes with Chrome you can safely go to a site with an expired certificate, and Firefox will issue a warning and will not let you go there.
Interestingly, according to the rules, incorrect certificates must be revoked in browsers within 7 days, but an exception was made for this situation. Mozilla's Ben Wilson said they won'trevoke certificates with missing id-pkix-ocsp-nocheck extension. Although such certificates are not compliant, the Firefox browser is not affected by this specific security vulnerability because it does not accept OCSP responses signed by intermediate CAs.
CAs should somehow replace the incorrect certificates, but there is no final deadline for them.
For more information about PKI solutions for enterprises , contact GlobalSign managers +7 (499) 678 2210, sales-ru@globalsign.com.