各ユーザーのサブドメインとワイルドカードSSL証明書を持つサイトがあります
問題は、誰かがuser1.theirsite.com-> user1.mysite.comなどのcnameレコードを設定し、それでもhttpsを使用できるかどうかです。
接続を保護するためにサーバーにSSL証明書をインストールすると機能しますか？
ありがとう
質問する
33249 次
3 に答える
13
これが機能するための最良の方法は、SSL証明書にX.509証明書の拡張機能として「エイリアス」を含めるように手配することです。Subject Alternate Name
これは、一部のCDNhttpsがクライアントのサイトをホストするときに使用するアプローチです。1つのサーバーでホストされている既知のサイト名をすべて1つの大きなSSL証明書に入れ、クライアントはCNAMEを使用してドメインを適切なCDNサーバーにポイントします。 。
于 2012-05-04T11:11:57.720 に答える
12
ホスト名と証明書の検証（実際には、SSLが使用されていることの確認）は、クライアントの責任です。
ホスト名の検証は、RFC 2818で指定されているように、クライアントがURLで要求するホスト名に基づいてクライアントによって実行されます。ホスト名のDNS解決がCNAMEエントリに基づいているか、それとも他の何かに基づいているかは関係ありません。
ユーザーがhttps://user1.theirsite.com/ブラウザに入力している場合、ターゲットサイトの証明書はに対して有効である必要がありますuser1.theirsite.com。
user1.theirsite.comとは異なる独自のサーバーがある場合、user1.mysite.comDNSCNAMEエントリは意味がありません。2つのホストが事実上別個であると仮定すると、それらは独自の有効な証明書をuser1.theirsite.com持ち、へのリダイレクトを行うことができますhttps://user1.theirsite.com/。リダイレクトはアドレスバーにも表示されます。
user1.theirsite.comからへのCNAMEが本当に必要な場合はuser1.mysite.com、サーバー名表示を使用して、サイトでもホストできるように、証明書と秘密鍵を提供できる可能性があります（同じポート、もちろん同じIPアドレスを使用していると仮定します）。 'CNAMEを使用しています）。これは、SNIをサポートするクライアントで機能します。ただし、秘密鍵を提供することには一定のリスクがあります（これは一般的には推奨されません）。
于 2012-05-02T01:46:06.367 に答える
0
以下が設定され、機能しています。
a.corp.com->CNAME- b.corp2.com>AのDNSエントリ1.2.3.4
のhaproxyは1.2.3.4の証明書を提供しa.corp.com、サイトはWebサーバーのバックエンドから正常にロードされます。
user1.theirsite.comしたがって、サーバー上で証明書が必要になり、それが機能します。
于 2016-01-19T18:24:14.620 に答える