201143 - Priority of errors in cert verification

Status: NEW

(NSS :: Libraries, defect, P3)

Description

[Julien Pierre]

I recently ran into an interesting problem when connecting to an internal SSL
server, namely phonebook.

I was getting an error that the issuer cert was expired.

It turned out that in fact , my client didn't have the built-ins loaded
correctly, and the server was sending a cert chain with a pre-Y2K verisign cert.

I believe that in this case, we should have returned something like "issuer not
trusted" rather than "expired issuer".

I know that it is more efficient to check the expiration date first, and it is
an optimization that we get out of the cert verification function.
However the fundamental problem here was not the expiration, but the lack of trust.

Once I installed the built-ins in my application, both errors went away, by
virtue of the fact that I picked up a new Verisign root, with a newer expiration
date, and that root overrode the one the server sent.

I think we should establish a list of priorities and slightly reorder the way
the  checks are done and what error gets returned by the various
CERT_VerifyCert* functions .

Currently the order of checks is (roughly) as follows :

validity date
DN
usage
trust
revocation

I think essentially moving trust to the top of the list would give more coherent
results for applications and their users. It does come at the cost of some more
overhead to go to the token and retrieve trust.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

I'm afraid that trying to find a priority order for errors in cert chains is
doomed.  No one priority order will best serve all situations, I think.
The solution is for the UI to show all the problems found with the cert, I
think, much as MSIE's GUI does.  NSS has the functionality to facilitiate that
now.  The applications just need to make use of it.  

I'm not sure there's a valid NSS bug here.