93046 - Store unknown intermediate CAs in db after SSL negotiation

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect)

Description

[David P. Drinan]

Currently, NSS does not store in the db the unknown intermediate CAs that it 
finds in the cert chain during an SSL negotiation. This breaks the PSM UI that 
deals with displaying the certification path of an SSL server certificate.

Comment 1

[Robert Relyea]

I talked to david about this. We don't really want to store the certs in the
perm db just to make the UI work. What we want is to have the certs in the temp
db (where we can find them). The problem is we don't want to leak the certs.

The solution is the application needs to keep a reference to the certificates.
this can be done providing an 'authCertificate' callback function instead of
using the default callback. The CA certs are available at the time of the
callback. The application already has to store it's own pointer to the peerCert.
The trust chain can be preserved the same way.

bob

Comment 2

[Wan-Teh Chang]

Assigned the bug to Bob.

Comment 3

[Bob Lord]

This functionality seems like something that the core libraries should do for
the application so every new app doesn't need to re-invent the wheel.

Comment 4

[Robert Relyea]

That would be true if a significant fraction of applications needed this
functionality. The fact is one application needs it, and most of the
applications that use NSS doesn't want this semantic.

The other thing to factor in is only the application knows when and how long the
certs should be stored. You don't want to *always* store the intermediate certs
because you rarely store the leaf cert. Only the application knows when it no
longer needs these certificates. (If NSS kept them around forever we'd have a
slow memory leak on our hands).

What may be useful is for NSS to provide tools to handle the whole cert chain
(though I believe those tools already exist).

bob

Comment 5

[Robert Relyea]

OK, here are the helper functions already available in NSS:

1) when you save the server cert from your SSL connection, you can also save the
cert chain by calling:
CERTCertList *certList;

certList= CERT_GetCertChainFromCert(serverCert,PR_Now(), certUsageSSLCA);

This returns a CERTCertlist which you can save in the same data structure you
are currently saving the server cert. When you are through with the server cert
you can destroy the certificate list with CERT_DestroyCertList(). The CertChain
exists during any of the SSL client auth handshakes. If you preseve the list,
the chain will continue to stick around in the temp db.

2) if you save the server cert, you can write the chain as well by calling:

CERTCertificateList *list;

list = CERT_CertChainFromCert(serverCert,certUsageSSLCA,PR_True);
if (list== NULL) /* error */;
rv = CERT_ImportCAChainTrusted(list->certs,list->len, certUsageSSLCA);
if (rv != SECSuccess) /* error */;
CERT_DestroyCertificateList(list)


NOTE: CERTCertList and CERTCertificateList are different data structures.

I'm going to close the NSS side of this bug. There is still some PSM work. If
there are any questions on how to do this with NSS functions, feel free to ask me.