最近更新：
本页面描述了 Let’s Encrypt 过往及当前运作的所有证书颁发机构（CA）。 所谓的 CA 应当理解为一组名称和密钥：一家 CA 可以由 很多 证书表示，只要所有证书的主体和公钥信息相同即可。 对于这种情形，我们也提供了 CA 对应的所有证书的详细信息。
根证书颁发机构
我们的根证书密钥是在安全的地点离线存储的， 而提供给用户的最终实体证书都是由下一节介绍的中间证书签发。 所有根证书中主体的国家字段均为 C = US。
需要注意的是，根证书的有效期限和其他证书有所不同。 作为一种自签名证书，根证书也有 notAfter 截止日期，但各类根证书项目和证书库可以选择延长或提前终止对根证书的信任。 因此，下列证书有效期限仅为依据各根证书项目的现行政策所作的预估。
- ISRG Root X1
- ISRG Root X2
关于我们的根证书与各类设备及证书库的兼容性，详见证书兼容性页面。
中间证书颁发机构
我们目前有四份中间证书供轮转使用。 包含 ECDSA 公钥的用户证书由其中一份 ECDSA 中间证书签发，包含 RSA 公钥的用户证书则由其中一份 RSA 中间证书签发。
所有中间证书中主体的国家字段均为 C = US。
- Let’s Encrypt E5
- Let’s Encrypt E6
- Let’s Encrypt R10
- Let’s Encrypt R11
点击下方展开当前签发层级外的其他中间证书颁发机构：
备用证书
这些中间证书已经生效，但尚未用于签发其他证书。 我们随时可能在无预先告知的情况下将下列证书用于签发流程。
- Let’s Encrypt E7
- Let’s Encrypt E8
- Let’s Encrypt E9
- Let’s Encrypt R12
- Let’s Encrypt R13
- Let’s Encrypt R14
已不再使用的证书
这些中间证书已不再用于签发用户证书。 其中尚未过期的中间证书仍有可能产生 OCSP 应答和/或 CRL。
- Let’s Encrypt E1
- Let’s Encrypt E2
- Let’s Encrypt R3
- Let’s Encrypt R4
- Let’s Encrypt Authority X1
- Let’s Encrypt Authority X2
- Let’s Encrypt Authority X3
- Let’s Encrypt Authority X4
OCSP 响应专用证书
此证书曾代替 Let’s Encrypt 的根证书用于签发 OCSP 响应，传达 Let’s Encrypt 中间证书的状态，从而使根证书能够以离线的形式安全存储。 现在我们已不再为中间证书提供 OCSP 响应，而是定期使用根证书发布 CRL 通告各中间证书的吊销情况。
证书链
ACME 客户端通过 Let’s Encrypt 的 ACME 接口下载的新证书实际上是“证书链”的一部分，这条链中还包含若干份中间证书。 一般情况下，证书链中只有最终实体证书和一份中间证书，但中间证书也可以有多份。 这样设计的意图在于，只要把这一整条证书链提供给网站访客的浏览器，浏览器就能顺着这条链逐一验证数字签名，直至找到其信任的根证书，全程不需要再下载其他的中间证书。
一份证书还可能有多条证书链。例如，当中间证书存在交叉签名时，任选其一均可形成证书链，并最终到达各自的根证书。 在这种情况下，各网站可以根据需要选择使用不同的证书链。
使用 RSA 公钥的用户证书均由我们的 RSA 中间证书签发，对应的根证书也只有使用 RSA 的 ISRG Root X1（即不存在交叉签名）。 因此，所有 RSA 用户证书都只有一条证书链：
使用 ECDSA 公钥的用户证书则由我们的 ECDSA 中间证书签发，对应的根证书既有使用 RSA 的 ISRG Root X1，也有使用 ECDSA 的 ISRG Root X2（即存在交叉签名）。 所以我们为此类证书提供了两条证书链：
ECDSA 用户证书 ← ECDSA 中间证书（E5 或 E6）← ISRG Root X2
第一条到 ISRG Root X1 的证书链兼容性更高，因为大多数证书库都收录了这份根证书。 第二条到 ISRG Root X2 的证书链则能降低每次 TLS 握手过程所占据的带宽。 为了保障兼容性，我们在默认情况下提供的是第一条证书链， 相比兼容性更注重数据量的用户可以查阅其 ACME 客户端的文档了解如何获取另一条证书链（例如使用 Certbot 的 --preferred-chain 选项）。