質問: 共有構成と一元化された証明書を使用したazurewebファームでのssl障害 [この質問が少し長い場合は申し訳ありませんが、関連性がある場合に備えて追加情報がたくさんあります]概要概要azureの4vmの負荷分散ファームでsslに問題があります。 https要求がファーム内の最初のサーバーに送信される場合、すべて問題ありません。他の3つのいずれかに到着した場合、呼び出しは失敗します。 chromeはsslプロトコルエラーを発行します、ieそしてfirefoxは単にページを表示できないと言います。セットアップazure上に4つのwindowsserver 2012 vmがあります(テスト用の小さなインスタンス)。 vmは、同じクラウドサービスと可用性セットに含まれています。ポート80と443に負荷分散されたエンドポイントが追加されました(サーバーへの直接の戻りは[〜#〜] not [〜#〜]これらで有効になっています)。 4台のマシンはすべて同じpowershellスクリプトを介してセットアップされ、2つの例外を除いてこの方法で完全に構成されました。各サーバーのiis構成は、グループ内の最初のサーバーから各サーバーにdfsを介して複製される共有構成を使用するように設定されています。これはサーバーごとに手動で構成され、正常に機能しています。 。dfsは、最初のサーバーから他のサーバーにwebsフォルダーを複製するためにも使用されます。また、展開スクリプトを作成した後、「新しい」集中証明書機能を発見したため、これも4台のサーバーに手動でインストールして構成しました。別のサーバーの共有を使用して証明書ファイルを保存しています。証明書要求は最初のサーバーで生成され、ssl.comを使用してアドレスsubdomain.domain.comの90日間の無料sslを取得しました。 azure subdomainアドレスを指すdomain.comのdnsにcloudappのcnameレコードを追加しました。ssl証明書を最初のサーバーにインポートしてから、subdomain.domain.com.pfx(パスワード付き)として再度エクスポートし、証明書ファイル共有にコピーしました。 4つのサーバーすべてで一元化された証明書をチェックすると、構成のパスワードが間違っていたことなどを示すエラーアイコンなしで、証明書が正常に一覧表示されます。最後に、サーバー1のバインディングを変更して、ホスト名subdomain.domain.comでhttpsを追加し、サーバー名の表示が必要および集中証明書ストアを使用オプションをオンにしました。他のサーバーをチェックすると、バインディングが期待どおりに伝播されていることがわかります。問題リクエストが処理されたサーバーの名前を単純に吐き出す基本的なページを追加しました。 http://subdomain.domain.comにアクセスするいくつかのieウィンドウをシェル化すると、さまざまなサーバー名が出力され、iis configファイルとwebファイルが正しくデプロイされており、azureの負荷分散もそれを行っています。実際、これは本当にクールだと思いました。ただし、https経由でこれを試してみると、無駄になります。最初のサーバーにヒットしたリクエストのみが成功し、残りのリクエストはクラッシュして、テストするブラウザーに応じて「このページを表示できません」または「sslプロトコルエラー」で書き込みます。サーバー1では、ページが正常に表示され、証明書が表示可能であり、証明書エラーはありません。これはどこかのサーバーの構成の問題だと確信していますが、一体何なのかわかりません。過去にiis6で物理的な非クラスター化windows2003 serverを使用していたように、私が遊んでいるもののほとんどは私にとって新しいものです。さらに厄介なのは、4つのvmを一晩シャットダウンし、今朝サービスを再起動すると、サーバー2がサーバー1に加えてssl要求に応答するようになったことです。それでも、昨日も完全にシャットダウンしました。その後もサーバー1のみが機能しました。iisログファイルには、失敗したssl要求は表示されません。サーバー1と2では、ポート80の場合は200の束、ポート443の場合は200と304が混在しています。私はグーグル検索でいくらかのデューデリジェンスをしました、しかし何も光を当てていません。実際、私がやったことがわかることとは正反対に、うまくいくはずです。これを解決するためのアドバイスをいただければ幸いです。
回答: iisの集中証明書ストアに関するほとんどの問題を解決するためのいくつかの手順を共有したいと思いました。一元化された証明書ストア(ccs)は、ssl証明書要求をccsにファネルするために使用する偽の証明書バインディングを作成します。このバインディングが存在しない場合、または同じipアドレスに複数のバインディングがある場合、クライアントがssl対応のwebサイトに接続しようとすると、ブラウザーエラーが発生します。次の設定を検討してください。 ipアドレス172.16.0.41と集中証明書ストアが有効になっているiisサーバーには2つのドメインが含まれています。 www.adomain.comおよびwww.bdomain.com。 pfx証明書パッケージは、各ドメインのiis一元化された証明書ストアにインストールされます。通常、2つのエラーがあります。問題1ブラウザがwebサイトに接続すると、間違った証明書が共有されます。たとえば、初めてwww.adomain.comにアクセスすると正しい証明書が提供されますが、ブラウザがwww.bdomain.comにアクセスすると、www.adomain.comの証明書が返され、ブラウザは無効な証明書エラーのフラグを立てます。[〜#〜]ソリューション[〜#〜]この問題の理由は通常、複数のwebサイトが同じipアドレスにバインドされており、少なくとも1つのwebサイトが有効になっていないサーバー名の識別が必要であるためです。同じipとポートを共有するすべてのwebサイトでこの設定を有効にしないと、iisは提供する証明書を決定できないため、最初の証明書が勝ちますポリシー適用されるようです。これは、同じiisサーバーでホストされている他のwebサイトへの後続の要求が、間違った証明書を返すことを意味します。解決する手順 各webサイトがrequire server name identificationに設定されていることを確認してください。これを行うには、iis managerで各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になり、バインディングを削除する必要があります。 (null)ccsパススルーバインディングは削除しないでください。このバインディングが存在しない場合は、以下の問題2を参照してください。 iisをiisresetでリセットし、webサーバー上の各ドメインに接続します。正しい証明書を共有する必要があります。手順2を繰り返し、sslポートとwebサーバーipへの特定のip:portバインディングが存在しないことを確認してバインディングを確認することもできます。 問題2一元化された証明書ストアが有効になっていることを確認した後でも、証明書が表示され、すべてのwebサイトがそれを使用するようにバインドされています。ブラウザーがwebサイトに接続すると、page cannot be displayedまたはinvalid encryptionエラーがスローされます。目的のウェブサイトが表示されません。ie(edge)では、これは通常、ブラウザで適切な暗号化タイプが有効になっていることを確認するための提案として現れます。サーバーをiisresetまたは再起動しても、問題は解決しません。[〜#〜]ソリューション[〜#〜]これは、ccsパススルーバインディングの作成におけるバグのようです。 ccs機能が有効になっている場合は、webサーバー上に作成されないため、証明書の着信要求はサイレントにドロップされます。解決する手順 最初に、集中証明書ストアが有効になっていて、そのパス内のすべての証明書を確認できることを確認します。これを行うには、iismanagerをチェックして、サーバーノード->集中証明書([管理]セクションの下)-> [機能設定の編集]を選択し、構成されて有効になっていることを確認します。 共通の証明書を使用するすべてのwebサイトがccsにバインドされていることを確認してください。これを行うには、iis managerで各webサイトをクリックし、[バインディング...]-> [httpsバインディングを選択]-> [編集]-> [require server name identificationを確認]を選択し、use centralized certificate storeもチェックされていることを確認します。 。 ccsバインディングが作成されていることを確認してください。 netsh http show sslcertを実行します。結果が空であるか、(null)パススルー証明書が存在しない場合(ccsバインディングの外観については、問題1の手順2を参照)、ccsバインディングは有効になっていません。 ssl certificate bindings: ------------------------- iis managerで、ccsを使用するwebサイトを1つ選択し、[バインド...]-> [httpsバインドを選択]-> [編集を選択]->およびuncheckuse centralized certificate storeおよびuncheckrequire 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 / それがお役に立てば幸いです。