web-dev-qa-db-ja.com

同じドメインに対して2つの異なるSSL証明書を構成することは技術的に可能ですか？

次のURLがあるとします。

  1. https://example.org/

  2. https://example.org/criticalpath

最初の証明書はドメインで検証された商用SSL証明書で提供され、2番目の証明書は拡張された検証SSL証明書で提供されます。技術的に可能ですか？ SSL/TLS（およびHTTPS？）標準とブラウザでサポートされていますか？

これが適切な構成であるかどうかは決して尋ねません（すべてのドメインでEVを使用します）。その構成がサポートされているかどうかを確認するだけです。標準への参照を本当に感謝します。

tlscertificatesdomain
24
Jaime Hablutzel

はいといいえ。

すべてが同じドメイン名を持つ複数の証明書を持つことが可能です。 Comodoのexample.org証明書とEntrustのexample.org証明書を使用できます。どちらも有効であり、公式であり、問​​題ありません。一部のロードバランサーは、接続ごとに使用されますが、ラウンドロビン方式でのみローテーションします。

Noは、URIに基づいて使用する証明書を選択できるかどうかを尋ねていることです（/ vs/criticalpath）。問題は、URIは、SSL接続が2つの証明書のいずれかを使用して釘付けにされた後にのみ使用できることです。そのため、実際に使用する証明書を、証明書を選択した後にのみ取得できる情報に基づいて選択することはできません。

さて、100％不可能だとは言いません。たとえば、Apacheでは、ディレクトリごとに SSLCipherSuite 構成を設定できるため、someの方法があったとしても驚くことはありません新しい証明書を必要とする再交渉を強制する。しかし、理論的には可能であるとしても、実際には実装されていないと思います。 （Apache SSLCertificate *は、ディレクトリごとではなく、サーバーごとまたはvhostごとです）。

付録：再交渉の際の考察

免責事項：私はこれを何もしていません。これは、RFCやその他のドキュメントの素人による解釈です。ここにいる何十人もの人々は、私よりもはるかにコメントする資格があります。

RFC 5246 内にきちんと記述されているので、TLS 1.2を見ていきます。

7.4.1.1項「HelloRequestメッセージはいつでもサーバーから送信される場合があります。」これにより、クライアントは接続を再ネゴシエートするようトリガーされます。 （クライアントはその要求を無視してもよく、クライアントが要求を無視しすぎるとサーバーは接続をドロップしてもよい（MAY）。

再ネゴシエーションは最初のネゴシエーションに非常によく似ていますが、パスを平滑化するために前のネゴシエーションからいくつかの情報を転送する場合があります（たとえばここに前回合意した暗号があります ）。したがって、クライアントはClientHelloを送信し、サーバーはServerHelloを送信します。 その後、サーバーはaServer Certificate（7.4.2 ）。

したがって、RFCの私の読み取りは、はい、サーバーは別のサーバー証明書の選択を含め、接続の再ネゴシエーションを強制することができます

私はあなたに正直になります、あなたがやりたいことをする既存のソフトウェアを見つけるかどうかはわかりません。 Perl Crypto :: OpenSSLまたはPythonのssl libを試してみて、テストできるかどうかを確認することをお勧めします。

33
gowenfawr

いいえ。この機能をサポートできるWebサーバーはありません。今ではありません。理由は次のとおりです。

HTTPSは次の手順をこの順序で実行します。

  1. クライアントがサーバーに接続する
  2. SSL/TLSネゴシエーション（証明書の交換、証明書の検証、暗号化の設定を含む）
  3. クライアントがリクエストを送信（サーバーのホスト名、パス、Cookieなどを含む）
  4. サーバーは応答を返します（応答ヘッダー、コンテンツなどが含まれます）

上記のステップ2はステップ3の前に行われることに注意してください。つまり、ブラウザーがサーバーに探しているURLを通知する前に、暗号化処理全体が完全に終了します。これは、サーバーが使用するSSL証明書を選択したときに、URLパスがどうなるかまだわからないことを意味します。この段階ではこの情報を利用できないため、どの証明書を使用するかを決定することはできません。

また、ホスト名はステップ3でサーバーに送信されるため、各証明書は通常、一意のIPアドレスにインストールされます。サーバーはIPアドレスを使用して、提示する証明書を決定します。 SSL/TLSの新しいバージョンには、クライアントがTLSネゴシエーション中にホスト名を指定できるようにする Server Name Identification と呼ばれる拡張機能が追加されましたが、これはホスト名に対してのみ機能します。

URLパスに基づいて証明書を選択できるようにする規定はありません。URLパスを証明書の選択の一部として暗号化せずにサーバーに送信する必要があることを意味するためです。また、URLを暗号化せずに送信することは、安全なページでは受け入れられません。

8
tylerl

私はそれがSSLオフロード、ディープパケットインスペクション、およびTLS再ネゴシエーションを使用して可能である可能性があると考えています。ただし、Google TLS再ネゴシエーションをグーグルする場合、上位20件のヒットは再ネゴシエーションの脆弱性に関するものです。そのため、そうした場合、サイトの安全性が低下し、それ以上ではなくなる可能性があります。

一方、あなたの計画がこのようなものだった場合：

https://example.org/

https://criticalpath.example.org/

それはかなり簡単です。これら2つのドメインを異なる内部IPにルーティングし、IPを異なる証明書にバインドするだけです。

3
John Wu