証明機関のガイダンス
公開日: 2016年9月
対象: Windows Server 2012 R2、Windows Server 2012
証明機関 (CA) はユーザー、コンピューター、および組織の ID を証明する役割を担います。 CA はエンティティを認証し、デジタル署名された証明書を発行することで、その ID を保証します。 CA は証明書の管理、取消、更新もできます。
証明機関は次を参照することができます。
エンド ユーザーの ID を保証する組織
証明書の発行および管理のために組織によって使用されるサーバー
Active Directory 証明書サービス (AD CS) の証明機関役割サービスをインストールすることで、CA として動作する Windows サーバーを構成することができます。
CA 役割サービスをインストールする前に、次を行う必要があります。
組織に適した公開キー基盤 (PKI) を計画します。
ハードウェア セキュリティ モジュール (HSM) を使用する予定がある場合は、HSM ベンダーの指示に従ってインストールおよび構成を行います。
既定のインストール設定を変更する場合は、適切な CAPolicy.inf を作成します。
PKI を計画する
組織が Active Directory 証明書サービス (AD CS) インストールのすべてを活用できるようにするため、PKI の展開を適切に計画する必要があります。 CA をインストールする前には必ず、いくつの CA をインストールし、どのように構成するかを決定する必要があります。 適切な PKI 設計の作成には時間がかかる場合がありますが、PKI の成功のためには重要です。
情報とリソースの詳細については、Microsoft TechNet の「PKI Design Guidance (公開キー設計ガイダンス)」を参照してください。
HSM を使用する
ハードウェア セキュリティ モジュール (HSM) を使用することで、CA および PKI のセキュリティを強化することができます。
HSM はオペレーティング システムとは別に管理される専用のハードウェア デバイスです。 このモジュールは、署名および暗号化の処理を高速化するための専用暗号化プロセッサだけでなく、CA キーのためのセキュリティで保護されたハードウェア ストアも提供します。 オペレーティング システムは CryptoAPI インターフェイスおよび HSM の機能を使用して、HSM を暗号化サービス プロバイダー (CSP) デバイスとして利用します。
HSM は通常 PCI アダプターですが、ネットワークベースのアプライアンス、シリアル デバイス、および USB デバイスでも入手することができます。 組織で 2 つ以上の CA を実装する予定がある場合は、単一のネットワークベース HSM をインストールして複数の CA 間で共有することができます。
HSM を使用して CA を設定するには、HSM をインストールして構成した後に HSM に格納されているキーを使用して CA を設定する必要があります。
CAPolicy.inf ファイルを考慮する
CAPolicy.inf ファイルは AD CS のインストールには必要ありませんが、CA の設定のカスタマイズに使用することができます。 CAPolicy.inf ファイルには CA のインストールまたは CA 証明書の更新で使用されるさまざまな設定が含まれています。 CAPolicy.inf ファイルを使用するには、作成して %systemroot% ディレクトリ (通常は C:\Windows) に格納する必要があります。
CAPolicy.inf ファイルに含む設定は、作成する展開の種類によって大きく異なります。 たとえば、ルート CA には次のような CAPolicy.inf ファイルが含まれる場合があります。
[Version]
Signature= "$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
LoadDefaultTemplates=0
一方、CA を発行するエンタープライズの CAPolicy.inf ファイルは次のようになります。
[Version]
Signature= "$Windows NT$"
[PolicyStatementExtension]
Policies = LegalPolicy, LimitedUsePolicy
[LegalPolicy]
OID = 1.1.1.1.1.1.1.1.1
URL = "https://www.contoso.com/pki/Policy/USLegalPolicy.asp"
URL = "ftp://ftp.contoso.com/pki/Policy/USLegalPolicy.txt"
[LimitedUsePolicy]
OID = 2.2.2.2.2.2.2.2.2
URL = "https://www.contoso.com/pki/Policy/USLimitedUsePolicy.asp"
URL = "ftp://ftp.contoso.com/pki/Policy/USLimitedUsePolicy.txt"
LoadDefaultTemplates=0
注意
- 例 CAPolicy.inf に表示された OID はあくまでも例です。 各組織は独自の OID を取得する必要があります。 OID の詳細については、「Obtaining a Root OID from an ISO Name Registration Authority (ISO 名前登録機関からのルート OID の取得)」を参照してください。
- 詳細については、「CAPolicy.inf Syntax (CAPolicy.inf 構文)」を参照してください。
CA 構成設定を選択する
次のセクションでは CA バイナリ インストール ファイルのインストール後に選択できる構成オプションについて説明します。
設定の種類を選択する
エンタープライズ CA は Active Directory ドメイン サービス (AD DS) に統合されています。 証明書および証明書失効リスト (CRL) を AD DS に発行します。 エンタープライズ CA はユーザー アカウントやセキュリティ グループのような AD DS に格納された情報を使用して、証明書要求の承認または拒否を行います。 エンタープライズ CA は証明書テンプレートを使用します。 証明書が発行されると、エンタープライズ CA は証明書テンプレートの情報を使用してその証明書の種類に適した属性を持つ証明書を生成します。
自動証明書承認および自動ユーザー証明書登録を有効にする場合は、エンタープライズ CA を使用して証明書を発行します。 これらの機能は CA インフラストラクチャが Active Directory に統合されている場合にのみ使用できます。 また、スマート カードのサインインを有効にする証明書はエンタープライズ CA しか発行できません。このプロセスでは、スマート カードの証明書が Active Directory のユーザー アカウントに自動的にマップされる必要があるためです。
注意
既定では、エンタープライズ CA のインストールおよび構成を行うには、Enterprise Admins グループのメンバーである必要があります。 権限の低いドメイン管理者がエンタープライズ CA のインストールと構成を行う必要がある場合は、「エンタープライズ証明機関の委任されたインストール」を参照してください。
[スタンドアロン CA] は AD DS を必要とせず、証明書テンプレートは使用しません。 スタンドアロン CA を使用する場合は、要求された証明書の種類に関するすべての情報を証明書要求に含める必要があります。 既定では、スタンドアロン CA に送信されるすべての証明書要求は、CA 管理者に承認されるまで保留中のキューに保持されます。 証明書が要求に応じて自動的に発行されるようにスタンドアロン CA を構成できますが、これは安全性が低く、要求が認証されないため、通常はお勧めしません。
パフォーマンスの観点からは、自動発行を使用するスタンドアロン CA を使用すると、エンタープライズ CA を使用するよりも早く証明書を発行することができます。 ただし、自動発行を使用していない場合は、スタンドアロン CA を使用して大量の証明書を発行すると、通常は管理コストが高くなります。これは、管理者が証明書要求ごとに手動で確認して承認または拒否しなければならないためです。 このため、スタンドアロン CA はユーザーがユーザー アカウントを持たず、発行および管理される証明書の量が比較的少ない場合に、エクストラネットおよびインターネット上の公開キー セキュリティ アプリケーションで最も多く使用されます。
Microsoft 以外のディレクトリ サービスを使用する場合、または AD DS が使用できない場合に証明書を発行するには、スタンドアロン CA を使用する必要があります。 次の表で説明するように、組織内ではエンタープライズとスタンドアロンの両方の証明機関を使用することができます。
| オプション | エンタープライズ CA | スタンドアロン CA |
|---|---|---|
| Active Directory の証明書を発行し、Active Directory を使用して証明書要求を検証する。 | はい | いいえ |
| CA をオフラインにする。 | 非推奨 | はい |
| 証明書を自動的に発行するように CA を構成する。 | はい | 非推奨 |
| 管理者が証明書要求を手動で承認するのを許可する。 | はい | はい |
| 証明書テンプレートの使用を許可する。 | はい | いいえ |
| Active Directory への要求を認証する。 | はい | いいえ |
CA の種類を選択する
エンタープライズおよびスタンドアロンの CA をルート CA または下位 CA として構成することができます。 下位 CA はさらに中間 CA (ポリシー CA とも呼ばれる) または発行元 CA として構成することができます。
ルート CA を指定する
ルート CA は証明書階層の最上位にある CA です。 組織内のクライアントによって無条件に信頼される必要があります。 すべての証明書チェーンはルート CA で終了します。 エンタープライズとスタンドアロンのどちらの CA を使用する場合でも、ルート CA を指定する必要があります。
ルート CA は証明書階層で最上位の CA であるため、ルート CA によって発行される証明書の [サブジェクト] フィールドには証明書の [発行者] フィールドと同じ値を持ちます。 同様に、証明書チェーンは自己署名 CA に達すると終了するため、自己署名 CA はすべてルート CA です。 CA を信頼されたルート CA として指定するかどうかは、エンタープライズ レべルで、または IT 管理者個人がローカルで決定することができます。
ルート CA は証明機関信頼モデルの基礎として機能します。 サブジェクトの公開キーが、発行される証明書の [サブジェクト] フィールドに表示される ID 情報と一致することが保証されます。 異なる CA で異なる標準を使用してこの関係を検証することもできます。したがって、公開キーを検証するための機関を信頼する選択を行う前にルート信用機関のポリシーおよび手順を理解することが重要です。
ルート CA は階層内で最も重要な CA です。 ルート CA に問題があると、同じ階層内のすべての CA とそこから発行されるすべての証明書にも問題があると見なされます。 ルート CA をネットワークから遮断し、下位 CA を使用してその他の下位 CA およびエンド ユーザーに証明書を発行することで、ルート CA のセキュリティを最大化することができます。
下位 CA
ルート CA ではない CA は下位と見なされます。 階層内の最初の下位 CA は、ルート CA からその CA 証明書を取得します。 この最初の下位 CA はこのキーを使用して他の下位 CA の整合性を確認する証明書を発行します。 このように上位にある下位 CA は中間 CA と呼ばれます。 中間 CA はルート CA より下位にありますが、1 つ以上の下位 CA に対しては上位証明機関として機能します。
中間 CA は、通常ポリシーによって区別できる証明書のクラスを区別するために使用されるため。ポリシー CA と呼ばれることが多くあります。 たとえば、ポリシーによる区別には CA が提供する保証のレベルや異なるエンドエンティティの生成を区別する CA の地理的な位置が含まれます。 ポリシー CA はオンラインにもオフラインにもすることができます。
警告
ルート CA を下位 CA に変換すること (またはその逆) はできません。
秘密キーを格納する
秘密キーは CA の ID の一部であり、問題が発生しないように保護する必要があります。 多くの組織はハードウェア セキュリティ モジュール (HSM) を使用して CA の秘密キーを保護しています。 HSM を使用しない場合、秘密キーは CA のコンピューターに格納されます。 詳細については、Microsoft TechNet の「Hardware Security Module (HSM) (ハードウェア セキュリティ モジュール （HSM))」を参照してください。
オフラインの CA は安全な場所に格納し、ネットワークには接続しないでください。 CA の発行では証明書を発行する際に秘密キーを使用するため、CA の使用中はこの秘密キーにアクセスできる (オンライン) ようにする必要があります。 CA とその CA の秘密キーは常に物理的に保護する必要があります。
既存のキーを探す
インストールで使用する秘密キーが既にある場合、[既存のキー] 画面を使用してそのキーを探すことができます。 [変更] ボタンを使用して暗号化プロバイダーや、必要に応じて既存のキーを検索する CA を変更することができます。
既存の証明書を探す
CA の秘密キーを含む証明書が既にある場合、[既存の証明書] 画面を使用して探すことができます。 [インポート] ボタンを使用して [既存の証明書のインポート] ダイアログ ボックスを開き、既存の PKCS #12 ファイルを探すことができます。
暗号化オプションを選択する
証明機関 (CA) の暗号化オプションを選択すると、その CA のセキュリティ、パフォーマンス、および互換性に重要な影響が発生する場合があります。 ほとんどの CA には既定の暗号化オプションが適していますが、暗号化について深く理解しており、柔軟性が必要な管理者およびアプリケーション開発者には、カスタム オプションの実装が役立つ場合があります。 暗号化オプションは暗号化サービス プロバイダー (CSP) またはキー記憶域プロバイダー (KSP) を使用して実装することができます。
重要
CA に RSA 証明書を使用する場合は、キーの長さが 2048 ビット以上であることを確認してください。 CA に対して 1024 ビットを下回る RSA 証明書は使用しないでください。 1024 ビットを下回る RSA キーがインストールされていると、CA サービス (certsvc) は開始しません。
CSP は Windows オペレーティング システムのハードウェアおよびソフトウェアコンポーネントで、汎用的な暗号化機能を提供します。 CSP を記述することで、さまざまな暗号化および署名アルゴリズムを提供することができます。
KSP は、Windows Server 2008 R2 以降のサーバーおよび Windows Vista 以降のクライアントを実行するコンピューターに対して強力なキー保護を提供できます。
重要
プロバイダー、ハッシュ アルゴリズム、およびキーの長さを選択するときは、使用しようとしているアプリケーションとデバイスでどのような暗号化オプションがサポートされるかを慎重に検討します。 最強のセキュリティ オプションを選択するのがベスト プラクティスですが、すべてのアプリケーションとデバイスがそれをサポートできるとはかぎりません。
サポート要件が変わり、さらに強力なセキュリティ オプション (KSP への移行や強力なハッシュ アルゴリズムなど) を使用できるようになった場合は、「暗号化サービス プロバイダー (CSP) からキー記憶域プロバイダー (KSP) への証明書機関キーの移行」を参照してください。
[CA が秘密キーにアクセスするときに、管理者による操作を許可する] は通常ハードウェア セキュリティ モジュール (HSM) で使用されるオプションです。 これにより CA が秘密キーにアクセスするときに暗号化プロバイダーがユーザーを追加で認証することができます。 このオプションを使用することで、管理者はすべての暗号化操作の前にパスワードを入力しなければならないため、CA とその秘密キーが許可なく使用されるのを防ぐことができます。
ビルトイン暗号化プロバイダーは次の表の説明のとおり、特定のキーの長さとハッシュ アルゴリズムをサポートします。
| 暗号化プロバイダー | キーの長さ | ハッシュ アルゴリズム |
|---|---|---|
| Microsoft Base Cryptographic Provider v1.0 | - 512 - 1024 - 2048 - 4096 |
- SHA1 - MD2 - MD4 - MD5 |
| Microsoft Base DSS Cryptographic Provider | - 512 - 1024 |
SHA1 |
| Microsoft Base Smart Card Crypto Provider | - 1024 - 2048 - 4096 |
- SHA1 - MD2 - MD4 - MD5 |
| Microsoft Enhanced Cryptographic Provider v1.0 | - 512 - 1024 - 2048 - 4096 |
- SHA1 - MD2 - MD4 - MD5 |
| Microsoft Strong Cryptographic Provider | - 512 - 1024 - 2048 - 4096 |
- SHA1 - MD2 - MD4 - MD5 |
| RSA#Microsoft Software Key Storage Provider | - 512 - 1024 - 2048 - 4096 |
- SHA1 - SHA256 - SHA384 - SHA512 - MD2 - MD4 - MD5 |
| DSA#Microsoft Software Key Storage Provider | - 512 - 1024 - 2048 |
SHA1 |
| ECDSA_P256#Microsoft Software Key Storage Provider | 256 | - SHA1 - SHA256 - SHA384 - SHA512 |
| ECDSA_P384#Microsoft Software Key Storage Provider | 384 | - SHA1 - SHA256 - SHA384 - SHA512 |
| ECDSA_P521#Microsoft Software Key Storage Provider | 521 | - SHA1 - SHA256 - SHA384 - SHA512 |
| RSA#Microsoft Smart Card Key Storage Provider | - 1024 - 2048 - 4096 |
- SHA1 - SHA256 - SHA384 - SHA512 - MD2 - MD4 - MD5 |
| ECDSA_P256#Microsoft Smart Card Key Storage Provider | 256 | - SHA1 - SHA256 - SHA384 - SHA512 |
| ECDSA_P384#Microsoft Smart Card Key Storage Provider | 384 | - SHA1 - SHA256 - SHA384 - SHA512 |
| ECDSA_P521#Microsoft Smart Card Key Storage Provider | 521 | - SHA1 - SHA256 - SHA384 - SHA512 |
CA 名を確立する
組織の証明機関 (CA) を構成する前に、CA 命名規則を確立する必要があります。
Unicode 文字を使用した名前も作成できますが、相互運用性に不安がある場合は ANSI 文字セットを使用することをお勧めします。 たとえば、一部のタイプのルーターでは、CA 名にアンダースコアのような特殊文字が含まれていると、ネットワーク デバイス登録サービスを使用して証明書を登録できません。
重要
ラテン文字以外 (キリル文字、アラビア文字、漢字など) を使用する場合は、CA 名を 64 文字未満にする必要があります。 ラテン文字以外のみを使用する場合は、CA 名の長さを 37 文字未満にする必要があります。
Active Directory ドメイン サービス (AD DS) では、サーバーを CA として構成するときに指定する名前が CA の一般名になり、この名前が CA が発行するすべての証明書に反映されます。 このため、CA の一般名には完全修飾ドメイン名を使用しないことが重要です。 そうすることで、証明書のコピーを取得する悪意のあるユーザーが身元を特定し、CA の完全修飾ドメイン名を使用して潜在的なセキュリティの脆弱性を生み出すことができなくなります。
警告
CA 名はコンピューターの名前と同じにすることはできません (NetBIOS または DNS 名)。 また、Active Directory 証明書サービス (AD CS) がインストールされた後は、その CA により発行されるすべての証明書を無効にしないとサーバーの名前を変更できません。 CA 名に関する追加の考慮事項については、TechNet Wiki の記事How to rename a Certificate Authority (証明書機関の名前を変更する方法).
AD CS をインストールした後にサーバー名を変更するには、CA をアンインストールし、サーバーの名前を変更し、同じキーを使用して CA を再インストールして、既存の CA キーおよびデータベースを使用するようにレジストリを変更する必要があります。 ドメインの名前を変更する場合は CA を再インストールする必要はありません。ただし、名前の変更をサポートするように CA を再構成する必要があります。
証明書要求を取得する
ルート証明機関 (CA) をインストールした後、多くの組織は公開キー基盤 (KPI) にポリシー制限を実装し、証明書をエンド クライアントに発行するために少なくとも 1 つの下位 CA をインストールします。 少なくとも 1 つの下位 CA を使用することで、ルート CA を不必要な漏洩から保護することができます。 下位 CA をインストールする場合は、親 CA から証明書を取得する必要があります。
親 CA がオンラインの場合、[親 CA に証明書要求を送信する] オプションを使用して CA 名またはコンピューター名で親 CA を選択することができます。
親 CA がオフラインの場合は [ターゲット コンピューターのファイルに証明書要求を保存する] オプションを使用する必要があります。 このための手順は親 CA によって異なります。 少なくとも、親 CA は下位 CA の新しく発行された証明書を含むファイルを提供しますが、証明書のフルパスが含まれているものが望ましいです。
証明書のフルパスを含まない下位 CA の証明書を取得した場合は、インストールする新しい下位 CA が開始される際に有効な CA チェーンを構築できる必要があります。 有効な証明書パスを作成するには、次の操作を行います。
親 CA がルート CA ではない場合、コンピューターの [中間証明機関] 証明書ストアに親 CA の証明書をインストールします。
チェーンの他のすべての中間 CA の証明書をインストールします。
ルート CA の証明書を信頼されたルート証明機関ストアにインストールします。
注意
設定したばかりの下位 CA に CA 証明書をインストールする前に、この証明書を証明書ストアにインストールする必要があります。
有効期間を確認する
証明書ベースの暗号化は、公開キーの暗号化を使用してデータに対する保護および署名を行います。 時間が経つにつれて、攻撃者は公開キーで保護されたデータを取得し、そのデータから秘密キーを引き出そうとします。 十分な時間とリソースがあれば、この秘密キーに問題が発生する可能性があり、保護されたデータも事実上保護されていない状態になります。 また、証明書によって保証されている名前も、時間が経てば変更しなければならない場合があります。 証明書は名前と公開キーを結び付けているため、そのどちらかが変更されると、証明書を更新する必要があります。
すべての証明書には有効期間があります。 有効期間が終了した後は、証明書は許容できるまたは使用できる証明書と見なされなくなります。
CA は自身の有効期間を超えて有効な証明書を発行することはできません。 有効期間の半分が過ぎたら CA 証明書を更新することをお勧めします。 CA をインストールする際は、この日付を計画し、将来のタスクとして記録する必要があります。
CA データベースを選択する
多くのデータベースでは、証明機関のデータベースはハード ドライブ上のファイルにあります。 このファイル以外に、他のファイルがトランザクション ログとして機能し、変更を行う前にデータベースに行われたすべての変更を受信します。 このようなファイルは同時にアクセスされることが頻繁にあると考えられるため、データベースとトランザクション ログを別々のハード ドライブに保持するか、ストライプ ボリュームなどの高パフォーマンスのディスク構成にする方法が最適です。
証明書のデータベースおよびログ ファイルは次のレジストリに保持されます。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration
レジストリには次の値が含まれています。
DBDirectory
DBLogDirectory
DBSystemDirectory
DBTempDirectory
注意
証明書データベースおよびログファイルはインストール後に移動することができます。 詳細については、Microsoft サポート技術情報の 記事 283193 を参照してください。
CA を構成する
ルートまたは下位の CA がインストールされた後は、CA が証明書を発行する前に機関情報アクセス (AIA) および CRL 配布ポイント (CDP) の拡張機能を構成する必要があります。 AIA 拡張拡張は CA の最新の証明書の検索場所を指定します。 CDP 拡張機能は CA によって署名された最新の CRL の検索場所を指定します。 これらの拡張機能はその CA によって発行されるすべての証明書に適用されます。
この拡張機能を構成することによって、この情報が CA の発行するすべての証明書に含まれ、すべてのクライアントが使用できるようになります。 これにより、PKI クライアントで発生し、VPN 接続エラー、スマート カードのサインイン エラー、電子メール署名の確認エラーを発生させる、未確認の証明書チェーンまたは証明書失効が原因のエラーの数を最小限に減らすことができます。
CA 管理者は CRL 配布ポイントおよび CDP と AIA の証明書発行場所を追加、削除、または変更することができます。 CRL 配布ポイントの URL の変更は新しく発行された証明書にしか影響しません。 以前に発行された証明書は引き続き元の場所を参照します。CA が証明書を配布する前に参照場所を確立する必要があるのはそのためです。
CDP 拡張機能の URL を構成する際は、このガイドラインを考慮してください。
オフラインのルート CA では Delta CRL の公開を避けてください。 オフラインのルート CA で多数の証明書を取り消すことはないため、Delta CRL が必要になることはおそらくありません。
証明機関の [プロパティ拡張機能] タブの [拡張機能] タブにある既定の LDAP:/// URL と HTTP:// URL の場所を必要に応じて調整します。
HTTP インターネットまたはエクストラネットの場所にある CRL を公開して、組織外のユーザーおよびアプリケーションが証明書検証を実行できるようにします。 CDP の場所の LDAP および HTTP の URL を公開して、クライアントが CRL データを HTTP および LDAP で取得できるようにすることができます。
Windows クライアントは常に有効な CRL が取得されるまで URL の一覧を順番に取得することに注意してください。
Windows 以外のオペレーティング システムで実行されるクライアントのアクセス可能な CRL の場所を提供するには、HTTP CDP の場所を使用します。
注意
CRL と Delta CRL の詳細については、「証明書の失効を構成する」を参照してください。
Windows PowerShell と certutil は、CDP と AIA の場所の公開に役立つ変数 (前にパーセント記号 (%) が付きます) をサポートします。 CA の [プロパティ拡張機能] タブは角かっこ付きの変数をサポートしています。 次の表はインターフェイス間の変数とその意味について説明しています。
| 変数 | 拡張機能のタブ名 | 説明 |
|---|---|---|
| %1 | <ServerDNSName> | CA コンピューターの DNS 名。 DNS ドメインに接続されている場合は完全修飾ドメイン名。接続されていない場合はコンピューターのホスト名。 |
| %2 | <ServerShortName> | CA サーバーの NetBIOS 名 |
| %3 | <CaName> | CA の名前 |
| %4 | <CertificateName> | 証明書にリビジョンが追加されるたびに固有のサフィックスを追加することができます。 |
| %4 | None | 不使用 |
| %6 | <ConfigurationContainer> | Active Directory ドメイン サービス (AD DS) の構成コンテナーの場所 |
| %7 | <CATruncatedName> | 32 文字以内に切り捨てられ、末尾にハッシュが付いた CA 名 |
| %8 | <CRLNameSuffix> | CRL をファイルまたは URL の場所に公開する際にファイル名のサフィックスを挿入します。 |
| %9 | <DeltaCRLAllowed> | Delta CRL が公開されると、Delta CRL と CRL を区別するため、CRLNameSuffix 変数を別のサフィックスに置き換えます。 |
| %10 | <CDPObjectClass> | LDAP URL に公開する際に使用される、CRL 配布ポイントのオブジェクト クラス ID。 |
| %11 | <CAObjectClass> | LDAP URL に公開する際に使用される、CA のオブジェクト クラス ID。 |
AIA 拡張機能を公開する
AIA 拡張機能はクライアント コンピューターに確認の必要な証明書の検索場所を伝えます。 これにより、証明書を信頼できるかどうかをクライアントが確認できるようになります。
AIA 拡張機能は証明機関インターフェイス、Windows PowerShell、または certutil コマンドを使用して構成できます。 次の表はこの方法で AIA 拡張機能とともに使用できるオプションを示しています。
| インターフェイスのチェック ボックス名 | Windows PowerShell パラメーター | Certutil の値 |
|---|---|---|
| 発行された証明書の AIA 拡張機能に含める | -AddToCertificateAia | 2 で保護されたプロセスとして起動されました |
| オンライン証明書状態プロトコル (OCSP) 拡張機能に含める | -AddToCertificateOcsp | 32 |
AIA 拡張機能を公開するこのセクションの例は、次のシナリオを表します。
ドメイン名は corp.contoso.com です。
ドメイン内に App1 という名前の Web サーバーがあります。
App1 には CA の読み書きを可能にする PKI という名前の共有フォルダーがあります。
App1 には www の DNS CNAME および PKI という名前の共有仮想ディレクトリがあります。
AIA 情報に関してクライアント コンピューターが最初に使用すべきプロトコルは HTTP です。
AIA 情報に関してクライアント コンピューターが 2 番目に使用すべきプロトコルは LDAP です。
構成されている CA はオンライン発行 CA です。
OCSP は使用されていません。
インターフェイスを使用して AIA 拡張機能を公開する
このインターフェイスでは、前の表で説明した変数とチェック ボックス名を使用します。 インターフェイスには証明機関インターフェイスからアクセスすることができます。 コンテンツ ウィンドウで CA を右クリックして [プロパティ] をクリックし、続けて [拡張機能] をクリックします。 [拡張機能を選択してください] で、[機関情報アクセス (AIA)] をクリックします。
.jpeg "AIA プロパティ")
図 1 AIA 拡張機能メニュー
ユーザー インターフェイスに構成された場所および設定は、次のとおりです。
C:\Windows\system32\CertSrv\CertEnroll\<ServerDNSName>_<CaName><CertificateName>.crt
https://www.contoso.com/pki/\<ServerDNSName>_<CaName><CertificateName>.crt
- 発行された証明書の AIA 拡張機能に含める
file://\\App1.corp.contoso.com\pki\<ServerDNSName>_<CaName><CertificateName>.crt
ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services,CN=Services,<ConfigurationContainer><CAObjectClass>
- 発行された証明書の AIA 拡張機能に含める
Windows PowerShell を使用して AIA 拡張機能を公開する
次の Windows PowerShell コマンドを使用して、所定のシナリオの AIA 拡張機能を構成することができます。
$aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};
Add-CAAuthorityInformationAccess -AddToCertificateAia https://www.contoso.com/pki/%1_%3%4.crt
Add-CAAuthorityInformationAccess -AddToCertificateAia file://\\App1.corp.contoso.com\pki\%1_%3%4.crt
Add-CAAuthorityInformationAccess -AddToCertificateAia "ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"
注意
- Windows PowerShell を使用して AIA パスを追加した場合、既存のパスは元の場所に残ります。 例にある最初の Windows PowerShell コマンドは、既存のパスをすべて削除します。 Windows PowerShell を使用して AIA パスを削除する方法の詳細については、「Remove-CAAuthorityInformationAccess」を参照してください。
- Add-CAAuthorityInformationAccess Windows PowerShell コマンドレットではローカル パスを追加できません。 CA 証明書は自動的に %systemroot%\system32\CertSrv\CertEnroll の既定の場所に公開されます。
certutil を使用して AIA 拡張機能を公開する
次の certutil コマンドを使用して、所定のシナリオの AIA 拡張機能を構成することができます。
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:https://www.contoso.com/pki/%1_%3%4.crt\n1:file://\\App1.corp.contoso.com\pki\%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"
注意
- このパスを変更したら、CertSvc を再実行してください。CertSvc は次の Windows PowerShell コマンドを実行することで再起動できます。
restart-service certsvc certutilコマンドで、すべてのパスを引用符で囲み、一続きの文字列として入力します。 それぞれのパスは\nで区切られます。
CDP 拡張機能を公開する
CDP 拡張機能は最新の CRL の検索場所をクライアント コンピューターに伝えるため、クライアントは特定の証明書が失効していることを確認することができます。
CDP 拡張機能は証明機関インターフェイス、Windows PowerShell、または certutil コマンドを使用して構成できます。 次の表はこの方法で CDP 拡張機能とともに使用できるオプションを示しています。
| インターフェイスのチェック ボックス名 | Windows PowerShell パラメーター | Certutil の値 |
|---|---|---|
| この場所に CRL を公開する | -PublishToServer | 1 で保護されたプロセスとして起動されました |
| すべての CRL に含め、 手動で公開するときは Active Directory のどこに公開するかを指定する |
-AddToCrlCdp | 8 |
| CRL に含め、 クライアントはこれを使って Delta CRL の場所を検索する |
-AddToFreshestCrl | 4 |
| 発行された証明書の CDP 拡張機能に含める | -AddToCertificateCdp | 2 で保護されたプロセスとして起動されました |
| Delta CRL をこの場所に公開する | -PublishDeltaToServer | 64 |
| 発行された CRL の IDP 拡張機能に含める | -AddToCrlIdp | 128 |
注意
発行する配布ポイント (IDP) 拡張機能は Windows 以外のクライアントが証明書失効を確認するために使用します。 IDP 拡張機能により、サード パーティの CA を使用する際にパーティション分割された CRL を展開できるようになります。 サード パーティはパーティション分割された CRL により、各 CRL の特定の証明書タイプのみの CRL を公開できるようになります。 たとえば、エンド証明書と CA 証明書にそれぞれ別の CRL を設定することができます。 特に、次のオプションを IDP に設定することができます。
- onlyContainUserCerts。 IDP のこのオプションでは、基本制限拡張機能に CA の値を持たない証明書のみが許可されます。 証明書に基本制限拡張機能が含まれていない場合は、CA ではないと見なされます。
- onlyContainsCACerts。 IDP のこのオプションにより、CA による基本制限拡張機能を含む証明書のみが CRL に含まれるようにすることができます。
インターネット インフォメーション サービス (IIS) Web サーバーに対する Delta CRL の公開を許可している場合は、IIS 構成の system.web セクションの requestFiltering で allowDoubleEscaping=true を設定することで既定の IIS 構成を変更する必要があります。 たとえば、IIS の既定の Web サイトの PKI 仮想ディレクトリにダブル エスケープを許可する場合は、IIS サーバー上で次のコマンドを実行します。appcmd set config "Default Web Site/pki" -section:system.webServer/security/requestFiltering -allowDoubleEscaping:true 詳細については、「AD CS:Web server should allow URI containing the “+” character to enable publishing of delta CRLs (Delta CRL の発行を有効にするには “+” 文字が含まれる URI を Web サーバーで許可する必要があります)」を参照してください。
CDP 拡張機能を公開するこのセクションの例は、次のシナリオを示します。
ドメイン名は corp.contoso.com です。
ドメイン内に App1 という名前の Web サーバーがあります。
App1 には CA の読み書きを可能にする PKI という名前の共有フォルダーがあります。
App1 には www の DNS CNAME および PKI という名前の共有仮想ディレクトリがあります。
CDP 情報に関してクライアント コンピューターが最初に使用すべきプロトコルは HTTP です。
CDP 情報に関してクライアント コンピューターが 2 番目に使用すべきプロトコルは LDAP です。
構成されている CA はオンライン発行 CA です。
IDP は使用されていません。
インターフェイスを使用して CDP 拡張機能を公開する
このインターフェイスでは前の表で説明した変数およびチェック ボックス名を使用します。 インターフェイスには証明機関インターフェイスからアクセスすることができます。 コンテンツ ウィンドウで CA を右クリックして [プロパティ] をクリックし、続けて [拡張機能] をクリックします。 [拡張機能を選択してください] で、[CRL 配布ポイント (CDP)] をクリックします。
.jpeg "CDP プロパティ")
図 2 CDP 拡張機能メニュー
インターフェイスに構成された場所および設定は、次のとおりです。
C:\Windows\System32\CertSrv\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
この場所に CRL を公開する
Delta CRL をこの場所に公開する
https://www.contoso.com/pki/\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
CRL に含め、 クライアントはこれを使って Delta CRL の場所を検索する
発行された証明書の CDP 拡張機能に含める
file://\\App1.corp.contoso.com\pki\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
この場所に CRL を公開する
Delta CRL をこの場所に公開する
ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>
すべての CRL に含め、 手動で公開するときは Active Directory のどこに公開するかを指定する
証明書の CDP 拡張機能に含める
Windows PowerShell を使用して CDP 拡張機能を公開する
次の Windows PowerShell コマンドを使用して、所定のシナリオの CDP 拡張機能を構成することができます。
$crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};
Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl -PublishToServer -PublishDeltaToServer
Add-CACRLDistributionPoint -Uri https://www.contoso.com/pki/%3%8%9.crl -AddToCertificateCDP -AddToFreshestCrl
Add-CACRLDistributionPoint -Uri file://\\App1.corp.contoso.com\pki\%3%8%9.crl -PublishToServer -PublishDeltaToServer
Add-CACRLDistributionPoint -Uri "ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10" -AddToCrlCdp -AddToCertificateCdp
注意
Windows PowerShell を使用して CDP パスを追加した場合、既存のパスは元の場所に残ります。 例にある最初の Windows PowerShell コマンドは、既存のパスをすべて削除します。 Windows PowerShell を使用して CDP パスを削除する方法の詳細については、「Remove-CACrlDistributionPoint」を参照してください。
certutil を使用して CDP 拡張機能を公開する
次の certutil コマンドを使用して、所定のシナリオの CDP 拡張機能を構成することができます。
certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n6:https://www.contoso.com/pki/%3%8%9.crl\n65:file://\\App1.corp.contoso.com\pki\%3%8%9.crl\n10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10"
注意
- このパスを変更した後は、必ず CA サービスを再起動してください。Windows PowerShell から次のコマンドを実行すると CertSvc を再起動することができます。
restart-service certsvc certutilコマンドで、すべてのパスを一続きの文字列として引用符で囲み、それぞれのパスを\nで区切ります。
CRL を公開するには、certutil -crl を Windows PowerShell の CA 上で実行するか、管理者としてコマンド プロンプトから実行します。 CRL の構成および公開の詳細については、「証明書の失効を構成する」を参照してください。
構成を確認する
CA 構成を確認するには、Windows PowerShell またはコマンド プロンプト ウィンドウから、次のコマンドを実行します。
| コマンド | 説明 |
|---|---|
| Certutil -CAInfo | CA の名前、ロケール、オブジェクト識別子 (OID)、および CRL の状態を示します。 |
| Certutil -getreg | CA のレジストリ構成を示します。 |
| Certutil -ADCA | エンタープライズ CA の構成を確認します。 |
AIA および CDP の公開構成について確認するには、エンタープライズ PKI ビュー (PKIView.msc) のツールを使用します。 詳細については、「エンタープライズ PKI の概要」を参照してください。
証明書失効を確認するには、オンライン レスポンダーの役割サービスも使用することができます。 オンライン レスポンダーの詳細については、「Microsoft オンライン レスポンダ (OCSP レスポンダ) のインストール、構成およびトラブルシューティング」を参照してください。