1. Google 的决定是否意味着我也要谨慎地从我的机器上删除或禁用根 CA？

不知道。赛门铁克不是太有帮助。从理论上讲，它不应该受到伤害，但客户似乎有些问题。

另外：供应商似乎不同意这一点。

我编写了一个快速脚本并解析了ssylze SSL 测试工具附带的四个信任库（Apple、Java、Microsoft、Mozilla）：

$ 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

所以：（如果 sslyze 商店是最新的）Apple 两者都有，Java 两者都有，微软有。Mozilla 没有。

旁注：sslyze 还附带一个“谷歌”信任存储，我跳过了它，因为我什至不知道它是什么。（也许对于 Android 手机？）一方面，Chrome 不使用自己的信任库。它依赖于操作系统信任库。这可能是这里问题的根源。他们不能只删除 CA，他们必须明确撤销它。-- Mozilla Firefox 在这方面更容易，因为他们运行自己的信任库。

2. 或者 Microsoft Windows 是否有一些自动化过程也会停止信任相同的证书（例如 IE）？

是的。他们有一个自动化的 CA 更新机制。他们会定期做出改变。例如，他们就在今天宣布打算删除大约 20 个 CA。

3. 此外，我可以不删除根 CA，而是转到它的属性，并可能使用“禁用此证书的所有用途”来更新它。选择这个选项会有什么好处吗？

绝对地。要么将证书移动到Untrusted Certificates商店。否则它只会被自动化过程重新添加。

2015 年 12 月 30 日星期三更新。哦，亲爱的，哦，亲爱的，哦，亲爱的。

Ryan Sleevi 发表了另一篇博文。这次是私下而不是作为谷歌发言人，并且有这些（令人沮丧的）话要说：

• Ryan Sleevi，来自 Medium.com 的博客，艰难选择的历史：

2015 年 12 月：赛门铁克仅提前一周通知，要求撤销在数十亿台设备上受信任的根证书，这样赛门铁克将不再有义务遵守该根的基线要求。如果没有此通知，赛门铁克以这种方式使用他们的根将违反他们与根程序的协议，从而使他们操作的所有其他根证书以及他们的每个客户都面临风险。然而，即使有此通知，也可能需要数年时间才能将赛门铁克从该根颁发的证书中面临风险的用户和设备数量减少到数千万的量化数量。

分解 apple.pem 包的步骤

我运行这些命令将 PEM 包拆分为单独的 PEM 文件：

[~] $ 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 遵循发行人赛门铁克提供的指导。详情在这里。

此外，Mozilla (Firefox) 于 2014 年 9 月在此处宣布删除此根 CA 证书信任和类似的其他证书。他们基于老化签名密钥的有限密钥强度做出该决定。

因此，您应该考虑像 Mozilla 和 Google 所做的那样，并得到赛门铁克的推荐。

它的措辞方式，而不是公众信任的证书，可以暗示（看起来谷歌想向我们建议），这个 CA 可以在被要求这样做时被拦截/模拟情况使用，也许是通过法律手段。谷歌担心（如果一家公司可以的话）也可能意味着这些证书甚至不会被证书透明度日志记录所揭示，并且也可能用于对抗谷歌基础设施用户。

基于 CA 的 PKI 是一个相当脆弱的 PKI - 数百个 CA 可以为一个名称颁发证书，虽然其中大多数只负责少数颁发的证书，但在某些地区或文化团体中，有些可能更受欢迎比所有其他人，因此撤销对其中任何人的信任会对少数用户产生相当广泛的影响。

当大量用户无法识别他们的证书时，对于同一 CA 的其他用户来说总是一个坏消息，因此这可能会将他们的一些客户赶走。如果发生这种情况，很容易遵循 google 的意见，但困难在于您无法判断您的服务中还有什么问题。

我认为这更像是谷歌方面的宣传噱头，以捆绑赛门铁克发布更多信息，或者停止推进他们没有向谷歌解释的计划，不管需要什么。如果您想绝对确定，并且可以解决所有证书验证问题，那么在这方面关注 Google 可能会更谨慎。但这更多是可以在技术上支持的个人观点。