因此,如果足以证明能够更改域的DNS记录,为什么不在DNS中使用带有指纹的自签名证书？
我会说这给出了与letsencrypt(和其他CA)基于DNS的程序完全相同的信任度：
>创建一个自签名CA(只需按照各种方法的步骤)
>为某些域创建证书
>使用步骤1中的CA对步骤2中的证书进行签名.您现在拥有一个由非受信任CA签名的基本证书
>将TXT(或专用)记录添加到每个域的DNS中,说明：我们使用此CA签署了此域的证书.喜欢：’CA = -fingerpint of CA-‘
>浏览器下载证书并通过将CA / CA证书的指纹与给定域的DNS中的数据进行比较来验证证书.
这样就可以在没有第三方干扰的情况下创建受信任的自签名证书,其信任级别与任何基本SSL证书相同.只要您有权访问DNS,您的证书就有效.甚至可以添加一些DNSSEC,如加密,从CA加上SOA记录,以确保信任在DNS记录的更改中消失.
之前是否考虑过这个问题？
Jelmer
解决方法
采用
然而,DANE尚未被广泛采用. VeriSign监控DNSSEC and DANE adoption和tracks its growth over time：
相比之下,根据VeriSign,存在大约270万个DNS区域,因此这意味着超过1％的区域至少有一个TLSA记录.
我不能给出任何权威的答案,为什么是DANE,但这里是我的推测：
DANE遇到与证书撤销列表(CRL)和在线证书状态协议(OCSP)相同的问题.为了验证提交的证书的有效性,必须联系第三方. HannoBöckgives a good overview,为什么这在实践中是一个大问题.它归结为当你无法到达第三方时该怎么做的问题.在这种情况下,浏览器供应商选择了软故障(又称许可),这使整个事情变得毫无意义,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这样的主要软件需要一段时间来支持它,并再次回顾HannoBöck的文章,他们弄错了,他们的实现存在缺陷.其他主要的软件项目,如Postfix或Dovecot don’t support OCSP,并且具有非常有限的CRL功能,基本上指向文件系统中的文件(不一定需要重新读取,因此您必须手动重新加载服务器等).
请记住,这些是经常使用TLS的项目.然后你就可以开始研究TLS不常见的东西了,例如Postgresql / @R_404_198@,也许他们最好提供CRL.
所以我甚至没有现代网络服务器实现它,大多数其他软件甚至没有实现OCSP和CRL,祝你5年的企业应用程序或设备好运.
潜在的应用
那你在哪里可以实际使用DANE？截至目前,不是一般的互联网.如果您控制服务器和客户端,也许它是一个选项,但在这种情况下,您通常可以采用公钥固定.
在邮件空间中,DANE正在获得一些牵引力,因为SMTP在最长时间内没有任何经过身份验证的传输加密. SMTP服务器确实有时在彼此之间使用TLS,但没有验证证书中的名称是否实际匹配,他们现在开始通过DANE检查这一点.
