我在使用 Wget 通过ftp.gnu.org使用Let's Encrypt X3根目录通过 HTTPS 下载文件时遇到问题。Let's Encrypt X3是交叉认证的，这意味着它有一个发行者并且它不是自签名的。使用Let's Encrypt X3时，Wget 失败并出现错误，即使我试图根信任 Let's Encrypt 证书，它也找不到颁发者证书。
我访问了RFC 4158，Internet X.509 公钥基础设施：认证路径构建以了解行为应该是什么。该文档详细讨论了从最终实体或订户证书到 CA 根和信任锚的构建路径。这是人们所期望的。
但是，第 1.3 节提供了术语，并定义了信任锚：
信任列表：信任锚列表。
信任锚：可信公钥和对应私钥所属实体名称的组合。
信任锚证书：用于证书路径处理的信任锚的自签名证书。
“信任锚证书”和要求“自签名”的定义意味着我们不能根信任从属证书，例如经过交叉认证的Let's Encrypt X3根。
我的问题是，为什么 RFC 会这样做？为什么我们被迫使用自签名证书作为锚点，并包含 PKI 中不需要的部分，这些部分只会使路径构建复杂化并增加攻击面？
这是那些棘手的微妙措辞之一。RFC 的完整含义在初读时可能并不明显。从你的问题（强调我的）：
信任锚：可信公钥和对应私钥所属实体名称的组合。 信任锚证书：用于证书路径处理的信任锚的自签名证书。
信任存储有两个目的：
其中的一些推论是：
微妙的是，RFC 允许您直接固定证书或公钥，但是如果您固定证书，则它需要是根证书。RFC 在这里给出了一些理由：
1.5.1。层次结构
图 1 中描绘的分层 PKI 是其中所有终端实体和依赖方使用单个“根 CA”作为其信任锚的一种。
从 CA 的角度来看，他们可能不希望您固定中间 CA，因为如果它受到损害，他们就无法撤销它：即使他们为它发布了撤销，您的客户也会忽略它。
在一个CA还是希望你能够使用一个中间CA的信任锚的情况下，我已经看到他们给予信任锚双方已颁发的证书，并为相同的公钥和DN自签名的证书。我假设 Let's Encrypt 不会为其中间 CA 执行此操作。
至于您关于wget,ftp.gnu.org和Let's Encrypt X3中间 CA 的实际问题，我认为您有两个选择：
Let's Encrypt X3并将其添加到您的信任库中。作为一般假设：如果它不是自签名的；您依靠其他实体来灌输信任；根据定义，其他实体成为锚。
尽管许多实现可能信任更下游的东西，但这不是 PKI/x509 的功能——它是带外信任；因此超出了 RFC 的范围。
它提出了一个问题：你为什么要在锚中灌输隐式信任，它本身没有来自其发行者的隐式信任（它可以被撤销）