This bug was found in the context of bug 249004. (even with a patch applied, that prevents importing of fake certs into the perm store). In a testcase for bug 249004, the application examines a fake CA cert, where DN is identical to one of the builtin and trusted certs. Although the application does not import the fake cert into the perm store, subsequent SSL access to a server, using a valid certificate by the trusted CA cert, fails with error -8182. More details, diagnostics, results of tests, and a suspicion about the cause. test case 1: - clean cert db - start application - use the application to look at the trusted builtin Thawte server CA cert - examine the invalid fake cert, having same DN as the Tawte server CA cert - access https://www.thawte.com -> works fine, no errors test case 2: - clean cert db - start application - examine the invalid fake cert, having same DN as the Tawte server CA cert - access https://www.thawte.com -> while loading the various web site contents, error -8182 is shown for one of the visited servers test case 3: - clean cert db - start application - examine the invalid fake cert, having same DN as the Tawte server CA cert - restart application - access https://www.thawte.com -> works fine, no errors Test case 3 shows the problem must be because of a temporary cert in memory. Test case 2 makes it appear likely NSS still keeps the fake cert in memory and uses it. Test case 1 makes the suspicion appear more likely to me, because during some initialization NSS already got to see the good CA. During debugging of test 2, I saw that during the call to CERT_VerifyCert an additional reference to the fake cert is created. It appears the reference to the fake cert is created during the call to SEC_CheckCRL, calling AcquireDPCache, creating some cache that will continue to hold a reference to the fake cert.

Julien's most familiar with the CRL DPCache. bob

Bob, The CRL cache uses whatever issuer certificate is passed to it from CERT_VerifyCert . It keeps a reference to the cert in order to be able to verify updated CRLs in the future . This is required because not all code paths in the cache have an issuer cert as input, for example, when a CRL is imported to a token, there is no issuer cert argument, and the CRL is unverifiable without an issuer cert, which delays its caching. The main problem here is that the issuer cert passed from CERT_VerifyCert hasn't been verified yet when the CRL cache is called. In this case, it turns out not to be valid, but that fact isn't known until after the CRL cache is already built. This is because of the loop in CERT_VerifyCert which goes from leaf to root. All verification and revocation checking happens one level at a time. The correct fix is to add more checks for the CRL issuer cert, so that an invalid CRL cache does not get built. This is a duplicate of bug 233118 . *** This bug has been marked as a duplicate of 233118 ***

If this is a dupe of a security'd bug, shoudln't this one be security'd as well?

Chris, This defect can remain public because the test cases and what's been discussed in this bug doesn't actually expose where the vulnerability is, whereas the other bug does.