为什么不通过 DNS 记录而不是 letencrypt 来验证自签名证书

Question

我只是想知道。我们使用了很多 SSL 证书。如今，我们几乎只使用letsencrypt（谢谢！）。这些证书的底线是，证书上域名的所有权证明来自操纵这些域下的 DNS 记录或网站的权力。DNS 证明来自向 DNS 添加一些密钥（由letsencrypt 提供）作为 TXT 记录。

那么，如果足以证明能够更改域的 DNS 记录，为什么不使用带有 DNS 指纹的自签名证书呢？

我会说这与基于 DNS 的 letencrypt（和其他 CA）过程完全相同的信任度：

1. 创建一个自签名 CA（只需按照各种操作方法的步骤操作即可）
2. 为某些域创建证书
3. 使用步骤 1 中的 CA 对步骤 2 中的证书进行签名。您现在拥有一个基本证书，由不受信任的 CA 签名
4. 将 TXT（或专用）记录添加到每个域的 DNS，声明：我们使用此 CA 签署了该域的证书。像：'CA=-CA-的指尖'
5. 浏览器下载证书并通过将 CA/CA 证书的指纹与给定域的 DNS 中的数据进行比较来验证它。

这将使创建不受第三方干扰的可信自签名证书成为可能，与任何基本 SSL 证书的信任级别相同。只要您可以访问 DNS，您的证书就是有效的。甚至可以添加一些 DNSSEC 之类的加密，从 CA 和 SOA 记录中生成散列，以确保信任在 DNS 记录中的更改时消失。

以前有没有考虑过这个问题？

杰尔默

Answer 1

使这成为可能的基本基础设施存在并且被称为命名实体的基于 DNS 的身份验证 (DANE)，并在RFC6698 中指定。它通过TLSA资源记录工作，该记录指定了最终实体或其链中 CA 之一的证书或其公钥（实际上有四种不同的类型，详细信息请参见 RFC）。

采用

然而，DANE 尚未被广泛采用。VeriSign 监控DNSSEC 和 DANE 的采用并跟踪其随时间的增长：

相比之下，根据 VeriSign，大约有 270 万个 DNS 区域，这意味着所有区域中略多于 1% 的区域至少有一个 TLSA 记录。

我无法给出任何权威答案，为什么是 DANE，但这里是我的推测：

DANE 面临与证书撤销列表 (CRL) 和在线证书状态协议 (OCSP) 相同的问题。为了验证所提供证书的有效性，必须联系第三方。Hanno Böck给出了一个很好的概述，为什么这在实践中是一个大问题。归结为当您无法联系到第三方时该怎么办的问题。在这种情况下，浏览器供应商选择了软失败（又名许可），这使得整个事情变得毫无意义，Chrome 最终决定在 2012 年禁用 OCSP。

DNSSEC

可以说，DNS 比 CA 的 CRL 和 OCSP 服务器提供了更好的可用性，但它仍然无法进行离线验证。另外DANE，应该只与DNSSEC结合使用。由于普通 DNS 运行在未经身份验证的 UDP 上，因此很容易出现伪造、MITM 攻击等。采用 DNSSEC 比采用 DANE 好得多，但仍远未普及。

使用 DNSSEC，我们再次遇到软故障问题。据我所知，没有主要的服务器/客户端操作系统默认提供验证 DNSSEC 解析器。

然后还有撤销的问题。DNSSEC 没有撤销机制，而是依赖于短期密钥。

软件支持

所有参与的软件都必须实现 DANE 支持。

理论上，您可能会认为，这将是加密库的工作，应用程序开发人员不必做太多事情，但事实是，加密库通常只提供原语，应用程序必须自己进行大量配置和设置（不幸的是，有很多方法会出错）。

我不知道，例如任何主要的 Web 服务器（例如 Apache 或 nginx）都实施了 DANE 或计划这样做。Web 服务器在这里特别重要，因为越来越多的东西建立在 Web 技术上，因此它们通常是第一个实现的地方。

当我们将 CRL、OCSP 和 OCSP Stapling 进行比较时，我们或许能够推断出 DANE 的采用故事将如何发展。只有部分使用 OpenSSL、libnss、GnuTLS 等的应用程序支持这些功能。像 Apache 或 nginx 这样的主要软件花了一段时间才支持它，再次参考 Hanno Böck 的文章，他们弄错了，他们的实现有缺陷。其他主要软件项目，如 Postfix 或 Dovecot不支持 OCSP并且具有非常有限的 CRL 功能，基本上指向文件系统中的文件（不一定要定期重新读取，因此您必须手动重新加载服务器等）。请记住，这些是经常使用 TLS 的项目。然后，您可以开始查看 TLS 不太常见的东西，例如 PostgreSQL/MySQL，也许它们最多提供 CRL。

所以我什至没有现代 Web 服务器实现它，大多数其他软件甚至还没有实现 OCSP 和 CRL，祝你 5 年的企业应用程序或设备好运。

潜在应用

那么您实际上可以在哪里使用 DANE？截至目前，不在一般互联网上。如果您控制服务器和客户端，也许这是一种选择，但在这种情况下，您通常可以求助于公钥固定。

在邮件领域，DANE 受到了一些关注，因为 SMTP 最长时间没有任何经过身份验证的传输加密。SMTP 服务器有时会在彼此之间使用 TLS，但没有验证证书中的名称是否实际匹配，他们现在开始通过 DANE 进行检查。

Answer 2

不同类型的证书验证程序

使用常规 CA 签名证书，有几个级别的证书验证：

• Domain Validation (DV)
  仅验证域名所有权，仅域名在证书中显示为“主题”
• 组织验证 (OV)
  域名和所有者名称经过验证，域名和所有者名称在证书中显示为“主题”
• Extended Validation (EV)
  更严格的所有者实体验证，域名和所有者名称在证书中显示为“主题”，带有所有者名称的绿色条

您描述并建议替代的过程仅适用于最低级别的域验证 (DV)。

DV 是验证相对简单的自动化级别，例如 LetsEncrypt 所做的，并提供与 DNS 可提供的信任级别相似的信任级别，如果它被用作信任锚的唯一来源（UI 含义，证书可能是可信的，但包含其他未经验证的数据）。

基于 DNS 的命名实体认证 (DANE)

DANE建立在 DNSSEC 之上（因为 DNS 数据的真实性至关重要）为 DNS 中的 TLS 客户端发布信任锚信息。

它使用TLSARR 类型，可用于识别最终实体或 CA的证书或公钥（选择器），无论是否需要常规证书链验证才能成功（证书使用）以及证书如何/key 数据在记录中表示（匹配类型）。

该TLSA记录拥有者名称具有前缀指示的端口和协议（例如，_443._tcp）和RDATA指示cert usage，selector并且matching type除了证书模式/键数据相匹配。有关这些参数的详细信息，请参阅RFC6698 的第 2.1 节。

TLSA例如，一条记录可以是这样的：

_443._tcp.www.example.com. IN TLSA  2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

使用使用模式2或3（指示单独使用 TLSA 信任锚），DANE 感知客户端将接受未由普遍信任的 CA 签名但与TLSA记录匹配的证书。
这在概念上与您在问题中提出的相同。

渔获？DANE 感知客户端目前或多或少不存在，一个问题是 DNSSEC 本身没有像 DANE 起飞可能需要的那样广泛部署（尤其是在客户端机器上的验证）。考虑到 DANE 是依赖经过身份验证的 DNS 数据的首批潜在的大型新用例之一，这可能是一个先有鸡还是先有蛋的问题。

有一个浏览器插件添加了 DNSSEC 和 DANE 验证，除此之外，目前没有多少接近主流的插件。而且，作为插件而不是本机支持，它在一般使用方面比其他任何东西都更能作为概念证明。

这是可以做到的。已经考虑过了。它仍然可能发生，但没有太多的运动。