私のアプリケーションがテナントの製品の技術文書をホストおよび提供するマルチテナントアプリケーションを実装しています。

さて、私が検討していることのアプローチだった-私のホストのドキュメントでdocs.<tenant>.mycompany.com、セットアップに私のテナントを尋ねるCNAME DNSレコードポイントにdocs.tenantcompany.comまでdocs.<tenant>.mycompany.com。

テナントの証明書を使用してサイトをSSL対応にしたい。テナント会社がワイルドカードSSL証明書を持っているdocs.tenantcompany.comかどうか、このセットアップで動作するか、新しいSSL証明書を購入する必要があるかを理解したかったのです。

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

場合docs.tenantcompany.comにCNAMEでfoo.example.com、証明書がないではないカバーに必要なfoo.example.comだけ、docs.tenantcompany.com。

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

リダイレクトを行うのは、サーバーがブラウザーに明示的に別の場所に移動するように指示しているWebサーバーのみです。Webサーバーが場合して、実際に他の名前へのリダイレクトをやって、あなたがなり、ブラウザが最終的に別々の両方に接続されるので、実際に両方の名前について本命が必要です。

テナント会社がワイルドカード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サブシステムは、適切なホストのIPアドレスを返します。このホストは、ローカルネットワークまたはインターネット上の他の適切なポートでWebサーバーを実行しています。HTTPS（セキュリティで保護された）トラフィックの443場合、URLで上書きされない限り、デフォルトのポートが使用されます。

• ときにTLSハンドシェイクは、サーバーのプレゼント、ブラウザとリモートサーバの間で要求されたアドレス（TLSでサービスを提供することを許可する信頼できる証明書を行われますdocs.tenantcompany.com）。

DNS

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

TLS

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

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

セキュアセッションの提供をサーバーに許可する方法はdocs.tenantcompany.com、ブラウザーのルート証明書ストアで事前の信頼が確立されている機関によって署名されたSSL証明書によるものです。これは、常にサーバーからクライアントへの最も強力な認証形式ではありません-集中型CAモデルでは多くの場合間違っている可能性がありますが、現時点での最善策です。

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

キー共有

多くの商用SSL証明書ベンダーは、単一の署名要求にのみ署名し、ワイルドカード証明書を単一の秘密キーに効果的にバインドします。秘密鍵を持っている人はだれでも、テナント企業の他のセキュリティで保護されたシステムとの通信を明らかに危険にさらす可能性があるため、テナント企業は組織外でこれを共有するのは不安かもしれません。

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

マスカレーディング

テナント企業がワイルドカード証明書のコピーを提供する場合（プライベートキーを共有するか、独自のCSRに署名する<anydomain>.tenantcompany.comことにより）、tenantcompany.comDNSネームスペースで識別されたサーバーの整合性を保証する重要な保護を破壊するように見せかけることができます。法的/責任の観点から、これはあなたとテナント会社の両方にとって悪い立場になる可能性があります。