プライベートCAを実行し、DNSSECとDANEの両方を採用しています。最近、2008年にPKIが設定されたときに1024ビットで生成されたCAルートキーと発行者キーを再発行することにしました。元のTLSA RRは、発行CAをトラストアンカーとして指定していました。ただし、RFCとさまざまなDANE関連の解説を読み直すと、代わりにROOT公開鍵を使用する必要があるかどうかという疑問が生じます。
現在、既存のDANEレコードと並行してこのアイデアを試しています。 https://dane.sys4.de/smtp/ を使用して検証すると、既存のサーバーキーがチェックアウトされますが、サーバーキーを切り替えていなくても、新しいROOTTLSAレコードも報告されます。新しい証明書チェーンに移動します。さらに、新しいトラストアンカーTLSA RRは、次のように報告されます。
使用可能なTLSAレコード
_2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e - self signed certificate in certificate chain: (19)
_
同じホストの現在のTLSARRは、次のように報告されます。
_2, 0, 2 67274b3554289058[...]5fd3917510e6722a
_
報告された最初のレコードは、新しいルートCAを参照しています。 2つ目は、元の発行CA(元のルートCAによって署名されたもの)を指します。
メッセージself signed certificate in certificate chain: (19)
を確認すると、これはエラーであるという印象があります。ただし、エラーの場合、CAルート公開鍵はDANEスキームのどこに正確に適合しますか?
私が実験を通して発見したのはこれです:
ルートと発行CATLSA
RRの両方を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
RRが、自己署名ルートCAとともにルートCAによって署名された発行CAに追加された場合。ホスト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
自己署名証明書は「おそらく」有効であるが信頼されていないが、完全な証明書チェーンは有効で信頼されているという推論です。
それでも、プロセスの仕組みを説明してもらいたいと思います。