企業への証明機関のインストール。 パート2

エンタープライズ証明機関に関する一連の記事を続けます。 今日は、公開キーダイアグラムの作成、証明機関の名前の計画、証明書失効リストの計画、およびその他のポイントについて説明します。 今すぐ参加しよう！

シリーズの最初の部分



シリーズの第3部

はじめに

用語集

このシリーズでは、次の略語と略語が使用されます。

• PKI （ 公開鍵インフラストラクチャ ）-秘密鍵と公開鍵に基づく暗号化タスクをサポートするために一緒に使用される、公開鍵インフラストラクチャ、一連のツール（技術、材料、人間など）、分散サービスおよびコンポーネント。 略語PKIは一般的ではないため、以下では、より馴染みのある英語の略語PKIが使用されます。
• X.509は、公開鍵インフラストラクチャおよび特権管理インフラストラクチャのITU-T標準です。
• CA （ 認証局 ）-デジタル証明書を発行するサービス。 証明書は、公開鍵が所有者に属していることを確認する電子文書です。
• CRL （ 証明書失効リスト ）-証明書失効リスト。 CAによって発行され、外部の理由により有効性が終了した失効した証明書のリストを含む署名付き電子文書。 失効した証明書ごとに、シリアル番号、失効の日付と時刻、および失効の理由（オプション）が示されます。 アプリケーションは、CRLを使用して、提示された証明書が有効であり、発行者によって取り消されていないことを確認できます。アプリケーションは、CRLを使用して、提示された証明書が有効であり、発行者によって取り消されていないことを確認できます。
• SSL （ Secure Sockets Layer ）またはTLS （ Transport Layer Security ）は、オープンネットワークを介したクライアントとサーバー間のデータ転送のセキュリティを保証する技術です。
• HTTPS （ HTTP / Secure ）-セキュアHTTPは、SSLを使用する特殊なケースです。
• インターネットPKIは、オープンデータ送信チャネル上のX.509標準に基づいてデータ送信を保護するための単一の（統一された）メカニズムを提供する一連の標準、合意、手順、および実践です。
• CPS （ Certificate Practice Statement ）は、公開鍵インフラストラクチャとデジタル証明書を管理するための手順を説明する文書です。

一般的な計画の問題

技術的なソリューションを実装するには、慎重な計画が必要です。 PKI実装も例外ではありません。 さらに、特定のケースで初期計画のエラーを比較的迅速かつ簡単に修正できる場合、PKIでは間違いなくそうではありません。 すでに述べたように、PKIサービスは、作業中に最小限の（または重要ではない）変更を行うだけで長年機能するように設計されています。



たとえば、CA証明書の有効期間は約10〜20年です。 このような長い寿命の理由の1つは、これらの証明書の再発行には多少時間がかかる操作であり、多数の顧客の変更が必要になる可能性があることです。 これは、アクセスできないクライアントでも変更が必要になるという事実によって悪化します。 もう1つのポイントは、PKIアーキテクチャに変更を加える場合、発行された証明書の有効期間中は現在の構成を維持する必要があるということです。 つまり、新しい構成は新しい証明書に対して機能しますが、それと並行して、既に発行された証明書が正しく機能するように以前の構成を維持する必要があります。 これにより、PKIを健全な状態に維持することが難しくなります。



これらの点を考慮すると、PKI計画には最も深刻な方法でアプローチする必要があります。 そして、PKIがデジタルセキュリティを長期間にわたって確実に機能させることに成功するのは初めてです。



多段階計画プロセスは、選択したモデルの論理図に基づいています。 各段階で、ダイアグラムの要素が拡張（詳細）され、そのために接続、タスク、および要件が形式化されます。 必要に応じて、完全に形式化されたシステムが得られるまで詳細化が続けられます。 この記事では、この計画アプローチの例を示します。

PKIチャート

先ほど言ったように、すべては選択したモデルの論理図から始まります。 論理図にはすべてのPKIコンポーネントが表示されるため、物理トポロジにシフトする必要があります。 2レベルのPKIモデルを適用する場合、そのような図は次の形式をとります。







この図は、次のコンポーネントとその論理接続を示しています。

• ルートCA —下位CAにのみ証明書を発行し、その証明書と失効リストを失効サーバーに公開します。
• 下位（中間）CA-エンドユーザーに証明書を発行し、その証明書と失効リストを失効サーバーに公開します。 同時に、失効サーバーからルートCA失効リストをダウンロードします。
• 失効サーバー -CA証明書とその失効リストのリポジトリであり、任意のクライアントがダウンロードできます。
• クライアント接続 -下位CAから証明書を受け取り、失効サーバーから失効リストをダウンロードします。

物理トポロジはわずかに異なり、次の形式になります。







物理トポロジは、クライアントがどこでも証明書を検証できるように、ネットワークの内外のすべてのクライアントが失効サーバーにアクセスできることを明示的に強調しています。

CA名の計画

CA名は、特定のCAの[ Subject



フィールドに表示される名前です。 証明書サービスのホスト名と混同しないでください。 CAのフルネームは、名前自体（CN属性または共通名）とX.500形式のオプションのサフィックスの2つのコンポーネントで構成されます。 デフォルトでは、ADCSは次の形式で名前を割り当てます。



スタンドアロンCAの場合：< ComputerName



> CA







エンタープライズCAの場合：< DomainShortName



>-< ComputerName



> CA,



< X500DomainSuffix



>



良いですか、それとも悪いですか？ 技術的には、任意の名前を選択できますが、機能的には何にも影響しません。 CAの名前は何らかの形でPKIの名刺であり、機能に直接関係していないが十分なレベルの情報と公開性を提供する詳細に対する態度を反映していると考えられています。 したがって、証明書のフルネームを選択するときは、いくつかの推奨事項に従う必要があります。

• 名前は、組織の名前（省略されている場合もあります）および階層内の特定のCAの役割（属性CN、共通名）を反映する必要があります。
• 接尾辞は、OU（組織単位）属性での管理を担当する部門または単位の名前を反映する必要があります。
• 組織のフルネームを複製します（属性O、組織）。
• CAの法的な場所。 これを行うには、属性L（地域）およびC（国）を使用するだけで十分です。 原則として、これは組織が法的に登録されている都市と国の名前です。 必要に応じて、S（州）属性を使用して州/地域を指定できます。

ラトビアのリガにあるContoso Pharmaceuticals Ltd.という会社のルートCAの名前を選択し、管理が情報技術部門によって提供されているとします。 この場合、CAの名前は次のようになります。

 CN=Contoso Pharm Root Certification Authority, OU=Division Of IT (DoIT), O=Contoso Pharmaceuticals Ltd., L=Riga, C=LV
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Country属性は2文字の国インデックスのみをサポートすることに注意してください。 たとえば、LV、GB、RU、USなど。 追加の例として、VeriSign / Symantec、DigiCertなどの商用プロバイダーのCA証明書を参照できます。 下位CAの場合、この名前は似ていますが、名前のRootという語がSubordinateまたはIssuingに置き換えられる点が異なります。 ポリシーCAが明確に割り当てられている3レベルの階層の場合、ルートという語はポリシーに置き換えられます。 上で述べたように、他のルールが会社に適用される場合があり、それらをCAの名前で実装できますが、これは機能に影響しません。 その際、以下を避けてください：

• CN属性の名前が長すぎる（最大50文字）。 CN属性が51文字より長い場合、名前の最後に破棄された名前のフラグメントのハッシュをドッキングすることにより短縮されます。 これは「衛生」プロセスと呼ばれ、プロトコル[ MS-WCCE ]の3.1.1.4.1.1で説明されています。 つまり 名前が長すぎると、単語が途中で途切れて見た目が悪くなることがあります。
• ラテンアルファベットの一部ではない文字、つまり クリリツァまたは弁証法の文字（ā、ž、Ü、ẞなど）はありません。 ADCSは、CN属性および制限された文字セットのシングルバイトエンコーディングのみをサポートします。 サポートされていない文字は別のエンコードに変換され、読み取り不能になります。 禁止文字の完全なリストは、[ MS-WCCE ]プロトコルの§3.1.1.4.1.1.2で提供されています。 「最高は善の敵である」という原則がここで機能するので、名前は簡潔で十分な情報を提供する必要があります。

計画レビューリスト（CRL）

論理図に従って、各CAはそのレビューリストを公開します。 レビューリストは、主に2つのカテゴリで特徴付けられます。

1. リコールリストの公開および配布のポイント。
2. リコールリストの構成と有効性。

リストの公開および配布ポイントのレビュー

失効リストを公開するには、2種類のCRL配布ポイントが使用されます。公開ポイント（物理ファイルが書き込まれる場所）とファイルの配布ポイント（受信）です。



最初のタイプのポイントは、ファイルが書き込まれるローカルまたはネットワークパス（UNC形式）を示します。 2番目のタイプのポイントは、発行された証明書に登録され、顧客がレビューリストをダウンロードできる方法を示します。 これらのパスは、CRL配布ポイントの証明書拡張機能で公開されます。 通常、これらのパスは一致しません（公開パスと配布パスが同じLDAPを除く）。 公開ポイントを決定する際には、次の規則に従ってください。

• ルートCAの場合、このサーバーはネットワークから隔離されるため、厳密にローカルなパスが指定されます。 ファイルの配布サーバー（IIS）へのコピーは手動で行われます。 ルートCAのレビューリストの公開頻度は月単位で測定されるため、これは問題ではありません（詳細については以下を参照してください）。
• 発行CAの場合、ネットワークパスが示されます。 DFSで共有フォルダーを作成することをお勧めします。これは、IISで仮想ディレクトリとして簡単に定義できます。 この場合、物理ファイルを配布ポイントに公開するプロセスは完全に自動化されます。
• 失効リストの公開および配布にLDAPを使用しないでください。

CRL配布ポイントと機関情報アクセスの拡張とプラクティスの計画の詳細については、ブログ投稿「 CRL配布ポイントと機関情報アクセスの場所の設計 」を参照してください。

リスト構成のレビュー

リコールリストの構成と有効性を計画する前に、リコールリストの目的とその動作条件に応じた最適なパラメーターを理解する必要があります。 ご存知のように、各CAは定期的にレビューリストを発行します。これには、特定のCAによって失効したすべての証明書のリストが含まれます。 さらに、各リストには、CAの全期間にわたるすべての失効した証明書が含まれます。 たとえば、CAの寿命が10年の場合、このリストは印象的なサイズ（数メガバイトのオーダー）に成長する可能性があります。



高速接続であっても、失効リストのトラフィックはかなりのサイズになります。 すべての証明書の消費者には最新の改訂リストが必要です。

失効リストのトラフィックを減らすために、2つのタイプのCRL、つまり基本（ベースCRL）と差分（デルタCRL）が公開されます。 ベースリストには、完全なレビューリストが含まれています。 差分リストには、ベースCRLの最後の発行以降に失効した失効した証明書のリストのみが含まれます。 これにより、基本リストをより頻繁に、より長期間公開することができ、間隔内の失効した証明書に対するクライアントの応答時間を短縮して、いくつかの短命な差分CRLを発行できます。



パラメータの選択は、いくつかの要因に依存します。 たとえば、発行された証明書の計画ボリュームと失効の計画ボリューム。 典型的なシナリオを検討してください。



ルートCA



ルートCAは、中間CAにのみ証明書を発行します。中間CAの数は通常、1ダース以内です。 中間CAの有効期間は、ルートCA証明書の有効期間と同等です。 また、下位CAは訓練された担当者によって管理され、適切なセキュリティ対策が実施されているため、下位CAをリコールするリスクは非常に低いと想定されています。 したがって、失効リストのボリュームには少数の失効した証明書のみを含めることができるため、CRLファイルのサイズが小さいことが保証されると言えます。



ヘルプ：レビューのサイズに基づいてCRLファイルの計画サイズを計算する方法は？ 一般的な空のCRLには約600〜800バイトが必要です。 各証明書失効レコードは88バイトです。 これらの値に基づいて、失効した証明書の数に応じてCRLサイズを計算できます。



したがって、ルートCAが存続する間、リコールリストは1kb以内になり、差分CRLには意味がありません。



CAの公開



発行元CAの場合、状況は変化しています。 発行された証明書の量はすでに多く、数千および数百万個になります。 消費者とは、有資格者によって絶えず監視されておらず、適切な手段を提供できないため、リコールのリスクが高いユーザーおよびデバイスです。 その結果、レビューリストは深刻なサイズに達する可能性があります。 たとえば、失効のリスクを10％にすると、発行された100万の証明書に対して約10万の失効があります。 88バイトの100kレコードは10mb未満です。 多くの場合、10 mbごとにファイルを更新することはあまり実用的ではなく、発行頻度を少なくして、メインCRLの発行間隔でいくつかの軽量差分Delta CRLを配布する方が便利です。 つまり ルートCAに基本的な失効リストだけで十分な場合は、エンドユーザーに証明書を発行するCAにデルタを使用する必要があります。

CRL有効期限計画

各CAのレビューリストの構成がすべてでした。 ここで、タイミングを決定する必要があります。

• レビューリストはどのくらいの期間公開する必要がありますか？
• その中の情報はどのくらいの期間信頼性があり、十分に関連性があると見なされますか

ここでは、動作条件に応じてアプローチを適用することもできます。 中間CAを取り消すリスクは非常に低いため、空のCRLを頻繁に公開することは意味がありません。 現代のプラクティスでは、CAのCRL有効期間に次の一般的な値が使用されます。これは、他のCAにのみ証明書を発行します：3、6、または12か月。 リコールリストを維持するためのリスクと管理コストの程度に基づいている必要があります。 特別な条件がない場合は、平均的な約6か月を選択することをお勧めします。



下位CAの場合、スキームは同じです。 クライアント証明書を取り消すリスクが高いため、取り消しの頻度が高いと想定できます。 したがって、このようなCAはレビューリストをはるかに頻繁に公開し、トラフィックを節約するために、基本CRLと差分CRLを組み合わせます。 デフォルトでは、Microsoft CAは次の頻度で失効リストを公開します。基本CRLは週に1回、デルタは毎日。 この状況では、24時間以内に、失効した最新の証明書がお客様に通知されます。



お客様が失効した証明書が有効であると認識しないように、この時間を（理想的には即座に）短縮する管理者の要望を理解できます。 ただし、1つのリスクが減少すると、別のリスクが増加します。 何らかの理由で、以前のCRLの有効期限が近づき、新しいCRLを公開できなかったときにCAサーバーが失敗したと想像してください。 その後、証明書の失効を確認し、CAサーバーが機能するように復元されるまでそれらを停止することから問題が始まります。 レビューリストの有効期限を設定するときは、この点を考慮する必要があります。



既定では、Microsoft CAは、予期しない場合や、レビューリストをすべての公開ポイントに配布するのに時間がかかる場合（たとえば、レプリケーションの遅延が原因）に、ある程度の時間的余裕を既に設けています。 英語の用語でのこの予備は、CRLオーバーラップと呼ばれます。 防御メカニズムの背後にある考え方は、CAが以前に発行されたリストの有効期限が切れる前にレビューリストを生成して発行することです。



これは、レビューリストの2つのフィールド、Next CRL PublishおよびNext Updateを使用して実現されます。 Next CRL Publishフィールドは、CAが更新された失効リストを（自動的に）公開する時刻を示します。 次の更新は、現在のリストが期限切れになる時間を示します。 Next Updateフィールドは、常にNext CRL Publishよりも少し遅れて設定されます。 つまり、CAは以前のリストが期限切れになる前に、更新された失効リストを公開します。 これらのフィールドの自動値を計算するアルゴリズムは自明ではなく、次の記事で説明されています： ThisUpdate、NextUpdate、NextCRLPublishの計算方法（v2） 何らかの理由でデフォルト値が適切でない場合は、編集できます。 時間マージンには下限と上限があることに留意してください。 たとえば、上限はCRL自体の有効期間を超えることはできません。 したがって、CRLの有効期間が1日間の場合、在庫は最大1日間になり、CAは毎日レビューリストを公開しますが、有効期間は2日間になります。 したがって、予期しない状況の場合にCAを復元するための時間のマージンが達成されます。



実際には、管理者がCRLの有効期限設定を次の理由で最小限度に調整したいという要望をよく目にしました。「ユーザーは終了し、失効した証明書で認証できないはずです」。 動機は理解できますが、レビューリストを通じて問題を解決することは完全に正しいとは限りません。 ユーザーが企業システムへのアクセスを停止する必要がある場合は、ユーザーアカウントまたはコンピューターを無効にする必要があります。



CRLの有効期限と頻度を計画するときは、次の推奨事項に従ってください。

• エンドユーザーではなく、他のCAのみに証明書を発行するすべてのCAは、3か月から12か月の間、1か月のマージンでCRLを公開する必要があります。
• エンドユーザー（ユーザーおよびデバイス）に証明書を発行するすべてのCAは、少なくとも1週間に1回基本CRLを発行し、少なくとも3日間（できれば毎日）差分リストを発行する必要があります。 時間マージンは調整しないでください（CAの内部ロジックによって自動的に計算されるものを使用してください）。

オンライン証明書ステータスプロトコル

この記事シリーズの一環として、失効した証明書に関する情報を配布する追加の方法にOCSPサーバーを使用しません。 必要に応じて、包括的なTechNet記事「 オンラインレスポンダーのインストール、構成、およびトラブルシューティングガイド」を参照できます。 実践が示すように、ほとんどの場合、OCSPのインストールとサポートはいくつかの理由で正当化されていません。



OCSPの主な目標は、CRLダウンロードトラフィックをオフロードすることです。 ご存知のように、CRLには、CAの全期間にわたるすべての失効した証明書のリストが含まれており、証明書の集中的な失効により、そのサイズは印象的なサイズ（数メガバイト）に達する可能性があります。 上記のように、失効した10万件の証明書はCRLファイルで約9MBになることに注意してください。 OCSPを使用して証明書の失効を確認する間、固定サイズは約2.5KBになります。 目に見える違いがあります。 実際には、多くの場合、リコール率ははるかに低くなります。 ルートCAまたはポリシーのCAについて話す場合、それらは部分的にレビューされ、レビューリストのサイズは1KBをほとんど超えません。



OCSPは、検証済みの証明書が1つあり、それを検証したい多くのクライアントがある場合に効果的であることに注意してください。 これは、典型的なSSL / TLS証明書のシナリオです。 この場合、各クライアントは条件付き9MB失効リストをダウンロードする代わりに、2.5KBのOCSPトラフィックを消費します。 ただし、反対の状況（1つのサーバーが多くのクライアント証明書を検証する）では、OCSPがネットワークに大きな負荷をかける可能性があります。 これには、一般的な企業ネットワークのシナリオが含まれます。証明書を使用したクライアント認証（ワイヤレスネットワークおよびVPNでのEAP-TLS認証、ドメインコントローラーでのKerberos認証など）。 従業員が職場に来て、ネットワーク（スマートカード、モバイルデバイスの証明書）およびドメインコントローラーの認証に証明書を使用すると、RADIUSサーバーは各クライアント証明書の検証を強制されます。 1Kの証明書のみをチェックするには、2.5 MBのトラフィックが消費されます。 この状況では、OCSPの利点はまったくありませんが、まったく逆です。



この側面は、Microsoft製品のロジックで考慮されます。 特定の期間、Crypto APIクライアントがOCSPを使用して1つのパブリッシャーから50（この値を構成可能）証明書をチェックすると、OCSPの処理が終了し、クライアントはこのパブリッシャーのCRLをダウンロードしてキャッシュします。 この動作の詳細については、Windows VistaおよびWindows Server 2008の証明書失効確認の 失効エクスペリエンスの最適化セクションをご覧ください。

証明書発行ポリシーを計画する

証明書発行ポリシーは、証明書の最も理解しにくい側面の1つであり、企業でPKIを計画および展開するときに管理者によって完全に無視されることがよくあります。 ただし、発行ポリシーを理解し、管理する能力により、より柔軟なシステム、追加の制御レベル、そして最終的にはPKIを記述および文書化する方法として提供されます。

ポリシー定義

まず、証明書発行ポリシーの定義を入力する必要があります。 証明書を発行/取得するプロセスは、基本的に、証明書の受信者と発行CAとの間の契約です。 この契約は、発行の手順、使用、責任範囲など、多くの側面を定義しています。



各企業は、アプリケーションの検証と証明書の発行に異なる方法を使用している場合があります。 いくつかの典型的なケースを考慮してください：

• 電子メールに署名するための証明書は、申請者の最小限の検証で自動的に発行できます（Active Directoryでのユーザーの認証が成功した場合のみ）。 これらの証明書を発行するために、それ以上のアクションは行われません。
• 文書のデジタル署名の証明書は、直属の上司との合意および必要なすべての署名を含む書面による申請書の提供後にのみ発行できます。
• スマートカードの証明書は、従業員の個人的な出席、およびカードの使用、関連規制文書への署名に関する規則に関する指示がある場合にのみ発行できます。
• , , -.

. , . , — .. , , (, ).



, . . Network Policy Server (NPS) Active Directory Dynamic Access Control . , . , -.



NPS , , , -. , NPS ( ) . , , . Active Directory Dynamic Access Control, .

, . , , . , ? .



, - . , . , . . , ( PKI ) , , , .



: PKI – Certificate Practice Statement CPS ( , , ). ( ) , RFC 3647 . , PKI. . , , - .



CPS :

1. PKI, , .
2. . PKI, , CPS, , .

CPS ( ). CPS ( ).



ITU-T ISO. : OID' ? , IANA (Internet Assigned Numbers Authority) . , , : 1.3.6.1.4.1.x.1, x – , IANA. :

• 1.3.6.1.4.1.x.1.1
• 1.3.6.1.4.1.x.1.2
• 1.3.6.1.4.1.x.1.3
• 1.3.6.1.4.1.x.1.4
• ...

, . , , . Certificate Policies , .







, DigiCert, 2.16.840.1.114412.2.1 ( Extended Validation ) 2.23.140.1.1 (, CAB/Forum) CPS. CPS .



, , , . . , - , , ( ). : Certificate Policies extension – all you should know (part 1) Certificate Policies extension – all you should know (part 2) . , , Windows.



: (10 ) , . (, ), . RFC 5280 §4.2.1.4 (global wildcard) anyPolicy = 2.5.29.32.0, .



, , . , .. , , , , anyPolicy , . , . anyPolicy .

AD CS ( ). (, ). , (AD CS JET Database Engine). これは理論上です。



, . Windows Server 2003 Evaluating CA Capacity, Performance, and Scalability ( , .. TechNet), , . (, ), .



2010 , Windows PKI Team ( 2007 ) Windows Server 2008. : Windows CA Performance Numbers . , , AD CS 2007 150 . . . , . Windows Server 2016 ( Windows Server 2016 System Requirements ):

• CPU — dual-core 1.4 GHz;
• — 1GB RAM;
• — 48 GB 48 GB . RAID1.
• — SVGA (800*600);
• — .

, ( ) ( ) .

( ), . , , . .

.

	Standalone CA
	Root CA
	15
AD ()	Certification Authorities AIA
CRT	1) - 2) C:\CertData\contoso-rca<CertificateName>.crt 3) IIS:\InetPub\PKIdata\contoso-rca<CertificateName>.crt*
CRT	1) URL=http://cdp.contoso.com/pki/contoso-rca<CertificateName>.crt
CRL	1) - 2) C:\CertData\contoso-rca<CRLNameSuffix>.crt 3) IIS:\InetPub\PKIdata\contoso-rca<CRLNameSuffix>.crt*
CRL	1) URL=http://cdp.contoso.com/pki/contoso-rca<CRLNameSuffix>.crt
	Contoso Lab Root Certification authority
	OU=Division Of IT, O=Contoso Pharmaceuticals, C=US
	RSA#Microsoft Software Key Storage Provider
	4096
	SHA256
	15
CRL	Base CRL
Base CRL
	Base CRL
	6ヶ月
	1ヶ月
	SHA256
AD

* — IIS .

.

	Enterprise CA
	Subordinate CA
	: 5 ( )
AD ()	AIA NTAuthCertificates
CRL	Base CRL Delta CRL
CRT	1) - 2) \\IIS\PKI\contoso-pica<CertificateName>.crt
CRT	1) URL=http://cdp.contoso.com/pki/contoso-pica<CertificateName>.crt
CRL	1) - 2) \\IIS\PKI\contoso-pica<CRLNameSuffix><DeltaCRLAllowed>.crl
CRL	1) URL=http://cdp.contoso.com/pki/contoso-pica<CRLNameSuffix><DeltaCRLAllowed>.crl
	Contoso Lab Issuing Certification authority
	OU=Division Of IT, O=Contoso Pharmaceuticals, C=US
	RSA#Microsoft Software Key Storage Provider
	4096
	SHA256
	15 ( )
	1) : All Issuance Policies OID=2.5.29.32.0 URL=http://cdp.contoso.com/pki/contoso-cps.html
Basic Constraints	isCA=True ( — ) PathLength=0 ( ).
Base CRL
	Base CRL
	1週間
	SHA256
AD
Delta CRL
	Delta CRL
	1
	-
	SHA256
AD

IIS

-	cdp
	cdp.contoso.com
	PKI=C:\InetPub\wwwroot\PKIdata
Double Escaping

, . , .

著者について

— PowerShell Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management 2009 PowerShell PKI. 9 PKI . PKI PowerShell .