Brian Smith (:briansmith, :bsmith, use NEEDINFO?) Reporter
	Description • 14 years ago

When certificate chain verification fails, PSM does another verification in order to learn the details of the failure through the error log. But, the errors encountered by the second verification may not be the same as the errors encountered in the first verification. For example, AFAICT, an OCSP request could fail in the first verification but then succeed in the second verification (or vice versa).

One solution would be to have the initial certificate chain verification generate the log.

	Matt McCutchen
	Comment 1 • 14 years ago

(In reply to comment #0)
> One solution would be to have the initial certificate chain verification
> generate the log.

The only other approach would be to commit to making the entire cert verification process reproducible.  I think the above is much more reasonable.

Currently:
- PSM's AuthCertificateCallback wraps the standard SSL_AuthCertificate (which does no logging) with additional status reporting but does not change the result.
- PSM's nsNSSBadCertHandler (a) does a second verification with logging (the logic parallels SSL_AuthCertificate), (b) maps the log to override bits, and (c) makes a decision based on the override bits, STS, and existing cert overrides.

Obviously, the single verification with logging needs to occur during AuthCertificateCallback.  So we have a few options:
1. In AuthCertificateCallback, replace the call to SSL_AuthCertificate with (a-b), save the override bits somewhere, and leave (c) in nsNSSBadCertHandler.
2. In AuthCertificateCallback, replace the call to SSL_AuthCertificate with (a), save the log somewhere, and leave (b-c) in nsNSSBadCertHandler.
3. Add logging support based on (a) to SSL_AuthCertificate, have PSM enable it, and leave (b-c) in nsNSSBadCertHandler.

Of these options, #1 and #2 do not touch NSS, while #3 requires adding an appropriate API for the logging to NSS.  In return, #3 eliminates the code duplication between SSL_AuthCertificate and nsNSSBadCertHandler, which makes it easier to add new server authentication schemes to NSS and PSM.  E.g., my DANE prototype (https://mattmccutchen.net/cryptid/#nss-dane) currently patches only SSL_AuthCertificate, so nsNSSBadCertHandler ignores DANE errors or hits the NS_NOTREACHED("why did NSS call our bad cert handler if all looks good? Let's cancel the connection") if the only error was a DANE error.  With #3, I would get proper PSM reporting of DANE errors for free, though for full integration I would still have to modify nsNSSBadCertHandler to add a new override bit.  So I have a personal interest in #3 being chosen.

However, it sounds like the single verification is going to be used for EV as well (bug 650307), so #3 would mean passing whatever parameters are required for that in and out of NSS as well.  This may tilt the judgment in favor of #1 or #2.

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?) Reporter
	Comment 2 • 10 years ago

As part of the migration to mozilla::pkix and the subsquent work on it, this bug was fixed. I'm not sure which bug fixed it. This can be verified by noticing that there's no certificate verification in SSLServerCertVerification.cpp except the one in AuthCertificate.