none
windows階層型CAの「CRL検証の挙動」について質問です RRS feed

  • 質問

  • お世話になっております。

    質問内容に至るまでの前提環境を以下に記載します。
    ・WORKGROUP スタンドアロンRootCA(親CA)
    ・ドメインメンバ エンタープライズ下位CA
    ・ドメインメンバ Client

    ・親CAにて、CRL更新タイミングを1時間に設定(DeltaCRLも同じく)
    ・親CAのCRLを、下位CAへ手動コピー
    ・親CAにて、CDPの拡張機能に、http://<エンタープライズ下位CA>/CRL/<親CA>.crlの情報を埋め込み
    ・Clientから、http://<エンタープライズ下位CA>/CRL/<親CA>.crlへアクセスし、CRLのダウンロードが可能な事を確認

    ・下位CAのmmcスナップインにて、「信頼されたルートCA」へ、親CAの証明機関の証明書をインポート
    ・下位CAのmmcスナップインにて、「中間証明機関」-「証明書失効リスト」へ、親CAのCRLをインポート
    ・親CAから、下位の証明機関の証明書を発行

    ・下位CAにて、発行された下位の証明機関の証明書をインストールし、下位CA起動
    ・下位CAにて、CRL更新タイミングを1時間に設定(DeltaCRLも同じく)
    ・Clientから、http://<エンタープライズ下位CA>/CRL/<エンタープライズ下位CA>.crlへアクセスし、CRLのダウンロードが可能な事を確認

    ・下位CAから、自身のIIS埋め込み用の証明書を発行
    ・IISに発行した証明書を埋め込み、バインド設定と、SSL通信のみアクセス可に設定
    ・Clientから、https://<エンタープライズ下位CA>/certsrvより、コンピュータ証明書発行

    一連の証明書の動作は正常に確認取れた状況です。

     ―エンタープライズ下位CAが乗っ取られた想定の検証―
     ・親CAから下位CAの証明機関の証明書を失効し、CRLを下位CAへ手動コピー
     ・下位CAにて、親CAからのCRLを、mmcスナップインで手動インポート

     ―想定していた動作―
     (前提条件として、失効後、CRLの更新タイミング1時間以上待ってCRLは更新されている)
     ①下位CAの証明機関のプロパティを参照すると、失効されている事が確認出来る
     ②mmcスナップインのストア内に埋め込まれている「下位CAから発行された各種証明書」の表示が以下の様な状態になる
        ○ 親CA
            L × 下位CA
               L ○ 下位CAから発行された証明書
     もしくは、
        ○ 親CA
            L × 下位CA
               L × 下位CAから発行された証明書

     ③クライアントから、https://<下位CA>/certsrv にアクセスした際に、証明書エラー
       (IEの発行元証明書の取り消しを確認する項目は、オンになっています)
     ④クライアントのmmcスナップインの個人ストア内に埋め込まれている、PC証明書の表示が④同様の挙動を示す

     ―現状結果―
     ①想定通り
     ②正常な証明書との表示になってしまう
     ③正常にアクセス出来て、証明書にも問題ないとの表示になってしまう
     ④正常な証明書との表示になってしまう

    ここで質問です。
     A.親CAのCRLの有効期間が終了しCRLが更新されたタイミングで、
      下位CAのストア内、およびクライアント共に不正な証明書と認識しないのでしょうか?

     B.あくまで下位CAが発行した証明書の為、下位CAで該当の証明書を失効しない限り、
      証明書の有効期間内は、正常な証明書と認識してしまうのでしょうか?
      (下位CAから失効したら、問題なく、不正な証明書と認識されました)

     C.「信頼されたルート証明機関」をグループポリシーから配備出来る様に、
      CRLをグループポリシーで配備出来ないのでしょうか?

     D.「B」の挙動が正しい場合、スタンドアロンRootCAの親CAから、下位CAを失効しても、
      迅速な対応は困難なのかな?と感じ、用途毎の下位CAを設けるとの階層構成の観点しか有効ではなく、
      セキュリティの観点での有効性が薄れるのではないか?と考えていますが、如何でしょうか?


    概念の話なのかも知れませんが、調べれば調べる程、想定していた挙動と離れていく為、
    博識の方よりアドバイスを頂ければと思い、質問させて頂きました。

    以上、宜しくお願い致します。

    2015年5月14日 8:53

回答

  • チャブーンです。

    WindowsではXPまでは証明書失効はCRLがデフォルトでしたが、Vista以降ではOCSPがデフォルトになりCRLは下位互換的な使われ方になっているようです。

    最近のWindowsでは、ローカルセキュリティポリシー(あるいはグループポリシー)でCRLを優先的に使用するよう、設定を変えられます。方法については、以下のページにある[証明書パス検証の設定]の[失効]タブに関する情報を確認してみてください。

    https://technet.microsoft.com/ja-jp/library/cc731638.aspx


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    • 回答としてマーク SASASA777 2015年5月18日 4:46
    2015年5月15日 2:21
    モデレータ
  • 当初のCRLから失効状態を確認する事とは、根本的には違いますが…

    運用解決が、少し無理やりですが、見つかりました。

    もし、下位CAが親CAから失効された場合、グループポリシーで下位CAの証明機関の証明書自体を、

    「信頼されていない証明書」へインポートしてあげれば…

    当然「下位CAが失効される前に発行した証明書」を使用してアクセスするサイトへクライアントからアクセスした際には、エラー表示となりました。

    何となくスッキリしませんが…

    そもそも親CAから失効されてしまっている下位CAなら、下位CAが使用していた証明書自体を、信頼されてない証明書に設定してしまえば、運用上もポリシーへの設定一発で済むので、良いのかな?と考えています。


    • 編集済み SASASA777 2015年5月15日 8:26
    • 回答としてマーク SASASA777 2015年5月18日 4:45
    2015年5月15日 8:17
  • チャブーンです。

    エンタープライズCAにおけるCRLですが、一番スマートな方法は「LDAP」に書き込むことです。

    各証明書のCDP配布のURIの「LDAP:」にパスが書いてあるはずですので、そのパスを頼りにDNを探して、そこのcertificateRevocationList属性にリストを書き込むことになります。

    [Active Directoryサイトとサービス]スナップインで"サービスノードの表示"をONにした状態で、[Services]-[Public Key Services]-[CDP]-[サーバ名]-[証明機関名]オブジェクトを探して、[属性エディター]タブでcertificateRevocationList属性を探すと、状況がわかるかもしれません。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    • 回答としてマーク SASASA777 2015年5月18日 4:45
    2015年5月15日 8:28
    モデレータ
  • 結果報告です。

    結果から言うと、ldapを設定したら、IEからCRLをちゃんと読み込む様になりました。

    以下、実施内容です。

     ※親CA - WORKGROUP スタンドアロンCA

     ※下位CA - ドメインメンバ エンタープライズCA

    -親CAのCDPの設定-

    ・httpとfileとldapをクライアントからも見えるパスを設定(今迄はhttpだけ設定)

     http://<下位CAのhostname>/<共有フォルダ>/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
     file://\\<下位CAのhostname>\<共有フォルダ>\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
     ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<下位CAのhostnameオブジェクト>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>

    ・CA証明書の書き換えで、親CAの証明機関の証明書を更新

    ・「証明機関の証明書」と「親CAのCRL」を下位CAの共有フォルダにコピー

    ・下位CAの新しい証明機関の証明書を発行

    -下位CAの設定-

    ・グループポリシーから「信頼されたルート証明機関」へ、親CAの更新された証明機関の証明書をインポート

    ・mmcスナップインから、「中間証明機関」-「証明書失効リスト」へ、親CAの更新されたCRLをインポート

    ・certutil -dsPublish "C:\<共有フォルダ>\<親CA名>.crl" <下位CAのhostnemeオブジェクト> で、ldapのオブジェクトへインポート

    ・親CAから発行された、下位CA用の新しい証明機関の証明書を証明機関よりインストール

    ・IIS用の証明書を下位CAで発行し、下位CAのIISへ埋め込む

    -親CAにて-

    ・下位CAの証明機関の証明書を失効

    ・CRL発行

    ・CRLを下位CAの共有フォルダへコピー

    -下位CAにて-

    ・mmcスナップインから、「中間証明機関」-「証明書失効リスト」へ、親CAの更新されたCRLをインポート

    ・certutil -dsPublish "C:\<共有フォルダ>\<親CA名>.crl" <下位CAのhostnemeオブジェクト> で、ldapのオブジェクトへインポート

    ・下位CAの証明機関のプロパティより、下位CAの証明書が失効しているのを確認

    CRLの更新時間を待つ (1時間に設定しているので、1時間以上待つ)

    -クライアント確認-

    ・ドメインメンバクライアント(win7)で、gpupdate /force でグループポリシーの更新

    ・IEからアクセスした結果、証明書正常の認識

    -下位CAにて-

    ・証明機関のサービスの再起動 (証明書が失効している為、起動はしてこない)

    -クライアント確認-

    ・ドメインメンバクライアント(win7)で、gpupdate /force でグループポリシーの更新

    ・IEからアクセスした結果、証明書エラー

    httpだけでCRLの設定した際には、下位CAを再起動しても、ちゃんとCRLを読み込んでくれていなく、証明書がいつまでも正常認識してしまっていたので、今回の動作が正常動作だとの結果でOKだと思われます。

    色々と、御助力頂き、有難う御座いました。

    本件、これにてクローズにしたいと思います。


    • 回答としてマーク SASASA777 2015年5月18日 4:45
    • 編集済み SASASA777 2015年5月18日 4:47
    2015年5月18日 4:45

すべての返信

  • チャブーンです。

    挙動に関して、CRLをチェックに行っていない気がします。IEについては、「サーバーの証明書失効を確認する」をONにした場合、挙動は変わりませんか?


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2015年5月14日 11:22
    モデレータ
  • チャブーン様

    お世話になっております。

    IEにて、「サーバーの証明書失効を確認する」をONにはなっています。

    その他、証明書系に関わる箇所?

    ・証明書が無効な場合でもソフトウェアの実行またはインストールを許可する OFF

    ・証明書のアドレスの不一致について警告する ON

    ・発行元証明書の取り消しを確認する ON

    に、なっております。

    補足情報としては、失効された下位CAサーバ自身からIEでhttps://<下位CA>/certsrvへアクセスすると不正な証明書エラーにはなります。

    しかし、それは、想定するに、下位CAには、親CAのCRLを手動でmmcから埋め込んで有り、その証明書が失効している事に気付いているからとの認識だと思われます。

    クライアントには、親CAのCRLは無く、信頼されたルートCAにグループポリシーで親CAの証明機関の証明書を配備している状況です。

    なので、親CAが下位CAを失効した事にクライアント(Win7)は気付いておらず、クライアントは、下位CAから発行された証明書(下位CAに埋め込まれているIISの証明書や、クライアントのPC証明書)のみを見て、ソレ等は失効されていないので正常だと判断し、この様な状況となっているのかな?と考えています。

    しかし、そもそも下位CAが失効されているので、ソレ等の証明書は無効になるとの挙動になるべきかな?とも考えています。

    もし、上記挙動が正常だとするなら、運用側にて何かしらの親CAのCRLをポリシーで配備する仕掛けが必要に思いますが、信頼された証明機関の証明書を配備する様なグループポリシーの項目のCRL版?みたいな物がなく、対処に困っています。

    一応、親CAのCRLは、クライアントからもhttpアクセスでダウンロード出来る場所に手動コピーしており、ダウンロードの挙動までは確認は取れています。(要はクライアントからも正常に見える所には置いてあり、証明書自体のCDP拡張機能にも含まれています)


    • 編集済み SASASA777 2015年5月15日 1:54
    2015年5月15日 1:17
  • チャブーンです。

    WindowsではXPまでは証明書失効はCRLがデフォルトでしたが、Vista以降ではOCSPがデフォルトになりCRLは下位互換的な使われ方になっているようです。

    最近のWindowsでは、ローカルセキュリティポリシー(あるいはグループポリシー)でCRLを優先的に使用するよう、設定を変えられます。方法については、以下のページにある[証明書パス検証の設定]の[失効]タブに関する情報を確認してみてください。

    https://technet.microsoft.com/ja-jp/library/cc731638.aspx


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    • 回答としてマーク SASASA777 2015年5月18日 4:46
    2015年5月15日 2:21
    モデレータ
  • チャブーン様

    有難う御座います。

    実はこのページは既に確認済みで、失効タブの設定も実施しております。

    今は、certutilコマンドからmmcの「中間証明機関」-「証明書失効リスト」にCRLをインポート出来る手段は無いか?

    確認しております。

    もし、有れば、そちらをログオンスクリプト等で動かして、クライアントに撒くしかないかな?と…

    親CAのCRLをバッチ処理でアクセス可能な場所にコピーし、

    ログオンスクリプトで、それをフォローする。。。

    なんて考えています。

    certutilでCRLをインポート出来れば良いのですが…

    2015年5月15日 4:47
  • certutil -addstore CA "\\<共有フォルダ>\CRL\<親CA>.crl"

    で、クライアントに強制的にCRLを撒く事は出来るのを確認したのですが…

    結局、クライアント側でローカルにCRLを持っている状態でも、

    下位CAから以前に発行された証明書を、下位CA自体を失効しても正常な証明書と認識してしまっていますね。。

    CRL自体を検証する動作をクライアントが放棄してる様子です。。

    もう少し色々と調べてみます…

    2015年5月15日 6:48
  • 当初のCRLから失効状態を確認する事とは、根本的には違いますが…

    運用解決が、少し無理やりですが、見つかりました。

    もし、下位CAが親CAから失効された場合、グループポリシーで下位CAの証明機関の証明書自体を、

    「信頼されていない証明書」へインポートしてあげれば…

    当然「下位CAが失効される前に発行した証明書」を使用してアクセスするサイトへクライアントからアクセスした際には、エラー表示となりました。

    何となくスッキリしませんが…

    そもそも親CAから失効されてしまっている下位CAなら、下位CAが使用していた証明書自体を、信頼されてない証明書に設定してしまえば、運用上もポリシーへの設定一発で済むので、良いのかな?と考えています。


    • 編集済み SASASA777 2015年5月15日 8:26
    • 回答としてマーク SASASA777 2015年5月18日 4:45
    2015年5月15日 8:17
  • チャブーンです。

    エンタープライズCAにおけるCRLですが、一番スマートな方法は「LDAP」に書き込むことです。

    各証明書のCDP配布のURIの「LDAP:」にパスが書いてあるはずですので、そのパスを頼りにDNを探して、そこのcertificateRevocationList属性にリストを書き込むことになります。

    [Active Directoryサイトとサービス]スナップインで"サービスノードの表示"をONにした状態で、[Services]-[Public Key Services]-[CDP]-[サーバ名]-[証明機関名]オブジェクトを探して、[属性エディター]タブでcertificateRevocationList属性を探すと、状況がわかるかもしれません。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    • 回答としてマーク SASASA777 2015年5月18日 4:45
    2015年5月15日 8:28
    モデレータ
  • チャブーン様

    親切に有難う御座います。

    確認してみます。

    結果は、来週になってしまうかと思われますが、また、状況を記載します。


    • 編集済み SASASA777 2015年5月18日 4:18
    2015年5月15日 8:34
  • 結果報告です。

    結果から言うと、ldapを設定したら、IEからCRLをちゃんと読み込む様になりました。

    以下、実施内容です。

     ※親CA - WORKGROUP スタンドアロンCA

     ※下位CA - ドメインメンバ エンタープライズCA

    -親CAのCDPの設定-

    ・httpとfileとldapをクライアントからも見えるパスを設定(今迄はhttpだけ設定)

     http://<下位CAのhostname>/<共有フォルダ>/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
     file://\\<下位CAのhostname>\<共有フォルダ>\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
     ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<下位CAのhostnameオブジェクト>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>

    ・CA証明書の書き換えで、親CAの証明機関の証明書を更新

    ・「証明機関の証明書」と「親CAのCRL」を下位CAの共有フォルダにコピー

    ・下位CAの新しい証明機関の証明書を発行

    -下位CAの設定-

    ・グループポリシーから「信頼されたルート証明機関」へ、親CAの更新された証明機関の証明書をインポート

    ・mmcスナップインから、「中間証明機関」-「証明書失効リスト」へ、親CAの更新されたCRLをインポート

    ・certutil -dsPublish "C:\<共有フォルダ>\<親CA名>.crl" <下位CAのhostnemeオブジェクト> で、ldapのオブジェクトへインポート

    ・親CAから発行された、下位CA用の新しい証明機関の証明書を証明機関よりインストール

    ・IIS用の証明書を下位CAで発行し、下位CAのIISへ埋め込む

    -親CAにて-

    ・下位CAの証明機関の証明書を失効

    ・CRL発行

    ・CRLを下位CAの共有フォルダへコピー

    -下位CAにて-

    ・mmcスナップインから、「中間証明機関」-「証明書失効リスト」へ、親CAの更新されたCRLをインポート

    ・certutil -dsPublish "C:\<共有フォルダ>\<親CA名>.crl" <下位CAのhostnemeオブジェクト> で、ldapのオブジェクトへインポート

    ・下位CAの証明機関のプロパティより、下位CAの証明書が失効しているのを確認

    CRLの更新時間を待つ (1時間に設定しているので、1時間以上待つ)

    -クライアント確認-

    ・ドメインメンバクライアント(win7)で、gpupdate /force でグループポリシーの更新

    ・IEからアクセスした結果、証明書正常の認識

    -下位CAにて-

    ・証明機関のサービスの再起動 (証明書が失効している為、起動はしてこない)

    -クライアント確認-

    ・ドメインメンバクライアント(win7)で、gpupdate /force でグループポリシーの更新

    ・IEからアクセスした結果、証明書エラー

    httpだけでCRLの設定した際には、下位CAを再起動しても、ちゃんとCRLを読み込んでくれていなく、証明書がいつまでも正常認識してしまっていたので、今回の動作が正常動作だとの結果でOKだと思われます。

    色々と、御助力頂き、有難う御座いました。

    本件、これにてクローズにしたいと思います。


    • 回答としてマーク SASASA777 2015年5月18日 4:45
    • 編集済み SASASA777 2015年5月18日 4:47
    2015年5月18日 4:45