No certificate hierarchy

In the certificate hierarchy there is only one certificate displayed for some sites.

added component::applications/tor browser owner::tbb-team priority::medium severity::normal status::reopened tbb-usability type::defect labels

Do you have an example which is showing in vanilla Firefox more than one certificate?

torproject.org

Check it several times. It displays proper certificate hierarchy, but when you close Certificate Viewer, and then open it again several times it will display only one certificate of torproject.org

Turns out this is very likely a duplicate of #13254 (moved), too.

Trac:
Status: new to closed
Resolution: N/A to duplicate

Replying to gk:

Turns out this is very likely a duplicate of #13254 (moved), too.

No, it is not. #14716 (moved) fixes that one but not this bug, reopening. They are probably related, though.

Trac:
Resolution: duplicate to N/A
Status: closed to reopened
Keywords: N/A deleted, tbb-usability added
Cc: N/A to mcs, brade

Kathy and I spent some time in the debugger and reading code to try to understand this issue. Unfortunately, we have not yet found the root cause. Here are some of the things we learned:

• The bug occurs because the intermediate CA certificate is no longer available. That cert. is present in the temporary (SSL context) certificate store while the https connection is open, but when the SSL socket is closed, it is deleted (see ssl3_CleanupPeerCerts() inside security/nss/lib/ssl/ssl3con.c).

• It is not clear to us why the security.nocertdb pref. value changes things, but for sites like https://blog.torproject.org/, if security.nocertdb=false (not the default), then the intermediate CA is found in the permanent / built-in certificate store even after it has been purged -- and everything works fine. We suspect in that case the cert. may be present because of the cert. pinning feature that was backported to Tor Browser. Maybe security.nocertdb=true (the default setting) makes it so that not everything is available to the UI code that is trying to construct the certificate chain.

• For unpinned sites such as https://github.com/, the bug described by this ticket occurs in Tor Browser 4.5a5+ even when security.nocertdb=false. But the pinned vs. unpinned theory is not 100% proven at this point.

The NSS code is a maze of twisty little passages, all alike. If we do not solve this issue soon, we should re-test when we have ff38-esr based builds and debug it further.

We have not been able to reproduce this problem with unmodified copies of Firefox 31 or 37.0.2.

---

Info. that is helpful for debugging this:

The call that returns the incomplete list of certificates is CERT_CreateSubjectCertList() inside security/nss/lib/certdb/stanpcertdb.c. The relevant C++ portion of the call stack is:

CERT_CreateSubjectCertList()
mozilla::psm::NSSCertDBTrustDomain::FindPotentialIssuers()
mozilla::pkix::BuildForward()
mozilla::pkix::BuildCertChain()
mozilla::psm::BuildCertChainForOneKeyUsage()
mozilla::psm::CertVerifier::MozillaPKIXVerifyCert()
mozilla::psm::CertVerifier::VerifyCert()
nsNSSCertificate::GetChain()
...

CERT_CreateSubjectCertList() is in security/nss/lib/certdb/stanpcertdb.c.

The in-memory / session certificate store is implemented by security/nss/lib/pki/pkistore.c.

The relevant JS code is the call to cert.getChain() within setWindowName() within the file security/manager/pki/resources/content/viewCertDetails.js

Trac:
Keywords: N/A deleted, ff38-esr added

As a workaround, if you install Certificate Patrol you should be able to get a view of the hierarchy on the first visit of each website as it is the primary information it gives (everything else in a certificate can be a lie). Or is Certificate Patrol also affected?

Trac:
Username: vynX

if security.nocertdb=false (not the default), then the intermediate CA is found in the permanent / built-in certificate store even after it has been purged temporary (SSL context) certificate store has been purged (?)

For https://github.com/ TypeError: cert is null in chrome://pippki/content/viewCertDetails.js : 270:4 asn1Tree.loadASN1Structure(cert.ASN1Structure); from the beginning.

nocertdb means "not to store certs" by its name. (But who knows what Mozilla thought...) So, no cert db - is not the resolution.

cert db must be permanent / session, isolated, in-memory, purgable. SSL context - isolated, in-memory.

Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A

TypeError: cert is null continues to appear in ESR45 if you select Intermediate CA in the hierarchy (https://blog.torproject.org/blog/tor-browser-65a3-released#comment-209108). EV certs have a special handling, so when TBB seems to forget hierarchy for the site (not for CertViewer), some weird effects occur.

Trac:
Keywords: ff38-esr deleted, N/A added
Reviewer: N/A to N/A

Looks related: https://bugzilla.mozilla.org/show_bug.cgi?id=1063276

mentioned in issue #14716 (moved)

mentioned in issue #15770 (moved)

moved to tpo/applications/tor-browser#13926 (closed)