The default bug view has changed. See this FAQ.

Unknown signature OID 1.3.14.3.2.29 causes sec_error_bad_signature, 3.11 ignores it

RESOLVED FIXED in 3.12

Status

NSS
Libraries
P1
normal
RESOLVED FIXED
10 years ago
3 years ago

People

(Reporter: kaie, Assigned: Nelson Bolyard (seldom reads bugmail))

Tracking

({regression})

trunk
3.12
regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: NSS312, URL)

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
Created attachment 290675 [details]
server cert

Originally reported in bug 403220.

Test: attempt to open https://75.127.66.155: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?
(Assignee)

Comment 1

10 years ago
The signature algorithm OID in this cert is OID.1.3.14.3.2.29 
That's an unknown OID to NSS.  
According to http://www.alvestrand.no/objectid/1.3.14.3.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.
(Assignee)

Updated

10 years ago
Assignee: nobody → rrelyea
Priority: -- → P1
Target Milestone: --- → 3.12
Version: 3.12 → trunk
(Assignee)

Updated

10 years ago
Summary: nss 3.12 rejects cert with sec_error_bad_signature, 3.11 accepts it → Unknown signature OID 1.3.14.3.2.29 causes sec_error_bad_signature, 3.11 ignores it

Comment 2

10 years ago
I agree:

1.3.14.3.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/
Whiteboard: NSS312
Created attachment 306190 [details] [diff] [review]
patch v1

This patch seems to fix it.  Julien, please review.
Assignee: rrelyea → nelson
Status: NEW → ASSIGNED
Attachment #306190 - Flags: review?(julien.pierre.boogz)

Comment 5

9 years ago
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.
Attachment #306190 - Flags: review?(julien.pierre.boogz) → review+
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
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 7

9 years ago
While this fix does solve the issue for https://75.127.66.155: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.  
(Reporter)

Comment 9

9 years ago
See also bug 424077, bug 412277
See Also: → bug 1042479
You need to log in before you can comment on or make changes to this bug.