1045189 - Include "USERTrust Legacy Secure Server CA" intermediate CA cert to ease transition off of roots removed in NSS 3.16.3

Status: RESOLVED FIXED

(NSS :: CA Certificates Code, task)

Description

[Kathleen Wilson]

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, some web server administrators have not updated their web servers to provide a new intermediate certificate signed by a newer root, even though the CA has implored them to do so. 

We can help mitigate the pain of migration from the old root by temporarily directly including the cross-signed intermediate certificate signed by the new root.

Comment 1

[Kathleen Wilson]

Steven, Bruce, Rick, and Ryanne,

In Bug #936304 and Bug #986005 we made the following changes to 1024-bit roots, for which we may see some compatibility problems regarding web servers that have not yet been updated to provide the newer (non-1024-bit) cert chain.

- The following 1024-bit CA certificates were Removed in NSS 3.16.3.
    -- CN = Entrust.net Secure Server Certification Authority 
        SHA1 Fingerprint:  99:A6:9B:E6:1A:FE:88:6B:4D:2B:82:00:7C:B8:54:FC:31:7E:15:39 
    -- 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 
    -- OU = ValiCert Class 2 Policy Validation Authority 
        SHA1 Fingerprint:  31:7A:2A:D0:7F:2B:33:5E:F5:A1:C3:4E:4B:57:E8:B7:D8:F1:FC:A6 

- The Trust Bits were changed for the following CA certificates in NSS 3.16.3
    -- OU = Class 3 Public Primary Certification Authority 
        SHA1 Fingerprint:  A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B 
        Turned off websites and code signing trust bits (1024-bit root) 
    -- OU = Class 3 Public Primary Certification Authority 
        SHA1 Fingerprint:  74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2 
        Turned off websites and code signing trust bits (1024-bit root) 

Concerns were raised about these changes in the mozilla.dev.security.policy forum.
https://groups.google.com/d/msg/mozilla.dev.security.policy/JFGRyr4-F44/sl44ywYCEdYJ

Our testing indicates that we are most likely to see compatibility problems regarding the removal of the 1024-bit Entrust.net and GTE CyberTrust roots. However, I wanted to make you all aware of this in case you know of reasons why we need to also be concerned about compatibility for the other root changes.

We can help mitigate the pain of migration from the old root by temporarily directly including the cross-signed intermediate certificate signed by the new root.

If you believe this is needed, please provide the following information by August 4.

1) Attach (to this bug) the cross-signed intermediate certificate that chains to the newer (non-1024-bit) root.

2) Provide a very short explanation about why the intermediate cert needs to be temporarily included.

3) Provide the date by which you expect the impacted web server administrators to have updated their web servers with the new cert chain. 

Thanks,
Kathleen

Comment 2

[Kathleen Wilson]

To clarify, we want to keep the list of directly-included intermediate certificates as small as possible. And, we would prefer that your customers (especially known enterprise customers who are still chaining up to the 1024-bit roots) update their web servers to included the new intermediate certs themselves, rather than us including their specific intermediate certs in NSS. Firefox 32 is scheduled to release on September 2, so they still have time to make these changes themselves.  For us to do this, we have to add a patch into our Beta cycle, and then at a later date make another code change to remove the intermediate certs from the NSS root store.

Comment 3

[Bruce Morton]

I believe that the issue was with sites that were provided under Bug #936304. We reviewed the certificates and found 5 were issued to other CAs. These CAs are also roots or have been issued a new 2048 cross-certificate. 

One cross-certified CA, USERTrust Legacy secure Server CA, had 90 certificates on the list. This CA has been provided a 2048 cross-certificate to mitigate any problem.

Entrust does not need any intermediate certificate to be directly-included.

Thanks, Bruce.

Comment 4

[Steven Medin]

If a chain points to a root that lacks a trust bit needed, as Brian mentioned in mds.p, it would be ideal keep looking.  Specifically, to exhaust AIA CA Issuers dynamic references before displaying failed trust UI.  Two customers are still doing testing before they swap out their AIA dynamic reference.

A further gain would be to favor TLS payload discovered paths over saved intermediates.  The connection establishment latency is worth exploring the path deeper from TLS than from the NSS stores. 

Or just wipe discovered intermediates. The speed of path decision gains they produce aren't worth the hassle they create in this situation.  Let paths discover to roots.

Comment 5

[Ryanne Fox]

GoDaddy does not need any intermediate certificate to be directly-included.

Thanks,
Ryanne

Comment 6

[Kathleen Wilson]

Attachment: USERTrust-2048.cert

CN = USERTrust Legacy Secure Server CA
Valid to: (11/1/15, 5:00:00  GMT)

Reason (from discussion in m.d.s.policy):
The particular case that Hubert mentioned at the start of this thread is the "USERTrust Legacy Secure Server CA": 2 intermediate certs containing the same Name and Public Key, one signed by a 1024-bit root and the other signed by a 2048-bit root.  i.e...

EE <- intermediate-2048 <- root-1024
EE <- intermediate-2048 <- root-2048

USERTrust Legacy Secure Server CA ceased issuing certs in September 2012, but many of those certs still have significant lifetime remaining.  All of the certificate holders were initially instructed to configure their servers to serve the chain up to the 1024-bit root.

Since then, despite efforts to persuade certificate holders to reconfigure their servers to serve the chain up to the 2048-bit root, a significant proportion of the certificate holders have left their server configuration unchanged.

I can see the attraction of bundling the second intermediate cert (signed by the 2048-bit root) with Firefox and/or NSS, especially given that Firefox/NSS doesn't attempt to fetch "missing" intermediates using AIA->caIssuers URLs.

Comment 7

[Rob Stradling]

(In reply to Kathleen Wilson from comment #6)
> Created attachment 8464119 [details]
> USERTrust-2048.cert

Thanks Kathleen.  Just to confirm: Comodo would like this intermediate to be (temporarily) included in NSS.


(In reply to Bruce Morton from comment #3)
<snip>
> One cross-certified CA, USERTrust Legacy secure Server CA, had 90
> certificates on the list. This CA has been provided a 2048 cross-certificate
> to mitigate any problem.

We did a scan yesterday and found several thousand servers that are still serving the "USERTrust Legacy Secure Server CA" intermediate that chains to the 1024-bit Entrust Root.

We have tried to contact these customers several times already.  Yes, the 2048 cross-certificate (attachment 8464119 [details]) has the potential "to mitigate any problem", but only if it can be distributed to all affected clients.  And given that many of the certificate holders can't be persuaded to install it on their servers, the only remaining options are to (1) implement the mechanism in this bug or (2) face a barrage of customer/user complaints shortly after FF32 is released!

Comment 8

[Kathleen Wilson]

I have filed Bug #1046343 to backout the changes to remove the GTE CyberTrust Global Root. This approach to temporarily include a small number of intermediate certs will not work for the "GTE CyberTrust Global Root" cert, so we need more time to figure out a transition plan for that root.

Comment 9

[Kai Engert (:KaiE:)]

As it has been decided that the "USERTrust Legacy Secure Server CA" intermediate CA cert, issued by the 2048 bit root "Entrust.net Certification Authority (2048)", with SHA1 fingerprint 4A:7E:DF:9D:AA:89:55:F8:00:F8:27:6E:C7:0E:9C:44:26:74:16:C7 as attached to this bug, will be the only intermediate CA cert to be included with NSS 3.16.4, I'm updating the bug summary to reflect the current plan.

Comment 10

[Kai Engert (:KaiE:)]

Subject: "CN=USERTrust Legacy Secure Server CA,O=The USERTRUST Network,L=Salt Lake City,ST=UT,C=US"

Issuer: "CN=Entrust.net Certification Authority (2048),OU=(c) 1999 Entrust.net Limited,OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.),O=Entrust.net"

Serial Number: 946071786 (0x3863e8ea)

Fingerprint (SHA1): 4A:7E:DF:9D:AA:89:55:F8:00:F8:27:6E:C7:0E:9C:44:26:74:16:C7

Comment 11

[Kai Engert (:KaiE:)]

Attachment: v1 - usertrust-intermediate-1045189.patch (based on intermediate with nonworking date/time)

Comment 12

[Kai Engert (:KaiE:)]

I've started a "try" build, which includes the patches for this bug and for bug 1046343.
(https://tbpl.mozilla.org/?tree=Try&rev=6f6e8837987a - note that site currently has issues loading, you must retry until it works.)

I'll submit the link to the downloadable build once it's completed (within a few hours).

I suggest that we use the www.groupon.my web site for testing the effectiveness of the included intermediate. 

If I understand correctly, current mozilla-central nightlies should fail to load that web site, because that site still attempts to chain to the old root, but the old root has been removed.

With the experimental "try" build, which contains the attached patch, that web site is expected to load, because we supply the intermediate.

There's one detail that has been mentioned once in discussions, but which we might not have checked yet, have we? The question is, does the new intermediate (attached to this bug) have a newer date/time value than the older one? I'll try to check, IIUC I should see that intermediate when downloading the cert chain from the groupon site.

Comment 13

[Kai Engert (:KaiE:)]

(In reply to Kai Engert (:kaie) from comment #12)
> There's one detail that has been mentioned once in discussions, but which we
> might not have checked yet, have we? The question is, does the new
> intermediate (attached to this bug) have a newer date/time value than the
> older one? I'll try to check, IIUC I should see that intermediate when
> downloading the cert chain from the groupon site.


old intermediate, e.g. sent by the groupon server:
Subject: "CN=USERTrust Legacy Secure Server CA,O=The USERTRUST Network,L=Salt Lake City,ST=UT,C=US"
Issuer: "CN=Entrust.net Secure Server Certification Authority,OU=(c) 1999 Entrust.net Limited,OU=www.entrust.net/CPS incorp. by ref. (limits liab.),O=Entrust.net,C=US"
        Serial Number: 1184831531 (0x469f182b)
        Validity:
            Not Before: Thu Nov 26 20:33:13 2009
            Not After : Sun Nov 01 04:00:00 2015


the replacement intermediate we plan to include:
Subject: "CN=USERTrust Legacy Secure Server CA,O=The USERTRUST Network,L=Salt Lake City,ST=UT,C=US"
Issuer: "CN=Entrust.net Certification Authority (2048),OU=(c) 1999 Entrust.net Limited,OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.),O=Entrust.net"
        Serial Number: 946071786 (0x3863e8ea)
        Validity:
            Not Before: Thu Nov 26 20:05:16 2009
            Not After : Sun Nov 01 05:00:00 2015


When given the choice of the above two certificates for chaining, which use an identical subject, the legacy NSS chaining code will try only one path. It will decide which certificate to use based on the validity time/date. It will pick the one that looks newer.

Unfortunately, the time/date of the certificates don't indicate a clear "winner". 
The dates are identical, and the times are:

        old: 20:33:13 - 04:00:00
replacement: 20:05:16 - 05:00:00


I don't remember which field NSS will check first.

If NSS starts by checking the "not before" value, it will decide the "old" cert is newer, will prefer it, will ignore our replacement intermediate, and our plan fails.

If NSS starts by checking the "not after" value, it will decide the "replacement" cert is newer, will prefer it, and our plan works.

Comment 14

[Kai Engert (:KaiE:)]

(In reply to Kai Engert (:kaie) from comment #12)
> I'll submit the link to the downloadable build once it's completed (within a
> few hours).

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-6f6e8837987a/

(at the time of this comment, only linux builds are ready yet, but the others should become available soon)

Comment 15

[Kai Engert (:KaiE:)]

Direct link to the patch used in the try build:
https://hg.mozilla.org/try/rev/6f6e8837987a

Comment 16

[Kai Engert (:KaiE:)]

It looks like we're lucky.
I can successfully open https://www.groupon.my with the try build.
(It fails with todays nightly build.)

Comment 17

[Kathleen Wilson]

I just tested with the MacOS version of the try build, and it works for me too.

I don't know how to test with the legacy NSS chaining code in the try build.

Comment 18

[Rashmi Tabada]

Hi Kathleen,

Thank you for the transition mitigation.
Please trust "VERISIGN CLASS 3 SECURE SERVER CA - G2" to mitigate the impact on customers (from the 1024 root removal). I will send the ICA via email to you.

Thank you,
Rashmi

Comment 19

[Kathleen Wilson]

(In reply to Rashmi Tabada from comment #18)
> Please trust "VERISIGN CLASS 3 SECURE SERVER CA - G2" to mitigate the impact
> on customers (from the 1024 root removal). I will send the ICA via email to
> you.

The cert you sent me is a 1024-bit cert. Our intent is to remove 1024-bit certs from NSS, so we will not include this 1024-bit intermediate cert.

The idea of this transition plan is that for sites that present a chain like this:
2048 bit host cert <- 1024 bit old sub CA <- 1024 bit root CA
we can find a certificate chain like this:
2048 bit host cert <- 2048 bit cross-signed sub CA <- 2048 bit root CA
where the cross-signed sub CA is shipped by NSS

Comment 20

[Kai Engert (:KaiE:)]

(In reply to Kathleen Wilson from comment #17)
> I don't know how to test with the legacy NSS chaining code in the try build.

I just tried using the linux version of the Firefox 24.7.0 (ESR) release. I replaced the file libnssckbi.so with the one contained in the try build.

It didn't work. I get an error on the secure groupon site. It uses the chain to the 1024bit intermediate, despite the fact that the 2048bit intermediate is present in cert manager.

So, while including the intermediate in NSS will help users of Firefox 31 and later (those that use mozilla::pkix), it seems like it won't help any other software that relies on the legacy NSS chain validation code.

Comment 21

[Kai Engert (:KaiE:)]

Because this intermediate is intended to help Firefox 32, it should still be sufficient reason to ship it with NSS.

Comment 22

[Rashmi Tabada]

(In reply to Kathleen Wilson from comment #19)

the intermediate I sent should have been a 2048-bit root. I've appended it below. Please confirm.  Thanks.

-----BEGIN CERTIFICATE-----
MIIGLDCCBZWgAwIBAgIQbk/6s8XmacTRZ8mSq+hYxDANBgkqhkiG9w0BAQUFADCB
wTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQL
EzNDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5
IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1
dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv
cmswHhcNMDkwMzI1MDAwMDAwWhcNMTkwMzI0MjM1OTU5WjCBtTELMAkGA1UEBhMC
VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEvMC0GA1UEAxMmVmVyaVNpZ24gQ2xh
c3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQDUVo9XOzcopkBj0pXVBXTatRlqltZxVy/iwDSMoJWzjOE3JPMu
7UNFBY6J1/raSrX4Po1Ox/lJUEU3QJ90qqBRVWHxYISJpZ6AjS+wIapFgsTPtBR/
RxUgKIKwaBLArlwH1/ZZzMtiVlxNSf8miKtUUTovStoOmOKJcrn892g8xB85essX
gfMMrQ/cYWIbEAsEHikYcV5iy0PevjG6cQIZTiapUdqMZGkD3pz9ff17Ybz8hHyI
XLTDe+1fK0YS8f0AAZqLW+mjBS6PLlve8xt4+GaRCMBeztWwNsrUqHugffkwer/4
3RlRKyC6/qfPoU6wZ/WAqiuDLtKOVImOHikLAgMBAAGjggKpMIICpTA0BggrBgEF
BQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTAS
BgNVHRMBAf8ECDAGAQH/AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwMwVjAo
BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL2NwczAqBggrBgEF
BQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQtMCsw
KaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMtZzIuY3JsMA4GA1Ud
DwEB/wQEAwIBBjBtBggrBgEFBQcBDARhMF+hXaBbMFkwVzBVFglpbWFnZS9naWYw
ITAfMAcGBSsOAwIaBBSP5dMahqyNjmvDz4Bq1EgYLHsZLjAlFiNodHRwOi8vbG9n
by52ZXJpc2lnbi5jb20vdnNsb2dvLmdpZjApBgNVHREEIjAgpB4wHDEaMBgGA1UE
AxMRQ2xhc3MzQ0EyMDQ4LTEtNTIwHQYDVR0OBBYEFKXvCxHOwEEDo0plkEiyHOBX
LX1HMIHnBgNVHSMEgd8wgdyhgcekgcQwgcExCzAJBgNVBAYTAlVTMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMyBQdWJsaWMgUHJpbWFy
eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5
OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrghB92f4Hz6getxB5Z/uniTTGMA0G
CSqGSIb3DQEBBQUAA4GBAGN0Lz1Tqi+X7CYRZhr+8d5BJxnSf9jBHPniOFY6H5Cu
OcUgdav4bC1nHynCIdcUiGNLsJsnY5H48KMBJLb7j+M9AgtvVP7UzNvWhb98lR5e
YhHB2QmcQrmy1KotmDojYMyimvFu6M+O0Ro8XhnF15s1sAIjJOUFuNWI4+D6ufRf
-----END CERTIFICATE-----

Comment 23

[Kathleen Wilson]

(In reply to Rashmi Tabada from comment #22)
> (In reply to Kathleen Wilson from comment #19)
> 
> the intermediate I sent should have been a 2048-bit root. I've appended it
> below. Please confirm.  Thanks.
> 

I saved the certificate content into "anothertry.cert" ...
kathleenwilson$ ~/nssbin/pp -t certificate -i anothertry.cert -a
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:4f:fa:b3:c5:e6:69:c4:d1:67:c9:92:ab:e8:58:c4
        Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
        Issuer: "OU=VeriSign Trust Network,OU="(c) 1998 VeriSign, Inc. - For
            authorized use only",OU=Class 3 Public Primary Certification Auth
            ority - G2,O="VeriSign, Inc.",C=US"
        Validity:
            Not Before: Wed Mar 25 00:00:00 2009
            Not After : Sun Mar 24 23:59:59 2019
        Subject: "CN=VeriSign Class 3 Secure Server CA - G2,OU=Terms of use a
            t https://www.verisign.com/rpa (c)09,OU=VeriSign Trust Network,O=
            "VeriSign, Inc.",C=US"
...

So, the cert is "CN=VeriSign Class 3 Secure Server CA - G2". 
And the issuer is "OU=Class 3 Public Primary Certification Authority - G2".

The only "Class 3 Public Primary Certification Authority - G2" root I see in the Certificate Manager is a 1024-bit root.

Comment 24

[Kathleen Wilson]

We are discussing *not* using this transition path for this first batch of 1024-bit root removals.
https://groups.google.com/d/msg/mozilla.dev.security.policy/JFGRyr4-F44/v0uR5XETlyoJ

Comment 25

[Rick Andrews]

Kathleen, I guess we misunderstood. We thought that you were going to trust an existing 2048-bit intermediate that chained up to a 1024-bit root. In comment 19, you say that you're looking for a 2048-bit cross-certificate that chains up to a 2048-bit root. We haven't issued any cross-certificate. So if that's the only option, I guess we can't take advantage of this.

Comment 26

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Rick Andrews from comment #25)
> Kathleen, I guess we misunderstood. We thought that you were going to trust
> an existing 2048-bit intermediate that chained up to a 1024-bit root. In
> comment 19, you say that you're looking for a 2048-bit cross-certificate
> that chains up to a 2048-bit root. We haven't issued any cross-certificate.
> So if that's the only option, I guess we can't take advantage of this.

Why don't you just create that cross-certificate? It doesn't even need to be a cross-certificate signed by a root; it could be a cross-certificate signed by any of your 2048-bit intermediaries (as long as other constraints, in particular the path length constraint, aren't violated).

Comment 27

[Kathleen Wilson]

It's too late for this batch of 1024-bit root changes, but worth considering for the upcoming 1024-bit root changes -- Bug #986014 (Thawte/Symantec 1024-bit roots) and Bug #986019 (Equifax/Symantec 1024-bit roots). Please continue investigation for those bugs. Thanks.

Comment 28

[Rob Stradling]

Attachment: USERTrustLegacySecureServerCA_3.crt

(In reply to Kathleen Wilson from comment #24)
> We are discussing *not* using this transition path for this first batch of
> 1024-bit root removals.
> https://groups.google.com/d/msg/mozilla.dev.security.policy/JFGRyr4-F44/
> v0uR5XETlyoJ

Kathleen noted that the "USERTrust Legacy Secure Server CA" intermediate issued by the 1024-bit Entrust root has a newer notBefore date/time than the one issued by the 2048-bit Entrust root, and that this causes unhappiness with the "classic" NSS path building code.

To workaround this issue, I'm attaching yet another intermediate cert that we've just issued to this intermediate CA.  This intermediate cert has a notBefore date of today, and it was issued by our 2048-bit "AddTrust External CA Root" built-in root.

Please include this new intermediate cert instead of the one in attachment 8464119 [details] in NSS 3.16.4.  Thanks.

Comment 29

[Kai Engert (:KaiE:)]

Attachment: patch v3, based on USERTrustLegacySecureServerCA_3.crt

patch based on attachment 8467646 [details]

Comment 30

[Rob Stradling]

(In reply to Kai Engert (:kaie) from comment #29)
> Created attachment 8467675 [details] [diff] [review]
> patch v3, based on USERTrustLegacySecureServerCA_3.crt
> 
> patch based on attachment 8467646 [details]

Thanks Kai!

Comment 31

[Kai Engert (:KaiE:)]

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://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-8a0a7ea6cc4a/

I could visit the groupon site successfully.

In addition, I tested a Firefox 24.7 release, combined with the trust module from the try build. That worked, too.

This means, the new intermediate seems to work correctly, both with mozilla::pkix from Firefox 32 and with the NSS legacy code in Firefox 24.7

Comment 32

[Kathleen Wilson]

(In reply to Rob Stradling from comment #28)
> To workaround this issue, I'm attaching yet another intermediate cert that
> we've just issued to this intermediate CA.  This intermediate cert has a
> notBefore date of today, and it was issued by our 2048-bit "AddTrust
> External CA Root" built-in root.
> 
> Please include this new intermediate cert instead of the one in attachment
> 8464119 [details] in NSS 3.16.4.  Thanks.


I am OK with this strategy, and the new cert looks fine to me. I also noted that it still expires on November 1, 2015 (which is good).

Does anyone else want to double-check the new cert?

Thanks,
Kathleen

Comment 33

[Kai Engert (:KaiE:)]

branch checkin for 3.16.4:
https://hg.mozilla.org/projects/nss/rev/dbbcf3107000

Comment 34

[Kai Engert (:KaiE:)]

trunk checkin for 3.17:
https://hg.mozilla.org/projects/nss/rev/71c5e72d1ba7

fixed

Comment 35

[Sylvestre Ledru [:Sylvestre]]

Kai, I guess this bug is going to be fixed with the new uplift of nss, right?

Comment 36

[Kai Engert (:KaiE:)]

(In reply to Sylvestre Ledru [:sylvestre] from comment #35)
> Kai, I guess this bug is going to be fixed with the new uplift of nss, right?

This bug is fixed in NSS 3.16.4, so any Firefox branches that picked up NSS 3.16.4 got this fix.

Comment 37

[Kathleen Wilson]

(In reply to Kai Engert (:kaie) from comment #36)
> (In reply to Sylvestre Ledru [:sylvestre] from comment #35)
> > Kai, I guess this bug is going to be fixed with the new uplift of nss, right?
> 
> This bug is fixed in NSS 3.16.4, so any Firefox branches that picked up NSS
> 3.16.4 got this fix.


Bug #1048876 indicates which Firefox releases picked up NSS 3.16.4.

Comment 38

[Lawrence Mandel [:lmandel] (use needinfo)]

Marking 32 as fixed based on comment 37. Do we need to uplift 3.16.4 to 33?

Comment 39

[Kai Engert (:KaiE:)]

(In reply to Lawrence Mandel [:lmandel] from comment #38)
> Marking 32 as fixed based on comment 37. Do we need to uplift 3.16.4 to 33?

The Firefox 33 branch already uses NSS 3.17, which is newer, and includes these changes, too.

Comment 40

[Lawrence Mandel [:lmandel] (use needinfo)]

Kai - Is this worth adding to our release notes? If so, can you suggest the wording for the note?

Comment 41

[Kathleen Wilson]

(In reply to Lawrence Mandel [:lmandel] from comment #40)
> Kai - Is this worth adding to our release notes? If so, can you suggest the
> wording for the note?

I just sent you email about this. We can certainly mention that this intermediate is being temporarily included to help with the transition off of a 1024-bit root, but I think it's more important to talk about the other 1024-bit root changes that are in Firefox 32. My email has the details.

Thanks,
Kathleen

Comment 42

[Sylvestre Ledru [:Sylvestre]]

33 and 34 are fixed (cf comment #39)

Comment 43

[Sylvestre Ledru [:Sylvestre]]

Too late for the 32 release notes.