986005 - Turn off SSL and Code Signing trust bits for VeriSign 1024-bit roots

Status: RESOLVED FIXED

(NSS :: CA Certificates Code, task)

Description

[Kathleen Wilson]

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

> VeriSign, Inc.
> Class 3 Public Primary Certification Authority	
> VeriSign Class 3 Public PCA	
> 1996 Jan 29	
> 2028 Aug 02	
> SHA-1
> SHA1 Fingerprint: A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B

> VeriSign, Inc.	
> Class 3 Public Primary Certification Authority	
> VeriSign Class 3 Public PCA	
> 1996 Jan 29	
> 2028 Aug 01	
> MD2
> SHA1 Fingerprint: 74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2

> VeriSign, Inc.	
> VeriSign Trust Network	
> VeriSign Class 2 Public PCA – G2	
> 1998 May 18	
> 2028 Aug 01	
> SHA-1
> SHA1 Fingerprint: B3:EA:C4:47:76:C9:C8:1C:EA:F2:9D:95:B6:CC:A0:08:1B:67:EC:9D
Note: The websites trust bit is not currently enabled, so only need to turn off the Code Signing trust bit for this one.

Comment 1

[Kathleen Wilson]

A Test Build with these changes has been created as part of Bug #1021967.
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-394c2eeb9793/

I have already checked/tested it, but you are all welcome to check it too.

Comment 2

[Matt Wobensmith [:mwobensmith][:matt:]]

A compatibility test run of 200,000+ SSL-enabled sites only found three affected:

https://wissen.harvardbusinessmanager.de
https://www.colissimo.fr
https://store.cybercable.net.mx 

I will revisit this testing with a data set of one million sites as time permits.

Comment 3

[Kai Engert [:KaiE:]]

fixed as part of bug 1021967

Comment 4

[Kai Engert [:KaiE:]]

Fallout from this change:
https://lists.fedoraproject.org/pipermail/devel/2014-September/202127.html

In short, the s3.amazonaws.com still includes an intermediate that points to one of these old root.

Although NSS is able to ignore the unnecessary intermediate, and finds a chain from the first intermediate to the trusted G5 root, other certificate validation software fails to do so. I believe it's openssl who fails.

I think Symantec should reach out to Amazon, and potentially to other customers, too, and suggest to remove intermediates from their server configurations that point to these old roots.

Comment 5

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

Peter, see comment 4.

Comment 6

[Peter Bowen]

Brian, thanks for the pointer.  I will work with our team to see about getting our cert chains updated for S3.  Leaving in needinfo until I have more data.

Comment 7

[Gervase Markham [:gerv]]

Restoring needinfo.

Gerv

Comment 8

[Peter Bowen]

I cannot find any standards on how a PKIX library is supposed to select a trust anchor from a known list when doing chain validation.  OpenSSL appears to select purely based on the last certificate in the chain ignoring the possibility that some certificates in the chain are unnecessary to create a valid chain from a known trust anchor to the end entity certificate.

NSS does consider this possibility, so I'm not sure if it is relevant to continue the discussion in this bug, as removing these roots will not break apps using NSS.

Comment 9

[Ryan Sleevi]

Peter: See RFC 4158. RFC 5280 presumes (and is clear) that you have explicitly discovered/built a candidate path and want to verify it. RFC 4158 describes the way the PKI works, and considerations that an application library should take into mind.

OpenSSL 1.0.1 has better support for explicit trust anchors as intermediates (e.g. matching Windows/OS X/NSS in treating TAs as any arbitrary key/sig pair, and not just as a self-signed root cert), and OpenSSL 1.1.0+ have improved selection algorithms.

You're correct that OpenSSL (and, unfortunately, Android) have less-than-ideal methods for path construction, and this causes real world issues. mozilla::pkix is one way that you could resolve OpenSSL, by porting the [2? 3?] bits that use NSS to use OpenSSL. Almost everything else in mozilla::pkix is portable, mod the C++11 conventions (that also make it problematic for Chrome)

Comment 10

[Julien Gilli]

Matt, I'm interested to know more about the "compatibility test run of 200,000+ SSL-enabled sites" you mentioned in your comment. Is it a program that has been written specifically for this change? Is it available somewhere?

Thank you!

Comment 11

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Julien, I think this is it: https://github.com/mozilla/pkix-compatibility-testing/

Comment 12

[Julien Gilli]

Thank you David, that is very helpful!