230996 - Failure to detect two different certs with same issuer and SN

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Ken Johanson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040113
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040113

With a particular combo of 3rd-party-CA signed certs (containing x509v3 alt
subject names), issued to different websites, Mozilla alerts a cert/site
mismatch and then "<site> recieved a message with incorrect Message
Authentication Code. If the error occurs frequently, contact the website
administrator." Subsequent connections fail until restart.

Reproducible: Always

Steps to Reproduce:
1. Open http://www.onnet.cc - click on and install the 3rd-party root CA cert
(it's the certificate image).
2. Open https://test.breezeway.tv , signed by the 3rd-party CA.
3. Mozilla will (falsely) alert a site/cert mistmatch.
4. If you click the OK button to continue, Mozilla then alerts "<site> recieved
a message with incorrect Message Authentication Code. If the error occurs
frequently, contact the website administrator."
Actual Results:  
Mozilla will alert a site-name-mistmatch; stating that the cert belongs to
'Interactive Engines', even though '*.ascentmedia.com' is that site's cert's
primary-subject CN (an indication that site-1's cert is falsely being claimed by
Mozilla to have been served from site-2). Note that my CA signed that cert it
and that *.beeezeway.tv is in its alt-subject list.

Subsequent connection attempts to site-2 (test.breezeway.tv) fail until after
restarting Mozilla.

Also, note that connecting to the two sites in opposite order
(1:test.breezeway.tv, 2:www.onnet.cc) produces the opposite result; a warning
for the second site that the first-site's cert has been presented.


None of these issues occur in IE.

I've tried creating different profiles, and Linux and Windows builds - all yield
same result.

Comment 1

[Ken Johanson]

Oops. Steps to repro should be clarified:

1. Open http://www.onnet.cc - (redirects to https)
2. Accept the untrusted-cert for the session duration
3. Click on and install the 3rd-party root CA cert (it's the certificate image).
4. Restart Mozilla.
5. Open https://www.onnet.cc , signed by the 3rd-party CA.
6. Open https://www.breezeway.tv , also signed by the 3rd-party CA.
7. Mozilla will (falsely) alert a site/cert mistmatch.
8. If you click the OK button to continue, Mozilla then alerts "<site> recieved.."

Steps 5-8 are repeatable after completing steps 1-4.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Ken,

In your original description, you cite https://test.breezeway.tv  
but in your next comment, you cite https://www.breezeway.tv 
Which is correct?

Do you mind if I fetch and attach all the relevant certs to this bug?
Otherwise, you'll have to keep the servers up until this bug is fixed.

Comment 3

[Ken Johanson]

Sorry, habit. I meant to say 'test.breezeway.tv' instead of www.breezeway.tv.
You are certainly welcome to fetch the certs. The servers will stay up as well.
Thanks!!

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Changing summary to succinctly summarize reported error message.
Not yet confirmed.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Ken,  your server https://www.onnet.cc/ has a timeout time that is WAY too short.
It must be no more than a second or two.  Please raise it, say, 30 seconds, to
give the user time to look at the cert and click OK.
This is probably not the cause of the reported problem, but it is a problem.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Ken,  I have reproduced the problems you describe. 
The certificate at test.breezeway.tv has a large list of subject Alt Names,
most of which are not of the correct syntax.  In particular, all but one of 
them use an asterisk as a wildcard.  e.g. *.breezeway.tv  which is not 
proper syntax for a subject Alt Name.  Subject Alt Names don't support
wild cards at all, as far as I can recall.  You must list all the hosts' 
dNSNames individually.

Still investigating the bad MAC alert.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

First a clarification about comment 6.  Mozilla does honor wildcards (e.g. "*")
in subject alt names, but IIRC, RFC 3280 doesn't suggest/define it, and so this
behavior is probably non-standard.  Therefore, one would not expect all browser
products to honor it, and so if one wanted one's cert to interoperate with all
standards-compliant browsers, one would not make use of wildcards.

Next, I observe that once you've downloaded and trusted that root CA cert,
you can visit the two URLs in either order, e.g. either
   https://www.onnet.cc/      and then https://test.breezeway.tv/  or else
   https://test.breezeway.tv/ and then https://www.onnet.cc/ 

Either way, the host name mismatch AND the BAD MAC ALERT occur on the
second site you visit.

The problem here is that your CA has issued two very different certs with
the same serial number.  Both of the certs for the two servers named above have
the serial number 1.  This is a violation of RFC 3280.  A CA must never issue
two certs with the same serial number.  NSS (the crypto component of mozilla)
absolutely depends on this, and attempts to enforce it.  

When NSS receives a second certificate that has the same issuer name and serial
number as one it has previously seen, but is not the same identical certificate,
NSS returns a special error code reporting this.  NSS WILL NOT accept a second
certificate with the same issuer name and serial number.  Any attempt to use
the certificate with that issuer name and serial number will get the first 
cert the NSS saw with those values, not the second one.  That is why NSS returns
the special error code about this problem.

Mozilla should (and usually does) return an error dialog reporting that problem.
 That error should be detected BEFORE the name mismatch error is found.  The
user should not see the name mismatch error without seeing that other error first.  

But in this case, for some reason, mozilla did not report the error about two
certs with the same serial number.   Either the problem was not detected, or
mozilla ignored it.  So, mozilla went on and did the name match check, but it
was checking the name of the second server against the FIRST cert that it 
got with that serial number, which does not bear the name of the second server,
and so it reports the name mismatch.   In some sense, the name mismatch is 
correct, because the name of the second server is NOT in the list of alt names
for the first server's cert.

The BAD MAC ALERT happens because NSS uses the public key from the first
server's cert to talk to the second server.  

So, there are two separate problems here, one the fault of mozilla or NSS,
and one the fault of the issuing CA.  

1. The CA should reissue BOTH CERTS, with serial numbers that it has not 
used before (don't use serial 01 ever again!).  I recommend using the 
number of seconds elapsed since midnight January 1, 1970, GMT, as the serial
number, because that number increases monotonically.

2. We need to understand why mozilla didn't detect or report the fact that
it had received a second cert with the same issuer name and serial number 
as another.  My guess is that this is a PSM bug, not an NSS bug.

I have changed the summary of this bug to reflect the real problem.

Investigation of the failure will continue next week.
I will attach the relevant certs here.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Attachment: root CA cert SN 00 (base 64)

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Attachment: breezeway's cert SN 01 (base 64)

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Attachment: onnet's cert, also SN 01 (base 64)

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

This is an NSS bug.  The test for a duplicate issuer and serial number is only
done if the previously-seen cert with the same issuer and SN was a "permanent"
cert.  The test should also be done if it is not a perm cert.  
patch forthcoming.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Raising to P1.  Target NSS 3.9.1.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

Attachment: patch v1

With this patch in place, mozilla correctly displays the dialog proclaiming
that you have recieved a cert with duplicte issuer and serial number.  

I will ask Ian to review this.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 139300 [details] [diff] [review]
patch v1

Ian, please review

Comment 15

[Wan-Teh Chang]

Comment on attachment 139300 [details] [diff] [review]
patch v1

Thanks a lot for tracking this down, Nelson.

I've reviewed this patch.  I think it's correct (r=wtc).
But Ian should still review it, and I suggest that Bob
also review it.

Comment 16

[Ken Johanson]

Nelson, Thank You!!! Again!! You guys are all truly an invaluable asset to this
project. Your expertise sets an example for mentorship, certainly for me! 

I'm glad to see this browser has such a solid foundation of software engineers.
Makes me proud to love this platform.

Nelson, that's two good catches you've got on me!!

Unless you object, I will have the certs re-issued for those servers Monday or
Tues morning.

The fact that Mozilla rejected the doubly-issued serial number, distinguishes it
even more from all the other browsers --and several APIs -which completely
ignore that discrepency. I guess this further exemplifies the reason that those
'other products' have miserable security vulnerabilities discovered on a
near-monthly basis.

As for my use of wildcards in the alt-subjects, I will probably opt to continue
using that malformed syntax, simply because:
1) Mozilla and all others products I've tried DO tolerate it.
2) My hosting environment at work must support virtual host lists which change
FAR to often to re-issue certs on a weekly or monthly basis (it's a family of
intra/extranet sites for out subsidiary companies), whereas using wildcards will
reduce the re-issuance to something less than a year (depending on how quickly
we buy companies, ala TLDs :-).
3) If the primary subject supports wildcards, it seem(ed) intuitive that the
alt's should too -- but I would never argue with the RFCs which (hopefully) have
some valid reasoning for not specifically stating the alt-subj macthing behavior
be the same as the primary subject's. /k

Comment 17

[Nelson Bolyard (seldom reads bugmail)]

Ken,  Now that I've captured the relevant certs and attached them to this bug,
please fix your servers' certs at your soonest convenience. 

I also recommend that you read the following info on issuing valid certs:
a) http://certs.mozdev.org/cadraft.html  
 (skip down to the part that begins "Since you're telling readers how to be a CA")
b) RFC 3280, especially sections 1-4.  

Comment 18

[Ian McGreer]

Comment on attachment 139300 [details] [diff] [review]
patch v1

Good catch, Nelson.

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

/cvsroot/mozilla/security/nss/lib/certdb/stanpcertdb.c,v  <--  stanpcertdb.c
new revision: 1.62; previous revision: 1.61

Comment 20

[Nelson Bolyard (seldom reads bugmail)]

*** Bug 39495 has been marked as a duplicate of this bug. ***