web-dev-qa-db-ja.com

DNSリダイレクトには別のSSL証明書が必要ですか？

アプリケーションがホストし、テナントの製品の技術ドキュメントを提供するマルチテナントアプリケーションを実装しています。

今、私が検討していたアプローチは-docs.<tenant>.mycompany.comでドキュメントをホストし、docs.tenantcompany.comがdocs.<tenant>.mycompany.comを指すようにCNAME DNSレコードを設定するようにテナントに依頼しました。

テナントの証明書を使用してサイトをSSL対応にしたい。私のテナント会社がワイルドカードSSL証明書を持っているかどうかを知りたいのですが、この設定で動作しますか、それともdocs.tenantcompany.com用に新しいSSL証明書を購入する必要がありますか？

domain-name-systemsslssl-certificatecname-recorddns-zone
18
codematix

証明書名は、「最終的な」DNSレコードではなく、ユーザーがブラウザに入力したものと一致する必要があります。ユーザーがdocs.tenantcompany.comを入力した場合、SSL証明書はそれをカバーする必要があります。

docs.tenantcompany.comがfoo.example.comへのCNAMEである場合、証明書はfoo.example.comをカバーする必要がありますnotdocs.tenantcompany.comのみをカバーします。

40
Jason Martin

ジェイソンの答えは正しいです。しかし、ここで少し用語を明確にするために、「DNSリダイレクト」は少し誤った名称です。 DNSには、別の名前を指す名前であるCNAMEレコード（別名エイリアス）があります。しかし、それはリダイレクトではありません。名前から名前、IPへの変換はすべてバックグラウンドで行われ、ブラウザは最初の名前のみを考慮します。

リダイレクトを行うのは、サーバーがブラウザーに別の場所に移動するよう明示的に指示しているWebサーバーのみです。 Webサーバーwasが実際に他の名前へのリダイレクトを行っている場合、ブラウザは最終的に両方に個別に接続するため、実際にはwould両方の名前の証明書が必要です。

26
Ryan Bolger

自分のテナント会社にワイルドカードSSL証明書があるかどうかを知りたいのですが、この設定で動作しますか、それともdocs.tenantcompany.com用に新しいSSL証明書を購入する必要がありますか？

短い回答：いいえ。テナント企業の名前にワイルドカードが*.tenantcompany.comに含まれている場合、サーバーにインストールしてアクセスをカバーするのに十分ですその名前で。これをしたいかどうかは別の話です。

名前docs.<tenant>.mycompany.comの証明書（直接証明書やワイルドカード*.<tenant>.mycompany.comなど）は、常にdocs.tenantcompany.comの名前を介してアクセスする場合は役に立ちません。

より長い答え

適切なブラウザでhttps://docs.tenantcompany.comを閲覧するとします。ブラウザはHTTPプロトコルを介してTLSを実行します。具体的には2つの点に注意します。それ：

  • ブラウザおよびオペレーティングシステムのDNSサブシステムは、ローカルネットワークまたはインターネット上のどこか適切なポートでWebサーバーを実行している適切なホストのIPアドレスを返します。 HTTPS（保護された）トラフィックの場合、URLで他の方法でオーバーライドされない限り、デフォルトのポートは443です。

  • TLSハンドシェイク がブラウザーとリモートサーバー間で発生すると、サーバーは信頼された証明書を提示し、要求されたアドレス（docs.tenantcompany.com）でTLSサービスを提供できるようにします。

DNS

ブラウザはDNSをブラックボックスと見なします。適切なDNSライブラリを呼び出して、わかりやすい完全修飾ドメイン名（FQDN）から適切なIPアドレス（v4またはv6）へのマッピングを要求します。 そのIPアドレスの取得方法は関係ありません。元のレコードとDNSの間に20個のCNAMEエイリアスがある場合AまたはAAAAレコード。DNSリゾルバーは、IPアドレスが取得されるまでそれらを追跡します。

TLS

ブラウザが TLSハンドシェイク を実行するとき、通信しているサーバーが、要求されたFQDNで安全なWebサイトサービスを提供することを承認されていることを確認する必要があります：docs.tenantcompany.com。

覚えておいてください：ブラウザーはdocs.<tenant>.mycompany.comを気にしません-DNSリゾルバーはCNAMEレコードを介して間接のすべての知識を抽象化しました。

サーバーがdocs.tenantcompany.comで安全なセッションを提供することを承認する方法は、ブラウザのルート証明書ストアで事前の信頼が確立されている機関によって署名されたSSL証明書によるものです。これは、サーバーからクライアントへの認証の最も強力な形式であるとは限りません。一元化されたCAモデルでは、多くの点で失敗する可能性がありますが、現時点ではこれが最も優れています。

ここにはさらに2つの警告があります。

鍵の共有

多くの商用SSL証明書ベンダーは、ワイルドカード証明書を単一の秘密鍵に効果的にバインドする単一の署名リクエストのみに署名します。秘密キーを所持している人は誰でも明らかに、テナント会社の他の安全なシステムとの通信を危うくすることができるので、テナント会社は組織の外でこれを不安に共有しているかもしれません。

一部のベンダーは、同じ証明書で複数の証明書署名要求に署名します。これにより、1つのワイルドカード証明書を、それらの間で秘密鍵を共有することなく複数のサーバーおよびシステムにインストールできます。

マスカレード

テナント会社からワイルドカード証明書のコピーが提供された場合（秘密キーを共有するか、独自のCSRに署名することにより）、<anydomain>.tenantcompany.comになりすまして、特定されたサーバーの整合性を保証する重要な保護を解除できます。 tenantcompany.com DNS名前空間。これは、法的/責任の観点から、あなたとテナント企業の両方にとって悪い立場になる可能性があります。

9
Cosmic Ossifrage