Created attachment 290675 [details] server cert Originally reported in bug 403220. Test: attempt to open https://22.214.171.124: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.126.96.36.199.2.29 That's an unknown OID to NSS. According to http://www.alvestrand.no/objectid/188.8.131.52.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 signature. 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.
I agree: 184.108.40.206.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. bob
Another example: https://mail.wyke.ac.uk/
Created attachment 306190 [details] [diff] [review] patch v1 This patch seems to fix it. Julien, please review.
Comment on attachment 306190 [details] [diff] [review] patch v1 Looks fine. 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.
Thanks, Julien. 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://220.127.116.11: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.