大多数低成本的 SSL 证书提供商实际上只验证您控制了一个域名。对于这些类型的证书，与其付费给第三方来验证我是否控制了域的 DNS 记录，为什么不在 DNS 中“签署”证书？如果我在服务器上生成密钥对并在 DNS 中为主机名发布相同的公钥，我认为这将是等效的安全级别。
我发现设计存在两个问题，但看起来都很小：
- 不能以这种方式完成 EA 证书和验证个人/公司详细信息的更高级别的证书。希望付费以在浏览器中获得绿条的组织可以继续这样做。
- 带有恶意 DNS 服务器的恶意网络可能会将您重定向到不同的主机名和不同的受信任 SSL 证书。也许 DNSSEC 可以解决这个否认问题？
我不知道有任何浏览器实现了这样的功能，但它似乎是一个好方法，至少可以在不显示可怕的“不受信任的证书”对话框的情况下获得受信任的加密连接。除了我上面提到的问题和现有的商业认证机构反对这个想法之外，还有其他原因会是一个坏主意吗？
在 DNS 记录中编码 X.509 证书已经完全有可能——查看RFC 4398
CERT中的记录类型。它没有在愤怒中完成的主要原因是因为传输机制还不安全。当根区域获得 DNSSEC 签名并且越来越多的 TLD 支持 DNSSEC 时，这将在今年晚些时候发生巨大变化。
DNS 查询大小（如其他地方所述）也是一个问题，尽管值得注意的是，
CERT RR它还允许您简单地存储可以从中下载真正 X.509 证书的 URL。在这一点上，有一些鸡和蛋的问题，虽然......SSL 证书应该验证站点的身份，以便最终用户可以确保他们的请求没有被中毒的 DNS 服务器、伪造的 BGP 广播或其他也允许提供伪造证书的肮脏技巧转移DNS 看起来有效。
我说“应该”是因为一切都被“即时”证书淡化了，这些证书没有特别证明，老实说，我认为浏览器供应商应该对所有未经审计的证书显示“不受信任的证书”警告，或者继续并允许无需提示的自签名证书。现状不一致。
自从我多年前提出这个问题以来，在实现这一目标方面取得了一些积极的进展。将 DNSSEC 与 DNS 中已发布的 TLS 证书相结合以保护您的 DNS 可以实现这一目标。谷歌浏览器已经支持 DNSSEC-stapled 证书有一段时间了，现在RFC6698 基于 DNS 的命名实体身份验证 (DANE)试图标准化这种支持。
浏览器对此的广泛支持还需要几年时间，但我很期待。
缺乏标准化，以及额外的管理开销（在机器上删除密钥/证书比添加密钥要容易得多——这可能很长，因此违反了 UDP 数据包限制）是从实际的角度来看，这些事情会扼杀这一点。缺乏安全的 DNS 有点令人担忧，但对于低价值目标而言，这并不是真正意义上的安全性降低。但是，对于内部服务，我们只是导入我们自己的 CA 证书，因此您不会真正从中获得任何东西，而且任何需要SSL 的公共站点无论如何都需要“真正的”证书。
如果要认真推动此类事情（RFC 草案、参考实现等），我希望看到商业证书提供商的强烈反对和 FUD——就像任何寄生虫一样，当他们的摇钱树看起来像它时，他们会非常恼火可能会被宰杀。
也许最好让事情保持简单——即不要让 DNS 做得比它应该做的更多。我对添加东西持谨慎态度，尤其是在安全方面。有时少即是多。我的想法背后的主要原因是因为 DNS 和 SSL 不在同一个域中，并且没有相似的功能或目的。