locked
時々、IISでクライアント証明書の失効が確認出来ない事がある RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票
    お世話になります。
    WEB(IIS)サーバー、CA(AD CS)サーバーをそれぞれ2008R2(仮想マシン)で構築し、WEBサーバーへはクライアント証明書必須でアクセスを許可しています。
    普段はアクセス出来ていますが、時々ステータス403が返却される問題が発生しています。
    失敗した要求トレース(FailedReqLogFiles)によると原因は「失効サーバーがオフラインのため、失効の関数は失効を確認できませんでした。 (0x80092013)」。
    403が返却される問題の事象は１時間程続いた後、アクセス出来るように復帰します。

    現在、類似事象を検証するために、
    ・CRL公開期間「1 時間」
    ・(Delta CRL)公開期間「30 分」　に設定しています。
    また、
    ・WEBサーバー、CAサーバーは、どちらもドメインでなくワークグループ
    ・WEBサーバー、クライアントにCA証明書をルート証明機関、中間証明機関に登録済み
    ・どちらもWindows UPDATEによるパッチ(重要な更新)適用済み。　　です。

    ログ等を解析したところ、
    ・WEBサーバーのイベントログ(ソース：CAPI2)に、
    　普段はほぼ１時間毎にCRLとdelta CRLを取得に行くイベントID：53「オブジェクトをネットワークから取得」がそれぞれ出力されていますが、
    　問題の事象が発生する直前のイベントID：53は、delta CRLしか存在せず、CRLに対するイベントが出力されていません。
    ・ちなみに「System32\config\systemprofile\AppData\LocalLow\Microsoft\X509Objects」内の該当時間の更新日時の「.crl」ファイルはdelta CRLしかありません。
    ・CAサーバーのIISアクセスログにも、その時間はdelta CRLのアクセスしか記録されていません。
    ・CAサーバーのIISアクセスログ(関連ログのみ抜粋、XXX-CAは偽名にしています)：
    2014-04-16 10:51:34 fe80::f99a:eb13:7c7b:1de4%10 GET /CertEnroll/XXX-CA(1).crl - 80 - fe80::7993:d27a:af9f:170%10 Microsoft-CryptoAPI/6.1 200 0 0 218
    2014-04-16 10:51:39 fe80::f99a:eb13:7c7b:1de4%10 GET /CertEnroll/XXX-CA(1)+.crl - 80 - fe80::7993:d27a:af9f:170%10 Microsoft-CryptoAPI/6.1 200 0 0 202
    2014-04-16 11:52:05 fe80::f99a:eb13:7c7b:1de4%10 GET /CertEnroll/XXX-CA(1)+.crl - 80 - fe80::7993:d27a:af9f:170%10 Microsoft-CryptoAPI/6.1 200 0 0 265
    2014-04-16 12:52:22 fe80::f99a:eb13:7c7b:1de4%10 GET /CertEnroll/XXX-CA(1).crl - 80 - fe80::7993:d27a:af9f:170%10 Microsoft-CryptoAPI/6.1 200 0 0 218
    2014-04-16 12:52:28 fe80::f99a:eb13:7c7b:1de4%10 GET /CertEnroll/XXX-CA(1)+.crl - 80 - fe80::7993:d27a:af9f:170%10 Microsoft-CryptoAPI/6.1 200 0 0 202

    ・403 Forbidden(失効サーバーがオフライン．．．)の原因は、このCRLを取得しに行かない事が原因と思われますが、取得しに行かない原因は何でしょうか？
    ・もしくは、自動での復帰に１時間掛かるのをOS再起動以外に復旧させる方法はないでしょうか？
    ※本来は客先環境(CRL(delta含む)公開期間は初期設定)で、1週間程度経過すると同事象が発生する問題があり、本件はその検証環境での事象です。
    ※イベントログは膨大なため、掲載を省略しますが、フィルタ条件を教えて頂ければ掲載します。

    どうぞ、よろしくお願い申し上げます。
    2014年4月17日 6:09

回答

  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    状況からですが、公開期限切れ直前にアクセスが行われた際、「CRLの有効期限はまだ切れていない(公開期限より長めに設定されているため)」ので、キャッシュの更新を行わず、そのためCRLが期限切れ扱いになってしまっているのかもしれません。それが正しい動作なのかはわかりませんが。

    Webサーバ上のCRLキャッシュについて「きちんとコマンドで」削除を行っていただくのはどうでしょうか？(手動で強引に行うのではなく)。以下のコマンドでできるはずですが。

    certutil -urlcache CRL delete

    うえのコマンドを30分毎にタスク等で動作させて、問題が解消するようならやはりキャッシュがらみの問題なのでしょう。

    あとこの問題について、ざっと検索等で探してみましたが、既存の不具合と思われる情報はありませんでした。環境に依存している問題の可能性もありますので(こういうケースでは無償掲示板のサポートはほとんど役に立ちません)、こういった無償掲示板でムリに解決するのではなく、MS有償サポートのご利用を考えていただくほうが、結果的には間違いがありません。ご検討ください。

    • 回答の候補に設定 佐伯玲 2014年4月22日 2:03
    • 回答としてマーク 冨田貴士 2014年4月22日 3:12
    2014年4月21日 8:45
  • Question
    サインインして投票
    0
    サインインして投票
    KB2666300 の修正プログラムを適用する事で解決しました。

    Security問題ではないのでWindows Updateには含まれていないらしく、別途ダウンロードする必要があります。

    原因は、CRL確認の為のOCSPサーバーを立てていませんが、CAのプロパティでOCSP(Online Certificate Status Protocol)を有効にしていたため、WebサーバーがCAにOCSPのURLでアクセスした際エラーになってしまい、それ以降はCRLのURLへのアクセスもしなくなってしまうという不具合によるものでした。

    有償サポート窓口から連絡して、上記KBを教えてもらいました。
    ご協力頂いた方々に感謝いたします。
    • 回答としてマーク 冨田貴士 2014年5月12日 11:33
    2014年5月12日 11:31

すべての返信

  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    CAについてはあまり詳しくはないので、その点は含みおきください。

    状況からですが、以下の観点で調査を行ってみるのはどうでしょうか？

    1. WebサーバがCDPに「100%アクセス」できることを確認する
      該当のクライアント証明書～ルート証明書までのCDPについて、名前解決の問題でアクセスできなくなっていないか、念のため確認されるといいのではないでしょうか？すべてのCDPが100%名前解決できるよう、hostsファイルにCDPのサーバ名(FQDNだと思いますが)を記載することになります。IIS6でこの情報に触れている資料があります。
      http://support.microsoft.com/kb/294305/ja
    2. CRLのキャッシュが影響を与えているかどうかを確認する
      certutilでCRLキャッシュの場所は確認できるので、CRLキャッシュを削除してみて、状況が変わらないかどうか、これも念のため確認したほうがいいと思います。キャッシュ削除についてはしたの資料が役立つかもしれませんが、certutilコマンドラインヘルプで確認いただいたほうがいいように思います。
      http://blogs.technet.com/b/pki/archive/2007/09/13/how-to-refresh-the-crl-cache-on-windows-vista.aspx

    名前解決の点ですが、ドメイン環境で(サーバ上の)参照先優先DNSサーバアドレスと代替アドレスに異なるレベルのDNSサーバ(代替にはDCと無関係のDNSサーバを指定している等)を指定している場合、突然DC側の名前解決ができなくなることがあります。


    2014年4月18日 9:51
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンさん。返信ありがとうございます。
    今回の検証環境ではjmeterによる自動Webアクセスでログ採取しているので、問題発生時には上記１、２共に試していません。

    なお、お客様の本番環境(Windowsパッチは未適用)で類似問題発生時には上記１、２共に試しています。
    １．Webサーバー上のIEから当該クライアント証明書に記載されているURLからCRT、CRLL共にダウンロード可能でした。
    ・CRL配布ポイント：
    [1]CRL Distribution Point
         Distribution Point Name:
              Full Name:
                   URL=http://win-msprl0t325o/CertEnroll/XXX-CA.crl
    ・機関情報アクセス
    [1]Authority Info Access
         Access Method=オンライン証明書状態プロトコル (1.3.6.1.5.5.7.48.1)
         Alternative Name:
              URL=http://win-msprl0t325o/CertEnroll/WIN-MSPRL0T325O_XXX-CA.crt
    また、http://win-msprl0t325o/CertEnroll/XXX-CA+.crl　として、delta CRLもダウンロードできます。
    ※XXX-CAは名前を伏せています。

    ２．Webサーバーのコマンドラインから、当該クライアント証明書に対してcertutil -verify -urlfetchはCRLを確認出来る正常を出力しました。
    　また、certutil(-urlcache)によるキャッシュクリアではありませんが、AdministratorとシステムのCRLキャッシュは削除しましたが、
    　その後も403エラーは継続して発生し続けました。
    　・C:\Users\Administrator\AppData\LocalLow\Microsoft\CryptnetUrlCache
    　・及びC:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache
    　　の Content、MetaData 内のファイルを削除

    同事象はWebサーバーのOS再起動で一旦解決(403エラーが発生しなくなる)する事を確認していますが、
    OS再起動以外で、解決（復帰）させる方法はありませんでしょうか？
    ちなみにIISマネージャからのIIS再起動では解決しませんでした。

    2014年4月21日 5:53
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    状況からですが、公開期限切れ直前にアクセスが行われた際、「CRLの有効期限はまだ切れていない(公開期限より長めに設定されているため)」ので、キャッシュの更新を行わず、そのためCRLが期限切れ扱いになってしまっているのかもしれません。それが正しい動作なのかはわかりませんが。

    Webサーバ上のCRLキャッシュについて「きちんとコマンドで」削除を行っていただくのはどうでしょうか？(手動で強引に行うのではなく)。以下のコマンドでできるはずですが。

    certutil -urlcache CRL delete

    うえのコマンドを30分毎にタスク等で動作させて、問題が解消するようならやはりキャッシュがらみの問題なのでしょう。

    あとこの問題について、ざっと検索等で探してみましたが、既存の不具合と思われる情報はありませんでした。環境に依存している問題の可能性もありますので(こういうケースでは無償掲示板のサポートはほとんど役に立ちません)、こういった無償掲示板でムリに解決するのではなく、MS有償サポートのご利用を考えていただくほうが、結果的には間違いがありません。ご検討ください。

    • 回答の候補に設定 佐伯玲 2014年4月22日 2:03
    • 回答としてマーク 冨田貴士 2014年4月22日 3:12
    2014年4月21日 8:45
  • Question
    サインインして投票
    0
    サインインして投票
    チャブーンさんのアドバイスによる回避は確認出来ていませんが
    本ＱＡに対する回答としてマークさせて頂きました。
    ありがとうございました。
    2014年4月22日 3:24
  • Question
    サインインして投票
    0
    サインインして投票
    KB2666300 の修正プログラムを適用する事で解決しました。

    Security問題ではないのでWindows Updateには含まれていないらしく、別途ダウンロードする必要があります。

    原因は、CRL確認の為のOCSPサーバーを立てていませんが、CAのプロパティでOCSP(Online Certificate Status Protocol)を有効にしていたため、WebサーバーがCAにOCSPのURLでアクセスした際エラーになってしまい、それ以降はCRLのURLへのアクセスもしなくなってしまうという不具合によるものでした。

    有償サポート窓口から連絡して、上記KBを教えてもらいました。
    ご協力頂いた方々に感謝いたします。
    • 回答としてマーク 冨田貴士 2014年5月12日 11:33
    2014年5月12日 11:31
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    フィードバックありがとうございます。

    デフォルトでインストールしていないなら、OCSP設定は既定では有効になりませんので、環境依存で発生するケースだというところで理解しました。

    こちらも勉強になりました。

    2014年5月13日 2:47