我只是想知道。我们使用了很多 SSL 证书。如今，我们几乎只使用 letsencrypt（谢谢！）。这些证书的底线是，证书上域名所有权的证明来自操纵 DNS 记录或这些域下的网站的能力。DNS 证明来自将一些密钥（由 letsencrypt 提供）作为 TXT 记录添加到 DNS。
因此，如果有足够的证据能够更改域的 DNS 记录，为什么不使用带有 DNS 中指纹的自签名证书呢？
我想说这给出了与基于 DNS 的 letsencrypt（和其他 CA）的程序完全相同的信任程度：
- 创建自签名 CA（只需按照各种操作方法的步骤操作即可）
- 为某些域名创建证书
- 使用步骤 1 中的 CA 签署步骤 2 中的证书。您现在拥有由非受信任 CA 签署的基本证书
- 在每个域的 DNS 中添加一个 TXT（或专用）记录，说明：我们使用此 CA 签署了此域的证书。例如：“CA=-fingerpint of CA-”
- 浏览器下载证书并通过将 CA / CA 证书的指纹与给定域的 DNS 中的数据进行比较来验证它。
这样就可以创建不受第三方干扰的受信任自签名证书，其信任级别与任何基本 SSL 证书相同。只要您可以访问 DNS，您的证书就是有效的。甚至可以添加一些类似 DNSSEC 的加密，对 CA 和 SOA 记录进行哈希处理，以确保在 DNS 记录发生变化时信任消失。
以前考虑过这个问题吗？
耶尔默
答案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。
因此，我甚至还没有让现代网络服务器实现它，而且大多数其他软件甚至还没有实现 OCSP 和 CRL，祝您 5 年的企业应用程序或设备好运。
潜在应用
那么你实际上可以在哪里使用 DANE？截至目前，还不能在一般互联网上使用。如果你控制服务器和客户端，也许这是一个选择，但在这种情况下，你通常可以求助于公钥固定。
在邮件领域，DANE 正在获得一些关注，因为 SMTP 长期以来没有任何类型的经过身份验证的传输加密。SMTP 服务器有时会在彼此之间使用 TLS，但并未验证证书中的名称是否真正匹配，他们现在开始通过 DANE 进行检查。
答案2
不同类型的证书验证程序
对于常规 CA 签名证书，证书验证有以下几个级别：
- 域名验证 (DV)
仅验证域名所有权，证书中仅显示域名为“主题” - 组织验证 (OV)
域名和所有者名称经过验证，域名和所有者名称在证书中显示为“主题” - 扩展验证 (EV)
对所有者实体进行更严格的验证，域名和所有者名称在证书中显示为“主题”，绿色条带有所有者名称
您描述并建议替代的过程仅适用于最低级别，即域验证（DV）。
DV 是验证相对容易自动化的级别，例如 LetsEncrypt 所做的那样，并且提供与 DNS 所能提供的类似的信任级别，如果它被用作信任锚的唯一来源（UI 含义，证书可能是受信任的，但包含绝对未经验证的额外数据）。
基于 DNS 的命名实体身份验证 (DANE)
丹麦建立在 DNSSEC 之上（因为 DNS 数据真实性至关重要）以在 DNS 中发布针对 TLS 客户端的信任锚信息。
它使用TLSARR 类型，可用于识别证书或公钥（选择器) 无论是终端实体还是 CA，都可能需要或不需要常规证书链验证才能成功 (证书使用）以及证书/密钥数据在记录中的表示方式（匹配类型）。
记录TLSA所有者名称具有表示端口和协议的前缀（例如_443._tcp），并且 RData除了要匹配的证书/密钥数据外还表示cert usage、selector和模式。请参阅matching typeRFC6698 第 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 验证的浏览器插件，除此之外，目前还没有太多接近主流的东西。而且，作为插件而不是原生支持，它在一般用途上更像是一个概念验证。
这是可以做到的。我们一直在考虑。这仍有可能发生，但目前还没有太多进展。