「ルート変更」の意味:
実際の例として、mysite.example.netは次のように設定されています。
mysite.example.net. 3600 IN CNAME some-other-site.elsewhere.com.
some-other-site.elsewhere.com. 580 IN A 22.33.11.0
次に、mysite.example.netは次のように変更されます。
mysite.example.net. 3600 IN CNAME newsite.differentplace.com.
newsite.differentplace.com. 3600 IN CNAME some-other-site.elsewhere.com.
some-other-site.elsewhere.com. 580 IN A 22.33.11.0
(CNAMEをCNAMEにポイントするというベストプラクティスを別にして)、「ルート」は2つのルックアップから3に変更されました。
また、ルックアップ「ルート」に沿った「途中」またはIPアドレスの側へのステップの数や種類の変更が、検証される証明書に影響を与えるかどうかも尋ねています。
この質問 からの次のスニップからの私の理解は、すべてのルックアップが「正しい」場所(つまり、証明書のCNが照会された最初のDNS URLと一致する)から発生している限り、証明書の検証には影響しません。ルックアップチェーンへの変更がいくつあっても、どんな種類の変更でも、証明書が有効/検証された最終結果に影響を与えてはなりません。
しかし、CAを使用すると、必要なすべてのサーバーを信頼できます!
はい、それが信頼の源です。CAを信頼して、希望どおりに証明書を作成しないようにする必要があります。 Microsoftのような組織、AppleおよびMozillaがCAを信頼している場合でも、CAは監査を受ける必要があります。別の組織が定期的にそれらをチェックして、すべてがルールに従って実行されていることを確認します。
証明書の発行は、登録者が証明書が発行されたドメインを所有していることを登録者が証明できる場合にのみ行われます。
私は正しいですか?
回答を制限しないでください。具体的には、途中で他の証明書が元のルックアップに巻き込まれますか? (たとえば、newsite.differentplace.com
には独自の証明書があると言いますが、検証ではmysite.example.net
の証明書の代わりにそれを使用しますか?)
DNSエイリアス(CNAME)またはIPアドレスの変更は、証明書の検証にはまったく関係ありません。重要なのは、クライアントから見たホスト名(URL内の名前など)が証明書のサブジェクトと一致することです。この名前は、DNSを変更しても変更されません。
多くの場合、DNS CNAMEはHTTPリダイレクトと混同されます。 CNAMEの場合、名前は同じままなので、CNAMEは証明書の検証には無関係です。 HTTPリダイレクトの場合、名前が変更される可能性があり、これはブラウザに表示されるURLの変更にも反映されます。