Windows、IE、およびOutlookにSSL / TLS証明書の状態キャッシュはありますか？
今日、3,000以上のOutlookクライアントが使用しているSSL証明書を変更しました。これを行う際に、私は証明書を、同じサブジェクト名、有効期限、その他すべてを備えた「古い」証明書に変更しました。拇印と1つのSAN=名前が変更されました。問題が報告されたら、変更を元に戻しました（1時間）。
これを実行すると、Outlookのいくつかの展開されたインスタンスがハングし、サポート能力で15年間Outlookを操作したにもかかわらず、プロファイルを復旧できず、再作成する必要があったようです。 （残りの20以上のプロファイルに対してこのプロセスを繰り返したくありません）
私は、SSLキャッシュがWindows、Outlook、またはIE依存関係に存在することを前提としています。
これは私に私の質問をもたらします：
IE SSL状態ボタンにどのSSLデータが存在しますか？これはWeb HTTPデータのキャッシュですか、それとも証明書データですか？
アプリケーションごとのSSLキャッシュまたはグローバルキャッシュ、あるいはその両方はありますか？ （例：schannelなど）
このキャッシュを編集または管理するにはどうすればよいですか？
IE（「SSL状態のクリア」を参照）のSSLエディタの画像を次に示します。
更新：
証明書が適切に形成されていても、Outlook構成の次のテキストボックスをオフにすると問題が修正されるようです
[SSL状態のクリア]ボタン ある SSLベースのサービスへの認証に使用される選択したクライアント証明書のSSLキャッシュを削除します。これは、クライアント証明書をより高速に動作させるために存在します（特定のサイトへの認証に使用した証明書を一部覚えておくことにより）。以前に表示されたSSL証明書はキャッシュしません。
Outlook + Exchangeは認証にクライアント証明書を使用できますが、一般的な構成ではありません。ほとんどのサイトでは、SSLを介したNTLMまたはKerberosを使用しています。
Outlook + IMAPはクライアント証明書を使用できませんが、私はかなり間違っているかもしれません。それらが使用される例については聞いたことがありません。
代わりに実行されている可能性があるのは、Windows SSL Validatorの問題です。
通常、SSL管理はプロセスごとに行われます。 SSLの実装DLLは、たとえば、SSLセッションを記憶し、省略されたハンドシェイクをネゴシエートできます（それはクライアントはサーバーに再接続し、以前の接続で確立した対称共有シークレットを再利用することに同意します。InternetExplorerにはいくつかのプロセスを生成する習慣がありますが、これらのプロセス全体でSSLセッション情報を共有するためのいくつかのトリックが含まれています。これすべてすべてのIEプロセスが閉じられても、消えます。
キャッシュに残っているのはCRLです。 Windowsが証明書（サーバー証明書など）を検証する場合、失効情報、つまり証明書自体にあるURLからダウンロードされたCRLまたはOCSP応答を取得しようとします。 WindowsはCRLをキャッシュしますが、再起動に抵抗するため、これはディスク上のキャッシュです。 Windowsは「ネガティブ」CRLもキャッシュします。つまり、指定されたURLからCRLを取得できません。 Windowsが特定のURLからCRLを取得できなかった場合、同じURLを8時間もの間再試行しないことがあり、ロックを解除するために再起動するだけでは不十分な場合があります。これはしばしば厄介です。
CRLキャッシュと同様に、Windowsは、証明書からのURL（Authority Information Access拡張子）を使用して、中間CA証明書をダウンロードする場合もあります。これらのCA証明書もキャッシュできますが、証明書ストアに表示されるとは限りません（certmgr.mscから確認できます）。
Windows CRLキャッシュの詳細については、 このブログ投稿 を参照してください。
Active Directoryのコンテキストで証明書ベースのクライアント認証を使用する場合、次の理由により、状況はさらに複雑になります。
- SSLクライアントは、SSLサーバー証明書を検証します。
- SSLサーバーはADサーバー証明書を検証します。
- ADサーバーはSSLクライアント証明書を検証します。
微妙に異なるルールを使用して、3つの検証を個別のマシンで実行すると、ADアカウントへの証明書のマッピングがさまざまな方法で失敗する可能性があります。