Should I be concerned that Google no longer trusts specific Symantec root CA cert that is also on my Windows system?
- Does Google's decision mean that it would be prudent for me to also delete or disable the root CA from my machine?
Dunno. Symantec ain't being too helpful. Theoretically it should not hurt but something seems to be broken in clients.
Also: Vendors don't seem to agree on this.
I've whipped up a quick script and parsed four trust stores (Apple, Java, Microsoft, Mozilla) that the ssylze SSL test tool ships with:
$ grep -rl 'Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority$' | xargs -- grep -A2 -- 'Serial Number'
apple.truststore/108.cer.txt: Serial Number:
apple.truststore/108.cer.txt- 70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
apple.truststore/108.cer.txt- Signature Algorithm: md2WithRSAEncryption
--
apple.truststore/164.cer.txt: Serial Number:
apple.truststore/164.cer.txt- 3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be
apple.truststore/164.cer.txt- Signature Algorithm: sha1WithRSAEncryption
--
java.truststore/143.cer.txt: Serial Number:
java.truststore/143.cer.txt- 3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be
java.truststore/143.cer.txt- Signature Algorithm: sha1WithRSAEncryption
--
java.truststore/61.cer.txt: Serial Number:
java.truststore/61.cer.txt- 70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
java.truststore/61.cer.txt- Signature Algorithm: md2WithRSAEncryption
--
microsoft.truststore/15.cer.txt: Serial Number:
microsoft.truststore/15.cer.txt- 70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
microsoft.truststore/15.cer.txt- Signature Algorithm: md2WithRSAEncryption
So: (if the sslyze stores are up to date) Apple has both, Java has both, Microsoft has one. Mozilla has none.
Sidenote: sslyze also ships with a "Google" trust store, I've skipped that, because I don't know what that even is. (For Android phones maybe?) For one thing, Chrome does not use its own trust store. It relies on the OS trust store. And this may be the root of the problem here. They can't just remove a CA, they must explicitly revoke it. -- Mozilla Firefox has it easier in that respect, since they run their own trust store.
- Or might Microsoft Windows have some automated process that would also stop trusting the same certificate (in for example IE)?
Yes. They have an automated CA update mechanism. And they regularly make changes. For example they announced the intention to remove some 20 CAs just today.
- Also, instead of deleting the root CA, I could go to it's properties and maybe update it with "Disable all purposes for this certificate". Would there be any benefits from choosing this option instead?
Absolutely. Either that or moving the certificate to the Untrusted Certificates store. Otherwise it will just be re-added by the automated process.
Update 2015-12-30Wed. Oh dear, oh dear, oh dear.
Ryan Sleevi made another blog post. This time privately and not as a Google spokesperson and has these (discouraging) words to say about it:
- Ryan Sleevi, blogged via Medium.com, A History of Hard Choices:
December 2015: With only one week’s notice, Symantec requests that a root certificate trusted on billions of devices be revoked, so that Symantec will no longer be obligated to abide by the Baseline Requirements for that root. Without this notice, Symantec’s use of their root in this manner would have been in violation of their agreements with root programs, putting at risk every other root certificate they operate and every single customer of theirs. Yet, even with this notice, it will likely take years to reduce the number of users and devices at risk from certificates issued by Symantec from this root to a something quantified in the tens of millions.
Steps to explode apple.pem bundle
I ran these commands to split the PEM bundle into individual PEM files:
[~] $ wc apple.pem
4903 5279 303714 apple.pem
[~] $ mkdir apple.truststore
[~] $ cd apple.truststore/
[~/apple.truststore] $ awk 'split_after==1{++n;split_after=0} /-----END CERTIFICATE-----/ {split_after=1} {print > "cert" n ".cer"}' < ../apple.pem
[~/apple.truststore] $ for RAWCERTFILE in *.cer; do openssl x509 -in $RAWCERTFILE -text 2>&1 > $RAWCERTFILE.txt; done
Google is following the guidance provided by the issuer Symantec. Details here.
Furthermore, Mozilla (Firefox) announced the removal of this Root CA certificate trust and similar others in September of 2014 here. They based that decision on the limited key strength of the aging signing key.
Accordingly, you should consider doing as both Mozilla and Google have done and is recommended by Symantec.
The way it is worded, not publicly-trusted certificates, can suggest (and it looks like Google wants to suggest to us), that this CA may be used by interception/impersonating situations when requested to do so, perhaps via legal means. That Google is worried (if a company can ever be) could also mean that these certificates won't even be revealed by certificate transparency logging, and possibly used againts google infrastructure users as well.
The CA-based PKI is a quite fragile one - hundreds of CAs can issue certificates for a single name, and while most of them are responsible for only a minority of the certificates issued, at some regional or cultural groups, some may be more popular than all the others, hence revoking trust for any of them can have quite far-ranging effects on a few number of users.
It's always a bad news for other users of the same CA when a large class of users won't recognise their certificates, so this can drive a few customers of theirs away. If this happens, it can be easy to follow google's opinion, but the difficulty is that you can't tell what else is breaking among your services.
I would think it's more of a publicity stunt from google's side to tie the hand of Symantec to release more information, or stop going forward with this plan they did not explain to google, whatever it takes. If you want to be absolute certain, and can troubleshoot all certificate verification issues, it may be more prudent to follow Google on this. But this is much more of a personal opinion that can be backed technically.