証明書サービスを使用してワイヤレス LAN のセキュリティを保護する

  • [アーティクル]

第 7 章 : 公開キー基盤を実装する

最終更新日: 2005年5月24日

トピック

はじめに
証明書サービス計画用ワークシート
サーバーを構築する
PKI を使用できるように Active Directory を準備する
証明書サービスを使用できるように Windows サーバーをセキュリティで保護する
その他の Windows 構成タスク
ルート CA をインストールおよび設定する
発行 CA をインストールおよび設定する
構築後の設定
クライアントの設定
要約

はじめに

この章では、Microsoft® Windows Server™ 2003 証明書サービスに基づいた公開キー基盤 (PKI) を構築する手順を詳細に説明します。 具体的には、証明機関 (CA: certification authority) のインストール作業と設定作業、Active Directory® ディレクトリ サービスと Microsoft インターネット インフォメーション サービス (IIS: Internet Information Services) の準備作業、およびクライアント証明書ポリシーの設定作業について説明します。 このガイダンスは、証明書インフラストラクチャの作成をサポートする目的で作成されています。この証明書インフラストラクチャは、あとの章でワイヤレス LAN のセキュリティに完全に対応したソリューションを構築するために使用できます。

この章の目的は、「第 4 章 : 公開キー基盤を設計する」で説明した PKI 設計の実装手順を説明することです。PKI の概要や Microsoft 証明書サービスの具体的な実装処理については説明しません。

この章は、PKI の計画と運用に関する章 (それぞれ第 4 章と 第 11 章) の補足として利用できるように構成されています。 計画ガイドの章では、この章で使用する実装を決定する際の論理的根拠について説明されています。 運用ガイドの章では、PKI の保守を正常に行うために必要なタスクと処理について説明されています。 計画ガイドの各章をまだ読んでいない場合は、この章を読む前に読むことをお勧めします。 さらに、この章のガイダンスを使用して PKI を実装する前に、運用ガイドのサポート要件を読んで内容を理解する必要があります。

章の前提条件

ここでは、組織で PKI を実装する準備を整えるために役立つチェックリストを記載しています ("準備" とは、ビジネス上の準備ではなくロジスティックス上の準備を意味します。このソリューションを実装するためのビジネス上の理由については、計画ガイドの前半の章で説明します)。

知識の前提条件

特に PKI と Microsoft 証明書サービスの概念について詳しく知っている必要があります。 次の領域については、Windows 2000 Server または Windows Server 2003 に関する詳しい知識も必要です。

  • Microsoft Windows® オペレーティング システムのインストール。

  • Active Directory の概念 (Active Directory の構造とツール、ユーザーの操作、他の Active Directory オブジェクト、グループ ポリシーの使用など)。

  • Windows システム セキュリティ。ユーザー、グループ、監査、アクセス制御リスト (ACL) などのセキュリティの概念、セキュリティ テンプレートの使用、グループ ポリシーまたはコマンド ライン ツールを使用したセキュリティ テンプレートの適用。

  • IIS の管理。

  • Windows スクリプト ホストと Microsoft Visual Basic® Scripting Edition (VBScript) 言語に関する知識があると、提供されているスクリプトを有効に活用できますが、これは必須ではありません。

この章を読む前に、計画ガイドを読んで、ソリューションのアーキテクチャと設計を詳しく理解する必要があります。

組織の前提条件

このソリューションの実装に参加する必要がある、次のような組織の他のメンバに相談する必要があります。

  • 企業のスポンサー。

  • セキュリティおよび監査の担当者。

  • Active Directory のエンジニアリング、管理、および運用の担当者。

  • DNS (ドメイン ネーム システム)、Web サーバー、およびネットワーク エンジニアリングの担当者。

  • 管理および運用の担当者。

前提となる IT インフラストラクチャ

この章では、既存の IT インフラストラクチャについて次の事項を想定しています。

  • 展開済みの Windows 2000 または Windows Server 2003 Active Directory ドメイン インフラストラクチャが存在している。 このソリューションの証明書サービスのすべてのユーザーが、同じ Active Directory フォレスト内のドメインのメンバである。

    注 : Windows Server 2003 証明書サービスと Windows 2000 Active Directory でのインターネット認証サービス (IAS: マイクロソフトの RADIUS の実装) との併用は完全にサポートされていますが、このソリューションは、そのような構成ではテストされていません。このソリューションは、Windows 2003 Active Directory を使用する構成でのみテストされています。 ただし、ガイダンスには Windows 2000 Active Directory を使用するための手順も説明されています。 少しの変更を加えることで、このソリューションを複数のフォレスト用に展開することができますが、そのための手順はここでは説明しません。 複数のフォレストへの展開の詳細については、この章の最後にある「関連情報」の記述を参照してください。 このソリューションには、既存の PKI に統合するためのガイダンスは含まれていません。 ただし、このソリューションを既存の PKI と共に展開できないわけではありません。

  • Windows Server 2003 証明書サービスの実行に適したサーバー ハードウェアが利用できる。 このガイダンスには、推奨される構成が記載されています。

  • このソリューションを既存の PKI に統合しない。 ただし、このソリューションを既存の PKI と共に展開できないわけではありません。

  • Windows Server 2003 Standard Edition および Enterprise Edition のライセンス、インストール メディア、およびプロダクト キーが利用できる。

章の概要

次の図に、この章で説明する PKI の構築プロセスを示します。

図7.1: PKI 構築プロセスのフロー

これらの手順は、この章の構成と一致しています。それぞれの手順についての説明は次の一覧のとおりです。 それぞれの手順はインストール タスクまたは構成タスクで構成されます。 各手順にはさらに検証手順が含まれており、次の手順に進む前にすべてが機能していることを確認できます。

  • 証明書サービス計画用ワークシート。 この章で証明書サービスをインストールおよび設定するときに使用する、設定情報の一覧です。 このワークシートには、実装を開始する前に準備しておくべき情報の一覧が含まれています。

  • サーバーを構築する。 ハードウェアの選定と設定、Windows Server 2003 のインストール、および IIS などのオプション コンポーネントのインストールについて説明します。

  • PKI を使用できるように Active Directory を準備する。 PKI の展開先となる Active Directory フォレストとドメインの前提条件について説明します。また、基本的な準備処理についても説明します。 さらに、管理作業を行うセキュリティ グループとユーザーを作成する処理、および管理作業を委任するためにアクセス許可を正しく設定する処理について説明します。

  • 証明書サービスを使用できるように Windows サーバーをセキュリティで保護する。セキュリティ テンプレートの適用によるオペレーティング システム レベルでのセキュリティの実装について説明します。 使用するテンプレートは、「Windows Server 2003 セキュリティ ガイド」から入手します。 このガイドの入手方法の詳細については、このモジュールの最後にある「関連情報」を参照してください。

  • その他の Windows 構成タスク。サーバーの基本的なインストールに関する共通タスクについて説明します。

  • ルート CA をインストールおよび設定する。準備作業、ソフトウェアのインストール、および証明書サービスの設定 (例 : サーバーに対する管理役割の定義) について説明します。 また最後に、オフライン ルート CA の証明書と証明書失効リスト (CRL: certificate revocation list) を Active Directory と Web サーバーに発行する処理について説明します。

  • 発行 CA をインストールおよび設定する。 ルート CA と同様のガイダンスです。ただし、ルート CA から CA 証明書を取得する手順についても説明します。 最後の確認処理では、発行 CA から取得した証明書を登録できたかどうかを確認します。

  • 構築後の設定。 発行 CA から発行される既定の証明書タイプを設定する処理、複数のドメインから成るフォレストに対してアクセス許可を設定する処理、およびバックアップを行う処理について説明します。これらの処理は、CA を実運用環境に導入する前に実行するものです。

  • クライアントの設定。ドメイン内のすべてのユーザーとコンピュータの自動登録を有効にする処理、およびルート証明書の信頼ポリシーを設定する処理について説明します。

ページのトップへ

証明書サービス計画用ワークシート

このセクションの表では、このソリューションで使用するすべての PKI 設定パラメータを示します。 この表は、計画の決定を行う際のチェックリストとして使用してください。

表のパラメータの一部は、この章で説明されている手順に従って手動で設定します。 それ以外のパラメータは、いずれかの手順で実行するスクリプトによって設定されます。他の設定または運用タスクを完了するために、スクリプトから参照されるパラメータもあります。 このようなパラメータについては、表中に関連するスクリプトの名前が記載されています。

注 : この章で使用されているスクリプトの詳細については、付録 A およびスクリプトに付属する ToolsReadme.txt ファイルを参照してください。

ユーザー定義の構成項目

次の表に、Woodgrove Bank という架空の組織に固有なパラメータの一覧を示します。 次の表のすべての項目に対応する自社の設定を収集または決定してから、セットアップ手順を開始してください。 この章のサンプル コマンドでは、表に示す架空の値を使用します。 これらの値は、自社に適した設定値に置き換える必要があります。 置き換える必要がある部分は斜体で表記されています。

表 7.1: ユーザー定義の構成項目

構成項目 設定 関連スクリプト
Active Directory フォレストのルート ドメインの DNS 名 woodgrovebank.com  
フォレストのルートの識別名 (DN: Distinguished Name) DC=woodgrovebank,DC=com Pkiparams.vbs
ドメインの NetBIOS (ネットワーク基本入出力システム) 名 WOODGROVEBANK  
ルート CA ワークグループの NetBIOS 名 WGB-Root  
ルート CA のサーバー名 HQ-CA-01  
発行 CA のサーバー名 HQ-CA-02  
ルート CA の X.500 共通名 (CN: Common Name) WoodGrove Bank Root CA  
発行 CA の X.500 CN WoodGrove Bank Issuing CA 1  
CA 証明書と CA 失効情報の発行に使用される Web サーバーの完全修飾ホスト名 www.woodgrovebank.com Pkiparams.vbs
#### ソリューションで規定されている構成項目 ソリューション設計とは異なる設定を使用する必要がある場合以外は、この表で指定されている設定を特定のインストール用に変更する必要はありません。 ここに示す設計パラメータを変更する場合は、パラメータの変更によりテスト済みのソリューションとは異なる仕様になることを十分に理解してから行ってください。 設定の変更による影響、および値を変更する前に存在していた各設定の依存関係 (構成の手順や提供されているスクリプト) についてよく確認してください。 **表 7.2: ソリューションで規定されている構成項目**

構成項目 設定 関連スクリプト
管理役割を担うセキュリティ グループ
公開キー サービス構成コンテナの管理者。 Enterprise PKI Admins ca_setup.wsf
CRL と CA 証明書をエンタープライズ設定コンテナに発行する権限を持つ管理グループ。 Enterprise PKI Publishers ca_setup.wsf
CA を構成および維持する管理グループ。それ以外のすべての CA の役割の割り当ておよび CA 証明書の更新に関する権限もコントロールする。 CA Admins ca_setup.wsf
証明書の登録および失効化の要求を承認する管理グループ。 これは CA Officer の役割の一つです。 Certificate Managers ca_setup.wsf
CA の監査ログおよびセキュリティ ログを管理する管理グループ。 CA Auditors ca_setup.wsf
CA のバックアップを管理する管理グループ。 CA Backup Operators ca_setup.wsf
IIS の構成
CA 証明書および CRL 情報の公開に使用するインターネット インフォメーション サービス (IIS) 仮想ディレクトリ名。 pki Pkiparams.vbs
IIS 仮想ディレクトリに対応する、発行 CA 上の物理パス。 C:\CAWWWPub Pkiparams.vbs
ルート CA と発行 CA に共通するパラメータ
証明書サービス要求ファイルの格納先ドライブおよびパス。 C:\CAConfig Pkiparams.vbs
証明書サービス データベース ログの格納先ドライブおよびパス。 %windir%\System32\CertLog  
ルート CA の設定
ルート CA キーの長さ (この表の後にある「注」を参照)。 4096  
ルート CA 証明書の有効期間。 16 Pkiparams.vbs
上記の値の単位。 年 Pkiparams.vbs
ルート CA から発行された証明書の有効期間。 8 Pkiparams.vbs
上記の値の単位。 年 Pkiparams.vbs
ルート CA における CRL 発行間隔。 6 Pkiparams.vbs
上記の値の単位。 月 Pkiparams.vbs
CRL 重複期間 (新しい CRL が発行されてから古い CRL が失効するまでの期間)。 10 Pkiparams.vbs
上記の値の単位。 日 Pkiparams.vbs
ルート CA における Delta CRL 発行間隔 (0 の場合、Delta CRL は発行されない)。 0 Pkiparams.vbs
上記の値の単位。 時間  
発行 CA に関するパラメータ
証明書サービス データベースの格納先ドライブおよびパス。 D:\CertLog  
発行 CA キーの長さ。 2048  
発行 CA 証明書の有効期間。 8 Pkiparams.vbs
上記の値の単位。 年 Pkiparams.vbs
発行 CA から発行された証明書の有効期間。 4 Pkiparams.vbs
上記の値の単位。 年 Pkiparams.vbs
発行 CA における CRL 発行間隔。 7 Pkiparams.vbs
上記の値の単位。 日 Pkiparams.vbs
CRL 重複期間 (新しい CRL が発行されてから古い CRL が失効するまでの期間)。 4 Pkiparams.vbs
上記の値の単位。 日 Pkiparams.vbs
発行 CA における Delta CRL 発行間隔 (0 の場合、Delta CRL は発行されない)。 1 Pkiparams.vbs
上記の値の単位。 日 Pkiparams.vbs
Delta CRL 重複期間 (新しい Delta CRL が発行されてから古い Delta CRL が失効するまでの期間)。 1 Pkiparams.vbs
上記の値の単位。 日 Pkiparams.vbs
その他
インストール スクリプトのパス。 C:\MSSScripts  
**重要 :** 特定サイズ以上のキーを処理できない他のベンダのデバイス (ルーターなど) や古いソフトウェアに対して証明書を発行したり、使用したりする場合、キーの長さとして 4,096 ビットを使用すると、互換性の問題が発生する可能性があります。 PKI を展開する前に、ルート CA 証明書キーが 4,096 ビットである証明書を使用して、社内のアプリケーションをテストしておく必要があります。 キーの長さが問題になる場合は、ルート CA キーのサイズを 2048 ビットに減らしてください (この指定は、ルート CA のインストール時に CAPolicy.inf ファイル内で行う必要があります。「ルート CA をインストールおよび設定する」を参照してください)。 [](#mainsection)[ページのトップへ](#mainsection) ### サーバーを構築する ここでは、サーバー ハードウェアの準備とオペレーティング システムのインストールに関する、基本的な作業について説明します。 必要なサーバーは 2 台、つまり、ルート CA 用サーバーと発行 CA 用サーバーです。 **重要 :** CA の構築作業を開始する前に、「第 4 章 : 公開キー基盤を設計する」の「CA のセキュリティ管理」を参照してください。この作業は、サーバーを構築するために使用されるセキュリティ環境に影響する場合があります。 #### サーバー ハードウェアを選定して設定する 以下の項では、ルート CA 用サーバーと発行 CA 用サーバーの基本仕様について概説します。 「第 4 章 : 公開キー基盤を設計する」では、主なハードウェア選定条件について詳しく説明しています。 ##### ルート CA 用サーバーのハードウェア仕様 次の表は、一般的な Windows Server 2003 ハードウェアの推奨事項に基づいた、ルート CA に推奨されるハードウェア仕様です。 ただし、第 4 章で説明している推奨条件を満たしているが、性能不足のため現在使用していないハードウェアがある場合、新しいハードウェアを購入しないで済む可能性があります。 **表 7.3: ルート CA 用サーバーの推奨ハードウェア仕様**

項目 要件
CPU 733 MHz 以上の CPU 1 個
メモリ 256 MB
ネットワーク インターフェイス なし (または無効にする)
ディスク記憶域 integrated device electronics (IDE) 規格または small computer system interface (SCSI) 規格の redundant array of independent disks (RAID) コントローラ RAID 1 ボリューム (ドライブ C) として設定された 2 台の 18 GB ハード ディスク ドライブ (SCSI) または 2 台の 20 GB ハード ディスク ドライブ (IDE) ローカルのリムーバブル メディア ドライブ (CD-RW またはテープ) (バックアップ用) 1.44 MB のフロッピー ディスク ドライブ (データ移動用)
発行 CA 用サーバーのハードウェア仕様

発行 CA に対しても性能上の要件がありますが、発行 CA の処理量は他の多くのサーバーと比べてきわめて少ないため、その水準はかなり低くなっています。 ここでは、発行 CA 用サーバーのハードウェアの品質と信頼性の選定条件を、ルート CA 用サーバーと同じにしています。 次の表に示すように、ネットワークとディスク容量に関しては、ルート CA の仕様と若干違いがあります。

表 7.4: 発行 CA 用サーバーの推奨ハードウェア仕様

項目 要件
CPU 733 MHz 以上の CPU 1 個
メモリ 256 MB
ネットワーク インターフェイス 障害からの復旧用に 2 枚のネットワーク インターフェイス カード (NIC)
ディスク記憶域 IDE 規格または SCSI 規格の RAID コントローラ RAID 1 ボリューム (ドライブ C および D) として設定された 2 台の 18 GB ハード ディスク ドライブ (SCSI) または 2 x 20 GB ハード ディスク ドライブ (IDE) (ネットワーク上でバックアップするしくみがない場合) ローカルのリムーバブル メディア ドライブ (CD-RW またはテープ) (バックアップ用) 1.44 MB のフロッピー ディスク ドライブ (データ移動用)

重要 : この表のサーバーの仕様は、約 5,000 ユーザーを想定したものです。 より多くのユーザーがいる場合は、少なくとも 2 台目のドライブのディスク容量を 2 倍にし (1,000 ユーザーあたり約 2 GB)、搭載されているメモリを 2 倍にする必要があります。 ディスク使用量のガイドラインについては、「第 11 章 : 公開キー基盤を管理する」の「発行 CA の保存およびバックアップ要件を判定する」を参照してください。

ハードウェアを準備する

ハードウェア ベンダの推奨に従って、すべてのハードウェアを構成します。 これらの推奨事項には、最新の BIOS およびファームウェアの適用が含まれる場合もあります。

ハードウェアに付属のディスク コントローラ管理ソフトウェアを使用して、表 7.3 または表 7.4 のとおりに RAID 1 ボリュームを作成します (ルート CA の場合はディスク ボリュームを 1 個、発行 CA の場合はディスク ボリュームを 2 個作成)。

ルート CA 用サーバーを準備する

ここで説明するタスクは、ルート CA として使用するサーバーに Windows をインストールするものです。

Windows Server 2003 Standard Edition をインストールする

既に多くの組織ではサーバーのインストール プロセスが自動化されています。 ここで使用するパラメータを自動構築プロセスに含めることができる場合は、自動インストール プロセスを使用してサーバーを構築できます。

ただし、構築作業においてネットワーク接続が必要な場合は例外です。 その場合は、少なくともルート CA については、手作業で構築することを検討してください。 オフラインの CA は、セキュリティがおおむね確保されています。その大きな理由は、現在ネットワークに接続しておらず、過去にもネットワークに接続したことがない、というものです。 このため、コンピュータが今までに外部からの攻撃によって被害を受けた可能性は、きわめて小さいと言えます。なぜなら、攻撃者がオフラインの CA を攻撃するには、何らかの方法で、その CA に (ネットワーク経由ではなく) 直接的にアクセスする必要があるからです。

Windows Server 2003 をインストールするには

  1. Windows Server 2003 Standard Edition の CD-ROM を CD-ROM ドライブに挿入し、システムを起動します。 サーバーの BIOS 設定で、CD-ROM からの起動が有効になっていることを確認します。

  2. プライマリ ボリュームにパーティションを 1 つ作成し、NTFS としてフォーマットして、そのパーティションを Windows のインストール先として指定するオプションを選択します。

  3. 適切な地域設定を選択します。

  4. Windows を登録するユーザー名と会社情報を入力します。

  5. ローカル Administrator アカウント用の強力なパスワードを入力します (10 文字以上の大文字と小文字の英字、数字、および区切り記号の組み合わせ)。

  6. コンピュータ名の入力を要求されたら、「HQ-CA-01」* *などの名前を入力します (この値は、お使いのコンピュータの名前に置き換えてください)。

    重要 : ルート CA をオフラインにする場合も、この名前は社内で一意にする必要があります。

  7. ワークグループまたはドメインの選択を要求されたら、ワークグループに参加するように指定します。 ***ワークグループ名として「***WGB-Root」などの名前を入力します (この値は、社内で決めたワークグループ名に置き換えてください)。

  8. オプション コンポーネントのインストールを要求された場合、何もインストールしないでください。

    主要なセットアップ プロセスが終了すると、サーバーが再起動されます。 次の処理に進んでください。

  9. 最新の Windows Service Pack をインストールします (このガイドの執筆時点では、Windows Server 2003 は製造段階に入ったばかりだったので、Service Pack はまだ提供されていませんでした)。また、推奨されるセキュリティ更新プログラムがあれば、それもインストールします (推奨される更新プログラムを調べるには、Microsoft Baseline Security Analyzer などのツールを使用します)。 社内テストの結果必要であることが判明している、(セキュリティ関連以外の) 機能に関する他の更新プログラムがあれば、それもインストールします。

  10. この Windows のコピーをアクティベートします。 サーバーがネットワークに接続されないようにするため、アクティベートはオフラインで実行する必要があります。

ネットワークを設定する

ルート CA はネットワークに接続されていません。 ルート CA が誤ってネットワークに接続された場合にネットワーク経由でアクセスされないようにするため、[コントロール パネル] の [ネットワーク接続] を使用して、ネットワーク インターフェイスをすべて無効にする必要があります。

インストールを確認する

オペレーティング システムのインストールが正常に完了したこと、およびパラメータが意図どおりに正しく構成されていることを確認する必要があります。

現在のシステム構成を表示するには

  1. コマンド プロンプトで systeminfo プログラムを実行します。

  2. systeminfo の出力結果中の、次の項目を確認します。わかりやすくするため、出力結果の一部は省略し、"..." で示してあります。

    ホスト名: HQ-CA-01

    OS 名: Microsoft® Windows® Server 2003, Standard Edition

    ...

    OS 構成: スタンドアロン サーバー

    登録されている所有者:

    登録されている組織:

    ...

    Windows ディレクトリ: C:\WINDOWS

    システム ディレクトリ: C:\WINDOWS\System32

    起動デバイス: \Device\HarddiskVolume1

    システム ロケール:

    入力ロケール:

    タイム ゾーン:

    ...

    ドメイン:

    ログオン サーバー: <\HQ-CA-01>

    ホットフィックス: ホットフィックスがインストールされています。

    [01]: Qxxxxxx

    ...

    [nn]: Qnnnnnn

    ネットワーク カード: なし

  3. これらの設定値が予期した値と一致しない場合、[コントロール パネル] を使用してサーバーの設定を変更するか、またはインストール処理を再実行します。

発行 CA 用サーバーを準備する

ここで説明する処理は、発行 CA として使用するサーバーに Windows をインストールするものです。

Windows Server 2003 Enterprise Edition をインストールする

ルート CA 用サーバー構築プロセスと同様のプロセスを実行しますが、次の例外があります。

ルート CA の場合と異なり、発行 CA 用サーバーを構築するときは、必要に応じてネットワーク ベースの構築手法を使用できます。 その発行 CA がセキュリティ上の脅威にさらされないよう、万全の対策を講じる必要があります。 たとえば、インターネットまたは主要な社内ネットワークへのルーティングが可能な経路を持たない、他のネットワークから切り離されたネットワーク内でインストールする必要があります。 最新のセキュリティ更新プログラムをインストールするまで、システムはネットワーク経由の攻撃にさらされる可能性があります。

Windows Server 2003 Enterprise Edition をインストールするには

  1. ルート CA サーバーに Windows オペレーティング システムをインストールする手順 1 ～ 5 を実行します。ただし、Windows Server 2003 Standard Edition ではなく Enterprise Edition をインストールします。

  2. コンピュータ名の入力を要求されたら、「HQ-CA-02」* *などの名前を入力します (この値は、お使いのコンピュータの名前に置き換えてください)。

  3. ワークグループまたはドメインの選択を要求されたら、ドメインに参加するように指定します。 サーバーを参加させる Active Directory ドメイン名として「WOODGROVEBANK」などの名前を入力します (この値は、実際に CA のインストール先となるドメイン名に置き換えてください)。 コンピュータをこのドメインに参加させる承認を得たユーザーについて、その資格情報を入力するよう要求されたら、所定の欄に入力します。

    注 : マルチドメイン構成のフォレストの場合、証明書サーバーは通常、フォレストのルート ドメインにインストールされます。この選択は必須ではありませんが、このソリューションではフォレスト ルート ドメインにインストールするものと想定しています。

  4. オプションのコンポーネントはインストールしないでください。

    主要なセットアップ プロセスが終了すると、サーバーが再起動されます。 次の処理に進んでください。

  5. ルート CA の場合と同様、最新の Service Pack と必要な修正プログラムをインストールします。

  6. 2 番目のハード ディスクのボリュームにパーティションを作成し、そのパーティションのドライブ文字として D を割り当て、NTFS でフォーマットします。

  7. ドライブ D 上に D:\CertLog というフォルダを作成します。

  8. この Windows のコピーをアクティベートします。 サーバーがインターネットに対して公開されないようにするため、アクティベートはオフラインで実行する必要があります。

ネットワークを設定する

発行 CA は、論理的なネットワーク インターフェイスを 1 つ備えています (このネットワーク インターフェイスは、耐障害性を向上させるため、実際には NIC を 2 枚使用して二重化している場合があります)。 ネットワーク インターフェイスは、ネットワークに応じて、固定 IP アドレスおよびその他の IP 構成パラメータ (既定のゲートウェイや DNS の設定など) で構成されます。

また、セキュリティ上の理由から、発行 CA とインターネットの間の送受信処理をすべて阻止する必要があります。 送信だけは許可してもよいように思われるかもしれませんが、その場合でも、ウイルスなど悪意のあるソフトウェアの危険性に変わりはありません。 これら悪意のあるソフトウェアは、たとえばインターネットから追加コードをダウンロードしたり、CA の秘密キーを盗んで社外に転送する恐れがあるので、きわめて危険です。

インストールを確認する

オペレーティング システムのインストールが正常に完了したこと、およびパラメータが意図どおりに正しく構成されていることを確認する必要があります。

現在のシステム構成を表示するには

  1. コマンド プロンプトで systeminfo プログラムを実行します。

  2. systeminfo の出力結果について、次の項目を確認します (一部の項目については省略)。

    ホスト名:    <HQ-CA-02>

    OS 名:    Microsoft® Windows® Server 2003, Enterprise Edition

    ...

    OS 構成:    メンバ サーバー

    登録されている所有者:    <YourOwnerName>

    登録されている組織:    <YourOwnerOrganization>

    ...

    Windows ディレクトリ:    C:\WINDOWS

    システム ディレクトリ:    C:\WINDOWS\System32

    起動デバイス:    \Device\HarddiskVolume1

    システム ロケール:    <YourSystemLocale>

    入力ロケール:    <YourInputLocale>

    タイム ゾーン:    <YourTimeZone>

    ...

    ドメイン:    <woodgrovebank.com>

    ログオン サーバー:    <\\DomainControllerName>

    ホットフィックス:    <X> ホットフィックスがインストールされています。

    [01]: Qxxxxxx

    ...

    [nn]: Qnnnnnn

    ネットワーク カード:    1 NIC(s) インストール済みです。

    [01]:    <ModelAndVendorofNetworkCard>

    接続名: ローカル エリア接続

    DHCP が有効:    いいえ

    IP アドレス

    [01]: 10.1.1.11

  3. これらの設定値が予期した値と一致しない場合、[コントロール パネル] を使用してサーバーの設定を変更するか、またはインストール処理を再実行します。

設定スクリプトをサーバーにインストールする

構成および運用の一部を簡略化する目的で、このソリューションには多くのスクリプトおよび構成ファイルが含まれています。 これらのスクリプトおよび構成ファイルは、各 CA サーバーにインストールする必要があります。 これらのスクリプトの一部は、運用ガイドで説明している作業を実行するために必要なので、CA のインストールが完了しても削除しないでください。

各サーバーにセットアップ スクリプトをインストールするには

  1. C:\MSSScripts という名前のフォルダを作成します。

  2. 配布されたメディアからこのフォルダにスクリプトをコピーします。

インターネット インフォメーション サービスをインストールおよび設定する

ここでは、発行 CA にインターネット インフォメーション サービス (IIS) をインストールして設定する作業について説明します。 このソリューションにおける IIS の用途は、Windows 以外のクライアントに対して CA 証明書と CRL のダウンロード ポイントを用意することです。 ルート CA に IIS をインストールすることはお勧めできません。 IIS を発行 CA にインストールすることもできますが、セキュリティの観点から見れば、CA 証明書と CRL のダウンロード ポイントは、発行 CA 用サーバーとは別のサーバー上に用意するほうが安全です。 社内および社外の証明書ユーザーの中には、CRL または CA チェイン情報を取得する必要はあるが、CA に対するアクセス権限が必ずしも付与されるべきでない人が、多数存在する可能性があります。 ダウンロード ポイントが CA 上に存在する場合、このようなユーザーに対して CA へのアクセスを制限することはできません。

重要 : このソリューションでは説明をわかりやすくするため、発行 CA 用サーバーを、Web サーバーとしても、また、CA 証明書と CRL のダウンロード ポイントとしても使用しています。 ただし、実際の環境では、CA のセキュリティを向上させるため、発行 CA 用サーバーと Web サーバーを分けることをお勧めします。 ここで説明する手順は、発行 CA サーバーと発行 CA とは別のサーバーのどちらに IIS をインストールして設定する場合にも当てはまります。

IIS は、証明書サービス サーバーの Web 登録ページをホストすることもできますが、このソリューションではそのような構成は使用しません。 CA 以外のサーバーに Web 登録ページをインストールする場合は、Active Directory 内にあるこのサーバーのコンピュータ オブジェクトで、委任時に信頼されるように設定する必要があります。

インターネット インフォメーション サービスを発行 CA にインストールする

IIS をインストールするには、[コントロール パネル] の [Windows コンポーネントの追加と削除] をクリックし、Windows オプション コンポーネント マネージャを開きます。 インストールするコンポーネントを次の表に示します。 インデントは、オプション コンポーネント マネージャのウィザードに表示されるコンポーネントの階層関係を表します (たとえば [ネットワーク COM+ アクセスの有効化] は [アプリケーション サーバー] のサブコンポーネントです)。 選択しないコンポーネントは、この表には示していません。

表 7.5: インストールする必要のあるオプション コンポーネント

コンポーネント インストールの状態
アプリケーション サーバー 選択する
      ネットワーク COM+ アクセスの有効化 選択する
      インターネット インフォメーション サービス 選択する
            共通ファイル 選択する
            インターネット インフォメーション サービス マネージャ 選択する
            WWW (World Wide Web) サービス 選択する
**IIS をインストールするには** 1. コマンド プロンプトで次のコマンドを実行します。 sysocmgr /i:sysoc.inf /u:C:\\MSSScripts\\OC\_AddIIS.txt このコマンドは、オプション コンポーネント マネージャに対して、自動インストール ファイル C:\\MSSScripts\\OC\_AddIIS.txt で指定されているコンポーネント設定を使用するよう、指示するものです。 ``` [Components] complusnetwork = On iis_common = On iis_asp = On iis_inetmgr = On iis_www = On ```

注 : この設定では、iis_asp = on の行で Active Server Pages (ASP) が有効になっています。 このオプションは、ソリューションを拡張する証明書サービス Web 登録ページ ソリューションを利用できるようにする場合に必要なコンポーネントですが、このソリューションで必須というわけではありません。 Web 登録ページが不要な場合は、ASP を無効にすることを検討してください。無効にするには、iis_asp = on の行を削除してから sysocmgr.exe を実行します。 この設定は、後で必要になったときいつでも有効にすることができます。

  1. 次のコマンドを入力してオプション コンポーネント マネージャを再度実行し、インストールされているコンポーネントが表 7.5 と一致しているかどうかを確認します。

    sysocmgr /i:sysoc.inf

    [アプリケーション サーバー] のサブコンポーネントのうち、表 7.5 にないサブコンポーネントは不要なので、選択する必要はありません。

機関情報アクセス (AIA: Authority Information Access) と CRL 配布ポイント (CDP: CRL Distribution Point) を発行できるように、発行 CA 上の IIS を設定する

Hypertext Transfer Protocol (HTTP) を使用して CA 証明書 (AIA) と CRL を発行するときに使用する仮想ディレクトリを、IIS 上に作成する必要があります。

IIS 上に仮想ディレクトリを作成するには

  1. IIS サーバー (つまり発行 CA 用サーバー) にローカル管理者権限でログオンします。

  2. CA 証明書と CRL を格納するための C:\CAWWWPub フォルダを作成します。

  3. エクスプローラを使用して、このフォルダにセキュリティを設定します。適用するアクセス許可を次の表に示します。 上の 4 つは、既に存在しているはずです。

    表 7.6: 仮想ディレクトリに対するアクセス許可の設定

    ユーザーまたはグループ アクセス許可 許可または拒否
    Administrators フル コントロール 許可
    システム フル コントロール 許可
    Creator Owners フル コントロール (サブフォルダとファイルのみ) 許可
    Users 読み取り フォルダの内容の一覧表示 許可
    IIS_WPG 読み取り フォルダの内容の一覧表示 許可
    Internet Guest Account 書き込み 拒否

  4. インターネット インフォメーション サービス管理コンソールで、既定の Web サイトの下に新しい仮想ディレクトリを作成します。

    • その仮想ディレクトリに pki という名前を付けます。

    • パスとして C:\CAWWWPub を指定します。

  5. この仮想ディレクトリのアクセス許可設定において、[ASP などのスクリプトを実行する] チェック ボックスをオフにします。

  6. この仮想ディレクトリに対して匿名認証が有効になっていることを確認します。

HTTP 発行ポイントに対する DNS エイリアスを指定する

CDP と AIA をホスティングする IIS サーバー (このソリューションでは www.woodgrovebank.com) に対する汎用 DNS エイリアス (CNAME) を作成することをお勧めします。 この DNS エイリアスは、以降の項で CA に対する CDP パスと AIA パスを設定するときに使用します。 このエイリアスを使用すると、CA 証明書を再発行せずに、CA 発行ポイントを簡単に別のサーバーやネットワーク上の場所に移動することができます。

IIS のインストール結果を確認する

次の作業に進む前に、IIS の基本的な動作を確認する必要があります。 次のテストのいずれかで不具合が発生した場合、前述の IIS のインストール処理と設定処理が正しく行われたかどうかを確認する必要があります。

IIS 仮想ディレクトリの動作が正しいかどうかを確認するには

  1. ローカルの Administrators グループのメンバとして IIS サーバー (つまり発行 CA 用サーバー) にログオンし、メモ帳などのテキスト エディタを使用してファイルを新規に作成します。 次のテキストを入力します (テキストの内容は、わかりやすいものであれば何でもかまいません。HTMLタグも不要です)。 次に例を示します。

    Hello World

  2. 「IIS 上に仮想ディレクトリを作成するには」の処理で CDP 情報と AIA 情報の発行用として作成したフォルダ (C:\CAWWWPub) に、このファイルを test.htm という名前で保存します。 また、このファイルを test.asp という名前で同じフォルダに保存します。

  3. ブラウザを起動し、次の URL (Uniform Resource Locator) を入力してページを開きます。

    https://www.woodgrovebank.com/pki/test.htm

    注 : この DNS エイリアスをまだ設定していない場合、この DNS エイリアスをローカルの hosts ファイル (%systemroot%\system32\drivers\etc\hosts) に一時的に追加し、IIS サーバーの IP アドレスに対応させることができます。 また、DNS エイリアスの代わりに IIS サーバーの実際のホスト名を使用することもできます。 ただしその場合、DNS エイリアスが正しく機能しているかどうかを後で検査する必要があります。

  4. ブラウザに "Hello World" というテキスト (または手順 1 で入力した内容) が表示されることを確認します。

実行権限が無効になっているかどうかを確認するには

  1. ブラウザを起動し、次の URL を入力してページを開きます。

    https://www.woodgrovebank.com/pki/test.asp

  2. 次のエラー メッセージ (または類似したメッセージ) がブラウザに表示されます。

    The page cannot be displayed

    You have attempted to execute a CGI, ISAPI, or other executable program from a directory that does not allow programs to be executed.

    また、次のエラー コードも表示されます。

    HTTP Error 403.1 - Forbidden: Execute access is denied.

    Internet Information Services (IIS)

このサイトへの匿名アクセスが有効になっていることを確認する必要があります。 Microsoft Internet Explorer では、Web サイトに対してユーザーを認証させる処理が自動的にかつバックグラウンドで実行されるので、認証済みアクセスではなく匿名アクセスが使用されたかどうかを判断するのは困難な場合があります。 匿名アクセスが使用されたかどうかを判断する方法の 1 つは、Internet Explorer のゾーン セキュリティ設定を変更して匿名ログオンの使用を強制し、上記 2 つのテスト処理を再実行することです。 あるいは、次の処理を実行する方法もあります。この処理は、telnet.exe を使用して、認証されていないアクセスを強制的に実行するものです。 この処理では、IIS サーバー自体から Web サイトをテストするものとします。このテストは、プロキシ サーバー経由では実行できません。

匿名アクセスが有効になっているかどうかを確認するには

  1. コマンド プロンプトで telnet プログラムを実行します。

  2. telnet プロンプトで次のコマンドを入力し、入力した文字がローカルで表示されるようにします。

    set localecho

  3. 次のコマンドを入力し、前述の処理で定義した DNS エイリアスを使用して IIS に接続します。

    open www.woodgrovebank.com 80

  4. 次のテキストを入力し、test.htm ページを取得します。テキストは、大文字/小文字の区別も含めて正確に入力してください。

    GET /pki/test.htm

    注 : カーソルが画面上端に戻ります。これは、画面上に今まで表示されていたテキストが、入力したテキストによって上書きされたことを意味します。これにより、画面表示がやや乱れることがありますが、 無視してかまいません。
    誤入力した場合は、Enter キーを押し、手順 3 の open コマンドを再度入力して再接続し、GET コマンドを再度入力します。

  5. 出力結果が次のようになることを確認します。

    Hello World

    Connection to host lost.

    Press any key to continue...

  6. 「quit」と入力して telnet を終了します。

ここまでの 3 種類のテストの結果に問題がなければ、test.htm ファイルと test.asp ファイルを Web サーバー上のフォルダから削除します。

その他のオペレーティング システム コンポーネントをインストールおよび設定する

ここでは、サーバーに必要なその他のコンポーネントをインストールおよび設定する処理について説明します。 これらの処理は、ルート CA 用サーバーと発行 CA 用サーバーの両方に対して実行する必要があります。

ルート証明書更新サービスを削除する

ルート証明書更新サービスを削除する必要があります。 ルート証明書更新サービスは、既定でインストールされるオプション コンポーネントです。 CA のルート信頼が自動更新されることは、望ましくありません。 また、ルート証明書更新サービスは、インターネットにアクセスできない場合は機能せず、イベント ログにエラーを記録します。 もちろん、オフラインの CA はネットワークにアクセスしませんが、前述したように、発行 CA とインターネットとの間の送受信も阻止する必要があります。

ルート証明書更新サービスを削除するには

  • コマンド プロンプトで次のコマンドを実行します。

    sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_RemoveRootUpdate.txt

このコマンドはオプション コンポーネント マネージャに対して、C:\MSSScripts\OC_RemoveRootUpdate.txt ファイルで指定されているコンポーネント設定を使用するよう、指示するものです。

    [Components]
    rootautoupdate = Off

Service Pack とセキュリティ更新プログラムを確認する

この時点で、インストールされている Service Pack と更新プログラムを再確認する必要があります。なぜなら、IIS などのオプション コンポーネントを追加インストールしている場合があるからです。 Microsoft Baseline Security Analyzer (MBSA) などのツールを使って確認を行い、必要な更新プログラムを取得し、テストした後でサーバーにインストールします。

MBSA の使用方法については、「関連情報」に記載されているリンクを参照してください。

注 : マイクロソフトの最新のセキュリティ更新プログラム一覧を別途ダウンロードする必要があります。これは、MBSA をオフラインで実行できるようにするためです。 これについては、MBSA のリンクにある MBSA に関する文書を参照してください。

追加ソフトウェアをインストールする

ここでは、CA に必要なその他のソフトウェアをインストールする処理について説明します。

CAPICOM

CAPICOM 2.0 (現在の実際のバージョンは 2.0.0.3 です) は、このソリューションに付属しているセットアップ スクリプトと管理用スクリプトの一部を使用するときに、ルート CA と発行 CA の両方で必要となるソフトウェアです。 最新バージョンの CAPICOM の入手方法については、この章の最後の「関連情報」を参照してください。

自己解凍型の実行可能ファイルの指示に従って、CAPICOM ダイナミック リンク ライブラリ (DLL) のインストールおよび登録を行います。

Windows Server 2003 サポート ツール

Windows Server 2003 サポート ツールは、厳密に言うと必要ではありませんが、発行 CA 用サーバーにインストールしておくと便利です。 これらのツールの中には、CA 上での特定の処理に役立つものや、トラブルシューティングに役立つものがあります。 サポート ツールは、Windows インストール用 CD-ROM からインストールできます (Support\Tools フォルダにある Suptools.msi を使用)。

ページのトップへ

PKI を使用できるように Active Directory を準備する

ここでは、Windows Server 2003 証明書サービスをインストールできるように Active Directory を準備する方法について説明します。

Active Directory スキーマの準備

Active Directory ドメイン インフラストラクチャに関する基本的な要件がいくつかあります。 これらの要件は、このソリューションの導入先が Windows 2000 Active Directory 環境であるか、それとも Windows Server 2003 Active Directory 環境であるかによって異なります。後者の Windows Server 2003 Active Directory 環境は、旧バージョンからアップグレードされた環境である場合と、新規にインストールされた環境である場合があります。

すべてのバージョンの Active Directory に共通する要件

このソリューションでは、CA 用サーバーの導入先ドメインの機能レベルが Windows 2000 ネイティブ モード以上でなければなりません。 この要件が必須なのは、このソリューションで使用する Active Directory ユニバーサル グループが Windows 2000 ネイティブ モード以降に使用可能になったためです。 ドメインがこの要件を満たしていない場合は、製品ドキュメントの指示に従ってそのドメインを変更する必要があります (この章の最後にある「関連情報」を参照してください)。

注 : Active Directory の既定のドメイン機能レベルは、常に "混在" です。これは、Windows Server 2003 Active Directory ドメイン コントローラのみを使用してインストールした場合でも同様です。 作業を進める前に、機能レベルを "混在" から引き上げておく必要があります。 Microsoft Windows NT® version 4.0 ドメイン コントローラをサポートする必要があるためにドメイン レベルを混在モードから引き上げることができない場合は、ユニバーサル グループの代わりに手動でドメイン グローバル グループを作成する必要があります。

このソリューションでは、Active Directory フォレストの機能レベルが "Windows 2000" (既定値) 以上であるとします。 この機能レベルを変更する必要はありません。 詳細については、このモジュールの最後にある「関連情報」を参照してください。

Windows 2000 ドメインにインストールする

重要 : マイクロソフトでは、Windows 2000 ドメイン コントローラを使用するドメインでの Windows 2003 Server 証明書サービスのインストールと使用をサポートしますが、このソリューションは、そのようなドメインで完全にテストされていません。

このソリューションを Windows 2000 Active Directory フォレストに導入する場合、Windows Server 2003 証明書サービスが正しく動作するようにするため、ディレクトリ スキーマを更新する必要があります。 また、すべての Windows 2000 ドメイン コントローラに Windows 2000 Service Pack 3 以降が適用されている必要があります。 Service Pack を適用することにより、スキーマ更新ツールを使用できるようになり、その結果、ドメイン コントローラで Lightweight Directory Access Protocol (LDAP) 署名をサポートできるようになります。 LDAP 署名は、Windows Server 2003 を実行している CA 用サーバー、および証明書自動登録機能を使用する Windows XP クライアントにとって必要となる、セキュリティ強化機能です。

Windows Server 2003 証明書サービスの機能の多く (例: ユーザー自動登録機能、テンプレート編集機能) を利用するには、Active Directory スキーマの Windows Server 2003 バージョンが必要です。 ただし、一部または全部の DC で Windows Server 2003 を実行していなければならないというわけではありません。 Windows Server 2003 証明書サービスでは、Windows 2000 Active Directory スキーマにない特定のスキーマ拡張機能が必要である、という意味です。 ディレクトリ スキーマを更新するには、adprep.exe ツールを使用します。このツールは、Windows Server 2003 配布メディアの i386 フォルダにあります。

adprep を使用するには、Windows 2000 を実行しているドメイン コントローラに Service Pack 3 が適用されている必要があります (adprep は、Service Pack 1 といくつかの修正プログラムが適用されていれば動作しますが、このソリューションでは別の理由で SP3 が必要なので、ここでは SP3 を適用するものとします)。 adprep は、すべてのドメイン コントローラに SP3 が適用されていることを確認してから使用してください。

警告 : adprep によってディレクトリ スキーマに加えられた変更結果は、元に戻すことができません。 adprep は安全なツールですが、実行する前に関連文書にしっかり目を通しておいてください。

フォレストのスキーマ マスタであるドメイン コントローラ上で、次のコマンドを実行してください。

ADPrep /ForestPrep

このコマンドを実行するには、Schema Admins グループのメンバでなければなりません。Schema Admins グループのメンバでない場合は、適切なアクセス権限を持つ管理者に、この変更作業を代行してもらう必要があります。

adprep ツールの詳細については、この章の末尾にある「関連情報」を参照してください。

Active Directory が正しく準備されているかどうかを確認する

ドメインの機能レベルとスキーマのバージョンを確認するには、次の処理を実行します。

ドメインの機能レベルが正しいかどうかを確認するには

  1. [Active Directory ユーザーとコンピュータ] を開きます。

  2. [ドメイン] オブジェクトのプロパティを表示します。

  3. [全般] プロパティ ページの [ドメインの機能レベル] に、次のいずれかの項目が表示されています。

    • Windows 2000 ネイティブ

    • Windows Server 2003

スキーマのバージョンが正しいかどうかを確認するには

  1. コマンド プロンプトで次のコマンドを入力します。「DC=woodgrovebank,DC=com」の部分は、実際のフォレストのルートの DN に置き換えてください。

    dsquery * "cn=schema,cn=configuration, DC=woodgrovebank,DC=com" -scope base -attr objectversion

    (このコマンドは表示の都合上複数行で示していますが、実際には 1 行で入力してください)

    注 : このコマンドは、Windows Server 2003 上で実行する必要があります。 既定では、dsquery.exe を Windows XP 上または Windows 2000 上で使用することはできません。

  2. 出力結果の中で、次のように 30 以上のスキーマ バージョンが表示されます。

      objectversion

      30

Active Directory のグループとユーザー

ここでは、CA によって使用される、Active Directory のセキュリティ グループとユーザー アカウントを作成する処理について説明します。

PKI と CA の管理用グループを作成する

管理役割と管理機能を定義するには、ドメイン ユーザー アカウントとドメイン セキュリティ グループを使用します。

注 : このソリューションでは、管理役割ごとにセキュリティ グループを定義します。 これにより、CA 管理業務を委任する方法を細かく制御できます。 ただし、これらの管理役割の一部または全部が社内の実際の管理モデルに対応していない場合、これらの管理役割の使用にこだわる必要はありません。 極端な例で言えば、たとえば社内に PKI 管理者が 1 人しかおらず、その PKI 管理者が証明書サービスを全面的に管理している場合、このアカウントを CA に対するすべての役割グループに追加できます。 実際には、役割を部分的に分離するのが一般的ですが、証明書サービスのすべての役割分離機能を使用するケースもまれにあります。

ドメイン内に CA 管理用グループを作成するには

  1. Users コンテナにユーザー オブジェクトとグループ オブジェクトを作成する権限を持つアカウントを使用して、ドメイン メンバ コンピュータにログオンします。

  2. 次のコマンドを実行し、ドメインの CA 管理用グループを作成します。

    Cscript //job:CertDomainGroups C:\MSSScripts\ca_setup.wsf

このスクリプトは、表 7.7 に示すセキュリティ グループを作成するものです。 セキュリティ グループはドメインの Users コンテナ内にユニバーサル グループとして作成されるので、適切な組織単位 (OU: organizational unit) に移動することをお勧めします。 適切な OU 構造の図を後に示します。

注意 : このスクリプトが作成するセキュリティ グループには、Active Directory フォレスト内で強力な権限が割り当てられます。 これらのグループのメンバは慎重に決定する必要があります。 ここでは一部のものについて説明します。

Enterprise PKI Admins これは非常に強力な権限を持つグループです。 このグループは、Active Directory フォレスト全体の PKI を完全に制御できます。さらに、ルート CA およびエンタープライズ CA のインストールと置き換え、ルート信頼の変更、相互証明書のインストールを行うことができます。 このグループは、Enterprise Admins グループと同じように慎重に扱う必要があります。

Enterprise PKI Publishers このグループは、一見無害ですが、このグループも強力な権限を持っています。 このグループは、フォレスト全体の信頼されたルート CA と相互証明書をインストールおよび削除することができます。 Enterprise Admins よりは権限が弱くなりますが、それでも慎重に扱う必要があります。

表 7.7: グループの名前と目的

グループ名 目的
Enterprise PKI Admins 公開キー サービス構成コンテナの管理者。
Enterprise PKI Publishers CRL と CA 証明書をエンタープライズ設定コンテナに発行する権限を持っています。
CA Admins CA に関する全面的な管理権限 (例: 他の役割をどのメンバに割り当てるかを決める権限) を持っています。
Certificate Managers 証明書の発行と失効を管理します。
CA Auditors CA に関する監査データを管理します。
CA Backup Operators CA のキーとデータをバックアップおよび復元する権限を持っています。
**注 :** CA 管理者、証明書管理者、監査担当者、およびバックアップ担当者をエンタープライズ CA ごとに別々に割り当てる必要がある場合、ここで説明するように企業全体に適用されるグループを各 1 個作成するのではなく、CA ごとにそれぞれのドメイン グループを作成する必要があります。 それらのグループにはたとえば *CAName* CA Admins などの名前を付けます。 これらのほとんどのドメイン グループと同様のローカル グループが、オフライン CA 上にも作成されます。 CA 用サーバーにおけるローカルの Administrators グループも、CA を管理する上で重要な役割を担っています。 ローカルの Administrators グループは既定で Windows サーバー上に存在します。 複数のドメインから成るフォレストの場合、これらのグループを、証明書サーバーが存在するドメイン内に作成する必要があります。このガイダンスの残りの部分では、証明書サーバーが存在するドメイン内にこれらのグループが作成されていることを前提としています (これらのグループはユニバーサル グループなので、これらのグループを使用することにより、フォレスト内の任意のドメインに導入されている CA を管理できます)。 ##### PKI と CA を管理するためのテスト用ユーザーを作成する テストと事例説明を行うため、ここで示すスクリプトでは、前に作成した管理グループによって定義された各役割に対応する汎用ユーザー アカウントを作成します。 ただし、実際に使用されるアカウントがこの時点で既に存在している場合、または、そのアカウントが定義され、そのアカウントを作成できる場合は、この処理を無視して、そのアカウントを代わりに使用してください。 **CA を管理するためのテスト用ユーザー アカウントを作成するには** 1. Users コンテナにユーザー オブジェクトとグループ オブジェクトを作成する権限を持つアカウントを使用して、ドメイン メンバ コンピュータにログオンします。 2. CA を管理する個人に対するテスト用ドメイン ユーザー アカウントを作成するため、次のスクリプトを実行します。 Cscript //job:CertDomainTestAccts C:\\MSSScripts\\ca\_setup.wsf このスクリプトを実行すると、すべてのアカウントに対して乱数パスワードが設定されます (つまり、パスワードが空白のままになることはありません)。 設定されたパスワードはスクリプトの出力結果の中に表示されるので、メモしておいてください。また、自動的に設定されたこれらのパスワードを、自分で決めたパスワードに変更することもできます。 **注意 :** このように管理者間でパスワードを共有している汎用アカウントを使用した場合、監査は事実上不可能になります。 テスト環境以外の環境では必ず、個人を特定してトレースできるアカウントを使用してください。 このスクリプトを実行すると、表 8 に示すドメイン ユーザー アカウントが作成されます。 ユーザー アカウントは Users コンテナ内に作成されるので、適切な OU に移動することをお勧めします (この移動作業については後述します)。 **表 7.8: アカウントの名前と目的**

ユーザー アカウント 目的
EntPKIAdmin 公開キー サービス構成コンテナの管理者
EntPKIPub CRL と CA 証明書をエンタープライズ設定コンテナに発行する権限を持っています。
CAAdmin CA に関する全面的な管理権限 (例: 他の役割をどのメンバに割り当てるかを決める権限) を持っています。
CertManager 証明書の発行と失効を管理します。
CAAuditor CA に関する監査データを管理します。
CABackup CA のキーとデータをバックアップおよび復元する権限を持っています。
**注 :** これらのテスト用アカウントの管理役割は、きわめて複雑な設定になっています。つまり、CA の役割ごとに別々の個人 (ユーザー アカウント) が設定されています。 ただし、実際に各役割を別々の個人が実行するのでない場合、通常、役割ごとにアカウントを設定するメリットはほとんどありません。 実際の管理構造をより正確に反映できるのであれば、ある特定のアカウントを複数の役割グループに追加しても問題ありません。ある特定のアカウントをすべての役割グループに追加することさえできます。 後の「エンタープライズ CA に対する簡略化された管理モデルを作成する」を参照してください。 ##### CA 管理用グループにアカウントを追加する それぞれの CA 管理用グループに、社内の適切な管理担当者のアカウントを追加する必要があります。 これらの管理用グループと証明書サービス インフラストラクチャの管理役割との対応関係については、「第 4 章 : 公開キー基盤を設計する」の「管理役割」を参照してください。Windows Server 2003 証明書サービスの管理役割の詳細については、オンライン ヘルプの「役割ベースの管理」、または、この章の末尾にある「関連情報」を参照してください。 **注 :** テスト用ドメイン アカウントを作成した場合、これらのアカウントを、対応するセキュリティ グループのメンバとして手動で追加する必要があります。 セキュリティ上の理由により、スクリプトはこの手順を既定では実行しません。 後述のセットアップ処理では、一部のセットアップ操作を実行するときに、Enterprise PKI Admins グループ、Enterprise PKI Publishers グループ、および CA Admins グループのメンバであるアカウントを使用する必要があります。 このアプローチにより、絶対に必要な場合を除き、Enterprise Admins 権限または Domain Admins 権限を使用する必要がなくなります。 **注 :** Windows Server 2003 証明書サービス (Enterprise Edition のみ) では、強制的に厳密な役割分離を行うことができます。 つまり、(直接的に、または所属しているグループによって) 複数の役割に割り当てられているアカウントは、CA 上のすべての管理役割から外されます。 この厳密な役割分離は、Windows Server 2003 の既定の設定でもこのソリューションでも、有効になっていません。したがって、特定のユーザー アカウントを複数の管理役割に割り当てることが、社内の管理構造にとって適切であれば、そのように割り当てることができます。 ##### エンタープライズ CA に対する簡略化された管理モデルを作成する これらテスト用のアカウントと管理グループは、きわめて複雑な設定になっています。つまり、CA の役割ごとに別々の個人 (ユーザー アカウント) が設定されています。 しかし、実際の管理構造をより正確に反映できるのであれば、ある特定のアカウントを複数の役割グループに追加しても問題ありません。ある特定のアカウントをすべての役割グループに追加することさえできます。 多くの企業では、CA 管理者、監査担当者、バックアップ担当者の 3 つの役割のみが使用されます。 この 3 つの役割を表 7.9 に示します。この表では、「PKI と CA を管理するためのテスト用ユーザーを作成する」で作成したテスト用アカウントの一部を使用しています。 **表 7.9: 簡略化された管理モデルにおけるグループ割り当て**

簡略化された管理役割ユーザー アカウント ユーザー アカウントのグループ メンバシップ
CAAdmin Enterprise PKI Admins CA Admins Certificate Managers Administrators (CA のローカル管理者)
CAAuditor CA Auditors Administrators (CA のローカル管理者)
CABackup CA Backup Operators
この簡略化された管理モデルを使用した場合、CAAdmin アカウントは、エンタープライズ CA に関するすべての管理作業 (例: 証明書の承認と取り消し) を実行できます。また、Active Directory 内のすべての社内 PKI 設定情報を管理できます (これらの社内 PKI 設定情報に対するアクセス許可の設定については、後述します)。 ##### CA および証明書テンプレートの管理において推奨されるドメイン OU 構造 PKI の管理と運用に関連するグループとユーザー アカウントが数多くあります。 これらのグループおよびユーザー アカウントを OU にまとめ、管理作業を簡素化することをお勧めします。 表 7.10 は、推奨される OU 構造と 各 OU の目的を示したものです。字下げされている項目は、Certificate Services OU の子 OU です。 Enterprise PKI Admins グループに対して、Certificate Services OU 内およびすべての子コンテナ内のグループとユーザーを作成および削除する権限を、付与する必要があります。 **表 7.10: OU 構造の例**

OU 目的
Certificate Services 親 OU。
\—Certificate Services Administration CA およびエンタープライズ PKI 構成を管理する管理グループを含む。
\—Certificate Template Management 個々の証明書テンプレートを管理するためのグループを格納します。
\—Certificate Template Enrollment 同名のテンプレートに対する登録権限および自動登録権限を付与されているグループを格納します。 これらのグループの制御を適切な個人に委任することにより、テンプレート自体を使用しなくても柔軟な登録体制を実現することができます。
\—Certificate Services Test Users 一時テスト用アカウントを格納します。
これらの OU の使用方法、および各 OU に格納されるグループの詳細については、「第 11 章 : 公開キー基盤を管理する」の関連するセクションを参照してください。 **Certificate Services OU の管理階層を作成するには** 1. OU を作成する権限、およびそれらの OU 内の権限を委任する権限を持つアカウントを使用してログオンします。 新規に OU を作成した管理者は、その OU の制御を委任する権限を常に持つことができます。 2. 表 7.10 に示す OU 構造を、ドメイン内の適切な場所に作成します (ここでは、このドメインはフォレストのルート ドメインであるものとします。ただし、必ずしもフォレストのルート ドメインである必要はありません)。 3. Enterprise PKI Admins グループに対して、Certificate Services OU 内およびすべての子コンテナ内のグループを作成および削除する権限を付与します。 **注 :** この OU 構造は単なる例です。 この OU 構造を必ず採用しなければならない、というわけではありません。 #### Active Directory の Public Key Services のセキュリティ ここでは、Public Key Services コンテナの制御を PKI 管理用セキュリティ グループに委任する処理について説明します。 ##### Public Key Services コンテナに対するアクセス権限を付与する フォレスト全体に対する PKI 設定情報は、Active Directory の Configurationコンテナに保管されます。 Configuration コンテナおよびそのすべてのサブコンテナとオブジェクトを変更する権限は、既定では Enterprise Administrators セキュリティ グループにのみ付与されています。 次のような理由で Public Key Services コンテナに対するセキュリティを変更する必要があります。 - Enterprise PKI Admins グループのメンバが Enterprise Admins セキュリティ グループのメンバにならなくてもエンタープライズ CA のインストールと証明書テンプレートの設定を実行できるようにする。 - Enterprise PKI Publishers グループのメンバが Enterprise Admins セキュリティ グループのメンバにならなくても証明書失効リストと CA 証明書を発行できるようにする。 自分が Active Directory の Enterprise Admins グループのメンバでない場合、Enterprise Admins グループのメンバに対して、「Enterprise PKI Admins グループにアクセス権限を付与するには」の処理を自分の代わりに実行するよう依頼する必要があります。 **注意 :** この手順では、フォレスト全体のユーザーとコンピュータに影響する、Active Directory の非常に重要な部分を委任します。 Public Key Services コンテナの制御を委任するユーザーは慎重に決定する必要があります。 このコンテナを制御するアクセス許可を持つユーザーは、特に、信頼されたルート CA の追加と削除、エンタープライズ CA の追加と削除、およびフォレスト内のすべてのユーザーの有効な資格情報の作成を行うことができます。 **Enterprise PKI Admins グループにアクセス権限を付与するには** 1. Enterprise Admins セキュリティ グループのメンバとしてログオンします。 2. \[Active Directory サイトとサービス\] Microsoft 管理コンソール (MMC) スナップインで、**\[表示\]** メニューを使用して **\[Services\]** ノードを表示します。 PublicKey Services サブコンテナを選択し、そのプロパティを開きます。 3. **\[セキュリティ\]** プロパティ ページで、Enterprise PKI Admins セキュリティ グループを追加し、このグループに**フル コントロール**権限を付与します。 4. **詳細**ビューで、このグループの権限を編集し、**フル コントロール**権限の適用先として **\[このオブジェクトとすべての子オブジェクト\]** を選択します。 5. Services コンテナを選択し、そのプロパティを開きます。 6. **\[セキュリティ\]** プロパティ ページで、Enterprise PKI Admins セキュリティ グループを追加し、このグループに**フル コントロール**権限を付与します。 7. **詳細**ビューで、このグループの権限を編集し、**フル コントロール**権限の適用先として **\[このオブジェクトのみ\]** を選択します。 **Enterprise PKI Publishers グループにアクセス権限を付与するには** 1. Enterprise PKI Admins (または Enterprise Admins) セキュリティ グループのメンバとしてログオンします。 2. \[Active Directory サイトとサービス\] MMC スナップインで、**\[Services\]** ノードを表示し、Public Key Services の下の AIA コンテナのプロパティを開きます。 3. **\[セキュリティ\]** プロパティ ページで、Enterprise PKI Publishers セキュリティ グループを追加し、このグループに次のアクセス権限を付与します。 - 読み取り - 書き込み - すべての子オブジェクトの作成 - すべての子オブジェクトの削除 4. **詳細**ビューで、このグループの権限を編集し、これらのアクセス権限の適用先として **\[このオブジェクトとすべての子オブジェクト\]** を選択します。 5. 次のコンテナに対して手順 2 ～ 4 を再度実行します。 - Public Key Services\\CDP - Public Key Services\\Certification Authorities **注 :** 前の手順で Enterprise PKI Admins グループにアクセス権限を付与すると、このグループのメンバは Enterprise PKI Publishers グループにアクセス権限を付与できるようになります。 ##### Cert Publishers グループにアクセス権限を付与する Cert Publishers セキュリティ グループには、ドメイン内のすべてのエンタープライズ CA 用サーバーのコンピュータ アカウントが属しています。 このグループの用途は、ユーザー オブジェクト、コンピュータ オブジェクト、および「Enterprise PKI Publishers グループにアクセス権限を付与するには」の処理で述べた CDP コンテナ内のオブジェクトに対して、アクセス権限を付与することです。 CA をインストールするとき、そのコンピュータ アカウントをこのグループに追加する必要があります。 既定では、Cert Publishers グループのメンバを変更する権限を持っているのは、Domain Admins グループ、Enterprise Admins グループ、およびドメインにあらかじめ用意されている Administrators グループだけです。 Enterprise PKI Admins グループのメンバがエンタープライズ CA をインストールできるようにするには、このセキュリティ グループに対するアクセス権限を変更する必要があります。 **Cert Publishers グループのメンバを変更する権限を付与するには** 1. 発行 CA のインストール先ドメインにおける Domain Admins グループのメンバとしてログオンします。 2. \[Active Directory ユーザーとコンピュータ\] MMC スナップインを開きます。 3. MMC の **\[表示\]** メニューで、**\[詳細設定\]** が有効になっていることを確認します。 4. Cert Publishers グループを選択し、そのプロパティを表示します。既定では、このグループは Users コンテナの下にあります。 5. **\[セキュリティ\]** プロパティ ページで、**Enterprise PKI Admins** グループを**追加**し、**\[詳細\]** をクリックします。 6. 一覧で **Enterprise PKI Admins** グループを選択し、**\[編集\]** をクリックします。 7. **\[プロパティ\]** タブをクリックし、**\[適用先\]** ボックスで **\[このオブジェクトのみ\]** が選択されていることを確認します。 8. 一覧をスクロールして、**\[許可\]** 列で**メンバの書き込み**オプションのチェック ボックスをオンにします。 9. 各ダイアログ ボックスで **\[OK\]** をクリックして変更結果を保存し、すべてのダイアログ ボックスを閉じます。 10. 証明書サービス コンポーネントをインストールする前に、発行 CA 用サーバーを再起動する必要があります。 再起動すると、発行 CA 用サーバーは、そのアクセス トークンに新しく登録されたグループ メンバシップを検出できるようになります。 ##### Enterprise PKI Admins グループに復元権限を付与する エンタープライズ CA をインストールするには、インストール先ドメイン内のファイルとディレクトリを復元する権限を持っている必要があります。 証明書サービスのインストール プロセスでは、証明書テンプレートをドメインにインストールするときにこのユーザー権限が必要となります。 具体的に言うと、テンプレート上のセキュリティ記述子とその他のディレクトリ オブジェクトを結合するときに、この権限が必要になります。これにより、ドメインの PKI オブジェクトに正しいアクセス許可を設定できます。 ドメインにあらかじめ用意されている Administrators グループ、Server Operators グループ、および Backup Operators グループは、既定でこの復元権限を持っています。 このソリューションでは、Enterprise PKI Admins グループを使用して CA のインストールを実行するので、このグループにファイルとディレクトリの復元ユーザー権利を付与する必要があります。 **Enterprise PKI Admins グループに復元権限を付与するには** 1. 発行 CA のインストール先ドメインにおける Domain Admins グループのメンバとしてログオンします。 2. \[Active Directory ユーザーとコンピュータ\] MMC スナップインを開きます。 3. "Domain Controllers OU" を選択し、その OU のプロパティを開きます。 4. \[グループ ポリシー\] プロパティ ページで、**\[Default Domain Controllers Policy\]** GPO を選択し、**\[編集\]** をクリックします。 5. \[コンピュータの構成\] - \[Windows の設定\] - \[セキュリティの設定\] - \[ローカル ポリシー\] - \[ユーザー権利の割り当て\] を選択し、**\[ファイルとディレクトリの復元\]** をダブルクリックします。 6. Enterprise PKI Admins グループを一覧に追加します。 7. ダイアログ ボックスを閉じ、GPO 編集 MMC を閉じます。 **重要 :** DC 上で **\[ファイルとディレクトリの復元\]** ユーザー権利を設定するGPO が他にもある場合、**\[Default Domain Controllers Policy\]** ではなく優先度の最も高い GPO に対してこの処理を実行する必要があります。 ユーザー権利の設定は累積型ではなく、このユーザー権利が設定されている GPO のうち最後に適用される GPO (つまり、優先度の最も高い GPO) だけが有効になります。 #### 確認作業 グループ、ユーザー、および OU が正しく作成されたかどうかを確認するには、\[Active Directory ユーザーとコンピュータ\] MMC でユーザーとグループを調べます。 各ユーザーが適切なグループのメンバになっていることを確認します (テスト用ユーザーまたは実際の PKI 管理ユーザー アカウントのどちらを使用している場合も同じです)。 Public Key Services コンテナに正しいアクセス許可が設定されているかどうかを確認するには、次の処理を実行します。 なお、この処理を実行するシステムに、Windows Server 2003 サポート ツールがインストールされている必要があります。 この処理は、CA 上で実行する必要はありません。 **注 :** 次の手順では、異なるユーザー アカウントでログオンする代わりに、Runas またはエクスプローラの **\[別のユーザーとして実行\]** ショートカット メニューを使用して、必要なユーザーのコンテキストで ADSIEdit MMC を実行することができます。 **Public Key Services コンテナに対してアクセス許可が正しく設定されているかどうかを確認するには** 1. Enterprise PKI Admins グループのメンバとしてドメイン メンバ サーバー (例: 発行 CA 用サーバー) にログオンします。 2. mmc.exe を実行し、\[ADSIEdit\] スナップインを読み込みます。 3. ADSI Edit フォルダを右クリックして **\[接続の設定\]** をクリックし、**\[既知の名前付けコンテキストを選択する\]** ボックスの一覧で **\[構成\]** をクリックします。 4. Public Key Services コンテナを選択し、このコンテナを右クリックします。 次に、**\[新規\]** をポイントして **\[オブジェクト\]** をクリックします。 5. 一覧から**コンテナ**を選択し、名前 (例: 「**Test**」) を付けます。 Public Key Services コンテナ内にコンテナ オブジェクトが作成されます。 6. 手順 5 で作成したコンテナ オブジェクトを削除します。 7. Configuration コンテナ内の、Services コンテナとその子コンテナ以外の場所にコンテナ オブジェクトを作成できないことを確認します。 8. Enterprise PKI Publishers のメンバとしてログオンします。 9. ADSIEdit を読み込み、**構成**命名コンテキスト (NC) に接続します。 10. Public Key Services コンテナ内にコンテナ オブジェクトを作成できるかどうかを試します。 作成できなければ正常です。 11. AIA、CDP、Certification Authorities の各サブコンテナ内にテスト用コンテナ (コンテナ オブジェクト) を作成します。 12. 正常に作成されたことを確認したら、これらのテスト用オブジェクトを削除します。 **注意 :** 手順 11 で作成したテスト用オブジェクトだけを削除するよう、注意してください。 特に、Enterprise PKI Admins のメンバは、Public Key Servicesコンテナ全体を削除する権限をもっているので注意が必要です。 **注 :** Windows Server 2003 サポート ツールをインストールしていない場合、ADSIEdit は利用できません。 この確認処理をコマンド ラインで実行するには、組み込みユーティリティである dsadd.exe と dsrm.exe を使用します。 ただし、これらのユーティリティを使用する場合は、構文とディレクトリ オブジェクト パスを間違えないよう、十分に注意してください。 また、これらのユーティリティを実運用環境の Active Directory フォレストで使用する前に、テスト環境で十分にテストしてください。 [](#mainsection)[ページのトップへ](#mainsection) ### 証明書サービスを使用できるように Windows サーバーをセキュリティで保護する ここでは、証明書サービスのインストールに先立ち、セキュリティ ポリシーなどのセキュリティ手段を Windows Server に適用する処理について説明します。 「第 4 章 : 公開キー基盤を設計する」の「物理的なセキュリティ」も併せて参照してください。 #### ルート CA 用サーバーにセキュリティを実装する ここでは、ローカルのグループとユーザー アカウントを設定する処理、および、CA 用サーバーにセキュリティ ポリシーを適用する処理について説明します。 ##### ルート CA 上でローカルのユーザー アカウントとセキュリティ グループを作成する ルート CA はどのドメインにも属していないので、その管理役割と管理機能を定義するには、ローカルのユーザー アカウントとセキュリティ グループを使用します。 **ルート CA 用サーバー上でローカルのユーザー アカウントとグループを作成するには** 1. ルート CA 上で、次のスクリプトを実行してローカルの CA 管理用グループを作成します。 Cscript //job:CertLocalGroups C:\\MSSScripts\\ca\_setup.wsf このスクリプトは、表 11 に示すローカル グループを作成するものです。 **表 7.11: グループの名前と目的** 
<p> </p>
<table style="border:1px solid black;">
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th style="border:1px solid black;" >グループ名</th>
<th style="border:1px solid black;" >目的</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="border:1px solid black;">CA Admins</td>
<td style="border:1px solid black;">CA に関する全面的な管理権限 (例: 他の役割をどのメンバに割り当てるかを決める権限) を持っています。</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">Certificate Managers</td>
<td style="border:1px solid black;">証明書の発行と失効を管理します。</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">CA Auditors</td>
<td style="border:1px solid black;">CA に関する監査データを管理します。</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">CA Backup Operators</td>
<td style="border:1px solid black;">CA のキーとデータをバックアップおよび復元する権限を持っています。</td>
</tr>
</tbody>
</table>

  1. CA を管理するユーザー用のローカル ユーザー アカウントを作成します。 テストと事例説明を行うため、次に示すスクリプトでは、表 11 のセキュリティ グループによって定義された各役割に対応する汎用ローカル アカウントを作成します。 ただし、この時点で実際のアカウントを作成できる場合は、この手順をスキップし、 代わりにそのアカウントを作成してください。

    Cscript //job:CertLocalTestAccts C:\MSSScripts\ca_setup.wsf

    このスクリプトでは、CAPICOM が使用され、すべてのアカウントに対して擬似乱数パスワードが設定されます (つまり、パスワードが空白のままになることはありません)。 設定されたパスワードはスクリプトの出力結果の中に表示されるので、メモしておいてください。また、自動的に設定されたこれらのパスワードを、自分で決めたパスワードに変更することもできます。

    注 : このように管理者間でパスワードを共有している汎用アカウントを使用した場合、監査は事実上意味がなくなります。 セキュリティ要件の厳しい実運用環境では必ず、個人を特定してトレースできるアカウントを使用してください。

    このスクリプトは、表 7.12 に示すローカル グループを作成するものです。

    表 7.12: アカウントの名前と目的

    アカウント名 目的
    CAAdmin CA に関する全面的な管理権限 (例: 他の役割をどのメンバに割り当てるかを決める権限) を持っています。
    CertManager 証明書の発行と失効を管理します。
    CAAuditor CA に関する監査データを管理します。
    CABackup CA のキーとデータをバックアップおよび復元する権限を持っています。

注 : これらのテスト用アカウントの管理役割は、きわめて複雑な設定になっています。つまり、CA の役割ごとに別々の個人 (ユーザー アカウント) が設定されています。 ただし、実際に各役割を別々の個人が実行するのでない場合、役割ごとにアカウントを設定するメリットはほとんどありません。 実際の管理構造をより正確に反映できるのであれば、ある特定のアカウントを複数の役割グループに追加しても問題ありません。ある特定のアカウントをすべての役割グループに追加することさえできます。

  1. これらのユーザー アカウントを適切な管理セキュリティ グループに追加します。 テスト用アカウントの場合は、表 7.13 に従って追加します。自社独自のアカウントの場合は、社内で規定されている IT 役割とセキュリティ ポリシーに従って追加します。

    表 7.13: アカウント名と所属グループ

    アカウント名 グループ メンバシップ
    CAAdmin CA Admins
    CertManager Certificate Managers
    CAAuditor –CA Auditors –Administrators
    CABackup CA Backup Operators

注 : CA Admins グループのメンバは、ローカルの Administrators グループのメンバにすることもできます。 ローカルの管理権限を必要とする作業がいくつかあるので、CA Admins グループのメンバをローカルの Administrators グループにも追加すれば、これらの作業を CA Admins グループの役割に割り当てることができます。

ルート CA に対する簡略化された管理モデルを作成する

大半の企業では、「ルート CA 用サーバー上でローカルのユーザー アカウントとグループを作成するには」で示したような複雑な管理構造にする必要はありません。 中には、役割分離を行う必要がまったくない企業もあります。多くの企業では、CA 管理者、監査担当者、バックアップ担当者の 3 つの役割を使用します。 この 3 つの役割を表 7.14 に示します。この表では、「ルート CA 用サーバー上でローカルのユーザー アカウントとグループを作成するには」で作成したテスト用アカウントの一部を使用しています。

表 7.14: 簡略化された管理モデルにおけるグループ割り当て

簡略化された管理役割 グループ メンバシップ
CAAdmin CA Admins Certificate Managers Administrators
CA Auditor CA Auditors Administrators
CABackup CA Backup Operators
###### グループとアカウントを確認する グループとユーザーが正しく作成されているか、および、グループに追加されているメンバが正しいかどうかを確認するには、\[コンピュータの管理\] MMC スナップインの \[ユーザーとグループ\] ノードを調べます。 ##### システムのセキュリティ設定をルート CA サーバーに適用する 「*Windows Server 2003 セキュリティ ガイド*」(この章の最後の「関連情報」を参照してください）で定義されているエンタープライズ クライアントの証明書サービス ロールを使用して、証明サーバーを保護します。 ルート CA はドメインのメンバではないためドメイン グループ ポリシーを使用できないので、セキュリティ テンプレートおよび処理を手動で適用する必要があります。 「*Windows Server 2003 セキュリティ ガイド*」から次のセキュリティ テンプレートを入手して、ルート CA サーバーの C:\\MSSScripts フォルダにコピーします。 - Enterprise Client–Domain.inf - Enterprise Client–Member Server Baseline.inf - Enterprise Client–Certificate Services.inf 次の処理を実行してセキュリティ テンプレートをカスタマイズし、サーバーに適用します。 **セキュリティ テンプレートをカスタマイズするには** 1. ローカル Administrators のメンバとしてログオンし、Enterprise Client-Certificate Services.inf をセキュリティ テンプレート MMC にロードします。 2. ローカル ポリシー\\セキュリティ オプションで、組織のセキュリティ標準に応じて次の項目を変更します。 - アカウント : Administrator アカウント名の変更 : *NewAdminName* - アカウント : Guest アカウント名の変更 : *NewGuestName* - 対話型ログオン : ログオン時のユーザーへのメッセージのテキスト : *LegalNoticeText* - 対話型ログオン : ログオン時のユーザーへのメッセージのタイトル : *LegalNoticeTitle* **注 :** 組織の現在のポリシーに基づいて項目を定義してください。 これらの値を設定することをお勧めしますが、設定しなくてもかまいません。 3. ローカル ポリシー\\ユーザー権利の割り当てで、ローカル グループ "CA Auditors" を "**管理監査およびセキュリティ ログ**" ユーザー権限に追加します。 4. ローカル ポリシー\\ユーザー権利の割り当てで、"CA Backup Operators" を次のユーザー権限に追加します。 - ファイルとディレクトリのバックアップ - ファイルとディレクトリの復元 5. ローカル ポリシー\\ユーザー権利の割り当てで、次のローカル グループを "**ローカル ログオンを許可する**" 権限に追加します。 - Administrators - Backup Operators - CA Admins - Certificate Managers - CA Auditors - CA Backup Operators 6. システム サービス フォルダにある次のサービスのプロパティを表示し、**\[このポリシーの設定をテンプレートで定義する\]** をクリックします。 **\[OK\]** をクリックして、既定のアクセス許可を適用します。 **\[サービスのスタートアップ モード\]** の値を **\[自動\]** に設定します。 - Removable Storage - Volume Shadow Copy - MS Software Shadow Copy Provider **注 :** これらのサービスは Member Server Baseline セキュリティ テンプレートでは無効になっていますが、NTBackup.exe の実行に必要です。 7. テンプレートを選択した状態で、テンプレートの変更を保存 (**\[ファイル\]** メニューの **\[保存\]** をクリック) し、MMC を閉じます。 8. 指定された順番で次のコマンドを実行し、必要なセキュリティ テンプレートを適用します。 Secedit ツールにより、いくつかの警告が生成されたことが示されます。これらの警告は問題なく無視できます (ただし、エラーは調査する必要があります)。 secedit /configure /db %temp%\\casec.db /cfg "C:\\MSSScripts\\Enterprise Client - Domain.inf" /overwrite /log "%temp%\\Enterprise Client - Domain.log" secedit /configure /db %temp%\\casec.db /cfg "C:\\MSSScripts\\Enterprise Client–Member Server Baseline.inf" /log "%temp%\\Enterprise Client–Member Server Baseline.log" secedit /configure /db %temp%\\casec.db /cfg "C:\\MSSScripts\\Enterprise Client - Certificate Services.inf" /log "%temp%\\Enterprise Client - Certificate Services.log" これらのコマンドは表示の都合上、複数行で示していますが、1 行で入力してください。 **注 :** セキュリティ設定の詳細については、「*Windows Server 2003 セキュリティ ガイド*」を参照してください。 ###### セキュリティ設定を確認する セキュリティ設定が正しく適用されていることを確認するには、次の手順を実行します。 **ルート CA セキュリティ設定を確認するには** 1. 前述の項で作成した secedit ログを参照し、主要なエラーが記録されていないことを確認します (通常、多数の警告や小さなエラーが記録されますが、セキュリティ テンプレートの適用が失敗するようなエラーはありません)。 2. サーバーを再起動し、必要なサービスがすべて開始されていること、およびシステム イベント ログにエラーが記録されていないことを確認します。 3. 作成したテスト アカウント (または実際のアカウント) でログオンを試行します。 法的な情報を通知するテキストが表示され、ログオンできます。 #### 発行 CA サーバーでセキュリティを実装する 次の項では、サーバーへのセキュリティ ポリシーの適用について説明します。 ##### システムのセキュリティ設定を発行 CA サーバーに適用する CA サーバーは、「*Windows Server 2003 セキュリティ ガイド*」で定義されている証明書サービス ロールを使用して保護されます。 発行 CA はドメインのメンバのため、ドメインベースのグループ ポリシーを使用してセキュリティ ポリシーの設定が適用されます。 CA サーバーのコンピュータ オブジェクトを保持する適切な OU 構造およびセキュリティ設定を適用する GPO 構造を作成する必要があります。 次の 3 つの GPO を作成してください。 - Enterprise Client–Member Server Baseline - Enterprise Client–Certificate Services - Enterprise Client–Certificate Services IIS (CA に IIS がインストールされている場合にのみ必要) **注意 :** 「*Windows Server 2003 セキュリティ ガイド*」には、ドメイン ポリシー (パスワードおよびアカウントのロックアウト ポリシー) に対する推奨設定が記載されています。 これらの設定は、ドメイン内のすべてのコンピュータにより継承されます。 ドメインレベルのポリシーを修正しないで、発行 CA に推奨される設定を使用する場合は、CA の OU にリンクする次の 4 番目のGPO も作成する必要があります。 Enterprise Client–Certificate Services Account Policies 次の処理を実行して、ドメイン ポリシーのテンプレートをこの GPO にインポートします。 これらの設定は、CA 自体のローカル アカウントにのみ影響を与えます。 次の手順は、組織で OU および GPO を作成する方法の概要を示したものです。 GPO と OU の名前は単なる例です。組織でのドメイン OU と GPO の名前付け基準に従って置き換えてください。 **CA サーバーの OU および GPO を作成するには** 1. 「*Windows Server 2003 セキュリティ ガイド*」から次のセキュリティ テンプレートを入手します。 - Enterprise Client–Domain - Enterprise Client–Member Server Baseline - Enterprise Client–Certificate Services - Enterprise Client–IIS Server (CA に IIS がインストールされている場合にのみ必要) 2. ドメイン管理者、または手順 4 で説明する OU を作成する権限を持つユーザーとしてログオンします。 また、Group Policy Creator Owners のメンバである必要があります。 3. \[Active Directory ユーザーとコンピュータ\] MMC スナップインを開きます。 4. 次の OU 構造を作成します。 woodgrovebank.com (ドメイン) Member Servers      CA 5. ドメイン コンテナのプロパティを開き、**\[グループ ポリシー\]** タブで **\[新規作成\]** をクリックして新しい GPO を作成し、 「**Domain Policy**」という名前を付けます。 6. GPO を編集して、コンピュータの構成\\Windows の設定\\セキュリティの設定に移動します。 セキュリティの設定フォルダを右クリックして、**\[インポート\]** を選択します。 Enterprise Client-Domain.inf ファイルを表示して、インポートするテンプレートとして選択します。 7. GPO を閉じます。 8. 次の表に示す OU、GPO、およびセキュリティ テンプレートの組み合わせに対して、前の 3 つの手順を繰り返します。 **表 7.15: セキュリティ テンプレートおよび OU への GPO の対応付け** 
<p> </p>
<table style="border:1px solid black;">
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th style="border:1px solid black;" >OU</th>
<th style="border:1px solid black;" >GPO</th>
<th style="border:1px solid black;" >セキュリティ テンプレート</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="border:1px solid black;">Member Servers</td>
<td style="border:1px solid black;">Enterprise Client — Member Server Baseline</td>
<td style="border:1px solid black;">Enterprise Client — Member Server Baseline.inf</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">CA</td>
<td style="border:1px solid black;">Enterprise Client — Certificate Services</td>
<td style="border:1px solid black;">Enterprise Client — Certificate Services.inf</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">CA</td>
<td style="border:1px solid black;">(省略可 — 前の注を参照)
Enterprise Client — Certificate Services Account Policies</td>
<td style="border:1px solid black;">Enterprise Client — Domain.inf</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">CA</td>
<td style="border:1px solid black;">(省略可 — CA に IIS がインストールされている場合)
Enterprise Client — Certificate Services IIS</td>
<td style="border:1px solid black;">Enterprise Client — IIS Server.inf</td>
</tr>
</tbody>
</table>

注 : この章で説明しているように発行 CA に IIS をインストールすることを選択した場合、CA に対してのみ別の IIS GPO を作成する必要があります。 イントラネット IIS サーバーに IIS GPO があるかもしれませんが、CA が独占的に使用するために別の GPO を作成することを強くお勧めします。 このようにすると、IIS GPO を変更しても、CA のセキュリティは影響を受けません。また、CA GPO 管理者が引き続き CA のすべてのセキュリティ設定を管理できます。

GPO を作成してテンプレートをインポートしたあと、次の処理を実行して GPO の設定をカスタマイズし、証明書サービス コンピュータに適用してください。

Certificate Services GPO をカスタマイズして適用するには

  1. [Active Directory ユーザーとコンピュータ] で、Enterprise Client-Certificate Services GPO を編集します。 コンピュータの構成\Windows の設定\セキュリティの設定\ローカル ポリシー\セキュリティ オプションで、組織のセキュリティ標準に応じて次の項目を変更します。

    • アカウント : Administrator アカウント名の変更 : NewAdminName

    • アカウント : Guest アカウント名の変更 : NewGuestName

    • 対話型ログオン : ログオン時のユーザーへのメッセージのテキスト : LegalNoticeText

    • 対話型ログオン : ログオン時のユーザーへのメッセージのタイトル : LegalNoticeTitle

  2. ローカル ポリシー\ユーザー権利の割り当てで、"CA Auditors" ドメイン グループを "管理監査およびセキュリティ ログ" のユーザー権限に追加します。

  3. ローカル ポリシー\ユーザー権利の割り当てで、"CA Backup Operators" を次のユーザー権限に追加します。

    • ファイルとディレクトリのバックアップ

    • ファイルとディレクトリの復元

  4. ローカル ポリシー\ユーザー権利の割り当てで、次のローカルおよびドメイン グループを "ローカル ログオンを許可する" 権限に追加します。

    • (ローカル) Administrators

    • (ローカル) Backup Operators

    • (ドメイン) Enterprise PKI Admins

    • (ドメイン) Enterprise PKI Publishers

    • (ドメイン) CA Admins  

    • (ドメイン) Certificate Managers

    • (ドメイン) CA Auditors

    • (ドメイン) CA Backup Operators

  5. [ファイル システム] で、フォルダ D:\CertLog を追加します。 次の表に示す権限があることを確認します。

    表 7.16: データベース フォルダの権限

    ユーザーまたはグループ アクセス許可 許可または拒否
    Administrators フル コントロール 許可
    System フル コントロール 許可
    Backup Operators フル コントロール 許可
    CREATOR OWNER フル コントロール 許可

  6. 同じフォルダに、表 7.17 に示す Everyone グループに対する監査エントリを追加します ([セキュリティ] ダイアログ ボックスの [詳細設定] ボタンをクリックし、[監査] タブをクリック)。 ユーザー名またはグループ名を要求するメッセージが表示されたら、「Everyone」と入力します。 Everyone グループを追加すると、[D:\CertLog の監査エントリ] ダイアログ ボックスが表示されます。このダイアログ ボックスに、詳細な監査の設定を入力することができます。 [適用先] フィールドで [このフォルダ、サブフォルダおよびファイル] がオンになっていることを確認します。 次の表で [はい] と示す項目をすべてチェックしてください。

    表 7.17: データベース フォルダの監査

    アクセス許可 成功 Failed
    フル コントロール   はい
    フォルダのスキャンとファイルの実行   はい
    フォルダの一覧とデータの読み取り   はい
    属性の読み取り   はい
    拡張属性の読み取り   はい
    ファイルの作成とデータの書き込み はい はい
    フォルダの作成とデータの追加 はい はい
    属性の書き込み はい はい
    拡張属性の書き込み はい はい
    サブフォルダとファイルの削除 はい はい
    削除 はい はい
    アクセス許可の読み取り   はい
    アクセス許可の変更 はい はい
    所有権の取得 はい はい

  7. システム サービス フォルダで次のサービスのプロパティを開き、[このポリシーの設定をテンプレートで定義する] をオンにします。 [OK] をクリックして、既定のアクセス許可を適用します。 [サービスのスタートアップ モード] の値を [自動] に設定します。

    • Removable Storage

    • Volume Shadow Copy

    • MS Software Shadow Copy Provider

    • Task Scheduler

      注 : これらのサービスは Member Server Baseline セキュリティ テンプレートでは無効になっていますが、最初の 3 つは NTBackup.exe の実行に必要です。 タスク スケジューラ サービスは、一部の操作スクリプトの実行に必要です。

  8. 発行 CA コンピュータ アカウントを証明書サービス OU に移動します。

  9. 発行 CA (CA がインストールされているサーバー) で、次のコマンドを実行して GPO 設定をコンピュータに適用します。

    gpupdate

    注 : これらのセキュリティ設定の詳細については、「Windows Server 2003 セキュリティ ガイド」を参照してください。

セキュリティ設定を確認する

セキュリティ設定が正しく適用されていることを確認するには、次の手順を実行します。

ルート CA セキュリティ設定を確認するには

  1. アプリケーション イベント ログで SceCli ソースからのイベントを確認します。 gpupdate コマンドの後にイベント ID 1704 が出力されていることを確認します。 イベントのテキストは次のとおりです。

    グループ ポリシー オブジェクトのセキュリティ ポリシーは正しく適用されました。

  2. サーバーを再起動し、必要なサービスがすべて開始されていること、およびシステム イベント ログにエラーが記録されていないことを確認します。

  3. 作成したテスト アカウント (または実際のアカウント) でログオンを試行します。 法的な情報を通知するテキストが表示され、ログオンできます。

発行 CA のターミナル サービス セキュリティを設定する

発行 CA の Terminal Services を無効にする必要があります。アタッカーが CA 集中的にアタックし、サーバーを保護している物理的なセキュリティ対策の効果を大幅に減少させるためです。 このサービスを有効にする必要がある場合 (リモート管理目的の場合) は、次の表に示す設定を行います。

注 : ネットワークに接続されていないため、ルート CA の Terminal Services の状態は関係ありません。

これらの設定は、オンライン CA に適用する Certificate Services Security GPO または他の GPO で行う必要があります。

表 7.18: コンピュータの構成\管理用テンプレート\Windows コンポーネント\ターミナル サービス構成の設定

設定のパス ポリシー 設定
  コンソール セッションにログインしている管理者のログオフを拒否する 有効
  ローカルの管理者によるアクセス許可のカスタマイズを許可しない 有効
  ターミナル サービス ユーザー セッションのリモート制御のルールを設定する リモート制御を許可しない
クライアント\サーバー データ リダイレクト タイム ゾーン リダイレクトを許可する 無効
  クリップボードのリダイレクトを許可しない 有効
  オーディオのリダイレクトを許可する 無効
  COM ポートのリダイレクトを許可しない 有効
  クライアント プリンタのリダイレクトを許可しない 有効
  LPT ポートのリダイレクトを許可しない 有効
  ドライブのリダイレクトを許可しない 有効
  クライアントの通常使うプリンタをセッションで通常使うプリンタに設定しない 有効
暗号化とセキュリティ クライアントが接続するたびにパスワードを要求する 有効
  クライアント接続の暗号化レベルを設定する 高
暗号化とセキュリティ\RPC セキュリティ セキュリティで保護されたサーバー (セキュリティが必要) 有効
セッション 切断されたセッションの制限時間を設定する 10 分
  オリジナルのクライアントからの再接続のみを許可する 有効
CA にアクセスするターミナル サービスを必要とするドメイン アカウントまたはセキュリティ グループはすべて、ローカル Remote Desktop Users グループに追加する必要があります (すでにローカル Administrators グループのメンバである場合を除く)。 [](#mainsection)[ページのトップへ](#mainsection) ### その他の Windows 構成タスク 組織のインフラストラクチャと標準に応じて、発行およびルート CA の両方で実行することが必要なその他の構成タスクがほぼ確実にあります。 これらのタスクは次のとおりです。 - バックアップの有効化 (第 11 章を参照) またはバックアップ エージェントのインストール - SNMP (Simple Network Management Protocol) または Windows Management Instrumentation (WMI) オプションの構成 - Microsoft Operations Manager (MOM) などの管理エージェントまたは Microsoft Systems Management Server (SMS) クライアント コンポーネントのインストール - アンチウイルス ソフトウェアをインストールする。 - 侵入検知エージェントのインストール 製品と一緒に提供されているマニュアルに従ってインストールするため、これらのアイテムを確認する必要があります。 [](#mainsection)[ページのトップへ](#mainsection) ### ルート CA をインストールおよび設定する ここでは、Certificate Services をルート CA にインストールして設定する方法について説明します。 #### ルート CA 用の Capolicy.inf ファイルを準備する Capolicy.inf ファイルを作成してから、Windows Server 2003 ルート証明機関を設定します。 このファイルにより、自己署名されたルート CA 証明書の特性が指定されます。指定される特性は、キーの長さ、証明書の有効期限、CRL と AIA の発行場所、証明書ポリシー、および既に作成されていた certificate practices statement (CPS) です。 **注 :** CPS およびCPS の作成を検討する必要があるかどうかについての詳細な説明は、「第 4 章 : 公開キー基盤を設計する」の「Certificate Practices Statements (CPS) を作成する」を参照してください。 CPS は法律文書であり、技術的なアイテムではないので、必要かどうかを確認してから、CA で設定する必要があります。 CRL と AIA の情報はルート CA 証明書では必要ないため、"CRLDistributionPoint" および "AuthorityInformationAccess" パラメータを CApolicy.inf ファイルで "**Empty**" に設定します。 **CAPolicy.inf ファイルを作成するには** 1. メモ帳などのテキスト エディタで次のテキストを記述します。 
    [Version]
Signature= "$Windows NT$"

[Certsrv_Server]
RenewalKeyLength=4096 
RenewalValidityPeriod=Years 
RenewalValidityPeriodUnits=16

[CRLDistributionPoint]
Empty=true

[AuthorityInformationAccess]
Empty=true

注意 : キーの長さを 4,096 ビットに設定すると、互換性の問題が発生する可能性があります。 特定のデバイス (ルーターなど) や他のベンダの古いソフトウェアの一部は、特定のサイズ以上のキーを処理できません。

  1. この CA に対して定義される CPS がある場合、次の記述を Capolicy.inf ファイルに書き込みます (二重引用符で囲まれた部分に使用している値を代入する必要があります)。
 [CAPolicy]
Policies=WoodGrove Bank Root CA CPS

[WoodGrove Bank Root CA CPS]
OID=your.Orgs.OID
URL = "https://www.woodgrovebank.com/YourCPSPage.htm"
  1. "%windir%"\Capolicy.inf としてファイルを保存します (Windows がインストールされたフォルダの絶対パス、C:\Windows などで "%windir%" を置き換えます)。 この処理を完了するには、ローカル管理者であるか、Windows フォルダに書き込む権限を所有している必要があります。

証明書サービスのソフトウェア コンポーネントをインストールする

CA ソフトウェア コンポーネントをインストールするには、Windows コンポーネント ウィザードを使用します。 インストールを完了するには、Windows Server 2003 インストール CD またはネットワーク パスが必要であることに注意してください。

証明書サービスをインストールするには

  1. ローカル Administrators グループのメンバとしてログオンし、オプション コンポーネント マネージャを実行します (または、[コントロール パネル]、[プログラムの追加と削除]、[Windows コンポーネントの追加と削除] の順に選択します)。

    sysocmgr /i:sysoc.inf.

  2. 証明書サービス コンポーネントを選択します ([はい] をクリックして名前の変更の警告メッセージ ボックスを閉じます)。

  3. "スタンドアロンのルート CA" として CAタイプを選択し、カスタム設定を使用するようになっていることを確認してください。

  4. [公開キーと秘密キーの組] ダイアログ ボックスで、キーの長さ以外は、4096 に設定されている既定値のままにしておきます。 "CSP の種類" は、"Microsoft Strong 暗号化サービス プロバイダ" です。

  5. 次のように情報を特定する証明機関を入力します。

    • CA の共通名 : WoodGrove Bank Root CA 

    • 識別名のサフィックス : DC=woodgrovebank,DC=com
      (組織の Active Directory フォレスト ルート名)

    • 有効期限 : 8 年

      注 : 以前にこのコンピュータに CA をインストールした場合、前のインストール時の秘密キーを上書きしてもよいかどうかを確認する警告ダイアログ ボックスが表示されます。 再度キーを使用しないことを確認してから、次に進みます。 問題がある場合には、インストール処理をキャンセルして、既存のキー情報をバックアップします (このバックアップ処理は、システムのバックアップ、または既存の CA 証明書と秘密キーのバックアップを使用します。詳細については、「第 11 章 : 公開キー基盤を管理する」を参照してください)。

    CSP によりキー ペアが生成され、ローカル コンピュータのキー ストアに書き込まれます。

  6. 証明書データベース、データベース ログ、および構成フォルダの場所を既定値のままにします。

    注 : 
    すべてのネットワーク インターフェイスが無効になっているため、設定処理中に、共有フォルダを作成できないという警告メッセージが表示される場合があります。 これを無視して先へ進んでも安全です。
    証明書データベースおよび証明書データベースのログオン ローカル NTFS ドライブを設置してください。

    次に、オプション コンポーネント マネージャにより証明書サービスのコンポーネントがインストールされます。 この処理には、Windows Server 2003 インストール メディア (CD) が必要です。

  7. [OK] をクリックして、IIS に関する警告を閉じ、インストールを続行します。

ルート CA のインストールを確認する

次のように証明書サービスのインストールの正常終了を確認できます。

ルート CA の適切なインストール内容を確認するには

  1. [すべてのプログラム]、[管理ツール] の順にクリックし、証明機関管理コンソールを開きます。 証明書サービスが開始されていることと、CA のプロパティを表示できることを確認します。

  2. [一般] タブで、CA 証明書を選択 (複数の証明書がある場合は CA 証明書のリストから [証明書 #0] を選択) して、[証明書の表示] をクリックします。

  3. CA 証明書の [詳細] タブを表示して、表示されている値が次の表に示されている値と一致しているかどうかを確認します。

    表 7.19: ルート CA の証明書のプロパティと拡張機能

    証明書の属性 必要な設定
    発行者フィールドと件名フィールド 両方のフィールドが同一で、インストール時に指定した CA の共通名に DN サフィックスを追加したものが表示されている必要があります。
    前なし - 後なし 16 年
    公開キーの長さ RSA (4096 ビット)
    キー使用法 デジタル署名、証明書の署名、オフライン CRL 署名、CRL 署名 (86)
    基本制限 (重大) Subject Type=CA Path Length Constraint=None

基本制限の Subject Type が存在していることが重要です。この値により、CA 証明書とエンドエンティティ証明書が識別されます。 また、この表には CDP または AIA の拡張機能は記載されていません。

どの値も予想された値ではない場合、証明書サービスのインストールを再開する必要があります。

注 : 証明書サービスのインストールを再実行する必要がある場合、秘密キーが既に存在する旨を通知する警告が表示されます。 このキーを使用する発行証明書がないことを知っている場合には、この警告を安全に無視して、新しいキーを作成できます。 CA が既に証明書を発行したことがある場合 (テスト証明書を除く)、以前のキーと証明書を安全にバックアップするまで、証明書サービスを再インストールできません (この手順については、「第 11 章 : 公開キー基盤を管理する」を参照してください)。

  1. 証明書サービスのセットアップ ログ (%systemroot%\certocm.log) を表示して、発生したエラーの詳細確認やトラブルシューティングに役立てることができます。

ルート CA プロパティの設定

CA 設定手順により、環境に固有のパラメータが適用されます。 これらのパラメータの値は、この章の前半の「証明書サービス計画用ワークシート」に記載されています。 この処理で、次のテーブルに示されている CA プロパティを設定します。

表 7.20: 設定される CA プロパティ

CA プロパティ 設定の説明
CRL 配布ポイントのURL HTTP、LDAP、および現在の CRL を取得できるファイルの場所を指定します。 ファイルの場所はローカル フォルダで、発行 CRL を保存する CA によってのみ使用されます。発行された証明書に LDAP および HTTP の場所だけが記載されています。 HTTP の URL、LDAP が順番に並んで表示されているため、ルート CA 証明書を使用するクライアントは Active Directory に依存せずに CRL を取得できます。
AIA URL CA 証明書を取得できる場所です。 CDP と同様に、ファイルの場所は CA 証明書を公開するためにのみ使用され、HTTP の URL は LDAP の URL より優先順位が高くなります。
有効期間 発行された証明書に対する最長の有効期限 (これは、CAPolicy.inf または親 CA で設定される CA 証明書自体の有効期限とは異なります)。
CRL 期限 CRL の公開の頻度
CRL オーバーラップ タイム 新しい CRL を発行する時刻と 1 つ前の CRL がタイムアウトする時刻の間の重なっている時間
Delta CRL 期限 Delta CRL の公開頻度。ルート CA で、Delta CRL は無効です。
CA Auditors CA 監査設定。 既定ではすべての監査が有効です。
**注 :** 表に示すプロパティは、ルート CA 証明書自体ではなく、ルート CA によって発行される証明書に影響します。 **ルート CA プロパティを設定するには** 1. CA サーバーにローカル Administrators グループのメンバとしてログオンします。 2. 次のスクリプト (C:\\MSSScripts\\pkiparams.vbs) をカスタマイズして、Active Directory フォレスト ルートの適切な DN、および Web サーバーを公開する CDP と AIA をポイントする HTTP の URLを含めます。 **AD\_ROOT\_DN** 設定の値を変更し、Active Directory フォレスト ルートのドメインの DN に一致させます。 **HTTP\_PKI\_VROOT** 設定を変更し、以前設定した IIS 仮想ディレクトリに HTTP パスを一致させます。 **注 :** ここでは、pkiparams.vbs ファイルの一部のみを示します。 スクリプトを変更することによる影響について理解している場合を除いて、ファイル内の他のアイテムを編集したり、削除しないでください。 ``` '************************************************************************** ' USER SETTABLE CONSTANTS ' ' These values MUST be set to reflect actual values used ' by the organization. '************************************************************************** 
' This is the URL where CRL and CA certs are to be published.
CONST CA_HTTP_PKI_VROOT        = " https://www.woodgrovebank.com/pki"

' This needs to be set only if non Active directory clients need to query
' the ldap URL for CRLs. Normally they are OK with HTTP. If you do set this 
' (to a specific DC FQDN) ALL clients will use this DC to query. Left blank
' AD clients use their default LDAP server (local DC) to query.
CONST CA_LDAP_SERVER        = ""

' This needs to be set to the DN of the Active Directory Forest root domain
' This is used to set the Root CA CDP and AIA paths so that clients can 
' obtain CRL and CA Certificate information from the Active Directory 
CONST AD_ROOT_DN            = "DC=woodgrovebank,DC=com"
```

  1. さらに、次のスクリプトを実行します。

    Cscript //job:RootCAConfig C:\MSSScripts\ca_setup.wsf

管理者の役割を設定する

CA の管理者の役割 (監査者、証明書マネージャなど) を使用するために、以前に作成したセキュリティ グループを役割に対応付ける必要があります。

注 : この方法では、複数の別の役割を定義するために以前に作成したグループを使用します。 これにより、CA 管理の職務を委任する最大の柔軟性が得られます。 しかし、この委任レベルが必要でない場合、この章の前半で指定した単純な管理グループ モデルを使用することを検討してみてください。 この単純なモデルにより、より少ない数のアカウントを使用して CA 管理機能を実行できます。

ルート CA の管理役割を設定するには

  1. 証明機関管理コンソールで、[プロパティ] をクリックして CA のプロパティを編集します。

  2. [セキュリティ] タブをクリックして、次の表のローカル セキュリティ グループを追加します。 各グループに、表に示される権限を追加します。

    表 7.21: 追加する CA 権限のエントリ

    グループ名 アクセス許可 許可または拒否
    CA Admins CA の管理 許可
    Certificate Managers 証明書の発行と管理 許可

注 : 完全に役割を分離する場合には、ローカル Administrators グループから管理 CA 権限を削除します (ルート CA は、Windows Server の Standard Edition にインストールされるので、役割の分離を強制的に実行することはできません。このオプションは、Enterprise Edition でのみ使用できます)。

  1. この CA に対する別の CA セキュリティの役割は、以前サーバーに適用されたセキュリティ ポリシーにより既に定義されています。

    • CA Auditors には、管理セキュリティおよび監査ログのユーザー権限が与えられています。

    • バックアップ実行者は、CA のバックアップや復元を行う権限を所有しています。

ルート CA 証明書と CRL をディスクに転送する

Active Directory、IIS 証明書公開サーバー、および CRL 公開サーバーに発行できるように、CA からルート CA 証明書と CRL をコピーする必要があります。

ルート CA 証明書と CRL をディスクにコピーするには

  1. ローカル CA Admins グループのメンバとしてルート CA にログオンし、ドライブ転送用に使用するディスクを挿入します。

  2. 次のスクリプトを実行して、CA 証明書をディスクにコピーします。

    Cscript //job:GetCACerts C:\MSSScripts\CA_Operations.wsf

  3. 次のスクリプトを実行して、CA CRL をディスクにコピーします。

    Cscript //job:GetCRLs C:\MSSScripts\CA_Operations.wsf

  4. このディスクに "Transfer-[HQ-CA-01]" というラベルを付け、日時を入れて、後の処理で保存します。

    注 : ディスクにはセキュリティの影響を受けやすい情報 (CA 秘密キー マテリアルなど) が含まれていないので、その取り扱いにおいてセキュリティを保護する必要はありません。

ルート CA 情報を公開する

発行 CAをインストールする前に、ルート CA の証明書を Active Directory の信頼されたルート ストアに発行して、ルート CA の CRL を Active Directory の CDP コンテナに公開する必要があります。 これにより、すべてのドメイン メンバによりルート CA の証明書が使用しているルート ストアにインポートされるようになり、ルート CA により発行された証明書の取り消し状況が確認できるようになります (発行 CA は、それ自身の証明書の取り消し状況を確認してから証明書サービスを開始する必要があります)。

注 : Certutil.exe およびサポートする certadm.dll と certcli.dll ライブラリがシステムにインストールされていれば、任意のドメイン メンバから次の処理を実行できます。certutil.exe (必要な DLL を含む) は Windows Server 2003 の一部としてインストールされています。 設定されていない発行 CA サーバーを使用して、この処理を実行できます。

ルート CA 証明書と CRL を Active Directory に公開するには

  1. ドメイン メンバのコンピュータに "Enterprise PKI Admins" グループのメンバとしてログオンして、前にルート CA 証明書と CRL ("Transfer-[HQ-CA-01]" のラベルを付けた) を保存するために使用したディスクを挿入します。

  2. 次のスクリプトを実行して、CA 証明書を Active Directory に公開します。

    Cscript //job:PublishCertstoAD C:\MSSScripts\CA_Operations.wsf

  3. 次のスクリプトを実行して、CA CRL を Active Directory に公開します。

    Cscript //job:PublishCRLstoAD C:\MSSScripts\CA_Operations.wsf

ルート CA 証明書と CRL を Web サーバーに公開する

CDP と AIA の URL の HTTP バージョンがこの CA によって発行された証明書の拡張機能で指定されているので、この処理は必要です。 これらの拡張機能が存在する場合、証明書で設定された URL への CRL と証明書の発行を受け付ける必要があります。

注 : この処理は、CDP および AIA 公開 Web サーバーが発行 CA に存在するか別のサーバーに存在するかにかかわらずまったく同じです。 仮想ディレクトリが、IIS で C:\CAWWWPub を指定するために既に設定されたディレクトリに一致していると仮定します。 異なるパスを使用する場合、C:\MSSScripts\PKIParams.vbs ファイルの WWW_LOCAL_PUB_PATH の値を更新する必要があります。

ルート CA 証明書と CRL を Web URL に公開するには

  1. ローカル管理者として、または C:\CAWWWPub フォルダに書き込み権限を持つアカウントで Web サーバーにログオンします。

  2. CA 証明書とCRL を保存しているディスク ("Transfer-[HQ-CA-01]"のラベルが付いた) がドライブに挿入されていることを確認します。

  3. 次のスクリプトを実行して、CA 証明書を Web サーバーのフォルダに公開します。

    Cscript //job:PublishRootCertstoIIS

    C:\MSSScripts\CA_Operations.wsf

    (このコマンドは表示の都合上複数行で示していますが、実際には 1 行で入力してください)

  4. 次のスクリプトを実行して、CA CRL を Web サーバー フォルダに公開します。

    Cscript //job:PublishRootCRLstoIIS

    C:\MSSScripts\CA_Operations.wsf

    (このコマンドは表示の都合上複数行で示していますが、実際には 1 行で入力してください)

ルート CA 情報のパブリケーションを確認する

ルート CA 情報のパブリケーションが正しく作成されたかどうかを確認します。 有効なドメイン アカウントを使用して、ネットワークに接続されたドメイン メンバのコンピュータにログオンし、これらの処理を実行する必要があります。

注 : Active Directory のレプリケーションの実行を待つ必要があります。 certutil -pulse コマンドを使用して、ルート CA 情報のパブリケーションを確認する前にルート CA 証明書のダウンロードを行う必要があります。

ルート CA 情報のパブリケーションを確認するには

  1. 信頼されたルート ストアへの CA 証明書のパブリケーションを確認するには、次のコマンドを実行します。

    certutil -viewstore -enterprise Root

  2. 表示された証明書を参照します。 "発行者" および "件名" の値が、ルートの名前に設定した値と一致していることと、"証明開始" が今日の日付であることを確認します。

  3. ディレクトリに対するルート CA CRL のパブリケーションを確認するには、次のコマンドを実行します。このとき、斜体の部分を使用している値 (CA 共通名、CA の短いホスト名、Active Directory フォレスト ルートの DN) に置き換えます。

    certutil -store -enterprise "ldap:///cn=WoodGrove Bank Root CA,cn=HQ-CA-01,cn=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=woodgrovebank,DC=com?certificateRevocationList?base?objectClass=crlDistributionPoint"

    (このコマンドは表示の都合上複数行で示していますが、実際には 1 行で入力してください)

  4. 出力結果は次のようなものになります。 "発行者" の値がルート CA に設定した名前と一致していることを確認してください。

    ================ CRL 0 ================

    Issuer:    CN=WoodGrove Bank Root CA,DC=woodgrovebank,DC=com

    CA Version: V1.0

    CRL Number: CRL Number=1

    CRL Hash(sha1): 73 03 a1 c7 5f a3 c3 f9 8a 09 d0 3c b5 09 00 9c b5 a3 de fe

    CertUtil: -store command completed successfully.

  5. Web サーバーへの CA 証明書のパブリケーションを確認するには、ブラウザに次の URL を入力して、斜体の部分を使用している環境で使用する値に置き換えます。

    https://www.woodgrovebank.com/pki/HQ-CA-01_WoodGrove Bank Root CA.crt

    注 : 証明書ファイル名には、CA サーバーの完全修飾 DNS 名 (つまり上に示す名前ではなくHQ-CA-01.woodgrovebank.com_WoodGrove Bank Root CA.crt) を使用する必要がある場合があります。

  6. そのファイルを開くか、保存するように指示されます。 ファイルを開いて、ルート CA 証明書が表示されることを確認します。

  7. Web サーバーへのルート CA CRL のパブリケーションを確認するには、ブラウザに次の URL を入力して、斜体の部分を使用している環境で使用する値に置き換えます。

    https://www.woodgrovebank.com/pki/WoodGrove Bank Root CA.crl

  8. そのファイルを開くか、保存するように指示されます。 ファイルを開いて、ルート CA CRL が表示されることを確認します。

    注 : CA 証明書または発行された複数の CRL を更新する場合、これらのコマンドの出力で異なるバージョン番号が表示される可能性があります。

ページのトップへ

発行 CA をインストールおよび設定する

ここでは、発行 CA サーバーに証明書サービスをインストールして設定する方法を説明します。 インストール処理中に、CA、ルート CA、Active Directory、および Web サーバーの間に複雑なやりとりがあります。 これらの関係を次の図に示します。 この項を通して作業するときに、この図を参照すると便利な場合があります。

図 7.2: 発行 CA をインストールするときの CA、Active Directory、および Web サーバー間のやりとり

発行 CA のインストール時におけるシステム間の主なやりとりが、図に示されています。 やりとりは次のとおりです。

  1. ルート CA 証明書と CRL を Active Directory に発行します。

  2. ルート CA 証明書と CRL を Web サーバーに公開します。

  3. ディスクのルート CA に取得する証明書の要求を作成する、証明書サービスのソフトウェアをインストールします。 ルート CA で、この要求に対して証明書を発行します。

  4. 発行 CA 証明書をインストールします。

  5. 発行 CA 証明書と CRL を Web サーバーに公開します。

    注 : 手順 1 と 2 は前の項「ルート CA 情報を公開する」で説明されています。「発行 CA プロパティを設定する」の処理で発行 CA に CRL と AIA の値を設定する一環として、図の X マークの付いた処理が自動的に実行されます。 この項では、他の処理について説明します。

発行 CA 用の Capolicy.inf ファイルを準備する

CAPolicy.inf は発行 CA に必ずしも必要なものではありません。 しかし、CA で使われるキー サイズを変更する場合には必要です。 Capolicy.inf ファイルを作成してから、発行 CA を設定します (後でファイルを追加して CA 証明書を更新することも可能です)。 このファイルにより、キーの長さや CPS など (作成した場合) の CA 証明書の一部特性を指定します。

CAPolicy.inf ファイルを作成するには

  1. メモ帳などのテキスト エディタで次のテキストを入力します。
[Version]
Signature= "$Windows NT$"

[Certsrv_Server]
RenewalKeyLength=2048
  1. この CA に対して定義される CPS がある場合、次の記述を Capolicy.inf ファイルに書き込みます (二重引用符で囲まれた部分に使用している値を代入する必要があります)。
[CAPolicy]
Policies=WoodGrove Bank Issuing CA 1 CPS

[WoodGrove Bank Issuing CA 1 CPS]
OID=your.Orgs.OID
URL = "https://www.woodgrovebank.com/YourCPSPage.htm"

注 : CPS およびCPS の作成を検討する必要があるかどうかについての詳細な説明は、「第 4 章 : 公開キー基盤を設計する」の「Certificate Practices Statements (CPS) を作成する」を参照してください。 CPS は法律文書であり、技術的なアイテムではないので、必要かどうかを確認してから、CA で設定する必要があります。

  1. %windir*%*\aCapolicy.inf としてファイルを保存します (Windows がインストールされたフォルダの絶対パス、C:\Windows などで %windir% を置き換えることもできます)。 この処理を完了するには、ローカル管理者であるか、Windows フォルダに書き込む権限を所有している必要があります。

証明書サービスのソフトウェア コンポーネントをインストールする

CA ソフトウェア コンポーネントをインストールするには、Windows コンポーネント ウィザードを使用します。 インストールを完了するには、Windows Server 2003 のインストール用メディア (CD) が必要です。

証明書サービスをインストールするには

  1. ローカル Administrators グループのメンバとしてサーバーにログオンして、オプション コンポーネント マネージャを実行します (または、[コントロール パネル]、[プログラムの追加と削除]、[Windows コンポーネントの追加と削除] を順に選択します)。

    sysocmgr /i:sysoc.inf

    注 : ローカル Administrators グループのメンバであれば、インストールの最初の部分は実行できます。 次の処理では、CA 証明書をインストールするために、さらに Enterprise PKI Admins (または Enterprise Administrators) のメンバにもなっている必要があります。

  2. 証明書サービス コンポーネントを選択します ([OK] をクリックして名前の変更の警告メッセージ ボックスを閉じます)。

  3. "エンタープライズの下位 CA" として CA の種類を選択して、カスタム設定を使用するようになっていることを確認してください。

  4. [公開キーと秘密キーの組] ダイアログ ボックスでは、キーの長さを 2048 に設定します。それ以外の値は既定値のままにします。 CSP の種類は、[Microsoft Strong Cryptographic Provider] に設定します。

  5. 次のように情報を特定する証明機関を入力します。

    • CA 共通名 : WoodGrove Bank Issueing CA 1 

    • 識別名のサフィックス : DC=woodgrovebank,DC=com
      (組織の Active Directory フォレスト ルート名)

    • 有効期限 : 親 CA により定義

      注 : 以前にこのコンピュータに CA をインストールした場合、前のインストール時の秘密キーを上書きしてもよいかどうかを確認する警告ダイアログ ボックスが表示されます。 再度キーを使用しないことを確認してから、次に進みます。 問題がある場合には、インストール処理をキャンセルして、既存のキー情報をバックアップします (このバックアップ処理は、システムのバックアップ、または既存の CA 証明書と秘密キーのバックアップを使用します。詳細については、「第 11 章 : 公開キー基盤を管理する」を参照してください)。

  6. CSP によりキー ペアが生成され、ローカル コンピュータのキー ストアに書き込まれます。

  7. 証明書データベース、データベース ログ、および構成フォルダの場所を次のように入力します。

    • 証明書データベース : D:\CertLog

    • 証明書データベース ログ : %windir%\System32\CertLog

    • 共有フォルダ : 無効

    パフォーマンスと復元のために、CA データベースを常に保存して、可能な場合には物理的な別ボリュームにログを記録します (何らかの理由でデータベースが破損した場合、最新のバックアップとログを使用して、エラーが発生した時点まで CA を復元できます)。証明書データベースと証明書データベースのログは、両方ともローカルの NTFS 形式のドライブに存在します。

  8. 証明書要求ファイルをディスクにコピーします。 証明書の要求が生成され、共有フォルダのパスに保存されます。 "HQ-CA-02.woodgrovebank.com_WoodGrove Bank Issuing CA 1.req" ファイルをディスクにコピーして、"Transfer-[HQ-CA-02]" のラベルを付けます。

    次に、オプション コンポーネント マネージャにより証明書サービスのコンポーネントがインストールされます。 このインストールには、Windows Server 2003 インストール メディア (CD) が必要です。

  9. [OK] をクリックして、IIS に関する警告を閉じ、インストールを続行します。 セットアップ ウィザードに、続行する前に親から CA 証明書を取得するように指示する通知が表示されます。

    注 : 
    "Pre Windows 2000 Compatible Access グループ" に CA を追加するインストールの終了段階で警告が表示されます。 これは、証明書サービスの証明書マネージャの制限を使用する場合にのみ関連があります。 この機能を使用する場合、このグループに CA コンピュータ アカウントを追加するようにドメイン管理者に依頼します。
    ルート CA により証明書の要求が処理されて、CA に証明書が返され、インストールされてから、証明書サービスは開始されます。

ルート CA に証明書の要求を送信する

次に、署名された要求に対するルート CA および発行 CA に発行された証明書に、発行 CA 証明書の要求を取得する必要があります。

ルート CA に証明書のリクエストを送信するには

  1. ルート CA にローカル 証明書マネージャ グループのメンバとしてログオンします。

  2. 証明機関管理コンソールから、CA の [タスク] メニューの [新しい要求の送信] を選択して、("Transfer-[HQ-CA-02]" ディスク上の) 発行 CA から転送されたリクエストを送信します。

    注 : 前の CA 設定が失敗して設定をやり直す場合、前の CA 設定の要求ファイルを再使用しないでください。このファイルは前のキー マテリアルに関連していますが、現在インストールされている CA とは関連していません。

  3. ルート CA は、すべての要求が手動で承認されている必要があります。 証明機関 MMC の保留中の要求コンテナの要求を見つけ、[共通名] フィールドが発行 CA の名前であることを確認し、要求を右クリックして [発行] を選択し、要求を承認します。

  4. [発行された証明書] コンテナで、新しく発行された証明書を検索して開きます。

  5. 証明書の詳細が正しことを確認し、[ファイルにコピー] をクリックして証明書をファイルにエクスポートします。そのとき、"Transfer-[HQ-CA-02]" のラベルの付いたディスク (発行 CA に転送するために) に　PKCS#7 ファイル (オプションを選択してチェーンにすべての可能な証明書を含めます) として保存します。

発行 CA 証明書をインストールする

ここで説明する処理を実行すると、前に Active Directory に発行したルート CA 情報を発行 CA にダウンロードできることが保証されます。 また、発行 CA 証明書を CA にインストールできます。

発行 CA の証明書情報をリフレッシュする

ルート CA 証明書は、前に Active Directory の信頼されたルート ストアに公開されました。 ここでは、発行 CA がこの情報をダウンロードして証明書を使用しているルート ストアに配置したことを確認します。

発行 CA の証明書の信頼情報をリフレッシュするには

  1. 発行 CA にローカル管理者としてログオンします。

  2. コマンド プロンプトで次のコマンドを実行します。

    certutil –pulse

このコマンドにより、CA はディレクトリから信頼された新しいルート情報をダウンロードして、ルート証明書を信頼された使用しているローカル ルート ストアに配置します。

注 : この処理は必ずしも必要ではありません。証明書を CA にインストールする最後の処理により、ルート CA 証明書が信頼されたローカル ルート ストアに自動的に配置されるからです。 しかし、この処理により、前の Active Directory への発行の処理が正常に完了したことを確認できます。 すべてのドメイン クライアントは Active Directory からルート CA と発行 CA の信頼情報を受信するので、発行が正常に実行されていることが重要です。

Active Directory からルート CA 信頼情報を正常にダウンロードしたことを確認するには

  1. mmc.exe を実行して、[証明書] スナップインを追加します。

  2. 管理する証明書ストアとして "コンピュータ アカウント" を選択します。

  3. ルート証明書が、信頼されたルート証明機関の証明書フォルダに存在することを確認します (CA の件名、すなわち CN 要素の分かりやすい形式により証明書の一覧が表示されます)。

証明書をインストールする

ここまでの処理で、ルート CA からの署名された応答 (証明書が含まれる PKCS#7 パッケージ) を発行 CA にインストールできるようになります。 CA 証明書を Active Directory の NTAuth ストア (これにより CA をエンタープライズ CA として特定します) に正常に発行するために、エンタープライズ PKI Admins およびローカル Administrators の "両方" のメンバのアカウントを使用して CA 証明書をインストールする必要があります。 エンタープライズ PKI Admins グループは証明書をディレクトリに発行する権限、ローカル Administrators グループは CA サーバーに CA 証明書をインストールする権限を持っています。 前に提案した単純な管理モデルを使用している場合、CAAdmin の役割はこれらの両方のグループのメンバです。

発行 CA 証明書をインストールするには

  1. エンタープライズ PKI Admins とローカル Administrators グループのメンバであるアカウントを使用して、発行 CA にログオンします。

  2. ルートにより発行された証明書が保存されているディスク ("Transfer-[HQ-CA-02]") を挿入します。

  3. 証明機関管理コンソールの CA の [タスク] メニューで、[証明書のインストール] を選択して、ディスクから発行 CA 証明書をインストールします。

ここで、CA を開始します。

発行 CA のインストールを確認する

次のように証明書サービスのインストールの正常終了を確認できます。

発行 CA のインストールを確認するには

  1. 証明機関管理コンソールを開きます。 証明書サービスが開始されていることと、CA のプロパティを表示できることを確認します。

  2. [一般] タブで、CA 証明書を選択 (複数の証明書がある場合は [証明書 #0] を選択) して、[証明書の表示] をクリックします。

  3. CA 証明書の [詳細] タブで、表示されている値が次の表に示されている値と一致しているかどうかを確認します。

    表 7.22: 発行 CA の証明書プロパティと拡張機能

    証明書の属性 必要な設定
    発行者 ルート CA 共通名 (DN サフィックスも含む)
    件名 発行 CA 共通名 (DN サフィックスも含む)
    前なし - 後なし 8 年
    公開キーの長さ 2048 ビット
    キー使用法 デジタル署名、証明書の署名、オフライン CRL 署名、CRL 署名 (86)
    基本制限 (重大) Subject Type=CA Path Length Constraint=None
    CRL 配布ポイント 2 エントリ - HTTP および LDAP の URL
    機関情報アクセス 2 エントリ - HTTP および LDAP の URL

基本制限の Subject Type が存在していることが重要です。この値により、CA 証明書とエンドエンティティ証明書が識別されます。 さらに、ルート CA 証明書に表示されない "機関キー識別子" の一覧に表示される他の拡張機能があります。 この値は、ルート証明書の "サブジェクト キー識別子" と一致する必要があります。

以前の値がいずれも予想された値ではない場合、証明書サービスのインストールを再開する必要があります。

注 : 証明書サービスのインストールを再実行する必要がある場合、秘密キーが既に存在する旨を通知する警告が表示されます。 このキーを使用する発行証明書がないことを知っている場合には、この警告を安全に無視して、新しいキーを作成できます。 CA が既に証明書を発行したことがある場合 (テスト証明書を除く)、以前のキーと証明書を安全にバックアップするまで、証明書サービスを再インストールできません (この手順については、「第 11 章 : 公開キー基盤を管理する」を参照してください)。

  1. [証明のパス] タブを参照すると、発行 CA 証明書がルート CA に正しくつなげられていることを確認できます。

  2. セットアップ エラーのイベントの詳細確認またはトラブルシューティングのヘルプ用に、証明書サービスのセットアップ ログ (%systemroot%\certocm.log) を表示できます。

発行 CA プロパティを設定する

CA 設定手順により、環境に固有のパラメータが適用されます。 これらのパラメータの値は、この章の前半の「証明書サービス計画用ワークシート」に記載されています。 この処理で、次の表に示されている CA プロパティを設定します。

表 7.23: 設定される CA プロパティ

CA プロパティ 設定の説明
CRL 配布ポイントのURL HTTP、LDAP、および現在の CRL を取得できるファイルの場所を指定します。 ファイルの場所はローカル フォルダで、発行 CRL を保存する CA によってのみ使用されます。発行された証明書に LDAP および HTTP の場所だけが記載されています。 HTTP の前に LDAP の URL の一覧が順に表示され、ローカル ドメイン コントローラが CRL のダウンロードに対して優先されるターゲットになります。表の後の注を参照してください。
AIA URL CA 証明書を取得できる場所です。 CDP と同様に、ファイルの場所は CA 証明書を公開するためにのみ使用され、LDAP の URL は HTTP の URL より優先順位が高くなります。表の後の注を参照してください。
有効期間 発行された証明書に対する最長の有効期限 (これは、CAPolicy.inf または親 CA で設定される CA 証明書自体の有効期限とは異なります)。
CRL 期限 CRL の公開の頻度
CRL オーバーラップ タイム 新しい CRL を発行する時刻と 1 つ前の CRL がタイムアウトする時刻の間の重なっている時間
Delta CRL 期限 CRL の公開の頻度
Delta–CRL 重複期間 新しい CRL を発行する時刻と 1 つ前の CRL がタイムアウトする時刻の間の重なっている時間
CA Auditors CA 監査設定。 既定ではすべての監査が有効です。
**重要 :** 「第 4 章 : 公開キー基盤を設計する」で説明したように、非ドメイン クライアントをサポートする必要がある場合は、HTTP エントリの優先順位が高くなるように、CDP エントリと AIA エントリの順序を変更する必要があります。 この順序を変更するには、CA 設定スクリプト (ca\_setup.vbs) を編集するか、CA MMC を使用して手動で CDP エントリと AIA エントリを変更する必要があります。 LDAP の URL は、ドメイン クライアントで使用した場合のみ信頼できるので、HTTP の URL のみを使用する必要があります。 その場合は、HTTP AIA および CDP 発行ポイントをホストしている Web サーバーが攻撃に対して強固であることを確認する必要があります。 **発行 CA プロパティを設定するには** 1. CA サーバーにローカル Administrators グループのメンバとしてログオンします。 2. ルート CA のセットアップ時に、各組織固有の設定にスクリプト "C:\\MSSScripts\\pkiparams.vbs" をカスタマイズしたはずです。 これらの変更を、発行 CA にインストールした "C:\\MSSScripts\\pkiparams.vbs" のコピーに複製する必要があります。 3. さらに、次のスクリプトを実行します。 Cscript //job:IssCAConfig C:\\MSSScripts\\ca\_setup.wsf ##### 管理者の役割を設定する CA の管理者の役割 (監査者、証明書マネージャなど) を使用するために、セキュリティ グループを役割に対応付ける必要があります。 **注 :** この方法では、複数の別の役割を定義するために以前に作成したグループを使用します。 これにより、CA 管理の職務を委任する最大の柔軟性が得られます。 しかし、この委任レベルが必要でない場合、この章の前半で指定した単純な管理グループ モデルを使用することを検討してみてください。 この単純なモデルにより、より少ない数のアカウントを使用して CA 管理機能を実行できます。 **発行 CA の管理役割を設定するには** 1. 証明機関管理コンソールで、**\[プロパティ\]** をクリックして CA のプロパティを編集します。 2. **\[セキュリティ\]** タブをクリックして、次の表のドメイン セキュリティ グループを追加します。 各グループに、表に示される権限を追加します。 **表 7.24: 追加する CA 権限のエントリ** 
<p> </p>
<table style="border:1px solid black;">
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th style="border:1px solid black;" >グループ名</th>
<th style="border:1px solid black;" >アクセス許可</th>
<th style="border:1px solid black;" >許可または拒否</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="border:1px solid black;">CA Admins</td>
<td style="border:1px solid black;">CA の管理</td>
<td style="border:1px solid black;">許可</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">Certificate Managers</td>
<td style="border:1px solid black;">証明書の発行と管理</td>
<td style="border:1px solid black;">許可</td>
</tr>
</tbody>
</table>

注 : 完全に役割を分離する場合には、ローカル Administrators グループから管理 CA 権限を削除します。

  1. 別の CA セキュリティの役割には、設定を追加する必要があります (以前サーバーに適用したセキュリティ ポリシーにより、既に一部が定義されています)。

    • CA Auditors には、管理セキュリティおよび監査ログのユーザー権限が与えられています。 このグループをローカル Administrators グループに追加します。

    • CA バックアップ実行者には、CA のバックアップと復元の権限が与えられました。 このグループに対して、さらに設定する必要はありません。

発行 CA 情報を公開する

証明書と CRL は、発行 CA から Active Directory に自動的に公開されます。 ただし、CA 証明書と CRL の HTTP CDP および AIA パスへの公開は自動的に行われません。これらのタスクを行うにはスケジュールされたジョブを設定する必要があります。

発行 CA 証明書と CRL を Web サーバーに公開する

発行 CA 証明書および CRL は、それぞれ HTTP AIA と CDP の場所に公開する必要があります。 技術的には、Web サーバーのフォルダに直接公開するように CA を設定することができます。これを簡単に行うには、発行 CA で Web サーバーをホストします。 しかしこの方法は、セキュリティとネットワーク接続の面を考慮すると、常に可能なわけではありません。 次の方法では、ほとんどの設定に合わせて拡張できる簡単なファイル コピーのテクニックを使用します。

注 : この方法は、直接のネットワーク接続を必要とし、通常はインターネット ファイアウォールで保護されている Windows ネットワーク ファイル共有を使用するため、インターネットに接続されている Web サーバーへの直接公開にはふさわしくありません。 インターネット サーバーに公開するには、次の手順を使用して中間的な場所に公開し、Web サーバーへのセキュリティ公開コンテンツの標準的な方法を使用します。 この場合、手順が 1 つ増えるので、CRL の更新が遅れる可能性があることを考慮に入れる必要があります。

CA 証明書はほとんど更新されないので、CA 証明書が更新された場合には手動で AIA に公開できます。

発行 CA の証明書を公開するには

  1. 発行先の Web サーバー フォルダへの書き込みアクセス許可を持つアカウントで、発行 CA にログオンします。

  2. Web サーバーがリモート サーバー上にある場合は、Web サーバー フォルダが共有されていることを確認します。 この共有フォルダの UNC パスを書き留めておきます。

  3. Web サーバーが CA と同じサーバーにある場合には、Web サーバー フォルダのローカル パスを書き留めておきます。

  4. Web サーバーのフォルダの宛先パスに一致するように、C:\MSSScripts\PKIParams.vbs の WWW_REMOTE_PUB_PATH パラメータを更新します (既定値はローカル パス C:\CAWWWPub です)。

  5. 次のコマンドを実行して、CA 証明書を Web サーバーに発行します。

    Cscript //job:PublishIssCertsToIIS

    C:\MSSScripts\CA_Operations.wsf

    (このコマンドは表示の都合上複数行で示していますが、実際には 1 行で入力してください)

CRL は発行 CA から CA 証明書よりも頻繁に発行されるので (Delta CRL の場合と同様に 1 日に 1 回または 1 時間に 1 回)、Web サーバーに CRL を自動的に複製する方法が必要です。

CRL の発行を自動化するには

  1. ローカル Administrators のメンバであるアカウントで発行 CA にログオンします。

  2. このサーバーからリモート共有またはローカル パスとして Web サーバー フォルダにアクセスできることを確認します。

  3. Web サーバーがリモートである場合、発行 CA にファイル システム フォルダ ("変更" アクセスを許可) および共有フォルダ ("変更" アクセスを許可) への書き込みアクセスを許可します。 Web サーバーがフォレストのメンバである場合、ドメインの Cert Publishers グループを使用してアクセスを許可します。  これにより、このフォルダに証明書と CRL を公開するのに必要な権限をドメイン内のすべてのエンタープライズ CA に与えることができます。 Web サーバーの権限を変更する必要はありません (「機関情報アクセス (AIA: Authority Information Access) と CRL 配布ポイント (CDP: CRL Distribution Point) を発行できるように、発行 CA 上の IIS を設定する」を参照)。

  4. 次のコマンドを実行して、CRL をコピーするようにスケジュールしたジョブを作成します。

    schtasks /create /tn "Publish CRLs" /tr "cscript.exe

    //job:PublishIssCRLsToIIS C:\MSSScripts\CA_Operations.wsf"

    /sc Hourly /ru "System"

    (このコマンドは表示の都合上複数行で示していますが、実際には 1 行で入力してください)

    注 : この手順を実行すると、1 時間ごとに CRL を CA から Web サーバーに公開するようにスケジュールされたジョブが作成されます。 毎日または半日ごとに Delta CRL の発行がスケジュールされている場合には、この頻度で十分に対処できます。 CRL スケジュールがこれよりも頻繁である場合、スケジュールされたジョブをより頻繁に更新する必要があります。 目安として、コピー ジョブの間隔は、Delta CRL の発行間隔の約 5 ～ 10% にすることをお勧めします。

発行 CA 情報のパブリケーションを確認する

発行 CA 情報のパブリケーションが正しく作成されたかどうかを確認します。 有効なドメイン アカウントを使用して、ネットワークに接続されたドメイン メンバのコンピュータにログオンするこれらの処理を実行する必要があります。

発行 CA 情報のパブリケーションを確認するには

  1. 中間 CA ストアへの CA 証明書のパブリケーションを確認するには、次のコマンドを実行します。

    certutil -viewstore -enterprise CA

  2. 表示された 2 つの証明書を見てください。1 つはルート CA の証明書、もう 1 つは発行 CA の証明書です。 発行 CA 証明書をダブルクリックして、"件名" が発行 CA に設定した名前に一致していることと、"有効期限の開始日" が現在の日付であることを確認します。

  3. NTAuth CA ストア (ここで、すべてのエンタープライズ CA が公開されます) への CA 証明書のパブリケーションを確認するには、次のコマンドを実行します。

    certutil -viewstore -enterprise NTAuth

    発行 CA に表示されるのと同じ証明書が表示されます。

  4. ディレクトリに対する発行 CA CRL のパブリケーションを確認するには、次のコマンドを実行します。このとき、斜体の部分を使用している値 (CA 共通名、CA の短いホスト名、Active Directory フォレスト ルートの DN) に置き換えます。

    certutil -store -enterprise "ldap:///cn=Woodgrove Bank Issuing CA 1,cn=HQ-CA-02,cn=CDP,CN=Public Key Services, CN=Services,CN=Configuration,DC=woodgrovebank,DC=com?certificateRevocationList?base?objectClass= cRlDistributionPoint"

    (このコマンドは表示の都合上複数行で示していますが、実際には 1 行で入力してください)

  5. 出力結果は次のようなものになります。 "発行者" の値が発行 CA に設定した名前と一致していることを確認してください。

    ================ CRL 0 ================

    Issuer: CN= WoodGrove Bank Issuing CA,DC=woodgrovebank,DC=com

    CA Version: V1.0

    CRL Number: CRL Number=1

    CRL Hash(sha1): 73 03 a1 c7 5f a3 c3 f9 8a 09 d0 3c b5 09 00 9c b5 a3 de fe

    CertUtil: -store command completed successfully.

  6. Web サーバーへの CA 証明書のパブリケーションを確認するには、ブラウザに次の URL を入力します。このとき、斜体の部分を使用している値に置き換えます。

    https://www.woodgrovebank.com/pki/HQ-CA-02_WoodGrove Bank Issuing CA 1.crt

  7. そのファイルを開くか、保存するように指示されます。 ファイルを開いて、発行 CA 証明書が表示されたことを確認します。

  8. Web サーバーへの発行 CA CRL のパブリケーションを確認するには、ブラウザに次の URL を入力します。このとき、斜体の部分を使用している値に置き換えます。

    https://www.woodgrovebank.com/pki/WoodGrove Bank Issuing CA 1.crl

  9. そのファイルを開くか、保存するように指示されます。 ファイルを開いて、ルート CA CRL が表示されたことを確認します。

    注 : CA 証明書または発行された複数の CRL を更新する場合、これらのコマンドの出力で異なるバージョン番号が表示される可能性があります。

証明書の登録を確認する

発行 CA から証明書を登録できることを確認します。

証明書の登録を確認するには

  1. 発行 CA と同じドメインのコンピュータにログオンします。 ドメインのアカウントを使用します。

  2. 現在のサーバーの [証明書] MMC スナップインを開きます (定義済みのスナップインがないので、[スナップインの追加と削除] を使用してこのスナップインを空の MMC に追加する必要があります)。

  3. 個人用フォルダを右クリックして、[すべてのタスク] サブメニューから新しい証明書を要求するオプションを選択します。

  4. 選択する証明書の種類の一覧が表示されるので、"ユーザーの種類" を選びます。 [詳細設定] チェック ボックスをオンにしないでください。

  5. 証明書に、"発行 CA の確認" などの識別しやすく、分りやすい名前を付けます。

  6. [完了] をクリックして、証明書を登録します。

  7. 個人用フォルダの証明書サブフォルダに進みます。 "発行 CA の確認" 証明書がここに表示されます (最初にストアを更新する必要があるかもしれません。MMC の左ペインで "証明書 - 現在のユーザー" ルート オブジェクトを右クリックして、[更新] をクリックします)。

この検証テストが失敗する場合には、この章の手順に戻って、特定された問題を修正します。 それでも問題を解決できない場合は、「第 11 章 : 公開キー基盤を管理する」の「トラブルシューティング」を参照してください。

ページのトップへ

構築後の設定

組織向けにルート CA と発行 CA を構築しましたが、未解決の設定タスクがいくつか残っています。 ここでは、それらのタスクについて説明します。

証明書テンプレートを設定する

ほとんどのタスクが、CA が発行できる証明書の種類、誰がその発行を制御するのか、および誰に証明書を発行するのかを設定することに関連しています。

発行 CA から不要なテンプレートを削除する

特定の証明書の種類が必要になるまで、証明書が誤って発行されないように CA 設定から対応するテンプレートを削除してください。 ディレクトリ内のテンプレートはいつでも使用可能であり、必要な場合に再び追加できます。

発行 CA から不要なテンプレートを削除するには

  1. CA Admins ドメイン グループのメンバとしてログオンします。

  2. 証明機関管理コンソールから、証明書テンプレートのコンテナを選択します。

  3. 次のテンプレートの種類を削除します。

    • EFS 回復エージェント

    • 基本 EFS

    • Web サーバー

    • コンピュータ

    • ユーザー

    • 下位の証明機関

    • 管理者

      注 : この手順により、ドメイン コントローラ、ドメイン コントローラの認証、およびディレクトリ電子メール複製以外のすべてのテンプレートを発行 CA から削除します。 Windows 2000 ドメイン コントローラは、ドメイン コントローラの証明書を使用して、スマート カード ログオンと Simple Mail Transfer Protocol (SMTP) の Active Directory 複製を有効にします。 Windows Server 2003 ドメイン コントローラは、ドメイン コントローラ認証証明書を使用して、スマート カード ログオンとセキュリティで保護された LDAP をサポートし、ディレクトリ電子メール複製の証明書を使用して、SMTP の Active Directory 複製をサポートします。
      > 削除したすべてのテンプレートは、後で必要に応じて再び追加できます。 同時に、意図的に選択した種類の証明書のみを発行できるようにすると効果的です。

証明書テンプレートを作成および管理する

セキュリティ グループを使用すると、エンタープライズ証明書テンプレートを効果的に管理したり、使用したりすることができます。 これらのグループを使用して、各テンプレートのプロパティを変更できるユーザー、およびその種類の証明書を登録できるユーザーを管理することができます。

注 : テンプレート管理グループは、別の管理者に権限を委ねるテンプレートを制御するかもしれない場合に便利です。 PKI 管理構造が大規模または複雑ではない場合、通常この機能は必要ありません。 この場合、エンタープライズ Admins ビルトイン グループとエンタープライズ PKI Admins (このソリューションの一部として作成された) のメンバのみ、証明書テンプレートを管理できます。

証明書テンプレート管理グループを作成したり、管理したりする処理については、「第 11 章 : 公開キー基盤を管理する」に記載された手順を参照してください。

このソリューションの特定の証明書テンプレートを作成する処理については、「第 9 章 : ワイヤレス LAN のセキュリティに対応したインフラストラクチャを実装する」の「ワイヤレス認証証明書を構成、配置する」を参照してください。

証明書テンプレートの作成と修正に関する一般的な処理については、「証明書テンプレートを作成および管理する」、およびテクニカル ペーパー「Windows Server 2003 での証明書テンプレートの実装および管理」を参照してください (この章の最後にある「関連情報」を参照してください)。

証明書の登録を管理する

テンプレート登録グループを使用すると、登録を行うことができるユーザーと、特定の種類の証明書に対して自動的に登録されるユーザーを簡単に管理できます。 セキュリティ グループのユーザーの追加または削除を簡単に行うことができます。 テンプレート登録グループ メンバシップを制御する権限を、証明書テンプレートのプロパティを直接編集させたくない管理スタッフに与えることもできます。

証明書テンプレート登録グループを作成したり、管理したりする処理については、「第 11 章 : 公開キー基盤を管理する」を参照してください。

マルチドメイン配置の権限を設定する

このソリューションをマルチドメイン フォレストに配置する場合は、CA のドメイン以外のドメイン内のユーザーとコンピュータに証明書を発行しなければならない場合があります。 その場合、CA が Active Directory 内の他のドメインに証明書を正しく公開できるように、既定の権限を変更する必要があります。

CA または証明書テンプレートのユーザーに対する登録権限を設定するときに、ユーザーとコンピュータが証明書を登録できるようにするすべてのドメインからそれらのユーザーとコンピュータを明示的に含めます。

別のドメインのユーザーとコンピュータに証明書の公開を許可するには

  1. 証明書の公開を許可するドメインのドメイン メンバにログオンします。 このドメインのドメイン管理者のメンバ、またはドメイン オブジェクトの権限を変更するのに十分な権限を持つグループのメンバである必要があります。

  2. [Active Directory ユーザーとコンピュータ] MMC スナップインを開いて、ドメイン ノードを右クリックします。

    注 : ターゲットのドメイン内で適切なアクセス許可を持っている限り、この操作を別のドメインから実行できます。 [Active Directory ユーザーとコンピュータ] からターゲットのドメインに接続する必要があります。

  3. [制御の委任] をクリックして、委任ウィザードを起動します。

  4. このウィザードで、[次へ] をクリックし、CA をインストールして発行したドメインから Cert Publishers グループを追加します。 [次へ] をクリックします。

  5. [委任するカスタム タスクを作成する] を選択して、[次へ] をクリックします。

  6. フォルダ内の "次のオブジェクトのみ" を選択します。

  7. [ユーザー オブジェクト] を選択して、[次へ] をクリックします。

  8. [プロパティ固有] オプションを選択します。

  9. [userCertificate の読み取り] および [userCertificate の書き込み] オプションを選択します。

  10. [次へ] をクリックしてから、[完了] をクリックします。

  11. 手順 3 ～ 10 を繰り返します。手順 7 では、[ユーザー オブジェクト] の代わりに [コンピュータ オブジェクト] を選択します。

この手順により、エンタープライズ CA が、このドメインのユーザーとコンピュータに証明書を正しく公開する権限を持つようになります。

CA キーおよび CA サーバーをバックアップする

ルート CA および発行 CA を構築したので、できるだけ早くバックアップして、サーバー エラーやデータの破損からキーと証明書データベースを守ります。

「第 11 章 : 公開キー基盤を管理する」の記載に従って次の手順を実行します。

  • 発行 CA バックアップを設定する

  • ルート CA のバックアップを設定したり、実行したりする

  • CA キーと証明書をバックアップする (このタスクは、各 CA に対して実行する必要があります)

ページのトップへ

クライアントの設定

ここでは、いくつかの重要なクライアントの設定タスクについて説明します。 ほとんどのクライアント関連の設定は、すべての証明書アプリケーションに共通のタスクではなく、WLAN や 仮想プライベート ネットワーク (VPN) などの証明書サービスを使用するアプリケーションまたはサービスに固有なので、重要なクライアントの設定タスクはわずかです。

ユーザーとコンピュータの証明書自動登録を可能にする

前の「証明書の登録を管理する」に記載されている方法では、セキュリティ グループとテンプレート権限を使用して、非常に細かいレベルで自動登録を制御できます。 ただし、Windows XP クライアントの自動登録機能は、既定では無効です。 この機能を有効にするには、グループ ポリシーで正しい設定を構成する必要があります。 セキュリティ グループを使用して自動登録を制御している場合、ドメインのすべてのユーザーとコンピュータの自動登録機能を有効にし、登録セキュリティ グループを使用して、証明書の種類ごとに証明書を受け取るユーザーを決定することができます。

注意 : この処理により、ドメイン内のすべてのコンピュータとユーザーの自動登録が可能になります。 発行 CA から既定のテンプレートを削除したことを確認してから、この処理を開始して、既定のコンピュータとユーザーの証明書がドメイン内の各コンピュータとユーザーに登録されないようにします。 この処理は、「第 11 章 : 公開キー基盤を管理する」に記載されたセキュリティ グループを使用して自動登録を制御していることが前提になります。

ドメイン内のすべてのユーザーとコンピュータに自動登録を許可するには

  1. GPO (Group Policy Creator Owners のメンバ) を作成する権限と、GPO をドメインにリンクする権限を所有するアカウントを使用してログオンします。 または、ドメイン管理者に依頼して、ユーザー用に GPO を作成してリンクし、GPO のユーザーに読み込み権限と書き込み権限を与えてもらいます。

  2. [Active Directory ユーザーとコンピュータ] で、ドメイン オブジェクトを選択して右クリックし、[プロパティ] をクリックします。

  3. [グループ ポリシー] タブで、[新規] をクリックして、GPO の名前 (たとえば、「ドメイン PKI ポリシー」) を入力します。

  4. [編集] をクリックして、GPO を編集して コンピュータの下にある "コンピュータの構成\Windows の設定\セキュリティの設定" の公開キー ポリシーに進みます。

  5. 詳細ペインで、[自動登録の設定] をダブルクリックします。

  6. 次の項目が選択されていることを確認してください。

    • 証明書を自動的に登録する

    • 有効期限が切れた証明書を更新、保留中の証明書を更新、及び破棄された証明書を削除する

    • 証明書テンプレートを使用する証明書を更新する

  7. ユーザーの自動登録の設定のために、"コンピュータの構成\Windows の設定\セキュリティの設定\公開キー ポリシー" で手順 5 と 6 を繰り返します。

  8. GPO を閉じます。

  9. その GPO の優先順位が、既定のドメイン ポリシー GPO より高いことを確認します。

    注 :
    マルチドメイン Active Directory フォレストを所有している場合は、証明書の自動登録を有効にするフォレスト内のすべてのドメインにこの処理を実行します。
    ドメイン内の一部のユーザーまたはコンピュータに対して自動登録を有効にする場合は、自動登録を有効にするユーザーやコンピュータを含む OU にリンクされた GPO を作成できます。
    ユーザーが移動プロファイルを使用せず、自動登録を例外なく有効にした場合は、ユーザーがログオンしたすべてのコンピュータで証明書が登録されます。 管理者やオペレータがサーバーにログオンしたときに証明書が自動登録されないいようにすることができます。 サーバーに適用する GPO を作成することにより (たとえば、GPO をサーバー OU にリンクすることにより)、これを実行できます。 その GPO で、[証明書を自動的に登録しない] を選択してユーザーの自動登録を無効にします。 同じ GPO で、"コンピュータの構成\管理用テンプレート\システム\グループ ポリシー\ユーザー グループ ポリシー ループバックの処理モード" 設定を有効にし、[置換] オプションを選択して、GPO ループバック処理を有効にします。

証明書の自動登録を有効にする方法は、この章の最後の「関連情報」の一覧に表示されている文書に詳細が記載されています。

Windows XP クライアント以降のバージョンのみ、ユーザーとコンピュータの両方の証明書の自動登録をサポートしています。 Windows 2000 クライアントは、コンピュータ証明書の自動登録のみサポートしています (ただし EFS などの一部のアプリケーションには、独自のユーザー証明書の自動登録メカニズムがあります)。

Windows 2000 の Active Directory 環境にこのソリューションを配置している場合は、Windows Server 2003 または Windows Server 2003 の管理ツールがインストールされた Windows XP Professional を実行しているコンピュータから、GPO 内の自動登録の設定を編集する必要があります (Windows Server 2003 の管理ツールをサポートする前に、Windows XP には特定の Service Pack と修正プログラムが必要です)。

ルート証明機関のドメイン ポリシーを設定する

ここでは、組織のクライアントによりどの民間ルート CA が信頼されているのかを管理する方法と、各ユーザーが信頼するルート CA を変更できるかどうかをどの程度制御するのかを説明します。

サードパーティの信頼を管理する

既定の Windows クライアントは、非常に多くの民間ルート CA ("固定されたルート" として知られる) を信頼するように設定されています。 ユーザーがサードパーティ ルート証明書を自動的に信頼しないようにするには、オンライン ヘルプの「ユーザーがグループ ポリシーを使って信頼するサードパーティのルート証明機関を信頼しないようにするには」の処理を実行します。 「関連情報」にもこのトピックの文書へのリンクがあります。

注 : サードパーティ ルートを許可しないと、クライアント アプリケーションでエラーが発生する場合があるので、その結果をテストしないでこれを行うべきではありません。 たとえば、ほとんどのパブリック セキュリティ Web サイトへのクライアント接続は、信頼エラーを発生する原因になります。

次のいくつかの方法で、すべてのサードパーティ信頼を削除する問題の一部を減らすことができます。

  • グループ ポリシーの信頼されたルート証明機関ポリシーの設定に追加して、各ルートを再び追加することができます。

  • ルート証明書を証明書信頼リストに追加して、グループ ポリシーのエンタープライズの信頼設定により配置できます。 この方法により、ルートが発行するどの証明書を信頼するのかに関する使用を制御できます。 ただし、クライアントのサポートは制限されているので、ほかに方法がない場合のみこの方法をお勧めします。

  • また、他の証明機関を相互に証明できます (または、限定従属の信頼関係を作成できます)。 この方法により、組織で信頼する証明機関の使用と証明書パラメータをいっそう制御できるようになります。

証明書信頼リストか限定従属のどちらか一方を使用するのは、サードパーティの信頼されたルートを組織に配置する最も安全な方法です。 この詳細については、「第 4 章 : 公開キー基盤を設計する」で説明されています。

信頼されたルートのユーザー コントロールを管理する

グループ ポリシーを使用して、ユーザーが新しいルート CA を信頼できないようにすることも可能です (これは、組織でのサードパーティ証明書の使用を制御するために、独自の証明書信頼リストまたは限定従属の信頼を作成した場合に特に重要です)。 グループ ポリシーを使用して、信頼されたルートに対するユーザー制御を管理する処理については、オンライン ヘルプの「ユーザーがグループ ポリシーを使って新しいルート証明機関を選択できないようにするには」または「関連情報」のリンクの一覧を参照してください。

ページのトップへ

要約

この章に記載されたすべての処理を実行すると、次のタスクを完了したことになります。

  • オフライン ルート CA のインストールと設定

  • オンライン発行 CA のインストールと設定

  • CRL および CA 証明書を公開するための Web サーバーのインストールと設定

  • CA および Active Directory PKI 設定情報を管理するための管理グループとユーザーの設定

  • PKI をサポートするための Active Directory およびグループ ポリシーの設定

PKI を使用するアプリケーションの設定準備ができました。 設定については、「第 8 章 : RADIUS インフラストラクチャを実装する」と「第 9 章 : ワイヤレス LAN のセキュリティに対応したインフラストラクチャを実装する」の 2 つの章に説明が記載されています。

さらに、「第 11 章 : 公開キー基盤を管理する」の関連する部分を読み、関連する運用担当者がそれらに精通するようにしてください。 この章には、安全で信頼できる方法で PKI を実行するのに必要な情報が含まれています。

関連情報

PKI と Windows 証明書サービスの一般的なバックグラウンド情報

  • PKI の概念と Windows 2000 証明書サービスの機能に関する概要は、「Windows 2000 の公開キー基盤の概要」を参照してください。

  • Windows Server 2003 および Windows XP の拡張された PKI 機能の説明については、「Windows XP Professional と Windows Server 2003 の PKI 拡張機能」https://technet.microsoft.com/ja-jp/library/bb457034.aspx を参照してください。

  • キーの概念と管理タスクに関して述べられているバックグラウンド製品ドキュメントについては、オンライン ヘルプの「証明書サービス」または Windows Server 2003 製品ドキュメントの「Public Key Infrastructure」https://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx (英語) を参照してください。

特別なトピック情報

ページのトップへ

目次

ページのトップへ