![共有構成と集中証明書を使用した Auzre Web ファームでの SSL 障害](https://rvso.com/image/1402624/%E5%85%B1%E6%9C%89%E6%A7%8B%E6%88%90%E3%81%A8%E9%9B%86%E4%B8%AD%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%20Auzre%20Web%20%E3%83%95%E3%82%A1%E3%83%BC%E3%83%A0%E3%81%A7%E3%81%AE%20SSL%20%E9%9A%9C%E5%AE%B3.png)
[この質問が少し長くて申し訳ありません。関連する場合は追加情報が多数あります]
概要
Azure の 4 つの VM の負荷分散ファームで SSL に問題が発生しています。HTTPS 要求がファームの最初のサーバーに送信された場合は、すべて正常です。他の 3 つのサーバーのいずれかに到達すると、呼び出しは失敗します。Chrome は SSL プロトコル エラーを発行し、IE と Firefox は単にページを表示できないと表示します。
セットアップ
AzureにWindows Server 2012 VMを4台持っています(テスト用の小さなインスタンスです)。VMは同じクラウドサービスと可用性セットにあります。ポート80と443に負荷分散エンドポイントが追加されました(直接サーバーリターンはないこれらでは有効化されています)。4 台のマシンはすべて同じ PowerShell スクリプトを使用してセットアップされ、2 つの例外を除いてこの方法で完全に構成されました。
各サーバーの IIS 構成は共有構成を使用するように設定されており、グループの最初のサーバーから各サーバーに DFS 経由で複製されます。これは各サーバーに対して手動で構成されており、正常に動作しています。
DFS は、最初のサーバーから他のサーバーに Web フォルダーを複製するためにも使用されます。
また、展開スクリプトを書いた後に「新しい」集中証明書機能も発見したので、これも 4 台のサーバーに手動でインストールして構成しました。証明書ファイルの保存には別のサーバー上の共有を使用しています。
証明書要求は最初のサーバーで生成され、SSL.com を使用して、アドレス の 90 日間の無料 SSL を取得しました。Azure アドレスを指すように、DNS にsubdomain.domain.com
CNAME レコードを追加しました。subdomain
domain.com
cloudapp
SSL 証明書を最初のサーバーにインポートし、再度subdomain.domain.com.pfx
(パスワード付きで) エクスポートして、証明書ファイル共有にコピーしました。4 つのサーバーすべてで集中証明書を確認すると、構成のパスワードが間違っているなどのエラー アイコンが表示されず、証明書が正常にリストされています。
最後に、サーバー1のバインディングを変更して、ホスト名にhttpsを追加しsubdomain.domain.com
、サーバー名の表示が必要そして集中証明書ストアを使用するオプションがチェックされています。他のサーバーをチェックすると、バインドが期待どおりに伝播されていることがわかります。
問題
リクエストが処理されたサーバーの名前を単に表示する基本ページを追加しました。 複数の IE ウィンドウをシェルしてアクセスするとhttp://subdomain.domain.com
、さまざまなサーバー名が出力され、IIS 構成と Web ファイルが正しく展開されていること、および Azure の負荷分散機能も正常に動作していることがわかります。これは実にすばらしいと思いました。
しかし、HTTPS 経由でこれを試してもうまくいきません。最初のサーバーに到達したリクエストのみが成功し、残りのリクエストはクラッシュして、テストするブラウザーに応じて「このページは表示できません」または「SSL プロトコル エラー」というメッセージが表示されます。サーバー 1 では、ページは正常に表示され、証明書は表示可能で、証明書エラーはありません。
これはどこかのサーバーの構成の問題であることは確かですが、一体何なのかはわかりません。私が取り組んでいることのほとんどは私にとって新しいものです。これまでは、IIS6 を搭載した物理的な非クラスター化 Windows 2003 サーバーを使用していました。
さらに困惑しているのは、一晩中 4 つの VM をシャットダウンし、今朝サービスを再起動すると、どうやらサーバー 1 に加えてサーバー 2 も SSL 要求に応答するようになったことです。とはいえ、昨日も完全シャットダウンしましたが、その後もサーバー 1 だけが機能しました。
IIS ログ ファイルには失敗した SSL 要求は表示されず、サーバー 1 と 2 のポート 80 の 200 の集合とポート 443 の 200 と 304 の混合のみが表示されます。
Google 検索でかなりの努力をしましたが、何も明らかになりません。実際はまったく逆で、私がやったことはうまくいくはずだと私は思います。
この問題を解決するために役立つアドバイスがあれば、ぜひいただければ幸いです。
答え1
IIS の集中証明書ストアに関するほとんどの問題を解決する手順をいくつか紹介したいと思います。集中証明書ストア (CCS) は、SSL 証明書要求を CCS に送るために使用する偽の証明書バインディングを作成します。このバインディングが存在しないか、同じ IP アドレスに複数のバインディングがある場合、クライアントが SSL 対応の Web サイトに接続しようとすると、ブラウザー エラーが表示されます。
172.16.0.41
次の設定を検討してください。IP アドレスと集中証明書ストアが有効になっているIIS サーバーに2 つのドメインが含まれておりwww.adomain.com
、www.bdomain.com
各ドメインの IIS 集中証明書ストアに PFX 証明書パッケージがインストールされています。
通常、エラーは 2 つあります。
問題1
ブラウザが Web サイトに接続すると、間違った証明書が共有されます。たとえば、www.adomain.com
初めて にアクセスすると正しい証明書が提供されますがwww.bdomain.com
、ブラウザが にアクセスすると の証明書www.adomain.com
が返され、ブラウザは無効な証明書エラーのフラグを立てます。
解決
この問題の原因は通常、複数のウェブサイトが同じIPアドレスにバインドされており、少なくとも1つのウェブサイトで有効になっていないことです。サーバー名の識別が必要同じIPとポートを共有するすべてのWebサイトでこの設定を有効にしないと、IISはどの証明書を提供するか判断できず、先着順ポリシーが適用されるようです。
つまり、同じ IIS サーバーでホストされている他の Web サイトへの後続の要求では、間違った証明書が返されます。
解決手順
各 Web サイトが に設定されていることを確認します
Require Server Name Identification
。これを行うには、IIS マネージャーで各 Web サイトをクリックし、[バインド] を選択して、HTTPS バインドを選択し、[編集] を選択して、[チェック] をクリックしRequire Server Name Identification
、Use Centralized Certificate Store
もチェックされていることを確認します。サーバーのバインドを確認します。管理者権限のコマンドボックスから実行します。
netsh http show sslcert
CCS のバインディングが存在する必要があります:
SSL Certificate bindings:
-------------------------
Central Certificate Store : 443
Certificate Hash : (null)
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : (null)
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
証明書ハッシュとのバインディングは、(null)
CCS パススルー バインディングの存在を示していることに注意してください。サーバーの IP アドレスと SSL ポート (172.16.0.41:443
このシナリオの場合) をリッスンしている他のバインディングがある場合は、それらを削除する必要があります。
バインディングを削除するには、 と入力します
netsh http delete sslcert <binding>
。このシナリオでは、 となりnetsh http delete sslcert 172.16.0.41:443
、バインディングが削除されます。CCS(null)
パススルー バインディングは削除しないでください。このバインディングが存在しない場合は、問題2下に。iis をリセットして
iisreset
、Web サーバーの各ドメインに接続します。正しい証明書が共有されるはずです。手順 2 を繰り返して、IP:PORT
SSL ポートと Web サーバー IP への特定のバインドが存在し ないことを確認することで、バインドを確認することもできます。
問題2
集中証明書ストアが有効になっていて、証明書が表示され、すべての Web サイトがそれを使用するように設定されていることを確認した後でも、ブラウザーが Web サイトに接続すると、Page Cannot be displayed
またはinvalid encryption
エラーがスローされます。目的の Web サイトが表示されません。
IE (Edge) では、通常、ブラウザで適切な暗号化タイプが有効になっているかどうかを確認するよう求める提案が表示されます。
iisreset
サーバーの再起動を行っても問題は解決しません。
解決
これは、CCS パススルー バインディングの作成におけるバグのようです。CCS 機能が有効になっている場合、Web サーバー上では作成されないため、証明書の受信要求は暗黙的にドロップされます。
解決手順
まず、集中証明書ストアが有効になっていて、そのパス内のすべての証明書を表示できることを確認します。これを行うには、
IISManager
サーバー ノード -> 集中証明書 (管理セクションの下) -> 機能設定の編集... を選択し、構成され、有効になっていることを確認します。共通証明書を使用するすべての Web サイトが CCS にバインドされていることを確認します。これを行うには、IIS マネージャーで各 Web サイトをクリックし、[バインド] を選択して、HTTPS バインドを選択し、[編集] を選択して、[チェック] を選択し
Require Server Name Identification
、チェックUse Centralized Certificate Store
もオンになっていることを確認します。CCS バインディングが作成されたことを確認します。 を実行します
netsh http show sslcert
。結果が空の場合、または(null)
パススルー証明書が存在しない場合 (CCS バインディングの様子については、問題 1 の手順 2 を参照)、CCS バインディングは有効になっていません。SSL Certificate bindings: -------------------------
IISマネージャーで、CCSを使用するWebサイトを1つ選択し、「バインド...」をクリックし、HTTPSバインドを選択し、「編集」を選択し、チェックを外す
Use Centralized Certificate Store
そしてチェックを外すRequire Server Name Identification
。
ドロップダウンでSSL certificate
、サーバーのデフォルトWMSVC
証明書を選択し、をクリックしますOK
。Site Bindings
ウィンドウを開いたままにしておきます。
管理者特権のコマンド プロンプトに戻り、 を実行します
netsh http show sslcert
。次のようなバインディングが生成されます。SSL Certificate bindings: ------------------------- IP:port : 172.16.0.41:443 Certificate Hash : 64498c920fecb31b8f7ccbdac2fa2baa2ec4f19a Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914} Certificate Store Name : My Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled
ウィンドウに戻り
Site Bindings
、手順 4. の有効化と変更を元に戻しRequire Server Name Indication
、Use Centralized Certificate Store
をクリックしますOK
。管理者特権のコマンド プロンプトに戻り、
netsh http show sslcert
もう一度実行すると、運が良ければ、集中証明書ストアのバインディングが突然現れ、現在のバインディングが置き換えられるはずです。SSL Certificate bindings: ------------------------- Central Certificate Store : 443 Certificate Hash : (null) Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914} Certificate Store Name : (null) Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled
(null)
上記の証明書が値とバインドされていることが確認できれば、証明書はCertificate Hash
機能しており、CSS パススルーが有効になっているはずです。
- ブラウザを起動し、セキュア ソケット (HTTPS) 経由でサーバー上のドメインに接続してみると、すべて正常に動作するはずです。
重要な注意事項
このプロセスを Web ファーム内の各 Web サーバーで繰り返す必要があります。このプロセスを自動化して確認するには、PowerShell を使用するとよいでしょう。
パススルー バインディングが作成されると、ノードで集中証明書のサポートを無効にしない限り、無期限に保持されます。
余談ですが、このリンクには CCS が技術的なレベルでどのように機能するかについての情報が記載されており、一読する価値があります。https://blogs.msdn.microsoft.com/kaushal/2012/10/11/central-certificate-store-ccs-with-iis-8-windows-server-2012/
それが役に立つことを願います。