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.

This only applies to OCSP. The CRL is checked at all levels of the chain.

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.

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.

Unsetting target milestone in unresolved bugs whose targets have passed.

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

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.

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

We must revisit this after libPKIX became the default verification engine.

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.