User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:22.214.171.124) Gecko/20100401 Firefox/3.6.3 GTB6 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:126.96.36.199) 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/emailAddressemail@example.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.
Browser DB adjustment fixed the issue. Thanks!