Closed Bug 986014 Opened 10 years ago Closed 10 years ago

Second phase of removing 1024-bit roots - Thawte, VeriSign, and Equifax

Categories

(NSS :: CA Certificates Code, task)

Product:
NSS
Component:
CA Certificates Code
Version:
3.17.3
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kathleen.a.wilson, Unassigned)

References

Details

(Whiteboard: Changes are in NSS 3.17.3, Firefox 36) 

Please remove the following two 1024-bit root certificates owned by Symantec.

> Thawte Consulting cc	
> Certification Services Division	
> Thawte Server CA	
> 1996 Aug 01	
> 2020 Dec 31	
> MD5
> SHA1 Fingerprint: 23:E5:94:94:51:95:F2:41:48:03:B4:D5:64:D2:A3:A3:F5:D8:8B:8C
Note: The Websites and Code Signing trust bits are currently enabled (email trust bit not currently enabled.)


> Thawte Consulting cc	
> Certification Services Division	
> Thawte Premium Server CA	
> 1996 Aug 01	
> 2020 Dec 31	
> MD5
> SHA1 Fingerprint: 62:7F:8D:78:27:65:63:99:D2:7D:7F:90:44:C9:FE:B3:F3:3E:FA:9A
Note: The Websites and Code Signing trust bits are currently enabled (email trust bit not currently enabled.)


Additionally, please turn off the WebSites and Code Signing trust bits for the following 1024-bit root certificates owned by Symantec.

> VeriSign, Inc.	
> VeriSign Trust Network	
> VeriSign Class 3 Public PCA – G2	
> 1998 May 18	
> 2028 Aug 01	
> SHA-1
> SHA1 Fingerprint: 85:37:1C:A6:E5:50:14:3D:CE:28:03:47:1B:DE:3A:09:E8:F8:77:0F

> Equifax Secure Inc.		
> Equifax Secure eBusiness CA-1	
> 1999 Jun 21	
> 2020 Jun 21	
> MD5
> SHA1 Fingerprint: DA:40:18:8B:91:89:A3:ED:EE:AE:DA:97:FE:2F:9D:F5:B7:D1:8A:41
Whiteboard: Target Firefox 32
Whiteboard: Target Firefox 32 → Target Firefox 33
Looking at the certs of the first 10, they all appear to be 4- or 5-year certs issued in 2010.

Do we know if Verisign has been reaching out to their customers about this issue?

Gerv
Yes, Symantec/VeriSign has been reaching out to their customers with 1024-bit certs and trying to get them to switch to newer certs for quite a while now. They have many customers who have not responded to their requests to switch to newer certs.

We're doing this compatibility testing to find out what will still break when these roots are removed. Hopefully this information regarding the "top 200,000" sites will help Symantec in regards to which customers they may want to specifically reach out to.
Rick, Please see Bug #1045189 and let us know if we should consider temporarily directly including a cross-signed intermediate cert in order to help with the transition off of these 1024-bit roots. If yes, please attach the intermediate cert(s) to this bug.
Whiteboard: Target Firefox 33 → Target Firefox 35
We're meeting internally to discuss this. In the future, please use DL-ENG-Root-Certificate-Management@symantec.com in case I'm away from the office (which I was!).
(In reply to Rick Andrews from comment #5)
> We're meeting internally to discuss this. In the future, please use
> DL-ENG-Root-Certificate-Management@symantec.com in case I'm away from the
> office (which I was!).

For that to happen within Bugzilla, I think you need to create a Bugzilla account for that email address, and then CC that email address on the Bugs that you want.
https://bugzilla.mozilla.org/createaccount.cgi


Please update this bug to let us know if it would make sense to temporarily directly include a cross-signed intermediate cert in order to help with the transition off of any of these 1024-bit roots.
The idea 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 temporarily shipped by NSS to help with the transition.
We would like to take you up on your offer, and create a 2048-bit cross-certificate that would chain up to a 2048-bit root. We have one technical limitation, though, in that we would not be able to support OCSP for this intermediate (it wouldn't contain an AIA extension, but it would have a CDP). Is that acceptable to Mozilla? If we had to revoke it, we would of course notify Mozilla and you could blacklist the cert.
(In reply to Rick Andrews from comment #7)
> We would like to take you up on your offer, and create a 2048-bit
> cross-certificate that would chain up to a 2048-bit root. We have one
> technical limitation, though, in that we would not be able to support OCSP
> for this intermediate (it wouldn't contain an AIA extension, but it would
> have a CDP). Is that acceptable to Mozilla? If we had to revoke it, we would
> of course notify Mozilla and you could blacklist the cert.

Yes. I checked with the NSS team, and we are OK with the cross-certificate not containing an OCSP URI in the AIA. It would mean that if a problem does occur we would have to actively distrust the cross-certificate that we included.
Please attach the cross-certificate(s) to this bug, then we will provide a test build.

We are targeting Firefox 35 for this set of root changes, so we should target having the testing completed in September.
https://wiki.mozilla.org/RapidRelease/Calendar
Kathleen, we tried some basic testing (before doing anything with a cross certificate) by unchecking the "web sites" trust bit for VeriSign Class 3 Public PCA – G2 and then visiting a site that has a cert that chains up to that root (https://ssltest24.bbtest.net/), and we don't get any error message saying that the site is untrusted.

I see a new button called "Delete or Distrust...", and if I click that, I get the error message. 

In the past, you have said that unchecking the "web sites" trust bit was equivalent to removing the root for SSL purposes. Now it seems that has changed. Am I correct? Do you have any updated guidance on how we should test?
Rick, can you try this in a brand new profile? 

https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Also, make the change to the certificate trust settings before you load the site and see if you get different behavior.
(In reply to Rick Andrews from comment #10)
> Kathleen, we tried some basic testing (before doing anything with a cross
> certificate) by unchecking the "web sites" trust bit for VeriSign Class 3
> Public PCA – G2 and then visiting a site that has a cert that chains up to
> that root (https://ssltest24.bbtest.net/), and we don't get any error
> message saying that the site is untrusted.


That's probably due to caching. Please close the tab that you used to browse to the test site, then "Clear Recent History...". Then open a new tab and try browsing to the test site.

After doing this (and making sure I had turned off the trust bits for the correct root), I got the error message.



> 
> I see a new button called "Delete or Distrust...", and if I click that, I
> get the error message. 
> 
> In the past, you have said that unchecking the "web sites" trust bit was
> equivalent to removing the root for SSL purposes. Now it seems that has
> changed. Am I correct? Do you have any updated guidance on how we should
> test?

When you click on "Delete or Distrust..." it says: "You have requested to delete these CA certificates. For built-in certificates all trust will be removed, which has the same effect."

So, it's the same as unchecking the "web sites" trust bit.

I suspect you just ran into some browser history caching.
Thanks, Kathleen. Clearing Recent History did the trick.

Here's the intermediate we'd like you to include when you untrust VeriSign Class 3 Public PCA – G2:

-----BEGIN CERTIFICATE-----
MIIFOTCCBCGgAwIBAgIQH1Mq+vhUk9eCa1kw1lFZQDANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMDkwMzI1MDAwMDAwWhcNMTkwMzI0MjM1OTU5WjCBtTEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg
aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEvMC0GA1UEAxMmVmVy
aVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzIwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDUVo9XOzcopkBj0pXVBXTatRlqltZxVy/iwDSM
oJWzjOE3JPMu7UNFBY6J1/raSrX4Po1Ox/lJUEU3QJ90qqBRVWHxYISJpZ6AjS+w
IapFgsTPtBR/RxUgKIKwaBLArlwH1/ZZzMtiVlxNSf8miKtUUTovStoOmOKJcrn8
92g8xB85essXgfMMrQ/cYWIbEAsEHikYcV5iy0PevjG6cQIZTiapUdqMZGkD3pz9
ff17Ybz8hHyIXLTDe+1fK0YS8f0AAZqLW+mjBS6PLlve8xt4+GaRCMBeztWwNsrU
qHugffkwer/43RlRKyC6/qfPoU6wZ/WAqiuDLtKOVImOHikLAgMBAAGjggEsMIIB
KDASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg
pB4wHDEaMBgGA1UEAxMRQ2xhc3MzQ0EyMDQ4LTEtNTIwHQYDVR0OBBYEFKXvCxHO
wEEDo0plkEiyHOBXLX1HMGYGA1UdIARfMF0wWwYLYIZIAYb4RQEHFwMwTDAjBggr
BgEFBQcCARYXaHR0cHM6Ly9kLnN5bWNiLmNvbS9jcHMwJQYIKwYBBQUHAgIwGRoX
aHR0cHM6Ly9kLnN5bWNiLmNvbS9ycGEwLwYDVR0fBCgwJjAkoCKgIIYeaHR0cDov
L3Muc3ltY2IuY29tL3BjYTMtZzUuY3JsMB8GA1UdIwQYMBaAFH/TZafC3ey78DAJ
80M5+gKvMzEzMA0GCSqGSIb3DQEBBQUAA4IBAQAAtPxa2U5Ow7cG37CsplsUc4Xc
CvzXnzFXu6bykofrAC/zfYjmE4TKrMXKOte9hLcQ8FoPyMV087xA6USOCFUNh12s
5WMI9oo9LHnZniKKVT0aLb1AiJ+skAWC7f9Pq0ju/WfGxzMy1yxM+twexEyEECud
TYzDPuRO0/19Jmj1QPeEAMnsCMX7ynwvLeEak2c4Pr2rMwbrVMzhzCtk0jtxN2kE
yOp4TmeqIjEKu0P6jTiZp8pW+91xjPbwNzI3IRwpHQj3xrT4OU07d4i3e9Tvc+0N
4NplVvnFtdlSmKsTg/sYFo0Q78IDCaS9/3/45cscKNkma0+6vnxUs9jkZNWd
-----END CERTIFICATE-----
(In reply to Rick Andrews from comment #13)
> Thanks, Kathleen. Clearing Recent History did the trick.
> 
> Here's the intermediate we'd like you to include when you untrust VeriSign
> Class 3 Public PCA – G2:

I just tested it, and with this intermediate (and turning off trust bits for the old 1024-bit root), I get a valid cert chain of 2048-bit certs, chaining to a 2048-bit root that is included in NSS.

Rick, is that the only intermediate cert Symantec needs included to help with the transition off of the root certs listed in this bug?
Yes, thanks. This is the only intermediate for this bug.
Excellent!

We'll provide a test build for this bug soon.
Data has been provided to show which sites will be impacted by these changes:
https://groups.google.com/d/msg/mozilla.dev.security.policy/N1myPWWp3mc/JF0zhQmpcAMJ
(In reply to Kathleen Wilson from comment #17)
> Data has been provided to show which sites will be impacted by these changes:
> https://groups.google.com/d/msg/mozilla.dev.security.policy/N1myPWWp3mc/
> JF0zhQmpcAMJ

This data shows that 27 websites (out of the Alexa top 1 million sites) will become untrusted when the changes in this bug are made.

Symantec, Please contact the owners of the 27 websites that will become untrusted when Firefox 35 is released. ( https://wiki.mozilla.org/RapidRelease/Calendar )
Also, note that the changes will be in an NSS release in early October, so others who use NSS directly will notice the changes earlier.
(In reply to Rick Andrews from comment #13)
> Thanks, Kathleen. Clearing Recent History did the trick.
> 
> Here's the intermediate we'd like you to include when you untrust VeriSign
> Class 3 Public PCA – G2:
> 
> -----BEGIN CERTIFICATE-----
> MIIFOTCCBCGgAwIBAgIQH1Mq+vhUk9eCa1kw1lFZQDANBgkqhkiG9w0BAQUFADCB
> yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
> ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
> U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
> ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
> aG9yaXR5IC0gRzUwHhcNMDkwMzI1MDAwMDAwWhcNMTkwMzI0MjM1OTU5WjCBtTEL
> MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
> ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg
> aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEvMC0GA1UEAxMmVmVy
> aVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzIwggEiMA0GCSqGSIb3
> DQEBAQUAA4IBDwAwggEKAoIBAQDUVo9XOzcopkBj0pXVBXTatRlqltZxVy/iwDSM
> oJWzjOE3JPMu7UNFBY6J1/raSrX4Po1Ox/lJUEU3QJ90qqBRVWHxYISJpZ6AjS+w
> IapFgsTPtBR/RxUgKIKwaBLArlwH1/ZZzMtiVlxNSf8miKtUUTovStoOmOKJcrn8
> 92g8xB85essXgfMMrQ/cYWIbEAsEHikYcV5iy0PevjG6cQIZTiapUdqMZGkD3pz9
> ff17Ybz8hHyIXLTDe+1fK0YS8f0AAZqLW+mjBS6PLlve8xt4+GaRCMBeztWwNsrU
> qHugffkwer/43RlRKyC6/qfPoU6wZ/WAqiuDLtKOVImOHikLAgMBAAGjggEsMIIB
> KDASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg
> pB4wHDEaMBgGA1UEAxMRQ2xhc3MzQ0EyMDQ4LTEtNTIwHQYDVR0OBBYEFKXvCxHO
> wEEDo0plkEiyHOBXLX1HMGYGA1UdIARfMF0wWwYLYIZIAYb4RQEHFwMwTDAjBggr
> BgEFBQcCARYXaHR0cHM6Ly9kLnN5bWNiLmNvbS9jcHMwJQYIKwYBBQUHAgIwGRoX
> aHR0cHM6Ly9kLnN5bWNiLmNvbS9ycGEwLwYDVR0fBCgwJjAkoCKgIIYeaHR0cDov
> L3Muc3ltY2IuY29tL3BjYTMtZzUuY3JsMB8GA1UdIwQYMBaAFH/TZafC3ey78DAJ
> 80M5+gKvMzEzMA0GCSqGSIb3DQEBBQUAA4IBAQAAtPxa2U5Ow7cG37CsplsUc4Xc
> CvzXnzFXu6bykofrAC/zfYjmE4TKrMXKOte9hLcQ8FoPyMV087xA6USOCFUNh12s
> 5WMI9oo9LHnZniKKVT0aLb1AiJ+skAWC7f9Pq0ju/WfGxzMy1yxM+twexEyEECud
> TYzDPuRO0/19Jmj1QPeEAMnsCMX7ynwvLeEak2c4Pr2rMwbrVMzhzCtk0jtxN2kE
> yOp4TmeqIjEKu0P6jTiZp8pW+91xjPbwNzI3IRwpHQj3xrT4OU07d4i3e9Tvc+0N
> 4NplVvnFtdlSmKsTg/sYFo0Q78IDCaS9/3/45cscKNkma0+6vnxUs9jkZNWd
> -----END CERTIFICATE-----


Subject: "CN=VeriSign Class 3 Secure Server CA - G2,OU=Terms of use at https://www.verisign.com/rpa (c)09,OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US"

Issuer: "CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU="(c) 2006 VeriSign, Inc. - For authorized use only",OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US"

Serial Number:1f:53:2a:fa:f8:54:93:d7:82:6b:59:30:d6:51:59:40

Fingerprint (SHA-256): 0E:48:FE:8D:F7:98:36:EF:81:1C:61:B3:6E:A2:C5:47:05:31:AE:80:04:1D:B6:4D:29:B6:94:B4:A1:C1:BE:1F

Fingerprint (SHA1): 44:32:01:47:89:47:51:13:62:BA:58:E2:25:3C:FD:98:3D:76:D3:24
Also, Validity of this replacement intermediate:
  Not Before: Wed Mar 25 00:00:00 2009
  Not After : Sun Mar 24 23:59:59 2019

The existing certificate with the same subject and
  Fingerprint (SHA1): 4E:B6:D5:78:49:9B:1C:CF:5F:58:1E:AD:56:BE:3D:9B:67:44:A5:E5
has the following validity times:
  Not Valid Before: Wed Nov 08 00:00:00 2006
  Not Valid After : Wed Jul 16 23:59:59 2036

The not-valid-before of the intermediate is newer than the old root, which is good.

I don't remember if that's sufficient for the NSS classic code to prefer it as a replacement (because the not-after time is older). We really need to clarify that detail... I'll ask Bob, or I'll have to find a way to test it...
I found function CERT_IsNewer()
  https://hg.mozilla.org/projects/nss/file/ad4f3b2b5897/lib/certdb/certdb.c#l2205

Since comparing cert1.notbefore with cert2.notbefore and comparing cert1.notafter and cert2.notafter gives different results, the code continues and looks at the notbefore field with a higher priority.

If cert1 has a newer notbefore, and cert1 hasn't expired yet, that's sufficient for it to be used as the newer cert.

So in our scenario, the replacement intermediate will be preferred until March 2019.
That's good.
I assume we don't require 5 years until this intermediate cert becomes unnecessary?

(If we'd still include the intermediate after march 2015, it would be ignored, and the original root ca would get preferred again.)
I realize that I made irrelevant comparisons in comment 20 and 21.

It would be necessary to compare the validity times of the replacement cert from comment 13 with the dates of the older certificate it's supposed to replace.
Can you please point us to a server that still sends out an old intermediate equivalent to the one from comment 13?

Or alternatively, could you please attach the old intermediate to this bug?
Kai, I think this site has what you need: https://ssltest24.bbtest.net/
(In reply to Rick Andrews from comment #24)
> Kai, I think this site has what you need: https://ssltest24.bbtest.net/

Thank you.

The intermediate shown on this test site has the same subject as the cert from comment 13.

Also, it has the exact same validity times:
            Not Before: Wed Mar 25 00:00:00 2009
            Not After : Sun Mar 24 23:59:59 2019

This means, the intermediate cert from comment 13 isn't helpful for the intended purpose.

In order to work in all circumstances, the replacement certificate would have to use a newer not-before date, newer by at least one second, e.g.:
  Not Before: Wed Mar 25 00:00:01 2009

(If both certificates have equal validity, one would be chosen by classic NSS code at random.)
(In reply to Kai Engert (:kaie) from comment #25)
> This means, the intermediate cert from comment 13 isn't helpful for the
> intended purpose.
> 
> In order to work in all circumstances, the replacement certificate would
> have to use a newer not-before date, newer by at least one second, e.g.:
>   Not Before: Wed Mar 25 00:00:01 2009
> 
> (If both certificates have equal validity, one would be chosen by classic
> NSS code at random.)

Kai, Thank you for looking into this.

Rick, This means that our testing worked because NSS happened to choose the correct intermediate cert, but there's a 50% chance of NSS choosing the wrong intermediate cert.

Please create a new intermediate cert that has a more recent not-before date than the old intermediate cert.
Summary: Remove Thawte 1024-bit roots → Second phase of removing 1024-bit roots - Thawte, VeriSign, and Equifax
Thanks for all the info provided above. Here's another intermediate with the start date one day later:

-----BEGIN CERTIFICATE-----
MIIFOTCCBCGgAwIBAgIQLwBuzRdwZudfo4IKeR8FrjANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMDkwMzI2MDAwMDAwWhcNMTkwMzI0MjM1OTU5WjCBtTEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg
aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEvMC0GA1UEAxMmVmVy
aVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzIwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDUVo9XOzcopkBj0pXVBXTatRlqltZxVy/iwDSM
oJWzjOE3JPMu7UNFBY6J1/raSrX4Po1Ox/lJUEU3QJ90qqBRVWHxYISJpZ6AjS+w
IapFgsTPtBR/RxUgKIKwaBLArlwH1/ZZzMtiVlxNSf8miKtUUTovStoOmOKJcrn8
92g8xB85essXgfMMrQ/cYWIbEAsEHikYcV5iy0PevjG6cQIZTiapUdqMZGkD3pz9
ff17Ybz8hHyIXLTDe+1fK0YS8f0AAZqLW+mjBS6PLlve8xt4+GaRCMBeztWwNsrU
qHugffkwer/43RlRKyC6/qfPoU6wZ/WAqiuDLtKOVImOHikLAgMBAAGjggEsMIIB
KDASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg
pB4wHDEaMBgGA1UEAxMRQ2xhc3MzQ0EyMDQ4LTEtNTIwHQYDVR0OBBYEFKXvCxHO
wEEDo0plkEiyHOBXLX1HMGYGA1UdIARfMF0wWwYLYIZIAYb4RQEHFwMwTDAjBggr
BgEFBQcCARYXaHR0cHM6Ly9kLnN5bWNiLmNvbS9jcHMwJQYIKwYBBQUHAgIwGRoX
aHR0cHM6Ly9kLnN5bWNiLmNvbS9ycGEwLwYDVR0fBCgwJjAkoCKgIIYeaHR0cDov
L3Muc3ltY2IuY29tL3BjYTMtZzUuY3JsMB8GA1UdIwQYMBaAFH/TZafC3ey78DAJ
80M5+gKvMzEzMA0GCSqGSIb3DQEBBQUAA4IBAQArjhTM7IYIYDeLbGWJJSHeL1Ki
B55Y07MWeAGZUZW0E3fMd90LXIE31r72YtYENwsYc5rT9sGiHm2cu4wR5j4SXgdf
C4NcdALgUPSxJhttxujpv025ARUZ7FCa+RHwgVhDLE0RQLNaRgimXnOhiBI1jP8D
Or3Wnfrn3Ja5GmQ+xP3ZCrZlnrqlqFj8OyLwolfuildHnHfHJeGsNAVN84J+QSO6
tFfz58YBZddNiZkcaU1eePbrcnE9ssSVAZ9dDLcvJaZceUHvnsRnPKGdf3E60JWX
7HhCdJhuvj5oTFc8qJNBhwvkua+R+1BMDLrAJCfRFdtlSCEKL9fcfqDMZX55
-----END CERTIFICATE-----
(In reply to Rick Andrews from comment #27)
> Thanks for all the info provided above. Here's another intermediate with the
> start date one day later:

I tested with this new intermediate cert, and I get the expected results.

Thanks.
Depends on: 1088147
Test builds, which remove all the roots, and adds the intermediate from comment 27, can be found here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/kaie@kuix.de-647a7fdc0b5a/
Rick, please test. Especially regarding the addition of the intermediate cert.
You should be able to use the instructions here:
https://wiki.mozilla.org/CA:How_to_apply#Testing_Inclusion
even though they are usually used for testing root inclusions, the basic steps still apply.
I have tested this on Mac OS X v10.7.5, and I get the expected results. And I see the expected changes via the Certificate Manager.
Oops. I forgot to delete my cert8.db file before testing...

After doing that, I get the Untrusted Connection error when I browse to https://ssltest24.bbtest.net/
The error is "sec_error_unknown_issuer".
But I think that the intermediate cert in Comment #27 is supposed to fix this. Right?
OK. So I created a new profile, and deleted old copies of FirefoxNightly and FirefoxDebug. Then re-did the testing.

All looks good and works as expected.

The SSL cert for https://ssltest24.bbtest.net/ chains up to the temporarily-included intermediate cert, which chains up to the VeriSign Class 3 PCA G5 root.
Our testing looks good too. Thanks for including the new intermediate.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: Target Firefox 35 → Changes are in NSS 3.17.3, Firefox 36
Version: trunk → 3.17.3
https://www.ssllabs.com/ssltest/analyze.html?d=businesscollege.fi
Notice the intermediate used chains to the 1024-bit Thawte Premium Server CA,
not the 2048-bit thawte Primary Root CA.
I wonder where this intermediate comes from. The usual arrangement is that thawte Primary Root CA chains to Thawte Premium Server CA to support older clients.
(In reply to Matt Wobensmith [:mwobensmith][:matt:] from comment #1)
> Compatibility testing of top 200000 or so SSL-enabled sites has produced a
> list of 25 incompatible sites.
> 
> This is by no means a guarantee of all affected sites. I hope to run against
> a larger data set soon.
> 
> https://knowledge.verisign-grs.com 
> https://my.oakwood.edu 
> https://network.endian.com 
> https://publicaciones.colmex.mx 
> https://ssltest29.bbtest.net/ 
> https://store.bandwear.com 
> https://www.aclens.com 
> https://www.brillenplatz.de 
> https://www.copagloja.com.br 
> https://www.cqccms.com.cn 
> https://www.datatilsynet.no 
> https://www.drewag.de 
> https://www.ejapion.com 
> https://www.gold-super-markt.de 
> https://www.gumball3000.com 
> https://www.kreativgewerbe.de 
> https://www.motor-talk.de
> https://www.nlmotoring.com 
> https://www.pctonline.com 
> https://www.recyclingtoday.com 
> https://www.todaynic.com
> https://www.uac.edu.au 
> https://www.uniklinik-ulm.de
> https://www.whitireia.ac.nz
> https://www3.rtd-denver.com

Had similar issue with 

https://www.cocoleni.de, Had to buy new SSL from ssls.com and then install it.. cost around $5 per year.

I guess all stores need SSL now, as the unsecure page label will reduce conversion rate..
You need to log in before you can comment on or make changes to this bug.