为什么 CA 根证书都是 SHA-1 签名的（因为 SHA-1 已被弃用）？

根 CA 证书的签名根本无关紧要，因为不需要验证它们。它们都是自签名的。

如果您信任根 CA 证书，则无需验证其签名。如果你不信任它，它的签名对你来说毫无价值。

编辑：下面有一些非常相关的评论。我对复制或改写它们并为它们而不是它们的作者而感到不舒服。但我欢迎人们对此答案添加解释。

归根结底，根证书是自签名的。除了它自己之外，它永远不会被另一个实体签名。根证书通过带外过程获得信任，例如将其提交到受信任发布者的浏览器列表，或者让 Microsoft 接受它以插入到 Windows 受信任发布者的默认列表中。

这些证书（以及自签名它们的公司）（据称，希望）通过其他方式进行彻底审查，而不仅仅是他们的签名。

唯一重要的情况是，如果根由 SHA-1 签名，它可以被 SHA-1 撤销。也就是说，可以攻击 SHA-1 的人可以为根构建撤销。而且我绝对确定浏览器不知道如何坚持这一点，所以破坏者所做的只不过是放弃了 SSL 连接。多么蹩脚。

作为对此的说明，一些CA 已经将其根证书和中间证书更新为 SHA256。

我知道去年 GlobalSign 正在更新他们的证书，因为我们正在更新我们的代码签名证书，所以我也必须将他们的新链添加到这些证书中。

您可以检查哪些特定证书已更新，哪些证书已更新，但此处还保留了旧版 SHA1 证书 => 1

希望有帮助。

对于根 CA，您信任捆绑在 CRT 中的 CA 的公钥——不管它的自签名。

使用 .CRT 文件格式而不是原始公钥 .PEM 描述 CA 允许在其中捆绑更多详细信息 - 例如 CA 名称 - （再一次，签名毫无价值）

浏览器接受的非常旧的，主要是 2006 年或更早时代已经受信任的固定 SHA1 根证书，但没有任何较新的证书。还记得 Firefox 和 Chrome 是使用个位数进行版本控制的吗？

如果根 CA 使用 SHA1 证书并将 Not Before 设置为 2014 年之后的某个值，则证书将失败。实际日期限制取决于浏览器或其他应用程序。几年前，WebCA cabforum 已经明确了这一点。通过以下方式自行测试：

1. 创建使用 SHA1 签名的私有根证书颁发机构基础设施，称为 rootSHA1
2. 让 rootSHA1 创建一个“颁发”CA 或“中间”CA，该 CA 颁发带有链接到根的证书的证书。称之为中间SHA256。
3. 让中间 SHA256 颁发 CA 生成使用 sha256 或更高哈希值签名的证书。称它为 webServerSHA256。
4. 将 webServerSHA256 安装到 webServerSHA56.mydomain.com。
5. 将 rootSHA1、intermediateSHA256 和 webServerSHA256 证书安装到 Google Chrome 中的适当位置。使用证书链将根安装到受信任的根证书颁发机构和其他机构。
6. 将谷歌浏览器导航到https://webServerSHA256.mydomain.com/并确认 webServerSHA256 没有绿色挂锁。测试失败。