最も成功したデフォルトの動作ではないため、誤動作を何年もマスクできます

正しく選択されたデフォルトのおかげで、すべてが自動的に動作し、何も設定する必要がない場合に非常に便利です。 この話は、選択されたデフォルトは常に実行可能でなければならないということです。さもないと、何年も問題なく動作した後に予期しない失敗のリスクがあります。



Microsoft Azure WebロールでのWindows Serverの文書化されていない動作に直面しましたが、これは長年にわたってCloud OCR SDKサービスの誤った構成を隠していたため、非常に良い瞬間に個々のユーザーに深刻な問題をもたらしました。



2016年2月-この時点でサービスが数年間稼働していた-一部のユーザーは、安全な接続を確立しようとしたときに問題を報告し始めました。 これらのユーザーのプログラムは、サービス証明書に関するいくつかの問題に関するメッセージを発行しました。 「以前は機能していましたが、現在は破損している」ため、ユーザーが最初に決定したのは、証明書の有効期限が切れており、 ^TMに非常に不満があることです。 実際、数か月後に失効しました。



問題を再現する試みは、ほとんどの場合失敗しました-ユーザーが指定した正確なプラットフォーム上でさえ。 サードパーティの検証ツール（ 1および2 ）を使用して、中間証明書の誤ったインストールに関するメッセージを取得することができました。



この時点から、技術的な詳細が必要になります。 証明書は特別な組織、つまり誰もが信頼する認証センターによって発行されます。 発行された各証明書はデジタル署名され、クライアントプログラムが検証します。



各証明機関には、クライアントプログラムが確実に信頼する1つ以上の自己署名ルート証明書があります。 証明書センターによって発行された証明書は、原則として、このセンターのルート証明書によって署名できますが、このため、新しい証明書が発行されるたびに証明書の秘密キーが必要になるため、ルート証明書の秘密キーが漏洩するリスクが高まります。 確かに何百万ものコンピューティングシステムによって信頼されているルート証明書の秘密キーの漏洩は問題です。



したがって、認証センターは中間証明書を使用します。 中間証明書はルート証明書によって1回署名され、発行されたすべての証明書はすでに中間証明書によって署名されています。 チェーン内にいくつかの中間証明書があるオプションが可能です。 デジタル署名を確認するには、クライアントプログラムはチェーン内のすべての証明書を必要とします-プログラムはルート証明書を保存し、無条件に信頼します。その助けにより、中間証明書の署名のみを検証でき、サービス証明書の署名を検証するにはこの中間証明書が確実に必要です。



署名の検証には、クライアントプログラムに必要なのは秘密キーなしの証明書のみです。秘密キーは、認証センター（ルートおよび中間証明書）およびサービス所有者（サービス証明書の秘密キー）によって秘密にされます。



クライアントプログラムには、中間証明書を取得する方法がいくつかあります。



最初のオプションは、プログラムが実行されているマシンに中間証明書を以前にインストールできることです。 これは不便です;ユーザーが中間証明書をインストールすることを期待する価値はありません。



2番目のオプション-プログラムは、認証センターのサーバーからネットワーク経由でそれらをダウンロードしようとすることができます。 これは便利ですが、すべてのSSLクライアント実装でサポートされているわけではありません。 これも信頼性がありません-接続を確立するときに、認証センターのサーバーへのアクセスも必要です。 この方法では、最初の接続が遅くなります。



3番目の方法は、最も信頼性が高く普遍的な方法です。 サーバー自体は、安全な接続の確立の開始時に証明書を送信すると同時に、すべての中間証明書をクライアントに送信します。 およそ：「私の証明書は、これらの証明書によって署名されています。最後の証明書は、あなたにとって最も価値のあるクライアントプログラムであるルートによって署名されます。信頼できるものとしてマークされます。すべての署名を確認し、確認して接続を確立してください」



サードパーティの検証ツールは、接続を確立するときにサービスが中間証明書を提供することを示す場合がありますが、そうでない場合もあります。 確認後、利用可能な例に従って、サービスを展開するプロセスを誤って構成したことが判明しました。



これは、Webロールを持つ典型的なサービス定義のようです：

<?xml version="1.0" encoding="utf-8"?> <ServiceDefinition name="CoolCloudService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2014-06.2.4" > <WebRole name="CoolRole"> <Sites> <Site name="Web" > <Bindings> <Binding name="HttpIn" endpointName="HttpIn" /> <Binding name="HttpsIn" endpointName="HttpsIn" /> </Bindings> </Site> </Sites> <Endpoints> <InputEndpoint name="HttpIn" protocol="http" port="80" /> <InputEndpoint name="HttpsIn" protocol="https" port="443" certificate="ProductionCert"/> </Endpoints> <Certificates> <!--!!!   !!!--> <Certificate name="ProductionCert" storeLocation="LocalMachine" storeName="My"/> </Certificates> </WebRole> </ServiceDefinition>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通常、 Certificates要素内ではサービス証明書のみが指定されます。 これは間違っています。 チェーン内のすべての中間証明書を同じ場所に示すのは正しいことです。 エンドポイントのセクションに記載されていなくても構いません。



そうです：

  <Certificates> <!-- ! --> <Certificate name="IntermediateForProductionCert" storeLocation="LocalMachine" storeName="CA"/> <!--      ,   --> <Certificate name="ProductionCert" storeLocation="LocalMachine" storeName="My"/> </Certificates>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべての中間証明書を列挙すると、インスタンスの初期化中に、ロールの各インスタンスのリポジトリにインストールされます。 その後、IISは、セキュリティで保護された接続を確立するときに、クライアントプログラムに中間証明書を送信できるようになります。



勝つ？ いいえ、それほど速くありません。



設定を修正して変更を送信した後、クローズタイムゾーンに無事に到着したユーザーに連絡しましたが、彼は答えました。



次の課題は、オペレーティングシステムのイメージで、その上でサービスが機能しました。 証明書の検証に問題が発生する少し前に、サービスは次の一連の更新で次の新しいイメージに転送されました。 Microsoftが発生する可能性のある問題について事前に報告するというまれな例外を除き、何も破壊しない「ニュートラル」更新のみが選択されます。 今回は、リストに2つの更新があり、その説明には証明書のハッシュと安全な接続の更新が記載されていました。



サービスは一時的に前のイメージに転送されました...そして問題は解決しました。



勝つ？ いいえ、勝ち目もありません。



まず、2つの変更のうちどちらが問題を解決したかは明確ではありませんでした。 以前のイメージに永遠にとどまることはできません。2、3か月後、Azureインフラストラクチャによってサービスが新しいイメージに強制され、問題が再発する可能性があります。 サービスをオペレーティングシステムの新しいイメージに転送し、ユーザーをチェックするオプションは、どういうわけか適切ではありませんでした。



第二に、この時点で問題が再発した理由は明らかではなく、それ以前のものではありませんでした。設定は変更されませんでしたが、「以前は機能し、その後壊れました」。

1つの証明書のみを示す誤った「前」設定のテストサービスでは、すべてのサードパーティの診断ツールが証明書が正しくインストールされ、クライアントプログラムからの要求に応じてサービスによって返されることを示しました。 テストサービスに追加されたインストール済み証明書を表示するコードは、リポジトリに中間証明書がないことを示していました。



リポジトリに証明書はありませんが、サービスはユーザーに証明書を提供します。 どうやらテレポーテーション。 いつものこと。



ユーザーメッセージもありました。 その中には、次のような説明がありました。「ここにPHPコードがあります。ループで実行します。一度正常に動作し、問題が悪化するとクラッシュします。失敗。」



また、証明書の有効期間を定期的にチェックし、 念のためにX509Chain.Build（）メソッドを使用して信頼チェーンをチェックするコードもあります。 以前は正常に機能していましたが、ユーザーが問題に遭遇した期間に、この方法がうまくいかず、次の一連のメッセージが表示されることがありました。

• PartialChain証明書チェーンを信頼できるルート機関に構築できませんでした。
• RevocationStatusUnknown失効関数は、証明書の失効を確認できませんでした。
• OfflineRevocation失効サーバーがオフラインであったため、失効関数は失効を確認できませんでした。

疑わしいことに、認証センターのサーバーにアクセスすることは不可能です。



しかし、IISがクライアントインスタンスに証明書を渡すことができるように、役割インスタンス自体が認証センターから不足している中間証明書を受け取り、それらを慎重に隠すことができるとしたらどうでしょうか。 実質的な証拠なしにこのような仮定を立てることは非常に軽率であり、Windowsが子猫を食べることと同じ成功を収めることができます 。



確認する必要がありました。 ロールroleのインスタンスのhostsファイルを編集して、ファイアウォールまたはファイル名解決を構成しようとして失敗しました。 これは予想されていました-これらのアクションを初めて実行できるようになるまで、ロールインスタンスは数分間実行され、その後は遅すぎる可能性があります-証明書がダウンロードされ、慎重に非表示になります。



したがって、ロールインスタンスが認証センターインフラストラクチャにアクセスすることを完全に排除する方法が必要でした。 便利なことに、Azureはこれを非常に簡単にします。



「ネットワークセキュリティグループ」（ネットワークセキュリティグループ）でサブネット（サブネット）を作成する十分な「仮想ネットワーク」（仮想ネットワーク）があり、サービスがこの仮想ネットワークに公開されるように、サービス設定にNetworkConfiguration要素を追加しました。 簡単でした。



「ネットワークセキュリティグループ」では、ネットワークアクセス制限が設定されています。 彼らは、認証センターインフラストラクチャが配置されているアドレス範囲への発信要求を禁止するルールを追加しました。



その後、テストサービスを公開すると、オペレーティングシステムイメージの鮮度に関係なく、ユーザーが述べた問題の再現が開始されます。 IISは中間証明書の発行を停止します。 「セキュリティグループ」が要求を制限しないようにルールを変更し、サービスを再度公開すると、問題は発生しなくなります。



このブラックボックスを徹底的にチェックした後、ロールインスタンスの初期初期化中、再起動時、オペレーティングシステムイメージから再初期化されたとき、およびサービスパッケージが再公開されたときに、中間証明書を取得しようとすることがわかりました。 IISでアプリケーションプールを再起動しても、不足している証明書を取得することはありません。 したがって、中間証明書を取得しようとする試みは、サイトがIISに展開された瞬間に関連付けられています。おそらく、サイト証明書がインストールされたときに発生します。 この記事 （証明書失効の仕組み）では、CryptoAPI証明書の特定のディスクキャッシュについて説明しています。 CryptoAPIはWindows Serverの一部です。



通常の状況では、不足している証明書を取得する試みは成功し、誤ったサービス構成はマスクされ、ロールインスタンスログにこれに関する警告はありません。 誤って不足している証明書を取得しようとして失敗した場合、ロールの特定のインスタンスが最適な形式ではなく起動され、ログにもこれに関するメッセージはありませんが、一部のクライアントプログラムはそれとの安全な接続を確立できません。



ロールインスタンス間で着信要求を分散するには、スケーリングとロードバランサーを追加する必要があります。 異なるロールインスタンスを異なるタイミングで起動できるため、認証センターインフラストラクチャの可用性が異なるため、結果として、一部のインスタンスは他のインスタンスよりも良好な状態になります。 ロードバランサーは、その裁量で、異なるインスタンスに異なる要求を送信するため、異なる要求が応答の異なる証明書セットにつながる可能性があります。 非アクティブなユーザーは、「動作している、動作していない」、非常にアクティブであることを確認します。リクエストの一部は正常に完了し、残りは失敗します。



パズルが開発されました。 今勝ちます。



これは間違いなく最良のデフォルト動作ではありません。



これで、証明書を確認するときに、チェーン内のすべての証明書がロールインスタンスの対応するリポジトリにあることを確認するコードが作成されました。 新しいプールリクエストの力のおかげで、Microsoft Azureドキュメントの例はまもなく修正されます。



また、Webロールを持つサービスがある場合、それはまだ正しく構成されていない可能性があります。



ドミトリー・メッシェリャコフ、

開発者製品部門