web-dev-qa-db-ja.com

オフラインルートおよび中間認証局（CA）の構築に関するチェックリスト

マイクロソフトでは、CAがこのスイートをサポートしないクライアントに対して、Cryptography Next Generation（CNG）および 非互換性の問題に関するアドバイス を使用することを許可しています。

これは、2008 R2 CAのデフォルトの暗号化設定のイメージです。このマシンは、ドメインに接続されていないスタンドアロンCAです。

Default Cryptography settings

インストールされているプロバイダーは次のとおりです。 CNGプロバイダーは＃記号でマークされています

enter image description here

私の目的は、汎用のオフラインRoot-CAを用意し、次に特定の目的を果たすいくつかの中間CAを用意することです（MSFTのみvs Unix vsスマートカードなど）。

有効期限が5年、10年、15年のルート証明書の理想的な設定は何ですか？

  1. CSP
  2. 署名証明書
  3. キー文字長

これはRootCAであるため、いずれのパラメーターも低電力CPU（モバイルデバイス）に影響を与えます

encryptionwindowscertificatespublic-key-infrastructurecertificate-authority
25
goodguys_activate

注：これは、Microsoft、NIST、および他の高く評価されているPKIと暗号化の専門家が述べたさまざまな推奨事項とアクションの（非常に長い）要約です。少しでも修正が必要なものがあれば、私に知らせてください。

CAとそのサブクラスの構成に入る前に、MSFTのCryptoAPIが自己署名ルートを必要とする場合でも、一部の非MSFTソフトウェアがRFC 3280に準拠し、検証目的ですべてのCAが信頼できるルートになることを許可することを知っておくとよいでしょう。 1つの理由は、非MSFTソフトウェアがより短いキー長を優先することです。

CA ROOTとSubsの設定に関するいくつかの構成上の注意とガイダンスを以下に示します。

CAの秘密鍵の保存

  • 最適：キーのカウントをサポートするHSMにキーを保存します。 CAの秘密キーが使用されるたびに、カウンターが増加します。これにより、監査プロファイルが改善されます。 FIPS140レベル3または4を探す

  • 良い例：秘密キーをスマートカードに保存します。キーカウントを提供するスマートカードについては知りませんが、キーカウントを有効にすると、 イベントログに予期しない結果が表示される可能性があります

  • 許容：Windows DPAPIに秘密キーを保存します。これらのキーとキー登録エージェントが Roaming Credentials になっていないことを確認してください。関連項目： DPAPIおよびローミング資格情報を列挙する方法

キーの長さ

有効期限

アルゴリズムとキーの長さは、証明書を有効にしておく期間に影響を与える可能性があります。これは、攻撃者のクラックにかかる時間を効果的に決定するためです。つまり、暗号化が強ければ強いほど、証明書を有効にする準備が長くなる

1つのアプローチは、エンドエンティティ証明書に必要な最長の有効期間を確立し、発行CAに対してそれを2倍にし、次にルートCA（2層）に対して再び2倍にすることです。このアプローチでは、ライフタイムの半分に達したときに各CA証明書を定期的に更新します。これは、CAがCA証明書自体の有効期限より後の有効期限の証明書を発行できないためです。

適切な値は、実際には組織とセキュリティポリシーによってのみ決定できますが、通常、ルートCAの証明書の有効期間は10年または20年です。

互換性について懸念がある場合は、有効期限を2038未満に設定してください。これは、1970年1月1日からの秒数としてデータを符号付き32ビット整数でエンコードするシステムによるものです。 この問題の詳細については、こちらをご覧ください。

ハッシュの選択

特に：

  • Windows 2003および XPクライアントには、SHA256、SHA384、およびSHA512を含むSHA2アルゴリズム のパッチが必要な場合があります。 詳細な技術情報を参照

  • AuthenticodeおよびSHA2ハッシュを使用したS/MIMEは、XPまたは2003ではサポートされていません。

  • 「SHA-224のサポートに関しては、SHA-224はSHA-256よりもセキュリティが低くなりますが、リソースの量は同じです。また、SHA-224は通常、プロトコルやアプリケーションでは使用されません。NSAのSuite B標準にも含まれていません。」 ソース

  • 「XPで証明書を信頼するか、証明書を検証するか、チェーン検証で証明書を使用するか、CAから証明書を受け取る場合は、CA階層のどこにもSHA2スイートを使用しないでください。 XP SP3はCA階層でSHA2を使用する証明書の検証を許可し、KB 968730はSHA2を使用するCAによって署名された証明書の限られた登録を許可しますが、個別の署名を使用するとブロックされます= XP完全に。 "（ ソース ）

暗号化プロバイダーの選択

ランダムなシリアル番号の生成を有効にします

2012年以降、MD5をハッシュとして使用する場合、これは必須です。 SHA1以上が使用されている場合、 良いアイデアです 。詳細については、 このWindows 2008R2の「方法」 も参照してください。

証明書の実践ステートメントを作成します

証明書の実践ステートメントは、ITが発行する証明書を管理するために使用する実践のステートメントです。組織の証明書ポリシーが組織のシステムアーキテクチャとその運用手順のコンテキストでどのように解釈されるかについて説明します。 IT部門は、証明書の実践ステートメントを準備および維持する責任があります。 （ ソース ）

注：拘束力のある契約でデジタル署名が使用される場合など、状況によっては、証明書の実践に関する声明は、提供されるセキュリティのレベル、およびセキュリティレベルの確立と維持に使用される安全対策に関する法的声明と見なすこともできます。 。

CPSステートメントの記述を支援するために、 これはMicrosoftが作成した「ジョブエイド」です

ベストプラクティス：このフィールドにフリーフォームのテキストを入力することは可能ですが（下記のnoticeを参照）、理想的な解決策はURLを使用することです。これにより、証明書を再発行せずにポリシーを更新でき、証明書ストアの不要な肥大化も防止できます。

[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = "Legal policy statement text"
URL = "http://www.example.Microsoft.com/policy/isspolicy.asp"

証明書ポリシー

これは、発行ポリシーまたは保証ポリシー（MSFTの場合）とも呼ばれ、自分で定義したものですOIDこれは、証明書に加える必要のある信頼の程度（高、中、低など）を示します） 。 このフィールドを適切に使用する方法については、このStackExchangeの回答 を参照してください。

アプリケーションポリシーとEKUポリシーが一致することを確認します

アプリケーションポリシー は、オプションのMicrosoft規則です。アプリケーションポリシーとEKU拡張の両方を含む証明書を発行する場合は、2つの拡張に同じオブジェクト識別子が含まれていることを確認してください。

CRLチェックを有効にする

通常、Windows Server 2003 CAは、エンドエンティティ証明書を発行する前に、PKI階層内のすべての証明書（ルートCA証明書を除く）の失効を常にチェックします。この機能を無効にするには、CAで次のコマンドを使用してから、CAサービスを再起動します。

 certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

CRL配布ポイント

ルートCAに関する特別なガイダンス

  • これはルートCAではオプションであり、誤って行われると 秘密鍵が公開される可能性があります 。

  • すべてのCRL公開は、オフラインのRootCAから他のすべてのサブCAに対して手動で行われます。別の方法は、 オーディオケーブルを使用して、ルートからサブCAへの一方向の通信 を容易にすることです。

  • ルートCAに、発行された証明書ごとに異なるCRLロケーションを下位CAに発行させることは完全に許容されます。

  • CRLをルートに置くことは、2つのPKIが相互に信頼し、ポリシーマッピングを行う場合のベストプラクティスです。これにより、証明書を取り消すことができます。

CRLを「正しく」取得することは、CRLチェックを行うアプリケーションごとに異なるため、非常に重要です。たとえば、ドメインコントローラーでのスマートカードログオンは常に失効チェックを実行し、失効チェックを実行できないか失敗した場合、ログオンイベントを拒否します。

注チェーン内の証明書を検証できないか、取り消されていることが判明した場合、チェーン全体がその1つの証明書のステータスになります。

  • 自己署名ルートCAは、CDPを一覧表示しないでください。ほとんどのWindowsアプリケーションはCERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOTフラグを有効にしないため、CDPを無視します（ これはデフォルトの検証モードです ）。フラグが有効で、自己署名ルート証明書のCDPが空白の場合、エラーは返されません。

  • HTTPSとLDAPSは使用しないでください。これらのURLは、配布ポイント参照としてサポートされなくなりました。理由は、HTTPSおよびLDAPS URLが、失効する場合と失効しない場合がある証明書を使用しているためです。 HTTPSまたはLDAPS URLが使用されている場合、失効確認プロセスにより失効ループが発生する可能性があります。証明書が取り消されたかどうかを判別するには、CRLを取得する必要があります。ただし、HTTPSまたはLDAPSで使用される証明書の失効ステータスが判別されない限り、CRLを取得できません。

  • LDAPの代わりにHTTPを使用することを検討してください-AD DSはフォレスト内のすべてのドメインコントローラーへのCRLの発行を有効にしますが、失効情報の発行にはLDAPの代わりにHTTPを実装します。ETagおよびCache-Control: Max-ageヘッダーは、プロキシのサポートとよりタイムリーな失効情報を提供します。さらに、HTTPは、ほとんどのLinux、UNIX、およびネットワークデバイスクライアントでサポートされているため、異種混合サポートを提供します。

  • LDAPを使用しないもう1つの理由は、失効ウィンドウが小さくなるためです。 AD LDAPを使用してCA情報を複製する場合、失効ウィンドウは、AD内のすべてのサイトがCA更新を取得する時間より短くなることはありません。多くの場合、この複製には最大8時間かかることがあります...スマートカードユーザーのアクセスが取り消されるまで8時間です。 'Todo：新しい推奨CRL更新時間は次のとおりです：????? `

  • すべてのURLを高可用性にします（別名、外部ホストのLDAPを含めないでください）。 Windowsは検証プロセスを最大20秒間遅くし、 失敗した接続を再試行します 少なくとも30分ごとに繰り返します。ユーザーがサイトをアクティブに使用していない場合でも、 プリフェッチ が原因でこれが発生すると思われます。

  • CRLのサイズを監視します。 CRLオブジェクトが大きすぎて、CryptoAPIが割り当てられた最大タイムアウトしきい値内にオブジェクトをダウンロードできない場合、 「オフラインでの取り消し」エラーが返され、オブジェクトのダウンロードが終了します。

注：ETAGをサポートするHTTPを介したCRL配布は、TCP接続が継続的にリセットされるWindows 2003/IIS6を使用している場合にIE6で問題を引き起こす可能性があります。

  • （オプション） 最新のCRLを有効にする ：この重要でない拡張機能は、Delta CRLを取得する発行元と場所を一覧表示します。 「最新のCRL」属性がCRLにも証明書にも存在しない場合、ベースCRLは、ベースCRL /デルタCRLペアの一部としてではなく、通常のCRLとして扱われます。

Microsoft CAは、「Freshest CRL」拡張を発行済み証明書に含めません。ただし、発行された証明書に「Freshest CRL」拡張を追加することは可能です。コードを記述してリクエストに追加するか、カスタムポリシーモジュールを記述するか、保留中のリクエストでcertutil –setextensionを使用する必要があります。高度な証明書の登録の詳細については、 Microsoft Webサイト にある「高度な証明書の登録と管理」のドキュメントを参照してください。

警告CAでデルタCRLが有効になっている場合は、ベースCRLとデルタCRLの両方を検査して、証明書の失効ステータスを確認する必要があります。 2つのうちの1つ、または両方が使用できない場合、チェーンエンジンは失効ステータスを特定できないことを報告し、アプリケーションが証明書を拒否する場合があります。

CRLサイジングおよびメンテナンス（CRLパーティショニング）

CRLは、取り消される証明書ごとに29バイト増加します。したがって、証明書が元の有効期限に達すると、失効した証明書はCRLから削除されます。

CA証明書を更新すると、新しい/空白のCRLが生成されるため、発行CAは、妥当なCRLサイズを維持するために、100〜125Kの証明書ごとに新しいキーでCAを更新することを検討します。この発行数は、発行された証明書の約10％が自然な有効期限の前に取り消されるという想定に基づいています。実際の失効率または計画された失効率が組織に対して高いまたは低い場合、それに応じて主要な更新戦略を調整します。 詳細

また、失効の可能性が高まるため、有効期限が1年または2年を超える場合は、CRLをより頻繁に分割することを検討してください。

これの欠点は、各証明書がサーバーによって検証されるため、起動時間が長くなることです。

CRLセキュリティ対策

CRLを使用する場合は、MD5でCRLに署名しないでください。 CRL署名鍵にランダム化 を追加することもお勧めです。

機関情報アクセス

このフィールドにより、証明書検証サブシステムは、ローカルコンピューターに存在しない場合に、必要に応じて追加の証明書をダウンロードできます。

  • 自己署名ルートCAは、AIAの場所をリストするべきではありません（ 理由はこちらをご覧ください ）

  • 証明書チェーン内のすべての証明書について、AIA拡張機能で最大5つのURLが許可されます。さらに、証明書チェーン全体で最大10個のURLもサポートされます。 URLの数に対するこの制限は、サービス拒否攻撃における「Authority Info Access」参照の潜在的な使用を軽減するために追加されました。

  • HTTP[〜＃〜] s [〜＃〜]およびLDAP[〜＃〜]を使用しないでくださいs [〜＃〜]。これらのURLは、配布ポイント参照としてサポートされなくなりました。理由は、HTTPSおよびLDAPS URLが、失効する場合と失効しない場合がある証明書を使用しているためです。 HTTPSまたはLDAPS URLが使用されている場合、失効確認プロセスにより失効ループが発生する可能性があります。証明書が取り消されたかどうかを判別するには、CRLを取得する必要があります。ただし、HTTPSまたはLDAPSで使用される証明書の失効ステータスが判別されない限り、CRLを取得できません。

OCSP検証を有効にする

OCSPレスポンダは通常、http://<fqdn of the ocsp responder>/ocspにあります。このURLはAIAで有効にする必要があります。 これらのWindowsの手順を参照してください。

完全なOCSP検証はデフォルトでオフになっていることを知ってください（仕様に従ってEV証明書の場合は「オン」にする必要があります）。さらに、OCSPチェックを有効にする は、初期接続に遅延を追加します

より安全なシステムでは、クライアント側またはサーバー側で OCSP監視を有効にする必要があります

OCSPキャッシュ期間

すべてのOCSPアクションはHTTPプロトコル上で発生するため、通常のHTTPプロキシキャッシュルールに従います。

具体的には、Max-ageヘッダーは、条件付きGETを使用してオブジェクトが変更されたかどうかを判断する前に、プロキシサーバーまたはクライアントがCRLまたはOCSP応答をキャッシュする最大時間を定義します。この情報を使用して、適切なヘッダーを設定するようにWebサーバーを構成します。このためのAD-IIS固有のコマンドについては、このページの他の場所を参照してください。

発行された証明書でポリシーを定義します

親CAは、サブCAからのCA証明書ポリシーを許可するかどうかを定義します。発行者またはアプリケーションポリシーをサブCAに含める必要がある場合は、この設定を定義できます。

ポリシーの例には、スマートカードのEKU、認証、またはSSL /サーバー認証が含まれます。

  • ポリシーツリーが複雑になる可能性があるため、Certificate Policies拡張子のない証明書には注意してください。詳細については、RFC 5280を参照してください

  • ポリシーマッピングがパス内の他のポリシーを置き換えることができることを知っている

  • 処理を変更するanypolicyと呼ばれる特別なポリシーがあります

  • anypolicyを変更する拡張機能があります

  • 証明書ポリシーを使用する場合は、必ずcriticalとしてマークしてください。そうしないと、計算されたvalid_policy_treeが空になり、 ポリシーが栄光のコメントに変わります。

DNの長さの強制を監視します

OUフィールドの元のCCITT仕様では、64文字に制限する必要があると述べています。通常、CAはすべての要求に対して、証明書のサブジェクト拡張にx.500の名前の長さの標準を適用します。深いOUパスが通常の長さの制限を超える可能性があります。

クロス証明書配布ポイント

この機能は、環境に2つのPKIをインストールする必要がある場合に役立ちます。1つは最新の暗号化をサポートしないレガシーハードウェア/ソフトウェア用で、もう1つはより現代的な目的用のPKIです。

EKUを制限する

「一般に、[sic] EKU拡張はエンドエンティティ証明書にのみ表示される」と記載されているRFC 5280とは対照的に、CAキーの使用に 制約を課すことをお勧めします 。

典型的なスタンドアロンCA証明書には、デジタル署名、証明書署名、およびCRL署名をキー値として作成する権限が含まれます。これはFLAMEのセキュリティ問題の一部です。

MSFTスマートカードの実装 には、次のEKUのいずれかと、場合によっては修正プログラムが必要です

  • MicrosoftスマートカードEKU
  • PKINIT RFC 4556で定義されている、初期認証（PKINIT）クライアント認証EKUの公開鍵暗号化

また、EKUの検証に関して興味深い制約があります（リンクtbd）。

EKUの制限に関心がある場合は、 OIDに関するこの回答 および 制約付き証明書に関するこれ が表示されます。

基本的な制約「パス」に注意してください

基本的な制約 は、証明書が「エンドエンティティ」であるかどうかを示す必要があります 。中間CA へのパス制約の追加は、一般的ではない構成であり、クライアントがそれを受け入れない場合があるため、期待どおりに機能しない可能性があります。

中間CAの限定従属

  • サブCAが提供できる証明書のタイプを制限するには、 このリンク 、および これを参照

  • 限定従属が行われる場合、ルートはCRLを頻繁に更新しないため、相互署名されたルートを取り消すのは難しい場合があります。

Authority Key Identifier/Subject Key Identifier

注証明書のAKI拡張にKeyIDが含まれている場合、CryptoAPIでは発行者証明書に一致するSKIが含まれている必要があります。これは、SKIとAKIのマッチングが オプション であるRFC 3280とは異なります。 （todo：なぜ誰かがこれを実装することを選ぶのですか？）

AKI matching to find key parent

ルートとCAに意味のある名前を付けます

インポート、インポートされた証明書の確認、およびトラブルシューティングの際に、人々はあなたの証明書を操作します。 MSFTの推奨される慣行と 要件 は、ルートが組織を識別する意味のある名前を持ち、CA1のように抽象的な一般的なものではないことです。

この次の部分は、特定の目的のために制約される中間/サブCAの名前に適用されます：認証vs署名vs暗号化

驚いたことに、PKIのニュアンスを理解していないエンドユーザーや技術者は、S/MIMEやデジタル署名（など）を使用する場合に、思ったよりも頻繁に、選択したサーバー名と対話します。

個人的には、発行する証明書の名前を"Company Signer 1"のようなユーザーフレンドリーな名前に変更して、一目でわかるようにすることをお勧めします。

  • 誰が署名するのか（Texas A＆Mまたはそのライバル）
  • 何に使うの？暗号化と署名

2つのパーティ間で暗号化されたメッセージと署名されたメッセージの違いを伝えることが重要です。これが重要な1つの例は、受信者に送信したステートメントをエコーさせることができるかどうかです。ユーザーAはユーザーBに「A、私は$ 100を借りている」と伝えることができます。 Bが誤ったキーを使用してそのメッセージのエコーで応答した場合、彼らは事実上100ドルの架空の借金をデジタルで公証しました（暗号化だけ）。

以下は、 S/MIME のサンプルユーザーダイアログです。 Browerベースの証明書にも同様のUIが期待されます。発行者名がわかりにくいことに注意してください。

Select a SMIME certificate.. really?

代替エンコーディング

注：名前について言えば、チェーン内のいずれかのリンクが代替エンコーディングを使用している場合、クライアントはサブジェクトに対して発行者フィールドを確認できない場合があります。 Windowsは比較中にこれらの文字列を正規化しないため、（RFCの推奨とは対照的に）CAの名前がバイナリの観点から同一であることを確認してください。

Name matching to find key parent

高セキュリティ/スイートBの導入

  • Windows 2008およびR2でサポートされているSuite Bアルゴリズムに関する情報

    アルゴリズムシークレットトップシークレット

    暗号化：Advanced Standard（AES）128ビット256ビット

    デジタル署名：楕円曲線デジタル署名アルゴリズム（ECDSA）256ビット曲線。 384ビットカーブ

    キー交換：楕円曲線Diffie-Hellman（ECDH）256ビット曲線。 384ビットカーブ

    ハッシュ：セキュアハッシュアルゴリズム（SHA）SHA-256 SHA-384

  • Suite Bに準拠するため、ECDSA_P384#Microsoft Software Key Service Providerと384の鍵サイズ、およびハッシュアルゴリズムとしてのSHA384も、必要な分類レベルが最高機密である場合に選択できます。必要な分類レベルに対応する設定を使用する必要があります。 ECDSA_P521もオプションとして用意されています。 521ビットのECC曲線の使用はSuite Bの暗号要件を超える可能性がありますが、非標準のキーサイズのため、521は公式のSuite B仕様の一部ではありません。

PKCS＃1 v2.1

Microsoft CA DCOMポートを保護します

Windows Server 2003 CAは、デフォルトでICertRequestまたはICertAdmin DCOMインターフェイスに暗号化を適用しません。通常、この設定は特別な運用シナリオ以外では必要なく、有効にしないでください。これらのインターフェイスでのDCOM暗号化をデフォルトでサポートするのは、Windows Server 2003マシンのみです。たとえば、Windows XPクライアントは、デフォルトでは、Windows Server 2003 CAへの証明書リクエストに暗号化を適用しません。 source

CNG秘密キーストレージとCSPストレージ

証明書テンプレートv3を登録すると、秘密キーはクライアントコンピューターのCNG秘密キーストレージに格納されます。証明書テンプレートv2またはv1を登録すると、秘密鍵はCSPストレージに送られます。証明書はどちらの場合もすべてのアプリケーションで表示されますが、秘密鍵は表示されません。そのため、ほとんどのアプリケーションは証明書を使用可能として表示しますが、CNGストレージをサポートしない限り、関連する秘密鍵でデータに署名または復号化することはできません。

証明書MMCを使用してCNGストレージとCSPストレージを区別することはできません。特定の証明書が使用しているストレージを確認するには、CERTUTIL -repairstore my *（またはCERTUTIL -user -repairstore my *）を使用して、[プロバイダー]フィールドを確認する必要があります。 「...キーストレージプロバイダー」と表示されている場合は、CNGですが、他のすべてのプロバイダーはCSPです。

初期証明書要求を手動で作成する場合（MMCでカスタム要求を作成）、「CNGストレージ」または「レガシーキー」から選択できます。レガシーはCSPを意味します。以下は、CNGをサポートしていないものの経験に基づくリストです。信頼できるリストはどこにも見つからないため、これは、長期にわたる私の調査から生じています。

  • EFS Windows 2008/Vistaではサポートされず、Windows 7/2008R2ではサポートされます
  • ユーザー暗号化証明書

  • VPN/WiFiクライアント（EAPTLS、PEAPクライアント）

  • Windows 2008/7ユーザーまたはコンピューターの証明書認証ではサポートされていません

  • WebリスナーのTMG 2010サーバー証明書
  • 署名または暗号化のためのOutlook 2003ユーザーの電子メール証明書
  • Kerberos Windows 2008/Vista- DC証明書
  • System Center Operations Manager 2007 R2
  • System Center Configuration Manager 2007 R2
  • SQL Server 2008 R2-
  • Forefront Identity Manager 2010証明書の管理

CNG互換性の詳細については、こちらをご覧ください （チェコ語ですが、Chromeは自動翻訳を適切に処理します）

スマートカードと発行CA

ユーザーに認証用の2番目のスマートカードを提供する予定の場合は、そのために2番目の発行者CAを使用します。 理由：Windows 7の要件

スマートカードログインのトラブルシューティングには、WindowsコマンドCERTUTIL -viewstore -enterprise NTAuthを使用します。ローカルNTAuthストアは、Active Directory NTAuthストアから最後にグループポリシーをダウンロードした結果です。これはスマートカードログオンで使用されるストアなので、このストアを表示すると、スマートカードログオンエラーのトラブルシューティングに役立ちます。

PKIツリーの廃止

2つのPKIツリーを展開し、ある時点（すべての古いデバイスが廃止またはアップグレードされた場所）でレガシーツリーを廃止する目的で、CRLの次の更新フィールドをNullに設定することをお勧めします。これにより、クライアントへの新しいCRLSの継続的なポーリングが妨げられます（すべきですか？）。その理由は、PKIが廃止されると、管理がなくなり、証明書が取り消されることがなくなるためです。残りのすべての証明書は、有効期限が切れているだけです。

PKI廃止措置の詳細については、こちらをご覧ください

39
goodguys_activate

AD CS固有のコマンド

これは、Windows 2008 R2 CAサーバーの構成に関連するコマンドのリストです。それらの情報が長くなりすぎており、すべてのコマンドがCAの設定に直接関連しているわけではないため、他の投稿からそれらを削除しました。

これは、「何を、なぜ」というよりは、「使い方」セクションの詳細です。また、CAバージョン間のバージョン固有の違いも含まれています（2000と2003、vs 2008）。

登録ポリシー編集フラグのリスト

クライアントからの一部のリクエストは自動的に削除される場合があります これらの非表示のサーバー設定に基づいています。

C:\Users\ChrisLamont>certutil -getreg

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration:

Keys:
  Secure Email Root v1

Values:
  Active                   REG_SZ = Secure Email Root v1
  DBDirectory              REG_SZ = C:\Windows\system32\CertLog
  DBLogDirectory           REG_SZ = C:\Windows\system32\CertLog
  DBTempDirectory          REG_SZ = C:\Windows\system32\CertLog
  DBSystemDirectory        REG_SZ = C:\Windows\system32\CertLog

  DBSessionCount           REG_DWORD = 64 (100)
  LDAPFlags                REG_DWORD = 0

  DBFlags                  REG_DWORD = b0 (176)
    DBFLAGS_MAXCACHESIZEX100 -- 10 (16)
    DBFLAGS_CHECKPOINTDEPTH60MB -- 20 (32)
    DBFLAGS_LOGBUFFERSHUGE -- 80 (128)

  Version                  REG_DWORD = 40001 (262145) -- 4.1
  SetupStatus              REG_DWORD = 6001 (24577)
    SETUP_SERVER_FLAG -- 1
    SETUP_DCOM_SECURITY_UPDATED_FLAG -- 2000 (8192)
    SETUP_SERVER_IS_UP_TO_DATE_FLAG -- 4000 (16384)
CertUtil: -getreg command completed successfully.

C:\Users\ChrisLamont>certutil -getreg policy\editflags

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Secur
e Email Root v1\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditF
lags:

  EditFlags REG_DWORD = 83ee (33774)
    EDITF_REQUESTEXTENSIONLIST -- 2
    EDITF_DISABLEEXTENSIONLIST -- 4
    EDITF_ADDOLDKEYUSAGE -- 8        // <--- THIS ENTRY REMOVES A CLIENT'S Key Agreement  
    EDITF_ATTRIBUTEENDDATE -- 20 (32)
    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
    EDITF_BASICCONSTRAINTSCA -- 80 (128)
    EDITF_ENABLEAKIKEYID -- 100 (256)
    EDITF_ATTRIBUTECA -- 200 (512)
    EDITF_ATTRIBUTEEKU -- 8000 (32768)
CertUtil: -getreg command completed successfully.

解決策は、コマンドcertutil -setreg policy\EditFlags -EDITF_ADDOLDKEYUSAGEを実行することです。

     Configuration\spatula\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags:

CA単位でポリシーを定義する方法

発行された証明書にポリシーを含めるには、コマンドプロンプトで次のコマンドを入力します。

 certutil -v -setreg policy\EnableRequestExtensionlist "+2.5.29.32"
 certutil –shudown
 net start certsvc

あなたは設定を無効にすることができます

  certutil -v -setreg policy\EnableRequestExtensionlist      "-2.5.29.32"
  certutil –shudown
  net start certsvc

OCSPキャッシュ期間を定義する方法

次のコマンドを使用すると、Max-Ageヘッダー設定を設定、変更、および削除できます。

  appcmd set config /section:httpProtocol /+customHeaders.[name='cacheControlHeader',value='max-age=604800']

現在のhttpProtocolカスタムヘッダーを表示するには

  appcmd list config /section:httpProtocol

オフラインCA証明書をADにインポートする方法

:
: Root CA certificates
:
certutil -dspublish -f concorp-ca-00_CorporateRootCA.crt RootCA
:
: Sub CA certificate
:
certutil -dspublish -f connoam-ca-00_IntermediateCA1.crt SubCA
:
: Root CA CRLs
: Since these are .NET CA CRLS that have the publication location as
: part of the CRL, the publication location is optional
:
:                                              |-- publication location ---|
:
certutil -dspublish -f CorporateRootCA.crl     concorp-ca-00 CorporateRootCA
:
: Sub CA CRLs
:
certutil -dspublish -f IntermediateCA1.crl     connoam-ca-00 IntermediateCA1

PKCS＃1 v1.21を有効にする方法

これは、CAPolicy.infファイルにAlternateSignatureAlgorithm=1がある場合に有効になります。互換性の問題に注意してください。

最後に、AD証明書サービスのインストールは、役割を追加するほど簡単ではないことを知っておく必要があります。この VBSインストールスクリプト を確認し、ファイル CAPolicy.inf が環境に合わせて必要に応じて編集されていることを確認してください

相互証明書配布ポイントを定義する方法

Windows AD証明書サービスは、[CrossCertificateDistributionPointsExtension]エントリを含むCAPolicy.infoファイルでこれを有効にします

その他：Windows 2000 CAをWindows 2003にアップグレードするときのAIAの違い

Windows 2000と2003のCA間で動作に変更があることに注意してください。 Windows CAが発行する証明書のAKI拡張機能は、Windows 2000とWindows Server 2003で異なります。デフォルトでは、次の情報は、発行された証明書のAIA拡張機能に格納されます。

  • Windows 2000 CAが発行した証明書のAIA拡張には、発行CAのLDAP DN（発行者名）、発行CAの証明書のシリアル番号、およびCA証明書の公開鍵のキーハッシュが含まれています。

  • Windows Server 2003 CAによって発行された証明書のAIA拡張には、発行元CAの公開キーのハッシュ（キーIDとも呼ばれる）のみが含まれています。

動作の変更は、CAの証明書が更新されたときに発生する可能性があったチェーンエラーが原因です。 Windows 2000のデフォルトの動作では、発行された証明書の署名に使用されたCA証明書がクライアントで利用できない場合、チェーンが不完全になる可能性があります。 Windows Server 2003のデフォルトの動作では、CAが同じキーペアで更新された場合、同じキーペアを使用する発行元CAのCA証明書が証明書チェーンに含まれる可能性があります。

このコマンドを実行すると、古い動作を模倣できます

 certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERNAME
 certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERSERIAL

ADでの証明書のリスト

このコマンドは、Active Directoryで公開されている証明書を一覧表示します。

certutil -viewstore "ldap:///CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com?cACertificate?one?objectClass=certificationAuthority"

ISIS MTT v1.1 PKIの互換性

これを参照してください 手順についてはKB記事 、これも ISIS MTT v1.1の代替CAPolicy.infメソッド です。

4
goodguys_activate

チェックリストの1つのポイントが見落とされることがよくあります。

  • [〜＃〜]バックアップ[〜＃〜]
  • [〜＃〜]バックアップ[〜＃〜]
  • [〜＃〜]バックアップ[〜＃〜]

特にCAを実装する場合。

3
that guy from over there

以前の回答ではスペースが足りなくなりましたが、これは有効で有用な情報だと思います。

失効

次のいくつかのセクションではCRLと証明書について説明しますが、先に進む前に、運用とPKIの運用に影響を与える可能性のある問題に注意を向けたいと思います。PKIがMicrosoftのPKI（Active Directory Certificateサービス）の場合、失効日は最初の失効日ではなく、2番目の失効日になります。ただし、MicrosoftのFIM CM製品（Forefront Identity Management-証明書管理）を使用してスマートカード上の証明書を管理する場合、そのような重複した失効を行うことになります。 ソース

1
goodguys_activate