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

因此，如果有足够的证据可以更改域的DNS记录，那么为什么不在DNS中使用带有指纹的自签名证书呢？

我要说的是，此信任与letencrypt（和其他CA）基于DNS的过程完全相同：

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

这样就可以创建不受第三方干扰的，与任何基本SSL证书具有相同信任级别的受信任的自签名证书。只要您有权访问DNS，您的证书就有效。甚至可以添加一些DNSSEC（如加密），以从CA加上SOA记录中进行哈希处理，以确保信任因DNS记录的更改而消失。

以前考虑过吗？

耶尔默

存在使之成为可能的基本基础结构，该基础结构称为RFC6698中指定的基于DNS的命名实体身份验证（DANE）。它通过TLSA资源记录来工作，该资源记录指定了终端实体或其链中的CA之一的证书或公钥（实际上有四种类型，有关详细信息，请参阅RFC）。

采用

但是，DANE尚未得到广泛采用。威瑞信（VeriSign）监控DNSSEC和DANE的采用情况，并跟踪其随着时间的增长：

为了进行比较，根据VeriSign的说法，大约有270万个DNS区域，这意味着所有区域中超过1％的区域至少具有一个TLSA记录。

我不能给出任何权威性的答案，为什么选择DANE，但这是我的推测：

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

域名系统

可以说，DNS比CA的CRL和OCSP服务器提供了更好的可用性，但是仍然使脱机验证变得不可能。此外，DANE仅应与DNSSEC结合使用。由于正常的DNS在未经身份验证的UDP上运行，因此很容易出现伪造，MITM攻击等。采用DNSSEC比采用DANE更好，但仍远远没有普及。

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

然后还有撤销的问题。DNSSEC没有撤消机制，而是依靠短寿命密钥。

软件支援

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

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

我不知道，例如，任何主要的Web服务器（例如Apache或Nginx）都已实现DANE或已计划这样做。Web服务器在这里尤为重要，因为越来越多的东西是基于Web技术构建的，因此它们通常是第一个实现的东西。

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

因此，我什至没有现代的Web服务器来实现它，大多数其他软件甚至都没有实现OCSP和CRL，这对于您5年的企业应用程序或设备来说是好运。

潜在的应用

那么，您实际上可以在哪里使用DANE？截至目前，还没有在普通的Internet上。如果您控制服务器和客户端，也许是一种选择，但是在这种情况下，您通常可以诉诸公钥固定。

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

不同类型的证书验证程序

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

• 域验证（DV）
  仅验证域名所有权，证书中仅将域名显示为“主题”
• 组织验证（OV）
  域名和所有者名称经过验证，域名和所有者名称在证书中显示为“主题”
• 扩展验证（EV）
  对所有者实体，域名和所有者名称的更严格的验证在证书中显示为“主题”，带有所有者名称的绿色栏

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

DV是验证相对容易实现自动化的级别，例如LetsEncrypt所做的工作，并且提供与DNS所提供的信任级别相似的信任级别，如果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验证，除了目前还没有什么主流的插件。而且，作为一个插件而不是本机支持，它在一般用途上比其他任何东西更多地用作概念验证。

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