#1 楼
根CA证书的签名完全无关紧要，因为不需要验证它们。它们都是自签名的。如果您信任根CA证书，则无需验证其签名。如果您不信任它，那么它的签名对您就毫无价值。
编辑：下面有一些非常相关的评论。我不喜欢抄袭或改写它们，并为他们而不是他们的作者称赞。但我欢迎人们对此答案添加解释。
评论
提出了为什么要签名的问题
–Richard Tingle
17 Mar 14 '17 at 12:54
因为系统不支持未签名的证书。
–橙色狗
17年3月14日在14:03
在我看来，与可破解的根证书有关的问题不是“您不知道从何处获得根证书”，而是“您不知道还有谁能够破解此证书并使用它”签署他们想要的任何东西。”从您的回答看来，这两个（证书和证书签名）是分开考虑的，并且证书本身是适当的安全且不可破解的吗？
– Dewi Morgan
17年3月14日在21:55
除了“不需要验证它们”之外，我将走得更远。证书链中签名的目的是，较高的权限证明较低的权限。对于根CA，根据定义，没有更高的权限（这就是“根”的含义），因此没有人可以签名证书。如前所述，由于必须对证书进行签名，因此用“虚拟”签名对根CA进行签名，而最简单的方法是自签名。因此，不仅没有必要进行验证，而且验证根CA签名的想法是毫无意义的。
–Jörg W Mittag
17年3月14日在23:10
@DewiMorgan您不能通过散列冲突来“破解”根证书，因为客户端信任证书本身，而不是其（自）签名。您将必须恢复私钥，这是对RSA的攻击，而不是哈希算法的攻击。
– zwol
17年3月15日在13:31
#2 楼
最终，根证书是自签名的。除其自身外，它从未由其他实体签名。根证书通过带外过程获得信任，例如将其提交给受信任的发布者的浏览器列表，或者被Microsoft接受以插入到Windows信任的发布者的默认列表中。这些证书（以及对其进行自我签名的公司）（据称是希望）通过了不仅仅是签名的其他方式进行了彻底的审查。
评论
更不用说，更新根证书需要再次执行该带外过程。
–凯塔尔
17年3月13日在18:06
+1代表“有希望地”
–内森·奥斯曼（Nathan Osman）
17年3月16日在1:36
#3 楼
唯一重要的情况是，如果根由SHA-1签名，则SHA-1可以将其撤消。也就是说，可以攻击SHA-1的人可以为根构建撤消。而且我绝对确信浏览器不知道该如何持久，因此破坏者仅完成了删除SSL连接的任务。好la脚评论
这是一个有趣的想法，但是我怀疑这样做是否会起作用。我的猜测是每个代理都有自己的独特行为，但是我怀疑任何开发人员都会想到撤销列表将用于管理根证书的撤销。至少，如果在某些情况下可行，那将是由于软件吊销的抽象而不是开发人员有意为之。
– Peter Oehlert
17年3月15日在14:58
#4 楼
作为对此的说明，无论如何，某些CA已经将其根证书和中间证书更新为SHA256。我知道去年GlobalSign在更新我们的代码签名证书时也在更新他们的证书，所以我也必须在它们的基础上添加他们的新链。
您可以检查哪些特定证书已更新以及哪些证书已更新，但还可以在此处保留旧版SHA1证书=> 1
希望有所帮助。
#5 楼
对于根CA，您可以信任CRT中捆绑的CA的公钥，而不必考虑其自签名。使用.CRT文件格式而不是原始的公钥.PEM描述CA。允许在其中捆绑更多详细信息-例如CA名称-（再次，签名毫无用处）
#6 楼
浏览器已经接受了非常古老的，大多是2006年或更早的时代的受信任的固定SHA1根证书，但没有任何较新的证书。还记得Firefox和Chrome用一位数字进行版本控制吗？如果根CA使用SHA1证书且Not Before设置为2014年之后，则证书将失败。实际日期限制取决于浏览器或其他应用程序。 WebCA的论坛在几年前就明确了这一点。通过以下方法自己进行测试：
创建用SHA1签名的私有根证书颁发机构基础结构，将其称为rootSHA1
具有rootSHA1创建一个“颁发” CA或“中间” CA颁发带有链接到根的证书的证书。称为中间体SHA256。
让中间体SHA256颁发CA生成使用sha256或更大哈希值签名的证书。称为webServerSHA256。
将webServerSHA256安装到webServerSHA56.mydomain.com中。
将rootSHA1，中间SHA256和webServerSHA256证书安装到Google Chrome中的适当位置。将根安装到受信任的根证书颁发机构，并通过证书链安装其他根。
将Google Chrome浏览到https://webServerSHA256.mydomain.com/，并确认webServerSHA256没有绿色挂锁。测试失败。
评论
这是完全错误的。中间证书（和EE /叶证书）确实需要SHA2，而根证书则不需要。 Google自己的证书通过其私有CA（Google Internet Authority G3）链接到GlobalSign根CA R2（即SHA1），并且（毫不奇怪）Chrome被接受。
–dave_thompson_085
19年7月8日在3:05
是的，即使您将这些固定的SHA1证书添加到自己的“受信任的根”证书存储中，也不会接受任何新的SHA1根证书。在我的答案中添加了一个测试用例。
– rjt
19年7月11日，下午1:32
您有效地证明的是，您在相关信任存储中的第5步中安装的rootSHA1证书与在浏览器或系统中预装的“ CA root证书”所关联的信任级别不同。 ：前者应使用SHA2散列将其变为绿色，但后者应使用SHA1。结果本身很有趣。但是您并不真的认为您（或您的IT团队）可能与浏览器开发人员具有相同的信任度，对吗？
– AntoineL
20年6月12日在17:10
当然，我不认为我们的IT团队具有相同的信任度，这正是我的观点。谢谢。即使根证书位于相同的信任库中并使用SHA1进行了签名，但由于dateStamp的关系，根证书最有可能不相同。这证明了即使您明确告诉Web浏览器信任它，也不是所有的SHA1根证书都受chrome信任。根由自身和上面的理论讨论来签名是无关紧要的，Chrome仍然不信任它，因为它是SHA1。
– rjt
20年6月12日在19:18
评论
并非所有“ CA”根证书都是SHA1。根证书就像是世界观中的开始假设。信任他们需要信念。
@RoyTinker，除了cogito ergo sum（请参见根本性疑问，它的答案：笛卡尔怀疑论）？
跨堆栈：security.stackexchange.com/questions/120301/…和superuser.com/questions/1122069/…
@NickT：请放心-cogito ergo cogito ;-)