Visit https://shippingmanager.bpost.be with current Nightly shippingmanager.bpost.be uses an invalid security certificate. The certificate is not trusted because the issuer certificate is not trusted. (Error code: sec_error_untrusted_issuer) http://www.sslshopper.com/ssl-checker.html#hostname=shippingmanager.bpost.be Site also works without warnings in Chrome and IE.

Regression window(m-i) Good: https://hg.mozilla.org/integration/mozilla-inbound/rev/2925006239ec Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140209161501 Bad: https://hg.mozilla.org/integration/mozilla-inbound/rev/5b5e7559cda5 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140209163202 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2925006239ec&tochange=5b5e7559cda5 Regressed by: Bug 967153

Reading through that bug, and investigating the cert, it's rooted in GTE Cybertrust Global Root, which is using 1024-bits RSA.

Brian, Kathleen, in the dependent bug I see we are supposed to be working with the CAs to phase out these certificates. Is there some way they can force their users to update? This is the Belgian national mail service, so it's relatively high impact in my very biased view. What's Chrome's schedule for breaking these sites?

This is the first reported incompatibility due to the removal of the 1024-bit roots.

Kathleen, do you know if the CAS for whom we removed roots have cross-signing certificates to deal with these incompatibilities? I think that we may have to consider backing out the root removals if we can't find some kind of workaround, especially if more sites are going to be broken.

(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #5) > Kathleen, do you know if the CAS for whom we removed roots have > cross-signing certificates to deal with these incompatibilities? > > I think that we may have to consider backing out the root removals if we > can't find some kind of workaround, especially if more sites are going to be > broken. In Bug #881553 all of the CAs who own these root certs confirmed that these roots may be removed in Q1, 2014. For the "GTE CyberTrust Global Root" see https://bugzilla.mozilla.org/show_bug.cgi?id=881553#c7 CCing Steven on this bug, so he can get their customer to switch to a different cert.

Matt, this is another case, this time for Firefox Aurora 29, where we need to do compatibility testing, comparing Firefox 29 to Firefox 28. (Not sure I'm using qawanted correctly.)

Adding me as QA contact is enough. I'll own the verification of this bug.

Based on the status of this and one other customer migration, and the intent of Tom @ Microsoft to remove the related root in June, I request that we delay removal of the GTE CyberTrust Global Root consistent with other CAs that have this specific need. We are actively working on these subordinated customers who require more time to migrate their large populations of SSL certificates. In this specific matter, we will sign the existing intermediate again using the Baltimore CyberTrust Root and replace that intermediate in offered TLS chains on these servers. This is the same distribution approach we're using at other subordinates that could not queue a project to manage this migration until close to the end of trust. Where practical, we also propose to use the CA Issuers form of AIA.

We could delay bug #936304 to Firefox 30, which is currently scheduled for release on June 10. But how do we ensure that we don't just delay finding these types of compatibility problems?

Kathleen, we are working on the last betas for 29. What is the current status of this bug? Thanks

We delayed Bug #936304 which is to remove some 1024-bit roots, so websites with SSL certs chaining up to this root continue to work. However, those websites need to move to new SSL certs (that don't chain up to 1024-bit roots) by June. Resolving this bug as WorksForMe (for now). Hopefully the CA will get all of their customers migrated to a non-1024-bit root before we try to do Bug #936304 again.