If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

NSS on OS X too pendantic on CA Cert Serial Number

RESOLVED WORKSFORME

Status

NSS
Libraries
RESOLVED WORKSFORME
8 years ago
8 years ago

People

(Reporter: William Cordis, Assigned: Robert Relyea)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 GTB6
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 GTB6

NSS as embedded in Firefox 3.6.3 is failing to authenticate properly signed certs from a valid but private CA. 

from the offending cert:
X509v3 Authority Key Identifier:
keyid:xxxxxxx
DirName:/C=US/ST=North Carolina/L=Raleigh/O=Red Hat, Inc./OU=IS/CN=Red
Hat IS CA/emailAddress=xxxxxx@redhat.com
serial:00

The current RH CA Cert is:
Serial Number: 1 (0x1)

Which is consistent with the resigned CA key (the public/private data
and Subject are identical from the previous key)

Running firefox-3.6.1-2.fc14.i686 (The latest updated version on
f12) we do not see this issue. I believe what is happening is that
some SSL libraries honor the "serial" requirement of the Authority Key
Identifier, and some do not. Apparently the version of Firefox (using
the NSS SSL libraries) I am using does not, but openssl says:
openssl verify -CAfile RedHatISCA.pem
/home/rmonk/Download/wwwapps.rdu.redhat.com
/home/rmonk/Download/wwwapps.rdu.redhat.com: C = US, ST = North
Carolina, O = "Red Hat, Inc.", OU = Production Operations, CN =
wwwapps.rdu.redhat.com error 20 at 0 depth lookup:unable to get local
issuer certificate

If I look at the cert for xxxxx.redhat.com, which does not have the
serial requirement:
openssl verify -CAfile RedHatISCA.pem xxxxx.redhat.com
xxxxx.redhat.com: OK

In short the OS X browser is honoring the serial requirement and therefore not seeing that the cert was signed correctly.

Using Windows 7 Ultimate x86 with Firefox 3.6.3, we did not get the error
(it does not check the serial) so we believe this is something specific
to OSX/Firefox. Not sure why there is a difference however as they
all use the NSS libraries.

Since the Issuer Key Identifier information is only a guideline in the
x509 standard (It specifies how to store it and the possible values, but
not which values should be stored) then what actually gets checked is up
to the implementation.

Mozilla considers this an error to have the serial included:
http://www.mozilla.org/projects/security/certs/policy/

Specifically #4: "incorrect extensions (e.g., SSL certificates that
exclude SSL usage, or authority key IDs that include both the key ID and
the issuer's issuer name and serial number);"

Overall, the SSL lib that OSX/Firefox is using is more pedantic here,
and is more "correct" in that it's using all the values the CA set as
the identifier, but since resigning a CA is a fairly normal event
(extending the life of a non-compromised CA cert) than checking the
serial can lead to issues just like you see here.  Adding the Serial as
a check doesn't add any more real security, because someone with access
to sign a new cert has the private key and can make one with the old
serial if they wanted to.

Reproducible: Always

Steps to Reproduce:
1.Create CA
2.Extend CA by signing it with currently valid CA.
3.Create cert signed by extended CA including a serial check.
4.Validate and install CA in OSX Web browser.
5.Attempt to visit site using cert created in step 3.
Actual Results:  
xxxxx.com uses an invalid security certificate.

The certificate is not trusted because the issuer certificate has expired.

(Error code: sec_error_expired_issuer_certificate)

Expected Results:  
Secure web page loads.
The whole purpose of the serial number feature in authority key IDs is for
the issuer to say to the relying party "In the event that you have more
than one CA cert with the same subject name, and one of them is the one with 
this issuer name and serial number, use that one".  We're doing what the 
issuer told us to do, just like the RFC says.  

Amateur CAs.  Gotta love 'em.  Someone probably played with openSSL, filled 
in an AKID field whose implications he didn't fully understand (probably 
because some OpenSSL sample page found on the web showed how to do that), and 
shot himself and his company in the foot.

Anyway, the difference between your two systems (OS/X and Windows) is not 
the software algorithms but rather the browser DB contents.  One of them 
finds both old and new CA certs, and so chooses the old one (because of 
the matching serial number).  The other one doesn't find the old cert in 
its DB, and so doesn't choose it.  Delete the old CA cert from the DB 
that has it, and life should be good again.  

The lesson to learn here is: stop putting issuer-name-and-serial-numbers 
into AKID extensions.  That was only intended to provide a way to refer to 
issuer certs that were X.509 v1 certs that have no SKID extensions.  If 
your issuer has an SKID, then just put the SKID in your AKID, and no more.
(Assignee)

Updated

8 years ago
Assignee: nobody → rrelyea
(Reporter)

Comment 2

8 years ago
Browser DB adjustment fixed the issue.  Thanks!
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.