1913047 - Certificate chain validation problem

Status: RESOLVED FIXED

(NSS :: Libraries, defect)

Description

[Mike Hommey [:glandium]]

This was first reported as https://bugs.debian.org/1078468

Copy/paste from the original report:

Something is wrong with how libnss3 is verifying chains.

I first noticed this with pidgin with irc.oftc.net, but I can reproduce this
without needing pidgin (hence I don't think this is a pidgin bug).
Interestingly, Firefox (and I presume Thunderbird, but haven't checked this)
is unaffected.

To see this issue, run (I'm using Google here as I'd expect them to have the
chains correctly set up, and for any breakage to be noticed really quickly, but
other systems give the same error):

$ vfyserv -c google.com -p 443

which gives

Connecting to host google.com (addr 142.250.76.110) on port 443
Cert file cert.000 was created.
PROBLEM WITH THE CERT CHAIN:
CERT 0. CN=*.google.com :
ERROR -8179: Peer's Certificate issuer is not recognized.
CN=WR2,O=Google Trust Services,C=US
Error in function PR_Write: -8179

• Peer's Certificate issuer is not recognized.

Bisection points to https://hg.mozilla.org/projects/nss/rev/85b31820e432e580b7f3dfd291d444df2ee9f129 as the source of the regression.

Comment 1

[John Schanck [:jschanck]]

Bug 1890618 changed libssl so that it does not automatically construct CERTCertificates for all certificates in the peer's presented chain. Constructing CERTCertificates is somewhat expensive, and these CERTCertificates were being constructed in the default certificate DB, so this had a negative performance impact for many applications:

• Applications that did not rely on an NSS certificate DB for path validation, such as Firefox and Thunderbird, did not need to construct CERTCertificates at all.
• Applications that called CERT_VerifyCertificate(handle, ...) with a handle other than that returned by CERT_GetDefaultCertDB() would end up constructing CERTCertificates twice---once in the default db, once in the db pointed to by handle.

Some applications, such as vfyserv and the 2.x.y branch of pidgin, were assuming that all certificates from the peer's chain would be available in the default certificate db. These applications should

1. use the SSL_PeerCertificateChain function, instead of SSL_PeerCertificate, to construct CERTCertificates for the entire chain instead of just the end-entity.
2. hold a reference to the CERTCertList (or the individual CERTCertificates) returned by SSL_PeerCertificateChain through calls to CERT_VerifyCertificate etc.

Comment 2

[John Schanck [:jschanck]]

Attachment: Bug 1913047 - vfyserv: ensure peer cert chain is in db for CERT_VerifyCertificateNow. r=keeler

Comment 3

[Mike Hommey [:glandium]]

That sounds like a rather significant ABI change...

Comment 4

[John Schanck [:jschanck]]

I don't think it's an ABI change at all. We removed some code that had side-effects, and this exposed bugs in some applications that made poor assumptions in their custom SSLAuthCertificate hooks.

For what it's worth, you really have to wonder what an SSLAuthCertificate hook is doing if it only requests the end-entity certificate from libssl and not the full chain.

Comment 5

[John Schanck [:jschanck]]

I filed a bug and a patch with Pidgin: https://issues.imfreedom.org/issue/PIDGIN-17886/Certificate-verification-errors-with-NSS-3.103.

Comment 6

[John Schanck [:jschanck]]

https://hg.mozilla.org/projects/nss/rev/5c265fd0e994bbb0dadb6a5aac353b8e5a5a60dd

Comment 7

[Robert Relyea]

The side effects were intentional. The reason we did them was so the certs are available in the chain. For the Firefox/Thunderbird case, where you aren't actually reconstructing the chains, we should make a specific call to prevent the importing rather than making it the default behavior for all certs.