Created attachment 290675 [details]
Originally reported in bug 403220.
Test: attempt to open https://18.104.22.168:8443/
Firefox + NSS 3.11:
Cert is reported with error dialogs "problem with issuer"
and "domain mismatch".
After overriding these errors, connecting is possible.
Firefox + NSS 3.12:
Cert is rejected with error code sec_error_bad_signature
I'm attaching the server cert.
The attachment is a PEM file that contains both ascii encoding and a human readable dump. It can be converted to DER if needed.
Did NSS 3.12 regress?
The signature algorithm OID in this cert is OID.22.214.171.124.2.29
That's an unknown OID to NSS.
According to http://www.alvestrand.no/objectid/126.96.36.199.2.29.html
it is SHA1 with RSA signature.
NSS 3.11.x would decode it producing SEC_OID_UNKNOWN, but then would
ignore that OID completely. It used the fact that the signer's key
is an RSA key to decode the signature (that is, do the public key
operation) and then took the hash algorithm ID from the decoded
NSS 3.12 has a bunch of new code to deal with Alg IDs that represent
both a hash algorithm and a public key signature algorithm (such as RSA).
NSS 3.12 uses that new code in the verification of cert signatures,
and the new code does NOT ignore unknown algorithm IDs.
So, from NSS's perspective, this is not a regression but rather a long
standing bug (not recognizing this algorithm OID) that was prevsiously
masked (hidden) by another bug (ignoring signature OIDs for RSA signatures)
that has now been fixed.
The solution, I think, is to add this algorithm OID to NSS's table of
known OIDs, and add the SECOIDTag for it into the switch in function
sec_DecodeSigAlg in file secvfy.c. I suspect there are other similar OIDs
(which represent hash and signature algorithms) that also should be added.
Bob, let me suggest that you take this bug.
188.8.131.52.2 is the ISO SEC-SIG Algorithm space. Unfortunately ISO isn't happy with the standard OIDs defined in PKCS #1 and often include their own duplicates. This is one of those duplicates. As an ISO oid, it's prefectly valid (though not necessarily prefered), so we should support it.
Another example: https://mail.wyke.ac.uk/
Created attachment 306190 [details] [diff] [review]
This patch seems to fix it. Julien, please review.
Comment on attachment 306190 [details] [diff] [review]
The change to VFY_VerifyDataWithAlgorithmID is not necessary. I prefer the existing code since sigAlg is only used once and is a read-only argument passed by value, unlike encAlg and hashAlg which are returned and thus have to be locals.
The change to the VFY_ function enables me to set a conditional breakpoint,
stopping in that function if the sigAlg is SEC_OID_UNKNOWN.
Checking in util/secoidt.h; new revision: 1.27; previous revision: 1.26
Checking in util/secoid.c; new revision: 1.43; previous revision: 1.42
Checking in cryptohi/secvfy.c; new revision: 1.22; previous revision: 1.21
While this fix does solve the issue for https://184.108.40.206:8443/, it doesn't solve the issue for https://mail.wyke.ac.uk/ (which now just reports a bad signature with no opportunity to add an exception).
Should this be the behaviour for https://mail.wyke.ac.uk/? It's a pretty annoying regression over Firefox 2.0.
When I visit the wyke URL, I get this error message:
> An error occurred during a connection to mail.wyke.ac.uk.
> Certificate key usage inadequate for attempted operation.
> (Error code: sec_error_inadequate_key_usage)
That's a different issue than this bug.
The certificate is self-signed, which means that it is acting like a
CA cert, and its public key is being used to verify the signature on
a certificate, yet the certificate's extensions say that it is NOT a
CA and that its key is NOT allowed to sign certificates. NSS correctly
diagnoses all that. There is no NSS bug here. Your question concerns
how PSM handles a certificate with those errors. You may file a bug
against PSM if you wish.
See also bug 424077, bug 412277