none
AD証明機関のCRL配布について RRS feed

  • 質問

  • 早速ですが、2つの双方向信頼を結んでいるドメインにおいて、VDIの接続を行う環境があります。

    但し、セキュリティの関係で、アクセス元の端末からアクセス先のVDIに対してTCP3389ポートのみ解放している状態です。

    双方のドメインコントローラ同士はフルアクセス設定を行っており、信頼関係については問題無い状態となっております。

    この環境でVDI側のドメインでAD証明機関を構築してマシンの証明書を発行しています。

    証明書の発行は行えているのですが、CRL(失効状態)の公開情報が上手く設定出来ません。

    希望としてはドメインコントローラは双方向でフルアクセスなので、相手のドメインコントローラにCRLを配布して、端末にはそこを参照させるようにしたいのですが、CRLの設定を行い、その後発行された証明書を確認するとCRLのところに公開先のアドレスは掲載されているのですが、参照されていないのか警告メッセージが表示されます。

    どの部分が不足しているのかご教示頂けますでしょうか。

    なお、AC証明機関はドメインコントローラにセットアップされています。

    2017年8月30日 5:59

回答

  • チャブーンです。

    この件ですが、本当に知りたかった詳細は

    • どういう目的で証明書を使うのか
    • なぜアクセス元端末を信頼先ドメインコントローラーにアクセスさせないのか(これはかなりイレギュラーな運用です)
    • 利用している証明機関はエンタープライズCAかスタンドアロンCAか
    • どんなプロトコルでCRLを公開する意図があるのか(つまりCRL公開のためになにをやったのか)

    といった話しです。本来クロスフォレストでの証明書展開では、互いの証明書関連のLDAP情報を読みあえるように設定したうえ、相手先にアクセスして確認するべきです。

    そうしないということでしたら、ひとまずしたの資料にある「Share Folder」で公開する形式を選択し、CDPにそれを記載するといいでしょう。この情報はコンピュータ対象ならコンピュータが、ユーザー対象ならコンピューターもユーザーも読めるようにする必要があると思います。

    https://blogs.technet.microsoft.com/nexthop/2012/12/17/updated-creating-a-certificate-revocation-list-distribution-point-for-your-internal-certification-authority/

    ただし、CRLが読める=更新が勝手にできるということではないので、CRLの更新方法は作り込むことになります。


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

    2017年8月31日 6:35
    モデレータ
  • やきです。

    >ルート証明書のプロパティには~
    ということは拡張プロパティに意図したCRLが入っていないものと思われます。
    配布しようとしている証明書と、クライアントにインポートされているルート証明書が一致しているかどうかの確認ですね。

    後、先の追記に記載した "
    certutil -verify -urlfetch <hogehoge>" をVDIから提示されたクライアント証明書(*)に実行すると、「証明書 CDP」のところにどこを参照しようとしているかがわかります。
    * : 
    RDP時に警告が出てくる画面で[証明書の表示] - [詳細] - [ファイルにコピー] でローカルに保存したもの

    ここの各項目で全部、FATが接続できないドメインのLDAPパスになっていたり、ネットワーク的に接続できないURLになっていたりするとCRLの確認ができません。

    2017年9月1日 2:15
  • チャブーン様 やき様

    この度はいろいろアドバイス頂きましてありがとうございました。

    AIA設定を見直すことで正常に証明書の失効機関の読み取りが出来るようになりました。

    失効機関ということでCDPの部分だけ見ながら嵌まってしまいました。

    ありがとうございました。

    2017年9月8日 4:43

すべての返信

  • チャブーンです。

    これは、率直に申し上げて、状況がよくわからないです。証明書を実際にインストールして使用するのはVDI端末、ということであれば、アクセス元端末(シンクライアント?)に証明書の状態は関係ないので、ポート制限の問題も当然関係ありません。

    VDI端末はCAのあるドメインコントローラと直接通信ができるようになっているのでしょうか?通常エンタープライズCAであれば「LDAP」経由でCRLを確認しますので、対象ドメインコントローラーのLDAPポートにアクセスできる必要があります。LDAPの中身を見るために、VDI端末がCAのあるドメインに参加していて、コンピューター認証できている必要があります。

    エンタープライズCAであれば、CRLの設定は全自動でLDAPに書き込まれますから、手動の設定は不要です。そういった環境ではない、ということなら、環境の詳細と、やったことの詳細(CRLの設定とはなにをどうしたのか)がわからないと、たぶん誰も答えられないでしょう。


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

    2017年8月30日 6:35
    モデレータ
  • チャブーン様

    ご回答ありがとうございます。

    また、状況がよくわからないという点も承知致しました。

    今回証明書の警告が出るのはリモートデスクトップ接続の際に仮想マシン自体の証明書を検証する際に発生する症状です。

    アクセス元(FAT側)をdom-a.local

    アクセス先(VDI側)をdom-b.local

    とした場合に、dom-aからdom-bのドメインコントローラは参照できないので、LDAPに公開されているCRLは参照出来ません。

    ただ、信頼関係を構築しているので、dom-aとdom-bのドメインコントローラ同士は通信がおこなえるので、dom-aのドメインコントローラ上にCRLファイルを配置して端末から参照させたい。

    という状況です。

    ルート証明書はドメインポリシーを使用して全端末に配布済みです。

    証明機関の設定で拡張機能のCRL配布ポイントに追加すればそこに出力されるようになるという技術文書は何件が確認して、確かにこちらの希望する場所にファイルが配置される事も確認しています。

    ただ、FAT端末がVDIのマシン証明書を検証するのに指定したCRL配布ポイントを参照していない。

    という状況です。

    よろしくお願いいたします。

    2017年8月31日 0:40
  • やきです。

    現象は、配布したルート証明書が、CRLを確認できないことを理由に有効と判定されていないという認識でよいでしょうか。

    基本的なことなのですが、FATからCRL配布ポイントへはアクセス可能なのでしょうか。
    つまり、FATに導入されている証明書の「CRL配布ポイント」属性にあるアドレスに接続し、ダウンロードできますでしょうか。

    追記:

    HTTPSならブラウザでダウンロードできるかどうか確認できますが、LDAPだと簡単に確認できませんね。

    [証明書の表示] - [詳細] - [ファイルにコピー] でローカルに保存し、
    certutil -verify -urlfetch <証明書ファイルのパス>
    でエラーメッセージの詳細が確認できます。

    2017年8月31日 4:58
  • チャブーンです。

    この件ですが、本当に知りたかった詳細は

    • どういう目的で証明書を使うのか
    • なぜアクセス元端末を信頼先ドメインコントローラーにアクセスさせないのか(これはかなりイレギュラーな運用です)
    • 利用している証明機関はエンタープライズCAかスタンドアロンCAか
    • どんなプロトコルでCRLを公開する意図があるのか(つまりCRL公開のためになにをやったのか)

    といった話しです。本来クロスフォレストでの証明書展開では、互いの証明書関連のLDAP情報を読みあえるように設定したうえ、相手先にアクセスして確認するべきです。

    そうしないということでしたら、ひとまずしたの資料にある「Share Folder」で公開する形式を選択し、CDPにそれを記載するといいでしょう。この情報はコンピュータ対象ならコンピュータが、ユーザー対象ならコンピューターもユーザーも読めるようにする必要があると思います。

    https://blogs.technet.microsoft.com/nexthop/2012/12/17/updated-creating-a-certificate-revocation-list-distribution-point-for-your-internal-certification-authority/

    ただし、CRLが読める=更新が勝手にできるということではないので、CRLの更新方法は作り込むことになります。


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

    2017年8月31日 6:35
    モデレータ
  • やき様 チャブーン様

    ご返答ありがとうございます。

    まず、やき様の件から、

    配布したルート証明書がCRLを確認出来ない。という件ですが、

    ルート証明書のプロパティには「CRL配布ポイント」というプロパティが存在していなかったので、ルート証明書はCRL配布ポイントをいろいろ変更した後に再度配布し直したりしていないのですが、配布しなおしてみます。

    FAT端末からCRL配布ポイントへのアクセスは可能なのかという部分ですが、

    共有フォルダーやHTTPで公開してみたりしていますが、クライアントからは正常にアクセス出来ています。

    チャブーン様のけんですが、

    証明書の利用目的・・・リモートデスクトップの接続先コンピュータから提示される証明書です。ワークグループとかの端末からドメインの端末やサーバーにRDPする時に表示される証明書です。

    FAT端末とVDI端末を通信させない理由・・・セキュリティポリシーによる理由としか申し上げられないのですが、VDI端末はインターネットにアクセスできるが、FAT端末はアクセス出来ません。FAT端末をインターネットの脅威から保護する為に、VDI端末を経由してインターネットアクセスを許容しています。なので、RDPのプロトコル以外の通信を許可していません。先にも申し上げましたが、双方のドメインコントローラ同士は通信可能です。

    証明機関の種類・・・エンタープライズCAです。

    CRLの公開に使用するプロトコル・・・FAT端末から確認できるならどんなプロトコルでも良いと思っていますが、Windows共有、HTTPのどちらかを検討しています。

    CRL配布ポイントを変更させたい為にこちらで実施してみた作業ですが、

    証明機関のMMCスナップインから証明機関サーバーのプロパティを開き、拡張機能タブのCRL配布ポイントのところに、Windows共有の場所やHTTPの場所を記載しています。

    その後、スナップインのサーバーを展開して、失効した証明書フォルダーを右クリックして、すべてのタスク→公開を実行すると指定した場所のCRLファイルが更新されます。(タイムスタンプが変わります)

    証明書のCRL配布ポイントの値も指定した値になっている事は確認できます。

    2017年9月1日 1:27
  • やきです。

    >ルート証明書のプロパティには~
    ということは拡張プロパティに意図したCRLが入っていないものと思われます。
    配布しようとしている証明書と、クライアントにインポートされているルート証明書が一致しているかどうかの確認ですね。

    後、先の追記に記載した "
    certutil -verify -urlfetch <hogehoge>" をVDIから提示されたクライアント証明書(*)に実行すると、「証明書 CDP」のところにどこを参照しようとしているかがわかります。
    * : 
    RDP時に警告が出てくる画面で[証明書の表示] - [詳細] - [ファイルにコピー] でローカルに保存したもの

    ここの各項目で全部、FATが接続できないドメインのLDAPパスになっていたり、ネットワーク的に接続できないURLになっていたりするとCRLの確認ができません。

    2017年9月1日 2:15
  • やき様

    ご回答ありがとうございます。

    certutilコマンド実行致しました。

    エラーの内容が確認できました!

    結論から言いますと、CDPは正常に確認できていましたが、AIAが正常に構成されていませんでした。

    Windowsファイル共有で配布しようと、

    file://~~

    という指定を行うと、実際の証明書には

    file:////~~

    とスラッシュが4本に増えてしまいます。その結果AIAの取得が出来ていないという状態でした、

    なぜかhttpの指定をしてもスラッシュの数は変わらないので、httpでは正常にいきます。

    理由はわかりませんが、失効状態のエラーということでCDPの設定だけ必死に見直しておりましたが、AIAの方がエラー構成でも失効状態のエラーになるということで勉強になりました。

    やき様の適切なアドバイスのおかげで解決に至りそうです。

    チャブーン様にも適切なアドバイスをいただけて助かりました。ありがとうございます。

    AIAを更新して問題無く失効状態の取得が出来ましたら再度ご報告致します。

    2017年9月3日 23:54
  • チャブーンです。

    もう解決されているかもしれませんが。

    Windowsファイル共有で配布しようと、
    file://~~
    という指定を行うと、実際の証明書には
    file:////~~
    とスラッシュが4本に増えてしまいます。その結果AIAの取得が出来ていないという状態でした

    ということですが、これは仕様上問題ないというか普通です。Fileプロトコルの仕様上、"file://"は既定のURI記述であり、これに"\\Server\share→//Server/share"が加わるので"file:////Server/share"という記述になります。AIAが読めないのは別の理由かと思います。


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

    2017年9月7日 2:09
    モデレータ
  • チャブーン様 やき様

    この度はいろいろアドバイス頂きましてありがとうございました。

    AIA設定を見直すことで正常に証明書の失効機関の読み取りが出来るようになりました。

    失効機関ということでCDPの部分だけ見ながら嵌まってしまいました。

    ありがとうございました。

    2017年9月8日 4:43