In NSS 3.16.3 we began the removal of 1024-bit roots, according to Bug #936304 and Bug #986005 NSS 3.16.3 is included in Firefox 32, which is currently in Beta. Unfortunately, the removal of the "GTE CyberTrust Global Root" cert is proving to be problematic, so we need more time to figure out a better transition plan before removing this root. Please add back the following root cert that was removed in NSS 3.16.3: CN = GTE CyberTrust Global Root SHA1 Fingerprint: 97:81:79:50:D8:1C:96:70:CC:34:D8:09:CF:79:44:31:36:7E:F4:74
Assignee: nobody → kaie
Target Milestone: --- → 3.16.4
Version: 3.16.4 → 3.16.3
Summary: Backout removal of GTE CyberTrust Global Root → Backout (undo) the removal of GTE CyberTrust Global Root
The removal was done in bug 1021967 The contents of the old removal can be seen here: https://hg.mozilla.org/projects/nss/rev/d936c1e1c51e The attachment should be equivalent to the removal of the GTE root and its trust record (except that the patch is adding it back, instead of removing it).
Created attachment 8466353 [details] [diff] [review] patch v1 - Undo the removal of GTE, in other words, add it back.
I've started a try build with this patch included, please refer to bug 1045189 comment 12 and following. Who knows a server that we could use for testing the patch? A site that fails with latest mozilla-central (missing CA), but works with the try build (restored CA).
(In reply to Kai Engert (:kaie) from comment #3) > I've started a try build with this patch included, please refer to bug > 1045189 comment 12 and following. Thanks! > > Who knows a server that we could use for testing the patch? A site that > fails with latest mozilla-central (missing CA), but works with the try build > (restored CA). https://calendar.sacredheart.edu
(In reply to Kathleen Wilson from comment #4) > > Who knows a server that we could use for testing the patch? A site that > > fails with latest mozilla-central (missing CA), but works with the try build > > (restored CA). > > https://calendar.sacredheart.edu Thanks. For the record, this server uses an intermediate CA certs with an OCSP URI that uses https - which we don't support. With (strict) OCSP enabled, I get an error message when connecting to the site. So it will be necessary to disable OCSP while testing.
Kathleen, I cannot verify the site. I get an error message, sec_error_cert_signature_algorithm_disabled I don't understand why. I have disabled OCSP, and the site's certificate looks like it's using a SHA1 signature.
The problem appears to be with the root and the intermediate. I saved a copy of the intermediate, which is sent by the server during the TLS handshake, then I tried to use certificate manager to import it. It didn't help. I looked at the intermediate in cert viewer. The intermediate is signed with SHA1. Nevertheless, cert viewer displays text that the certificate was signed using an invalid (disabled) signature algorithm. Is this a property of the new mozilla::pkix validation library? Does it maybe reject the root (not the intermediate), which is self-signed using md5? In the NSS chain verification, the self signature on the root was ignored, given it's explicitly trusted.
(For testing purposes, I used a Firefox 24.7.0 build, which uses the old NSS logic, combined with the libnssckbi.so from the try build. It worked to access the site, that supports my theory that it might be a property of mozilla::pkix.)
Comment on attachment 8466353 [details] [diff] [review] patch v1 - Undo the removal of GTE, in other words, add it back. Bob, could you please review this? As said in earlier commnets, it's undoing a change from 3.16.3 We'd like to release this in both NSS 3.16.4 and 3.17
Attachment #8466353 - Flags: review?(rrelyea)
FYI, the confusion I reported earlier seems to be limited to FF34. So for now, for the FF32 we're targetting, the original plan seems good.
(In reply to Kai Engert (:kaie) from comment #11) > FYI, the confusion I reported earlier seems to be limited to FF34. > > So for now, for the FF32 we're targetting, the original plan seems good. (In reply to Kai Engert (:kaie) from comment #6) > I get an error message, sec_error_cert_signature_algorithm_disabled > > I don't understand why. I have disabled OCSP, and the site's certificate > looks like it's using a SHA1 signature. This is probably due to bug 1042479. If you test with Firefox 32 + mozilla::pkix then it should work.
See Also: → bug 1042479
I created a try build, based on Firefox 32 beta branch, with the newer intermediate (neutral trust, chaining to the addtrust root). https://tbpl.mozilla.org/?tree=Try&rev=8a0a7ea6cc4a (linux 64-bit done, 32-bit failed with some infrastructure issues, other platforms not yet done). https://email@example.com/ I can successfully connect to the sacredheart test site from comment 4. This confirms the patch works correctly, and confirms the new md5 behaviour isn't present in Firefox 32.
branch checkin for 3.16.4: https://hg.mozilla.org/projects/nss/rev/8415f0f74376
trunk checkin for 3.17: https://hg.mozilla.org/projects/nss/rev/c7a56f8cd2e4 fixed.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.