主流浏览器直接信任Let’s Encrypt根证书，宣告他成为顶级CA

8月6号，Let’s Encrypt 官方博客发表了一篇文章 Let's Encrypt Root Trusted By All Major Root Programs ，其中关键信息引用如下：

意思就是本月底，所有的微软产线（比如 Edge）也将直接信任 Let’s Encrypt 的根证书（ISRG Root X1），从而世界上所有的主流产品都直接支持其根证书了，那么这意味着什么？什么是直接信任？对使用 Let’s Encrypt 的证书的人有何影响？且听我慢慢道来。

这一消息表示：

也许你听的晕晕乎乎的，为了解明白，我们必须理解证书链的概念。

证书链是一个信任链，关系见下图：

以 Let’s Encrypt 签发的证书为例，申请者申请的证书可以称为服务器证书，运行 openssl 查看证书命令，关键信息如下：

这表示服务器证书是 simplehttpscom，它被中间证书 Let's Encrypt Authority X3 进行数字签名，也就是说服务器证书被 Authority X3 中间证书信任。

该中间证书就是 Let's Encrypt CA 机构的，用于签发服务器证书，需要说明的是中间证书可能有多张，迭代签名。

那么中间证书被谁签名了？运行下列命令：

中间证书是被 DST Root CA X3 根证书（IdenTrust CA 机构的根证书）签名的，同学们可能很奇怪了，为啥 Let's Encrypt 不用自己的根证书签名其中间证书啊？这是一个好问题。

根本原因就是 Let's Encrypt 作为一个新兴 CA 机构，历史并不悠久，大部分浏览器不可能直接信任其根证书，不信任就无法构建信任基础，怎么办？Let's Encrypt 为了快速投入运营，使用 IdenTrust CA 机构的根证书（被主流产品直接信任，比如 Chrome 可信任根证书列表包含该根证书）对其中间证书进行 交叉认证 ，从而主流产品就能信任 Let's Encrypt 服务器证书了，最终信任链链条： 服务器证书>Let's Encrypt Authority X3 中间证书->DST Root CA X3 根证书 。

同学们如果也使用 Let's Encrypt 证书，可以看一下证书链，打开 Chrome 开发者工具就能知晓，如图：

本质上，Let's Encrypt 有两条证书链（早就存在了）如下图：

绿色线条就是目前采用的证书链，如果主流浏览器都信任了 Let's Encrypt 根证书（ISRG Root X1），那么就可以采用红色线条标示的证书链了。也就是信任链链条： 服务器证书>Let's Encrypt Authority X3 中间证书->ISRG Root X1 根证书 。

经过我的配置，我的网站证书链如下图：

同学们可能会问，这是如何做到的？别着急。

本质上，Let's Encrypt 中间证书 Authority X3 有两个证书，分别是：

他们都可以对 Let's Encrypt 服务器证书进行签名（签名用的私钥是一样的），这是关键，这两个证书分别被 ISRG Root X1 和 DST Root CA X3 签名。

聪明的同学可能想到了，在申请 Let's Encrypt 证书的时候，Let's Encrypt 目前使用 Let’s Encrypt Authority X3 (IdenTrust cross-signed) 签名，申请者获取到证书后，配置证书链（服务器证书+中间证书）后提供 HTTPS 服务。浏览器校验证书，一看中间证书是 Let’s Encrypt Authority X3 (IdenTrust cross-signed) 签名，最终找到 IdenTrust 的根证书完成签名验证。

那今天博客所说的内容表示，在申请 Let's Encrypt 证书的时候，Let's Encrypt 可以使用 Let’s Encrypt Authority X3 (Signed by ISRG Root X1) 签名，申请者获取到证书后，配置证书链（服务器证书+中间证书）后提供 HTTPS 服务。浏览器校验证书，一看中间证书是 Let’s Encrypt Authority X3 (Signed by ISRG Root X1) 签名，最终找到 Let's Encrypt ISRG Root X1 根证书完成签名验证。

可实际上， 目前 你申请证书的时候，Let's Encrypt 仍然使用 IdenTrust cross-signed 中间证书签名服务器证书，原因何在，主流产品（比如 Chrome）虽然已经直接信任其根证书了，但这些产品有很多旧版本存在，如果不更新，那么这些版本仍然不信任 Let’s Encrypt 根证书，Let’s Encrypt 预估 5 年以后，这些旧版本将不复存在，那个时候 Let’s Encrypt 就可以大胆用 Let’s Encrypt Authority X3 (Signed by ISRG Root X1) 中间证书签发服务器证书了。

难倒我们了吗？是否可以手动让你的网站使用新的证书链呢？答案是可以（如果不考虑旧产品线不信任 Let’s Encrypt ISRG Root X1 根证书的问题）。

上面讲到，服务器证书可以任意使用下面的中间证书签名：

任意的关键就是，这两个证书的签名私钥是一样的，我们是否可以自行配置证书链呢（红色线条）？可以：

然后重新启动你的服务器，使用 Chrome 浏览器开发者工具观察网站证书链，是不是结果如下图：

很简单，你双击userp7b，打开证书-当前用户下拉菜单，选中对应文件夹，然后里面有个证书的文件夹，里面应该有几个证书，看一下对应的是哪一级。一般域名或者IP的是服务器证书，右键点击它，然后点击所有任务，点击导出然后点击下一步，选择base64格式，也就是cer格式。导出根证书操作一样。请采纳。

你好！

CA证书

CA证书就是电子商务认证授权机构，也称为电子商务认证中心，是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

证书的内容包括：电子签证机关的信息、公钥用户信息、公钥、权威机构的签字和有效期等等。目前，证书的格式和验证方法普遍遵循X509 国际标准。

自颁发证书

由服务器自己颁发给自己，用于证明自己身份的东西，非权威颁发机构发布，默认客户端都是不信任的，在如下情形中，一张证书是自颁发证书而不是自签证书：CA在进行密钥更替时，可能会存在两个密钥对（新密钥对和旧密钥对），可能会存在用新私钥签发旧公钥或用旧私钥签发新公钥的情形，如此形成的证书是自颁发证书，却不是自签证书。

自签证书

自签证书是一种由签名实体发布给自身的证书,即发布者和证书主体相同

从你CRL的URL看，是读取WIN-J8D30A2SBCL服务器上的crl文件。

我怀疑是因为无法成功读取到此crl文件所导致的错误 。请手工在浏览器 上把这个url输入，看能否成功下载到此crl。

一般查询crl是通过http或ldap协议，而不是直接通过file协议访问另一台机器上的文件。

使用file协议是需要访问电脑权限和访问特定目录文件的权限的！

Microsoft 在 Microsoft Windows 的不同版本中推出了新的根更新机制。这些机制都逐渐开始致力分发较少的根证书，而是使分配根证书是必需的而分发通过 Windows 根证书程序尽可能平稳顺畅。若要了解根更新机制中的区别，将 Windows 版本分为两个类别是最方便的方式：

　　支持自动根的操作系统版本更新的单独的根证书

　　依赖于较早的、 可选的根元素的操作系统版本更新的包 (包含所有当前分布式的根证书的包)

　　在 Windows 客户端 Sku，Windows Vista 或更高版本完全支持自动根更新机制。建议早于 Windows Vista 版本的 Windows 下载可选根目录更新包，其中包含所有当前分布式的根证书。

　　Windows Vista 和 Windows 7

　　Windows Vista 或更高版本上的根证书分发通过自动根更新机制。即，它们是通过根证书分发。当用户进入一个安全网站 (例如，通过使用 HTTPS SSL)，读取安全电子邮件 (S/MIME)，或下载 ActiveX 控件，它是签名 (代码签名)，然后遇到一个新的根证书时，则 Windows 证书链验证软件检查 Microsoft 更新根证书。如果软件找到根证书，则软件下载当前证书信任列表 (CTL)。CTL 包含程序中的所有受信任的根证书的列表，并验证存在列出了根证书。然后，它将指定的根证书下载到系统并在 Windows 受信任根证书颁发机构存储中安装证书。如果找不到根证书，证书链未完成，并且系统会返回一个错误。

　　对用户来说，成功的根更新是无缝的。用户不会看到任何安全性对话框或警告。下载将自动进行。此外，为 Windows Vista 或更高版本中，客户端 Sku 支持每周预取从 Microsoft 更新，以检查有更新的根证书属性 (例如，扩展的验证 (EV)、 代码签名，或服务器身份验证属性，即会添加到根证书的证书属性)。

　　Windows XP

　　Windows XP 不完全支持自动根更新机制。已经存在于用户的系统上的根证书时，它不会更新不论是否可在 Microsoft 更新根证书的副本已更改。Windows XP 也不支持的每周预提取证书属性从 Microsoft 更新功能，并在 Windows XP 上安装新的根证书属性的唯一方法是通过安装的根更新软件包。

　　建议在运行 Windows XP 的用户下载和安装根更新包，更新他们的根证书。根证书作为可选根更新包 – 包含每个根证书分发 Windows 根证书程序的可执行文件传递对于 Windows XP，通过 Microsoft 更新。Windows XP 用户可以选择每次更新，并将其由 Microsoft 更新的下载程序包。或者，也可以选择在更新时自动下载的根更新程序包。每年，大约三至四次或每季度更新可选根更新软件包。

　　Windows Server 2003 和 Windows Server 2008 中，Windows Server 2008 R2

　　Windows Server 2008 和更高版本，而不是 Windows Server 2003，则会启用自动根更新机制。Windows Server 2003 仅部分支持自动根更新机制。(这是不同于在 Windows XP 上的支持。和根更新程序包适用于 Windows XP Sku 仅用于客户端，因为它不是针对 Windows 服务器 Sku。但是，根更新包可能会下载并安装 Windows 服务器 Sku，受以下限制的约束。

　　如果您在 Windows 服务器 Sku 上安装根更新软件包，您可能会超过在 TLX 或 SSL 握手中想客户端报告根列表时 Schannel 可以处理的根证书数量的限制，因为在根更新软件包中分发的根证书的数量可能超过该限制。根证书更新时，受信任的 Ca 列表显著增大，并可能变得太长。列表然后被截断，并且可能导致问题的授权。这种行为也可能导致 Schannel 事件 ID 36885。在 Windows Server 2003 中，不能大于 0x3000 的发行者列表。

　　如果您需要在网站上的客户端证书，或者如果您在 Windows Server 2003 中使用 IAS，客户端无法建立连接。

　　注意您只有在 Windows 服务器上启用 SSL 客户端身份验证，将应用这些限制。

　　在断开连接的环境的根更新软件包安装

　　建议在断开连接环境中 (例如，位置自动根更新机制无法工作，因为连接到 Microsoft 更新不可用) 运行 Windows 的客户端或服务器 Sku 的系统应该安装根更新软件包。根更新程序包将安装 Windows Vista 和 Windows 7 在断开连接的环境中的一种解决办法。但是，我们不建议已通过网络连接到 Microsoft 更新的系统安装的根更新软件包，因为自动根更新机制将适用于它们。

　　您可以使用组策略将根证书分发到一组服务器在断开连接的环境中。

　　Windows Vista Crypt32dll 资源文件中包括一组受信任第三方根证书，这些证书可以用作回退，与 Windows 更新的连接不可用时。触发自动根更新后，它会尝试从网络上下载的受信任第三方根证书。在离线的环境中，网络检索失败，和 CAPI 检查 Crypt32dll 中的根证书的资源。如果根目录，则使用和安装在根存储区中。Windows 7 的类似行为。

　　如果禁用自动根更新，则不检索根尝试。因此，不会安装根目录。请注意，Crypt32dll 中的资源包括那些已存在于根程序操作系统发行版之前的一次的证书。在以后添加任何根证书中不存在该资源，和此类证书都可以仅通过根更新包。