我们运营一家私人 CA，同时采用 DNSSEC 和 DANE。最近，我们决定重新发布 CA 根密钥和颁发者密钥，因为这些密钥是在 2008 年建立 PKI 时以 1024 位生成的。我们最初的 TLSA RR 将颁发 CA 指向为信任锚。然而，重新阅读 RFC 和各种与 DANE 相关的评论提出了一个问题：是否应该改用 ROOT 公钥。
我们目前正在试验这个想法，与现有的 DANE 记录并行。当我们使用https://dane.sys4.de/smtp/进行验证，则我们现有的服务器密钥将通过检查，但即使我们尚未将服务器密钥切换到新的证书链，也会报告新的 ROOT TLSA 记录。此外，新的信任锚 TLSA RR 报告如下：
可用的 TLSA 记录
2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e - self signed certificate in certificate chain: (19)
而同一主机的当前 TLSA RR 报告方式如下：
2, 0, 2 67274b3554289058[...]5fd3917510e6722a
报告的第一条记录指的是新的根 CA。第二条记录指的是原始颁发 CA（由原始根 CA 签名）。
当我检查消息时，self signed certificate in certificate chain: (19)我形成的印象是这是一个错误。但是，如果这是一个错误，那么 CA Root 公钥究竟在 DANE 方案中处于什么位置？
答案1
我通过实验发现：
如果将根 CA RR 和颁发 CA TLSARR 都放在 DNS 转发区域中，则上面报告的错误就会消失。例如：
鉴于此主机 RR：
_443._tcp.inet04.hamilton.harte-lyne.ca. 300 IN CNAME _tlsa._dane.trust.harte-lyne.ca.
如果前向区域中的自签名根 CA 仅存在以下记录，那么我们会看到原始问题中报告的错误（或警告，我不确定是哪一个）：
;# CA_HLL_ROOT_2016 public key hashed sha512 Trust Anchor (active)
_tlsa._dane.trust.harte-lyne.ca. 300 IN TLSA ( 2 1 2
c26e0ec16a46a97386e8f31f8ecc971f2d73136aa377dfdaac2b2b00f7cab4bb29b
17d913c82093b41fd0d9e40b66a68361c126f1f4017f9ce60eabc5adba90e )
用这个测试站点进行检查：
https://dane.sys4.de/smtp/inet04.hamilton.harte-lyne.ca
产生此错误或警告：
Usable TLSA Records
2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e - self signed certificate in certificate chain: (19)
TLSA但是，如果为由根 CA 和自签名根 CA 签名的颁发 CA 添加以下RR；并且主机 RR 保持不变；则两个TLSARR 都将被报告为可用，而不会出现任何错误或警告消息：
;# CA_HLL_ISSUER_2016 public key hashed sha512 Trust Anchor (active)
_tlsa._dane.trust.harte-lyne.ca. 300 IN TLSA ( 2 1 2
380259229e21a1946b38cfc594cbc993b61bc93762b7b6c6637b3eef9c5a2bb70c5
89b91beb73bd1304eac11b3917e33819e2b47d25d4966435a2a3e83c1f80f )
TTL 过期后访问测试站点：
https://dane.sys4.de/smtp/inet04.hamilton.harte-lyne.ca
给出这个：
Usable TLSA Records
2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e
2, 1, 2 380259229e21a194[...]435a2a3e83c1f80f
推论是，自签名证书“可能”有效但不受信任，而完整的证书链既有效又受信任。
无论如何，我希望能解释一下这个过程的机制。