Check intermediate CA certs for revocation

NEW
Assigned to

Status

P2
enhancement
17 years ago
a year ago

People

(Reporter: julien.pierre, Assigned: alvolkov.bgs)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
If an intermediate CA certificate gets compromised and is listed in a CRL or
there is an OCSP responder, we don't check them. Only the leaf cert is checked
for revocation.
(Reporter)

Comment 1

16 years ago
This only applies to OCSP. The CRL is checked at all levels of the chain.
Summary: CERT_VerifyCert only checks revocation status for the leaf certificate → CERT_VerifyCert only checks OCSP status for the leaf certificate
This requests a change to the defined function semantics.  
There has been much discussion about this.  Perhaps an option is needed 
to select leaf-only or leaf-and-intermediate checking.  
Severity: normal → enhancement
Priority: -- → P2
QA Contact: bishakhabanerjee → jason.m.reid
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
(Assignee)

Updated

12 years ago
Assignee: nobody → alexei.volkov.bugs
Target Milestone: --- → 3.12
(Assignee)

Updated

12 years ago
Whiteboard: PKIX
Summary: CERT_VerifyCert only checks OCSP status for the leaf certificate → Check intermediate CA certs for revocation
Whiteboard: PKIX

Comment 3

11 years ago
Checking all checkable attributes of each certificate in a certificate chain is REQUIRED SECURITY, and always has been.  If some idiot forgot to do so in the OCSP checking code, that is an exploitable security bug, not something to introduce a new insecurity option for.

Step by step exploitation example:

1. Provoke the destruction of any one of the hundreds of trusted intermediary CAs, including a forced (self-)destruction of its private key.

From this moment on, no OCSP-responses (positive or negative) can be issued for certificates issued by this intermediare CA, but the issuing root CA can revoke the entire Intermediary CA with a single entry in its root-level OCSP backend database.

2. Compromise any certificate issued by the dead Intermediate CA.  This may be made easier by the fact that the upstream root CA has effectively revoked all such certificates by revoking the intermediary CA, thus prompting cert holders to consider those certs and their private keys as "dead".

3. Use the compromised, indirectly revoked, certificate to set up fake sites, man-in-the-middle attacks etc. etc. Mozilla-based products with this bug will not detect that the certificate is revoked because they only check the non-response from the dead Intermediarey CA, not the "intermediary revoked" response from the root CA.

Updated

10 years ago
Duplicate of this bug: 423665
Unsetting target milestone in unresolved bugs whose targets have passed.
Target Milestone: 3.12 → ---

Comment 6

7 years ago
Just to be clear: Julien's comment "The CRL is checked at all levels of the chain." is incorrect. I have a test case that demonstrates that the CRL of the intermediate CA is *not* automatically checked; it's checked only if I manually import the CRL.

I think it's very important for CAs to have the power to revoke an intermediate CA and have that immediately detected by the browser without a code update.

Here's a test case: https://ssltest30.bbtest.net. The end-entity cert is valid, the intermediate is revoked and it contains a CDP.

-Rick
(Reporter)

Comment 7

7 years ago
Rick,

Comment 1 was made in 2002 and refers to the legacy PKI code, which did not support CRL DP. In that context, if the CRL for every CA in your chain was manually imported to your NSS database, then NSS would check the validity of every cert against those local CRLs. This may not work well for a browser context where the client's cert chain, but it can somewhat work for servers where the chain for your clients is short and more predictable.

The CRL DP extension is a separate issue from this bug. I believe that this feature is currently supported in NSS with the "new" PKIX APIs. However, the application must enable this support. It may be that Firefox does not do so at this time.
(Reporter)

Comment 8

7 years ago
Re: previous comment I meant "where the client's cert chain is unpredictable".

Comment 9

7 years ago
We must revisit this after libPKIX became the default verification engine.
Depends on: 651246

Updated

7 years ago
Blocks: 725984
No longer depends on: 651246

Comment 10

a year ago
Hi, I have firefox 38 version and as we know that firefox removed certificate revocation check through CRL, now we have only OCSP protocol for the revocation check. I have a requirement that, whatever OCSP uri has been given in CA certifcate, I want that for revocation check firefox intercept OCSP uri to my local ocsp server uri. Is there any possibilities to do like this. This is urgent any one can reply early that would be really great help for me. Thanks in advance.
You need to log in before you can comment on or make changes to this bug.