5

So Google will be moving to distrust the “Class 3 Public Primary CA” root certificate operated by Symantec Corporation, across Chrome, Android, and Google products, because it is no longer going to adhere to the CA/Browser Forum’s Baseline Requirements.

However, the blog post says that

Symantec has indicated that they do not believe their customers, who are the operators of secure websites, will be affected by this removal. Further, Symantec has also indicated that, to the best of their knowledge, they do not believe customers who attempt to access sites secured with Symantec certificates will be affected by this.

How comes that?

UPDATE (after StackzOfZtuff's answer):

Some websites were actually affected (for instance, Netflix). The revocation has been temporarily reverted

Mario Trucco
  • 1,549
  • 2
  • 10
  • 25
  • 1
    Dunno. Maybe Symantec has migrated away from that root CA a long time ago, and all issued certificates have long since expired. But they better be right. Because: They certainly have a LOT of sub-CAs. (See [*Graph* section here](https://ssl-tools.net/subjects/48b76449f3d5fefa1133aa805e420f0fca643651). See [*Child CAs* section here](https://crt.sh/?caid=25).) – StackzOfZtuff Dec 13 '15 at 11:44
  • 2
    @Stackz &Mano:The Verisign G1 roots were issued in 1996 and have 1024-bit RSA keys which have been widely deprecated or even prohibited for two years now. Verisign-now-Symantec has been using **G5** root(s) **since 2007** at least for 'normal' SSL certs; I remember needing to update some reliers for it circa 2008. They provided a 'bridge' cert from G5 back to G1 (which with one for G3 are much of the fanout in the graphs you link) and for a while recommended servers present the bridge for old(er) clients, but apparently feel 8 years was long enough for clients to update. – dave_thompson_085 Dec 15 '15 at 06:06
  • 1
    I guess this is a continuation of the situation described here? http://security.stackexchange.com/questions/104197/browser-blacklists-the-symantec-google-certification-debacle – user100487 Dec 18 '15 at 18:57

2 Answers2

6

From Symantec itself you get the following description at https://www.symantec.com/page.jsp?id=roots about the usage of VeriSign Class 3 Public Primary CA:

This root CA is the root used for Secure Site Pro Certificates, Premium SSL Certificates and Code Signing Certificates. Effective December 1, 2015, Symantec has discontinued the use of the VeriSign G1 root for issuance of public SSL certificates. This root CA will be used to issue non-public SSL certificates. Browsers/root store operators are encouraged to remove/untrust this root from their root stores.

This suggests to me that this CA is not (or no longer?) intended for any kind of public certificates on the internet and thus removing it from the browsers will not cause any problems. In fact, they even suggest this.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • see @stackzofztuff's answer for an interesting update – Mario Trucco Dec 18 '15 at 14:36
  • @MarioTrucco: interesting indeed. If I understand this problem correctly Chrome will currently not trust a certificate if one trust path contains a revoked certificate, even if other trusts path would succeed. But this looks like an implementation problem with Chrome CRLSets which no other Browser uses as far as I know. – Steffen Ullrich Dec 18 '15 at 14:59
1

Update 2015-12-18Fr.

I commented this earlier:

Dunno. Maybe Symantec has migrated away from that root CA a long time ago, and all issued certificates have long since expired. But they better be right. Because: They certainly have a LOT of sub-CAs. (See Graph section here. See Child CAs section here.) – StackzOfZtuff Dec 13 at 11:44

And here's some new development: They've revoked the revocation:

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86