DANE Trust Anchor -自签名与否

Question

我们运行一个私有CA并同时雇用DNSSEC和DANE。最近，我们决定重新发行我们的CA根和颁发者密钥，因为这些密钥是在我们的PKI于2008年建立时在1024位生成的。我们最初的TLSA指出发行CA作为信任锚。然而，重读RFCs和各种DANE相关评论提出了是否应该使用根公钥的问题。

我们目前正在试验这一想法，平行于我们现有的丹麦记录。当我们使用https://dane.sys4.de/smtp/验证时，我们的现有服务器密钥签出，但是即使我们没有将服务器密钥切换到新的证书链，也会报告新的根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根公钥到底在哪里适合DANE方案？

Answer 1

我通过实验发现：

如果将根和发出的CA TLSA RRs同时放置在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)

但是，如果为由根CA签名的颁发CA和自签名的根CA添加了以下TLSA RR，并且主机RR保持不变，则报告两个TLSA RR都是可用的，没有任何错误或警告消息：

;# 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

推论是自签名证书“可能”有效但不可信，而完整证书链既有效又可信。

尽管如此，我还是希望解释一下这一过程的机制。