証明書サービスを使用してワイヤレス 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 |
構成項目 | 設定 | 関連スクリプト |
---|---|---|
管理役割を担うセキュリティ グループ | ||
公開キー サービス構成コンテナの管理者。 | 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 |
項目 | 要件 |
---|---|
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 をインストールするには
Windows Server 2003 Standard Edition の CD-ROM を CD-ROM ドライブに挿入し、システムを起動します。 サーバーの BIOS 設定で、CD-ROM からの起動が有効になっていることを確認します。
プライマリ ボリュームにパーティションを 1 つ作成し、NTFS としてフォーマットして、そのパーティションを Windows のインストール先として指定するオプションを選択します。
適切な地域設定を選択します。
Windows を登録するユーザー名と会社情報を入力します。
ローカル Administrator アカウント用の強力なパスワードを入力します (10 文字以上の大文字と小文字の英字、数字、および区切り記号の組み合わせ)。
コンピュータ名の入力を要求されたら、「HQ-CA-01」* *などの名前を入力します (この値は、お使いのコンピュータの名前に置き換えてください)。
重要 : ルート CA をオフラインにする場合も、この名前は社内で一意にする必要があります。
ワークグループまたはドメインの選択を要求されたら、ワークグループに参加するように指定します。 ***ワークグループ名として「***WGB-Root」などの名前を入力します (この値は、社内で決めたワークグループ名に置き換えてください)。
オプション コンポーネントのインストールを要求された場合、何もインストールしないでください。
主要なセットアップ プロセスが終了すると、サーバーが再起動されます。 次の処理に進んでください。
最新の Windows Service Pack をインストールします (このガイドの執筆時点では、Windows Server 2003 は製造段階に入ったばかりだったので、Service Pack はまだ提供されていませんでした)。また、推奨されるセキュリティ更新プログラムがあれば、それもインストールします (推奨される更新プログラムを調べるには、Microsoft Baseline Security Analyzer などのツールを使用します)。 社内テストの結果必要であることが判明している、(セキュリティ関連以外の) 機能に関する他の更新プログラムがあれば、それもインストールします。
この Windows のコピーをアクティベートします。 サーバーがネットワークに接続されないようにするため、アクティベートはオフラインで実行する必要があります。
ネットワークを設定する
ルート CA はネットワークに接続されていません。 ルート CA が誤ってネットワークに接続された場合にネットワーク経由でアクセスされないようにするため、[コントロール パネル] の [ネットワーク接続] を使用して、ネットワーク インターフェイスをすべて無効にする必要があります。
インストールを確認する
オペレーティング システムのインストールが正常に完了したこと、およびパラメータが意図どおりに正しく構成されていることを確認する必要があります。
現在のシステム構成を表示するには
コマンド プロンプトで systeminfo プログラムを実行します。
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
ネットワーク カード: なし
これらの設定値が予期した値と一致しない場合、[コントロール パネル] を使用してサーバーの設定を変更するか、またはインストール処理を再実行します。
発行 CA 用サーバーを準備する
ここで説明する処理は、発行 CA として使用するサーバーに Windows をインストールするものです。
Windows Server 2003 Enterprise Edition をインストールする
ルート CA 用サーバー構築プロセスと同様のプロセスを実行しますが、次の例外があります。
ルート CA の場合と異なり、発行 CA 用サーバーを構築するときは、必要に応じてネットワーク ベースの構築手法を使用できます。 その発行 CA がセキュリティ上の脅威にさらされないよう、万全の対策を講じる必要があります。 たとえば、インターネットまたは主要な社内ネットワークへのルーティングが可能な経路を持たない、他のネットワークから切り離されたネットワーク内でインストールする必要があります。 最新のセキュリティ更新プログラムをインストールするまで、システムはネットワーク経由の攻撃にさらされる可能性があります。
Windows Server 2003 Enterprise Edition をインストールするには
ルート CA サーバーに Windows オペレーティング システムをインストールする手順 1 ~ 5 を実行します。ただし、Windows Server 2003 Standard Edition ではなく Enterprise Edition をインストールします。
コンピュータ名の入力を要求されたら、「HQ-CA-02」* *などの名前を入力します (この値は、お使いのコンピュータの名前に置き換えてください)。
ワークグループまたはドメインの選択を要求されたら、ドメインに参加するように指定します。 サーバーを参加させる Active Directory ドメイン名として「WOODGROVEBANK」などの名前を入力します (この値は、実際に CA のインストール先となるドメイン名に置き換えてください)。 コンピュータをこのドメインに参加させる承認を得たユーザーについて、その資格情報を入力するよう要求されたら、所定の欄に入力します。
注 : マルチドメイン構成のフォレストの場合、証明書サーバーは通常、フォレストのルート ドメインにインストールされます。この選択は必須ではありませんが、このソリューションではフォレスト ルート ドメインにインストールするものと想定しています。
オプションのコンポーネントはインストールしないでください。
主要なセットアップ プロセスが終了すると、サーバーが再起動されます。 次の処理に進んでください。
ルート CA の場合と同様、最新の Service Pack と必要な修正プログラムをインストールします。
2 番目のハード ディスクのボリュームにパーティションを作成し、そのパーティションのドライブ文字として D を割り当て、NTFS でフォーマットします。
ドライブ D 上に D:\CertLog というフォルダを作成します。
この Windows のコピーをアクティベートします。 サーバーがインターネットに対して公開されないようにするため、アクティベートはオフラインで実行する必要があります。
ネットワークを設定する
発行 CA は、論理的なネットワーク インターフェイスを 1 つ備えています (このネットワーク インターフェイスは、耐障害性を向上させるため、実際には NIC を 2 枚使用して二重化している場合があります)。 ネットワーク インターフェイスは、ネットワークに応じて、固定 IP アドレスおよびその他の IP 構成パラメータ (既定のゲートウェイや DNS の設定など) で構成されます。
また、セキュリティ上の理由から、発行 CA とインターネットの間の送受信処理をすべて阻止する必要があります。 送信だけは許可してもよいように思われるかもしれませんが、その場合でも、ウイルスなど悪意のあるソフトウェアの危険性に変わりはありません。 これら悪意のあるソフトウェアは、たとえばインターネットから追加コードをダウンロードしたり、CA の秘密キーを盗んで社外に転送する恐れがあるので、きわめて危険です。
インストールを確認する
オペレーティング システムのインストールが正常に完了したこと、およびパラメータが意図どおりに正しく構成されていることを確認する必要があります。
現在のシステム構成を表示するには
コマンド プロンプトで systeminfo プログラムを実行します。
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
これらの設定値が予期した値と一致しない場合、[コントロール パネル] を使用してサーバーの設定を変更するか、またはインストール処理を再実行します。
設定スクリプトをサーバーにインストールする
構成および運用の一部を簡略化する目的で、このソリューションには多くのスクリプトおよび構成ファイルが含まれています。 これらのスクリプトおよび構成ファイルは、各 CA サーバーにインストールする必要があります。 これらのスクリプトの一部は、運用ガイドで説明している作業を実行するために必要なので、CA のインストールが完了しても削除しないでください。
各サーバーにセットアップ スクリプトをインストールするには
C:\MSSScripts という名前のフォルダを作成します。
配布されたメディアからこのフォルダにスクリプトをコピーします。
インターネット インフォメーション サービスをインストールおよび設定する
ここでは、発行 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_asp = on の行で Active Server Pages (ASP) が有効になっています。 このオプションは、ソリューションを拡張する証明書サービス Web 登録ページ ソリューションを利用できるようにする場合に必要なコンポーネントですが、このソリューションで必須というわけではありません。 Web 登録ページが不要な場合は、ASP を無効にすることを検討してください。無効にするには、iis_asp = on の行を削除してから sysocmgr.exe を実行します。 この設定は、後で必要になったときいつでも有効にすることができます。
次のコマンドを入力してオプション コンポーネント マネージャを再度実行し、インストールされているコンポーネントが表 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 上に仮想ディレクトリを作成するには
IIS サーバー (つまり発行 CA 用サーバー) にローカル管理者権限でログオンします。
CA 証明書と CRL を格納するための C:\CAWWWPub フォルダを作成します。
エクスプローラを使用して、このフォルダにセキュリティを設定します。適用するアクセス許可を次の表に示します。 上の 4 つは、既に存在しているはずです。
表 7.6: 仮想ディレクトリに対するアクセス許可の設定
ユーザーまたはグループ アクセス許可 許可または拒否 Administrators フル コントロール 許可 システム フル コントロール 許可 Creator Owners フル コントロール (サブフォルダとファイルのみ) 許可 Users 読み取り フォルダの内容の一覧表示 許可 IIS_WPG 読み取り フォルダの内容の一覧表示 許可 Internet Guest Account 書き込み 拒否 インターネット インフォメーション サービス管理コンソールで、既定の Web サイトの下に新しい仮想ディレクトリを作成します。
その仮想ディレクトリに pki という名前を付けます。
パスとして C:\CAWWWPub を指定します。
この仮想ディレクトリのアクセス許可設定において、[ASP などのスクリプトを実行する] チェック ボックスをオフにします。
この仮想ディレクトリに対して匿名認証が有効になっていることを確認します。
HTTP 発行ポイントに対する DNS エイリアスを指定する
CDP と AIA をホスティングする IIS サーバー (このソリューションでは www.woodgrovebank.com) に対する汎用 DNS エイリアス (CNAME) を作成することをお勧めします。 この DNS エイリアスは、以降の項で CA に対する CDP パスと AIA パスを設定するときに使用します。 このエイリアスを使用すると、CA 証明書を再発行せずに、CA 発行ポイントを簡単に別のサーバーやネットワーク上の場所に移動することができます。
IIS のインストール結果を確認する
次の作業に進む前に、IIS の基本的な動作を確認する必要があります。 次のテストのいずれかで不具合が発生した場合、前述の IIS のインストール処理と設定処理が正しく行われたかどうかを確認する必要があります。
IIS 仮想ディレクトリの動作が正しいかどうかを確認するには
ローカルの Administrators グループのメンバとして IIS サーバー (つまり発行 CA 用サーバー) にログオンし、メモ帳などのテキスト エディタを使用してファイルを新規に作成します。 次のテキストを入力します (テキストの内容は、わかりやすいものであれば何でもかまいません。HTMLタグも不要です)。 次に例を示します。
Hello World
「IIS 上に仮想ディレクトリを作成するには」の処理で CDP 情報と AIA 情報の発行用として作成したフォルダ (C:\CAWWWPub) に、このファイルを test.htm という名前で保存します。 また、このファイルを test.asp という名前で同じフォルダに保存します。
ブラウザを起動し、次の URL (Uniform Resource Locator) を入力してページを開きます。
https://www.woodgrovebank.com/pki/test.htm
注 : この DNS エイリアスをまだ設定していない場合、この DNS エイリアスをローカルの hosts ファイル (%systemroot%\system32\drivers\etc\hosts) に一時的に追加し、IIS サーバーの IP アドレスに対応させることができます。 また、DNS エイリアスの代わりに IIS サーバーの実際のホスト名を使用することもできます。 ただしその場合、DNS エイリアスが正しく機能しているかどうかを後で検査する必要があります。
ブラウザに "Hello World" というテキスト (または手順 1 で入力した内容) が表示されることを確認します。
実行権限が無効になっているかどうかを確認するには
ブラウザを起動し、次の URL を入力してページを開きます。
https://www.woodgrovebank.com/pki/test.asp
次のエラー メッセージ (または類似したメッセージ) がブラウザに表示されます。
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 サイトをテストするものとします。このテストは、プロキシ サーバー経由では実行できません。
匿名アクセスが有効になっているかどうかを確認するには
コマンド プロンプトで telnet プログラムを実行します。
telnet プロンプトで次のコマンドを入力し、入力した文字がローカルで表示されるようにします。
set localecho
次のコマンドを入力し、前述の処理で定義した DNS エイリアスを使用して IIS に接続します。
open www.woodgrovebank.com 80
次のテキストを入力し、test.htm ページを取得します。テキストは、大文字/小文字の区別も含めて正確に入力してください。
GET /pki/test.htm
注 : カーソルが画面上端に戻ります。これは、画面上に今まで表示されていたテキストが、入力したテキストによって上書きされたことを意味します。これにより、画面表示がやや乱れることがありますが、 無視してかまいません。
誤入力した場合は、Enter キーを押し、手順 3 の open コマンドを再度入力して再接続し、GET コマンドを再度入力します。出力結果が次のようになることを確認します。
Hello World
Connection to host lost.
Press any key to continue...
「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 が正しく準備されているかどうかを確認する
ドメインの機能レベルとスキーマのバージョンを確認するには、次の処理を実行します。
ドメインの機能レベルが正しいかどうかを確認するには
[Active Directory ユーザーとコンピュータ] を開きます。
[ドメイン] オブジェクトのプロパティを表示します。
[全般] プロパティ ページの [ドメインの機能レベル] に、次のいずれかの項目が表示されています。
Windows 2000 ネイティブ
Windows Server 2003
スキーマのバージョンが正しいかどうかを確認するには
コマンド プロンプトで次のコマンドを入力します。「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 上で使用することはできません。
出力結果の中で、次のように 30 以上のスキーマ バージョンが表示されます。
objectversion
30
Active Directory のグループとユーザー
ここでは、CA によって使用される、Active Directory のセキュリティ グループとユーザー アカウントを作成する処理について説明します。
PKI と CA の管理用グループを作成する
管理役割と管理機能を定義するには、ドメイン ユーザー アカウントとドメイン セキュリティ グループを使用します。
注 : このソリューションでは、管理役割ごとにセキュリティ グループを定義します。 これにより、CA 管理業務を委任する方法を細かく制御できます。 ただし、これらの管理役割の一部または全部が社内の実際の管理モデルに対応していない場合、これらの管理役割の使用にこだわる必要はありません。 極端な例で言えば、たとえば社内に PKI 管理者が 1 人しかおらず、その PKI 管理者が証明書サービスを全面的に管理している場合、このアカウントを CA に対するすべての役割グループに追加できます。 実際には、役割を部分的に分離するのが一般的ですが、証明書サービスのすべての役割分離機能を使用するケースもまれにあります。
ドメイン内に CA 管理用グループを作成するには
Users コンテナにユーザー オブジェクトとグループ オブジェクトを作成する権限を持つアカウントを使用して、ドメイン メンバ コンピュータにログオンします。
次のコマンドを実行し、ドメインの 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 のキーとデータをバックアップおよび復元する権限を持っています。 |
ユーザー アカウント | 目的 |
---|---|
EntPKIAdmin | 公開キー サービス構成コンテナの管理者 |
EntPKIPub | CRL と CA 証明書をエンタープライズ設定コンテナに発行する権限を持っています。 |
CAAdmin | CA に関する全面的な管理権限 (例: 他の役割をどのメンバに割り当てるかを決める権限) を持っています。 |
CertManager | 証明書の発行と失効を管理します。 |
CAAuditor | CA に関する監査データを管理します。 |
CABackup | CA のキーとデータをバックアップおよび復元する権限を持っています。 |
簡略化された管理役割ユーザー アカウント | ユーザー アカウントのグループ メンバシップ |
---|---|
CAAdmin | Enterprise PKI Admins CA Admins Certificate Managers Administrators (CA のローカル管理者) |
CAAuditor | CA Auditors Administrators (CA のローカル管理者) |
CABackup | CA Backup Operators |
OU | 目的 |
---|---|
Certificate Services | 親 OU。 |
\—Certificate Services Administration | CA およびエンタープライズ PKI 構成を管理する管理グループを含む。 |
\—Certificate Template Management | 個々の証明書テンプレートを管理するためのグループを格納します。 |
\—Certificate Template Enrollment | 同名のテンプレートに対する登録権限および自動登録権限を付与されているグループを格納します。 これらのグループの制御を適切な個人に委任することにより、テンプレート自体を使用しなくても柔軟な登録体制を実現することができます。 |
\—Certificate Services Test Users | 一時テスト用アカウントを格納します。 |
<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>
CA を管理するユーザー用のローカル ユーザー アカウントを作成します。 テストと事例説明を行うため、次に示すスクリプトでは、表 11 のセキュリティ グループによって定義された各役割に対応する汎用ローカル アカウントを作成します。 ただし、この時点で実際のアカウントを作成できる場合は、この手順をスキップし、 代わりにそのアカウントを作成してください。
Cscript //job:CertLocalTestAccts C:\MSSScripts\ca_setup.wsf
このスクリプトでは、CAPICOM が使用され、すべてのアカウントに対して擬似乱数パスワードが設定されます (つまり、パスワードが空白のままになることはありません)。 設定されたパスワードはスクリプトの出力結果の中に表示されるので、メモしておいてください。また、自動的に設定されたこれらのパスワードを、自分で決めたパスワードに変更することもできます。
注 : このように管理者間でパスワードを共有している汎用アカウントを使用した場合、監査は事実上意味がなくなります。 セキュリティ要件の厳しい実運用環境では必ず、個人を特定してトレースできるアカウントを使用してください。
このスクリプトは、表 7.12 に示すローカル グループを作成するものです。
表 7.12: アカウントの名前と目的
アカウント名 目的 CAAdmin CA に関する全面的な管理権限 (例: 他の役割をどのメンバに割り当てるかを決める権限) を持っています。 CertManager 証明書の発行と失効を管理します。 CAAuditor CA に関する監査データを管理します。 CABackup CA のキーとデータをバックアップおよび復元する権限を持っています。
注 : これらのテスト用アカウントの管理役割は、きわめて複雑な設定になっています。つまり、CA の役割ごとに別々の個人 (ユーザー アカウント) が設定されています。 ただし、実際に各役割を別々の個人が実行するのでない場合、役割ごとにアカウントを設定するメリットはほとんどありません。 実際の管理構造をより正確に反映できるのであれば、ある特定のアカウントを複数の役割グループに追加しても問題ありません。ある特定のアカウントをすべての役割グループに追加することさえできます。
これらのユーザー アカウントを適切な管理セキュリティ グループに追加します。 テスト用アカウントの場合は、表 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 |
<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 をカスタマイズして適用するには
[Active Directory ユーザーとコンピュータ] で、Enterprise Client-Certificate Services GPO を編集します。 コンピュータの構成\Windows の設定\セキュリティの設定\ローカル ポリシー\セキュリティ オプションで、組織のセキュリティ標準に応じて次の項目を変更します。
アカウント : Administrator アカウント名の変更 : NewAdminName
アカウント : Guest アカウント名の変更 : NewGuestName
対話型ログオン : ログオン時のユーザーへのメッセージのテキスト : LegalNoticeText
対話型ログオン : ログオン時のユーザーへのメッセージのタイトル : LegalNoticeTitle
ローカル ポリシー\ユーザー権利の割り当てで、"CA Auditors" ドメイン グループを "管理監査およびセキュリティ ログ" のユーザー権限に追加します。
ローカル ポリシー\ユーザー権利の割り当てで、"CA Backup Operators" を次のユーザー権限に追加します。
ファイルとディレクトリのバックアップ
ファイルとディレクトリの復元
ローカル ポリシー\ユーザー権利の割り当てで、次のローカルおよびドメイン グループを "ローカル ログオンを許可する" 権限に追加します。
(ローカル) Administrators
(ローカル) Backup Operators
(ドメイン) Enterprise PKI Admins
(ドメイン) Enterprise PKI Publishers
(ドメイン) CA Admins
(ドメイン) Certificate Managers
(ドメイン) CA Auditors
(ドメイン) CA Backup Operators
[ファイル システム] で、フォルダ D:\CertLog を追加します。 次の表に示す権限があることを確認します。
表 7.16: データベース フォルダの権限
ユーザーまたはグループ アクセス許可 許可または拒否 Administrators フル コントロール 許可 System フル コントロール 許可 Backup Operators フル コントロール 許可 CREATOR OWNER フル コントロール 許可 同じフォルダに、表 7.17 に示す Everyone グループに対する監査エントリを追加します ([セキュリティ] ダイアログ ボックスの [詳細設定] ボタンをクリックし、[監査] タブをクリック)。 ユーザー名またはグループ名を要求するメッセージが表示されたら、「Everyone」と入力します。 Everyone グループを追加すると、[D:\CertLog の監査エントリ] ダイアログ ボックスが表示されます。このダイアログ ボックスに、詳細な監査の設定を入力することができます。 [適用先] フィールドで [このフォルダ、サブフォルダおよびファイル] がオンになっていることを確認します。 次の表で [はい] と示す項目をすべてチェックしてください。
表 7.17: データベース フォルダの監査
アクセス許可 成功 Failed フル コントロール はい フォルダのスキャンとファイルの実行 はい フォルダの一覧とデータの読み取り はい 属性の読み取り はい 拡張属性の読み取り はい ファイルの作成とデータの書き込み はい はい フォルダの作成とデータの追加 はい はい 属性の書き込み はい はい 拡張属性の書き込み はい はい サブフォルダとファイルの削除 はい はい 削除 はい はい アクセス許可の読み取り はい アクセス許可の変更 はい はい 所有権の取得 はい はい システム サービス フォルダで次のサービスのプロパティを開き、[このポリシーの設定をテンプレートで定義する] をオンにします。 [OK] をクリックして、既定のアクセス許可を適用します。 [サービスのスタートアップ モード] の値を [自動] に設定します。
Removable Storage
Volume Shadow Copy
MS Software Shadow Copy Provider
Task Scheduler
注 : これらのサービスは Member Server Baseline セキュリティ テンプレートでは無効になっていますが、最初の 3 つは NTBackup.exe の実行に必要です。 タスク スケジューラ サービスは、一部の操作スクリプトの実行に必要です。
発行 CA コンピュータ アカウントを証明書サービス OU に移動します。
発行 CA (CA がインストールされているサーバー) で、次のコマンドを実行して GPO 設定をコンピュータに適用します。
gpupdate
注 : これらのセキュリティ設定の詳細については、「Windows Server 2003 セキュリティ ガイド」を参照してください。
セキュリティ設定を確認する
セキュリティ設定が正しく適用されていることを確認するには、次の手順を実行します。
ルート CA セキュリティ設定を確認するには
アプリケーション イベント ログで SceCli ソースからのイベントを確認します。 gpupdate コマンドの後にイベント ID 1704 が出力されていることを確認します。 イベントのテキストは次のとおりです。
グループ ポリシー オブジェクトのセキュリティ ポリシーは正しく適用されました。
サーバーを再起動し、必要なサービスがすべて開始されていること、およびシステム イベント ログにエラーが記録されていないことを確認します。
作成したテスト アカウント (または実際のアカウント) でログオンを試行します。 法的な情報を通知するテキストが表示され、ログオンできます。
発行 CA のターミナル サービス セキュリティを設定する
発行 CA の Terminal Services を無効にする必要があります。アタッカーが CA 集中的にアタックし、サーバーを保護している物理的なセキュリティ対策の効果を大幅に減少させるためです。 このサービスを有効にする必要がある場合 (リモート管理目的の場合) は、次の表に示す設定を行います。
注 : ネットワークに接続されていないため、ルート CA の Terminal Services の状態は関係ありません。
これらの設定は、オンライン CA に適用する Certificate Services Security GPO または他の GPO で行う必要があります。
表 7.18: コンピュータの構成\管理用テンプレート\Windows コンポーネント\ターミナル サービス構成の設定
設定のパス | ポリシー | 設定 |
---|---|---|
コンソール セッションにログインしている管理者のログオフを拒否する | 有効 | |
ローカルの管理者によるアクセス許可のカスタマイズを許可しない | 有効 | |
ターミナル サービス ユーザー セッションのリモート制御のルールを設定する | リモート制御を許可しない | |
クライアント\サーバー データ リダイレクト | タイム ゾーン リダイレクトを許可する | 無効 |
クリップボードのリダイレクトを許可しない | 有効 | |
オーディオのリダイレクトを許可する | 無効 | |
COM ポートのリダイレクトを許可しない | 有効 | |
クライアント プリンタのリダイレクトを許可しない | 有効 | |
LPT ポートのリダイレクトを許可しない | 有効 | |
ドライブのリダイレクトを許可しない | 有効 | |
クライアントの通常使うプリンタをセッションで通常使うプリンタに設定しない | 有効 | |
暗号化とセキュリティ | クライアントが接続するたびにパスワードを要求する | 有効 |
クライアント接続の暗号化レベルを設定する | 高 | |
暗号化とセキュリティ\RPC セキュリティ | セキュリティで保護されたサーバー (セキュリティが必要) | 有効 |
セッション | 切断されたセッションの制限時間を設定する | 10 分 |
オリジナルのクライアントからの再接続のみを許可する | 有効 |
[Version]
Signature= "$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=16
[CRLDistributionPoint]
Empty=true
[AuthorityInformationAccess]
Empty=true
注意 : キーの長さを 4,096 ビットに設定すると、互換性の問題が発生する可能性があります。 特定のデバイス (ルーターなど) や他のベンダの古いソフトウェアの一部は、特定のサイズ以上のキーを処理できません。
- この 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"
- "%windir%"\Capolicy.inf としてファイルを保存します (Windows がインストールされたフォルダの絶対パス、C:\Windows などで "%windir%" を置き換えます)。 この処理を完了するには、ローカル管理者であるか、Windows フォルダに書き込む権限を所有している必要があります。
証明書サービスのソフトウェア コンポーネントをインストールする
CA ソフトウェア コンポーネントをインストールするには、Windows コンポーネント ウィザードを使用します。 インストールを完了するには、Windows Server 2003 インストール CD またはネットワーク パスが必要であることに注意してください。
証明書サービスをインストールするには
ローカル Administrators グループのメンバとしてログオンし、オプション コンポーネント マネージャを実行します (または、[コントロール パネル]、[プログラムの追加と削除]、[Windows コンポーネントの追加と削除] の順に選択します)。
sysocmgr /i:sysoc.inf.
証明書サービス コンポーネントを選択します ([はい] をクリックして名前の変更の警告メッセージ ボックスを閉じます)。
"スタンドアロンのルート CA" として CAタイプを選択し、カスタム設定を使用するようになっていることを確認してください。
[公開キーと秘密キーの組] ダイアログ ボックスで、キーの長さ以外は、4096 に設定されている既定値のままにしておきます。 "CSP の種類" は、"Microsoft Strong 暗号化サービス プロバイダ" です。
次のように情報を特定する証明機関を入力します。
CA の共通名 : WoodGrove Bank Root CA
識別名のサフィックス : DC=woodgrovebank,DC=com
(組織の Active Directory フォレスト ルート名)有効期限 : 8 年
注 : 以前にこのコンピュータに CA をインストールした場合、前のインストール時の秘密キーを上書きしてもよいかどうかを確認する警告ダイアログ ボックスが表示されます。 再度キーを使用しないことを確認してから、次に進みます。 問題がある場合には、インストール処理をキャンセルして、既存のキー情報をバックアップします (このバックアップ処理は、システムのバックアップ、または既存の CA 証明書と秘密キーのバックアップを使用します。詳細については、「第 11 章 : 公開キー基盤を管理する」を参照してください)。
CSP によりキー ペアが生成され、ローカル コンピュータのキー ストアに書き込まれます。
証明書データベース、データベース ログ、および構成フォルダの場所を既定値のままにします。
注 :
すべてのネットワーク インターフェイスが無効になっているため、設定処理中に、共有フォルダを作成できないという警告メッセージが表示される場合があります。 これを無視して先へ進んでも安全です。
証明書データベースおよび証明書データベースのログオン ローカル NTFS ドライブを設置してください。次に、オプション コンポーネント マネージャにより証明書サービスのコンポーネントがインストールされます。 この処理には、Windows Server 2003 インストール メディア (CD) が必要です。
[OK] をクリックして、IIS に関する警告を閉じ、インストールを続行します。
ルート CA のインストールを確認する
次のように証明書サービスのインストールの正常終了を確認できます。
ルート CA の適切なインストール内容を確認するには
[すべてのプログラム]、[管理ツール] の順にクリックし、証明機関管理コンソールを開きます。 証明書サービスが開始されていることと、CA のプロパティを表示できることを確認します。
[一般] タブで、CA 証明書を選択 (複数の証明書がある場合は CA 証明書のリストから [証明書 #0] を選択) して、[証明書の表示] をクリックします。
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 章 : 公開キー基盤を管理する」を参照してください)。
- 証明書サービスのセットアップ ログ (%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 監査設定。 既定ではすべての監査が有効です。 |
' 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"
```
さらに、次のスクリプトを実行します。
Cscript //job:RootCAConfig C:\MSSScripts\ca_setup.wsf
管理者の役割を設定する
CA の管理者の役割 (監査者、証明書マネージャなど) を使用するために、以前に作成したセキュリティ グループを役割に対応付ける必要があります。
注 : この方法では、複数の別の役割を定義するために以前に作成したグループを使用します。 これにより、CA 管理の職務を委任する最大の柔軟性が得られます。 しかし、この委任レベルが必要でない場合、この章の前半で指定した単純な管理グループ モデルを使用することを検討してみてください。 この単純なモデルにより、より少ない数のアカウントを使用して CA 管理機能を実行できます。
ルート CA の管理役割を設定するには
証明機関管理コンソールで、[プロパティ] をクリックして CA のプロパティを編集します。
[セキュリティ] タブをクリックして、次の表のローカル セキュリティ グループを追加します。 各グループに、表に示される権限を追加します。
表 7.21: 追加する CA 権限のエントリ
グループ名 アクセス許可 許可または拒否 CA Admins CA の管理 許可 Certificate Managers 証明書の発行と管理 許可
注 : 完全に役割を分離する場合には、ローカル Administrators グループから管理 CA 権限を削除します (ルート CA は、Windows Server の Standard Edition にインストールされるので、役割の分離を強制的に実行することはできません。このオプションは、Enterprise Edition でのみ使用できます)。
この CA に対する別の CA セキュリティの役割は、以前サーバーに適用されたセキュリティ ポリシーにより既に定義されています。
CA Auditors には、管理セキュリティおよび監査ログのユーザー権限が与えられています。
バックアップ実行者は、CA のバックアップや復元を行う権限を所有しています。
ルート CA 証明書と CRL をディスクに転送する
Active Directory、IIS 証明書公開サーバー、および CRL 公開サーバーに発行できるように、CA からルート CA 証明書と CRL をコピーする必要があります。
ルート CA 証明書と CRL をディスクにコピーするには
ローカル CA Admins グループのメンバとしてルート CA にログオンし、ドライブ転送用に使用するディスクを挿入します。
次のスクリプトを実行して、CA 証明書をディスクにコピーします。
Cscript //job:GetCACerts C:\MSSScripts\CA_Operations.wsf
次のスクリプトを実行して、CA CRL をディスクにコピーします。
Cscript //job:GetCRLs C:\MSSScripts\CA_Operations.wsf
このディスクに "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 に公開するには
ドメイン メンバのコンピュータに "Enterprise PKI Admins" グループのメンバとしてログオンして、前にルート CA 証明書と CRL ("Transfer-[HQ-CA-01]" のラベルを付けた) を保存するために使用したディスクを挿入します。
次のスクリプトを実行して、CA 証明書を Active Directory に公開します。
Cscript //job:PublishCertstoAD C:\MSSScripts\CA_Operations.wsf
次のスクリプトを実行して、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 に公開するには
ローカル管理者として、または C:\CAWWWPub フォルダに書き込み権限を持つアカウントで Web サーバーにログオンします。
CA 証明書とCRL を保存しているディスク ("Transfer-[HQ-CA-01]"のラベルが付いた) がドライブに挿入されていることを確認します。
次のスクリプトを実行して、CA 証明書を Web サーバーのフォルダに公開します。
Cscript //job:PublishRootCertstoIIS
C:\MSSScripts\CA_Operations.wsf
(このコマンドは表示の都合上複数行で示していますが、実際には 1 行で入力してください)
次のスクリプトを実行して、CA CRL を Web サーバー フォルダに公開します。
Cscript //job:PublishRootCRLstoIIS
C:\MSSScripts\CA_Operations.wsf
(このコマンドは表示の都合上複数行で示していますが、実際には 1 行で入力してください)
ルート CA 情報のパブリケーションを確認する
ルート CA 情報のパブリケーションが正しく作成されたかどうかを確認します。 有効なドメイン アカウントを使用して、ネットワークに接続されたドメイン メンバのコンピュータにログオンし、これらの処理を実行する必要があります。
注 : Active Directory のレプリケーションの実行を待つ必要があります。 certutil -pulse コマンドを使用して、ルート CA 情報のパブリケーションを確認する前にルート CA 証明書のダウンロードを行う必要があります。
ルート CA 情報のパブリケーションを確認するには
信頼されたルート ストアへの CA 証明書のパブリケーションを確認するには、次のコマンドを実行します。
certutil -viewstore -enterprise Root
表示された証明書を参照します。 "発行者" および "件名" の値が、ルートの名前に設定した値と一致していることと、"証明開始" が今日の日付であることを確認します。
ディレクトリに対するルート 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 行で入力してください)
出力結果は次のようなものになります。 "発行者" の値がルート 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.
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) を使用する必要がある場合があります。
そのファイルを開くか、保存するように指示されます。 ファイルを開いて、ルート CA 証明書が表示されることを確認します。
Web サーバーへのルート CA CRL のパブリケーションを確認するには、ブラウザに次の URL を入力して、斜体の部分を使用している環境で使用する値に置き換えます。
https://www.woodgrovebank.com/pki/WoodGrove Bank Root CA.crl
そのファイルを開くか、保存するように指示されます。 ファイルを開いて、ルート CA CRL が表示されることを確認します。
注 : CA 証明書または発行された複数の CRL を更新する場合、これらのコマンドの出力で異なるバージョン番号が表示される可能性があります。
発行 CA をインストールおよび設定する
ここでは、発行 CA サーバーに証明書サービスをインストールして設定する方法を説明します。 インストール処理中に、CA、ルート CA、Active Directory、および Web サーバーの間に複雑なやりとりがあります。 これらの関係を次の図に示します。 この項を通して作業するときに、この図を参照すると便利な場合があります。
図 7.2: 発行 CA をインストールするときの CA、Active Directory、および Web サーバー間のやりとり
発行 CA のインストール時におけるシステム間の主なやりとりが、図に示されています。 やりとりは次のとおりです。
ルート CA 証明書と CRL を Active Directory に発行します。
ルート CA 証明書と CRL を Web サーバーに公開します。
ディスクのルート CA に取得する証明書の要求を作成する、証明書サービスのソフトウェアをインストールします。 ルート CA で、この要求に対して証明書を発行します。
発行 CA 証明書をインストールします。
発行 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 ファイルを作成するには
- メモ帳などのテキスト エディタで次のテキストを入力します。
[Version]
Signature= "$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=2048
- この 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 で設定する必要があります。
- %windir*%*\aCapolicy.inf としてファイルを保存します (Windows がインストールされたフォルダの絶対パス、C:\Windows などで %windir% を置き換えることもできます)。 この処理を完了するには、ローカル管理者であるか、Windows フォルダに書き込む権限を所有している必要があります。
証明書サービスのソフトウェア コンポーネントをインストールする
CA ソフトウェア コンポーネントをインストールするには、Windows コンポーネント ウィザードを使用します。 インストールを完了するには、Windows Server 2003 のインストール用メディア (CD) が必要です。
証明書サービスをインストールするには
ローカル Administrators グループのメンバとしてサーバーにログオンして、オプション コンポーネント マネージャを実行します (または、[コントロール パネル]、[プログラムの追加と削除]、[Windows コンポーネントの追加と削除] を順に選択します)。
sysocmgr /i:sysoc.inf
注 : ローカル Administrators グループのメンバであれば、インストールの最初の部分は実行できます。 次の処理では、CA 証明書をインストールするために、さらに Enterprise PKI Admins (または Enterprise Administrators) のメンバにもなっている必要があります。
証明書サービス コンポーネントを選択します ([OK] をクリックして名前の変更の警告メッセージ ボックスを閉じます)。
"エンタープライズの下位 CA" として CA の種類を選択して、カスタム設定を使用するようになっていることを確認してください。
[公開キーと秘密キーの組] ダイアログ ボックスでは、キーの長さを 2048 に設定します。それ以外の値は既定値のままにします。 CSP の種類は、[Microsoft Strong Cryptographic Provider] に設定します。
次のように情報を特定する証明機関を入力します。
CA 共通名 : WoodGrove Bank Issueing CA 1
識別名のサフィックス : DC=woodgrovebank,DC=com
(組織の Active Directory フォレスト ルート名)有効期限 : 親 CA により定義
注 : 以前にこのコンピュータに CA をインストールした場合、前のインストール時の秘密キーを上書きしてもよいかどうかを確認する警告ダイアログ ボックスが表示されます。 再度キーを使用しないことを確認してから、次に進みます。 問題がある場合には、インストール処理をキャンセルして、既存のキー情報をバックアップします (このバックアップ処理は、システムのバックアップ、または既存の CA 証明書と秘密キーのバックアップを使用します。詳細については、「第 11 章 : 公開キー基盤を管理する」を参照してください)。
CSP によりキー ペアが生成され、ローカル コンピュータのキー ストアに書き込まれます。
証明書データベース、データベース ログ、および構成フォルダの場所を次のように入力します。
証明書データベース : D:\CertLog
証明書データベース ログ : %windir%\System32\CertLog
共有フォルダ : 無効
パフォーマンスと復元のために、CA データベースを常に保存して、可能な場合には物理的な別ボリュームにログを記録します (何らかの理由でデータベースが破損した場合、最新のバックアップとログを使用して、エラーが発生した時点まで CA を復元できます)。証明書データベースと証明書データベースのログは、両方ともローカルの NTFS 形式のドライブに存在します。
証明書要求ファイルをディスクにコピーします。 証明書の要求が生成され、共有フォルダのパスに保存されます。 "HQ-CA-02.woodgrovebank.com_WoodGrove Bank Issuing CA 1.req" ファイルをディスクにコピーして、"Transfer-[HQ-CA-02]" のラベルを付けます。
次に、オプション コンポーネント マネージャにより証明書サービスのコンポーネントがインストールされます。 このインストールには、Windows Server 2003 インストール メディア (CD) が必要です。
[OK] をクリックして、IIS に関する警告を閉じ、インストールを続行します。 セットアップ ウィザードに、続行する前に親から CA 証明書を取得するように指示する通知が表示されます。
注 :
"Pre Windows 2000 Compatible Access グループ" に CA を追加するインストールの終了段階で警告が表示されます。 これは、証明書サービスの証明書マネージャの制限を使用する場合にのみ関連があります。 この機能を使用する場合、このグループに CA コンピュータ アカウントを追加するようにドメイン管理者に依頼します。
ルート CA により証明書の要求が処理されて、CA に証明書が返され、インストールされてから、証明書サービスは開始されます。
ルート CA に証明書の要求を送信する
次に、署名された要求に対するルート CA および発行 CA に発行された証明書に、発行 CA 証明書の要求を取得する必要があります。
ルート CA に証明書のリクエストを送信するには
ルート CA にローカル 証明書マネージャ グループのメンバとしてログオンします。
証明機関管理コンソールから、CA の [タスク] メニューの [新しい要求の送信] を選択して、("Transfer-[HQ-CA-02]" ディスク上の) 発行 CA から転送されたリクエストを送信します。
注 : 前の CA 設定が失敗して設定をやり直す場合、前の CA 設定の要求ファイルを再使用しないでください。このファイルは前のキー マテリアルに関連していますが、現在インストールされている CA とは関連していません。
ルート CA は、すべての要求が手動で承認されている必要があります。 証明機関 MMC の保留中の要求コンテナの要求を見つけ、[共通名] フィールドが発行 CA の名前であることを確認し、要求を右クリックして [発行] を選択し、要求を承認します。
[発行された証明書] コンテナで、新しく発行された証明書を検索して開きます。
証明書の詳細が正しことを確認し、[ファイルにコピー] をクリックして証明書をファイルにエクスポートします。そのとき、"Transfer-[HQ-CA-02]" のラベルの付いたディスク (発行 CA に転送するために) に PKCS#7 ファイル (オプションを選択してチェーンにすべての可能な証明書を含めます) として保存します。
発行 CA 証明書をインストールする
ここで説明する処理を実行すると、前に Active Directory に発行したルート CA 情報を発行 CA にダウンロードできることが保証されます。 また、発行 CA 証明書を CA にインストールできます。
発行 CA の証明書情報をリフレッシュする
ルート CA 証明書は、前に Active Directory の信頼されたルート ストアに公開されました。 ここでは、発行 CA がこの情報をダウンロードして証明書を使用しているルート ストアに配置したことを確認します。
発行 CA の証明書の信頼情報をリフレッシュするには
発行 CA にローカル管理者としてログオンします。
コマンド プロンプトで次のコマンドを実行します。
certutil –pulse
このコマンドにより、CA はディレクトリから信頼された新しいルート情報をダウンロードして、ルート証明書を信頼された使用しているローカル ルート ストアに配置します。
注 : この処理は必ずしも必要ではありません。証明書を CA にインストールする最後の処理により、ルート CA 証明書が信頼されたローカル ルート ストアに自動的に配置されるからです。 しかし、この処理により、前の Active Directory への発行の処理が正常に完了したことを確認できます。 すべてのドメイン クライアントは Active Directory からルート CA と発行 CA の信頼情報を受信するので、発行が正常に実行されていることが重要です。
Active Directory からルート CA 信頼情報を正常にダウンロードしたことを確認するには
mmc.exe を実行して、[証明書] スナップインを追加します。
管理する証明書ストアとして "コンピュータ アカウント" を選択します。
ルート証明書が、信頼されたルート証明機関の証明書フォルダに存在することを確認します (CA の件名、すなわち CN 要素の分かりやすい形式により証明書の一覧が表示されます)。
証明書をインストールする
ここまでの処理で、ルート CA からの署名された応答 (証明書が含まれる PKCS#7 パッケージ) を発行 CA にインストールできるようになります。 CA 証明書を Active Directory の NTAuth ストア (これにより CA をエンタープライズ CA として特定します) に正常に発行するために、エンタープライズ PKI Admins およびローカル Administrators の "両方" のメンバのアカウントを使用して CA 証明書をインストールする必要があります。 エンタープライズ PKI Admins グループは証明書をディレクトリに発行する権限、ローカル Administrators グループは CA サーバーに CA 証明書をインストールする権限を持っています。 前に提案した単純な管理モデルを使用している場合、CAAdmin の役割はこれらの両方のグループのメンバです。
発行 CA 証明書をインストールするには
エンタープライズ PKI Admins とローカル Administrators グループのメンバであるアカウントを使用して、発行 CA にログオンします。
ルートにより発行された証明書が保存されているディスク ("Transfer-[HQ-CA-02]") を挿入します。
証明機関管理コンソールの CA の [タスク] メニューで、[証明書のインストール] を選択して、ディスクから発行 CA 証明書をインストールします。
ここで、CA を開始します。
発行 CA のインストールを確認する
次のように証明書サービスのインストールの正常終了を確認できます。
発行 CA のインストールを確認するには
証明機関管理コンソールを開きます。 証明書サービスが開始されていることと、CA のプロパティを表示できることを確認します。
[一般] タブで、CA 証明書を選択 (複数の証明書がある場合は [証明書 #0] を選択) して、[証明書の表示] をクリックします。
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 章 : 公開キー基盤を管理する」を参照してください)。
[証明のパス] タブを参照すると、発行 CA 証明書がルート CA に正しくつなげられていることを確認できます。
セットアップ エラーのイベントの詳細確認またはトラブルシューティングのヘルプ用に、証明書サービスのセットアップ ログ (%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 監査設定。 既定ではすべての監査が有効です。 |
<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 権限を削除します。
別の 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 の証明書を公開するには
発行先の Web サーバー フォルダへの書き込みアクセス許可を持つアカウントで、発行 CA にログオンします。
Web サーバーがリモート サーバー上にある場合は、Web サーバー フォルダが共有されていることを確認します。 この共有フォルダの UNC パスを書き留めておきます。
Web サーバーが CA と同じサーバーにある場合には、Web サーバー フォルダのローカル パスを書き留めておきます。
Web サーバーのフォルダの宛先パスに一致するように、C:\MSSScripts\PKIParams.vbs の WWW_REMOTE_PUB_PATH パラメータを更新します (既定値はローカル パス C:\CAWWWPub です)。
次のコマンドを実行して、CA 証明書を Web サーバーに発行します。
Cscript //job:PublishIssCertsToIIS
C:\MSSScripts\CA_Operations.wsf
(このコマンドは表示の都合上複数行で示していますが、実際には 1 行で入力してください)
CRL は発行 CA から CA 証明書よりも頻繁に発行されるので (Delta CRL の場合と同様に 1 日に 1 回または 1 時間に 1 回)、Web サーバーに CRL を自動的に複製する方法が必要です。
CRL の発行を自動化するには
ローカル Administrators のメンバであるアカウントで発行 CA にログオンします。
このサーバーからリモート共有またはローカル パスとして Web サーバー フォルダにアクセスできることを確認します。
Web サーバーがリモートである場合、発行 CA にファイル システム フォルダ ("変更" アクセスを許可) および共有フォルダ ("変更" アクセスを許可) への書き込みアクセスを許可します。 Web サーバーがフォレストのメンバである場合、ドメインの Cert Publishers グループを使用してアクセスを許可します。 これにより、このフォルダに証明書と CRL を公開するのに必要な権限をドメイン内のすべてのエンタープライズ CA に与えることができます。 Web サーバーの権限を変更する必要はありません (「機関情報アクセス (AIA: Authority Information Access) と CRL 配布ポイント (CDP: CRL Distribution Point) を発行できるように、発行 CA 上の IIS を設定する」を参照)。
次のコマンドを実行して、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 情報のパブリケーションを確認するには
中間 CA ストアへの CA 証明書のパブリケーションを確認するには、次のコマンドを実行します。
certutil -viewstore -enterprise CA
表示された 2 つの証明書を見てください。1 つはルート CA の証明書、もう 1 つは発行 CA の証明書です。 発行 CA 証明書をダブルクリックして、"件名" が発行 CA に設定した名前に一致していることと、"有効期限の開始日" が現在の日付であることを確認します。
NTAuth CA ストア (ここで、すべてのエンタープライズ CA が公開されます) への CA 証明書のパブリケーションを確認するには、次のコマンドを実行します。
certutil -viewstore -enterprise NTAuth
発行 CA に表示されるのと同じ証明書が表示されます。
ディレクトリに対する発行 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 行で入力してください)
出力結果は次のようなものになります。 "発行者" の値が発行 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.
Web サーバーへの CA 証明書のパブリケーションを確認するには、ブラウザに次の URL を入力します。このとき、斜体の部分を使用している値に置き換えます。
https://www.woodgrovebank.com/pki/HQ-CA-02_WoodGrove Bank Issuing CA 1.crt
そのファイルを開くか、保存するように指示されます。 ファイルを開いて、発行 CA 証明書が表示されたことを確認します。
Web サーバーへの発行 CA CRL のパブリケーションを確認するには、ブラウザに次の URL を入力します。このとき、斜体の部分を使用している値に置き換えます。
https://www.woodgrovebank.com/pki/WoodGrove Bank Issuing CA 1.crl
そのファイルを開くか、保存するように指示されます。 ファイルを開いて、ルート CA CRL が表示されたことを確認します。
注 : CA 証明書または発行された複数の CRL を更新する場合、これらのコマンドの出力で異なるバージョン番号が表示される可能性があります。
証明書の登録を確認する
発行 CA から証明書を登録できることを確認します。
証明書の登録を確認するには
発行 CA と同じドメインのコンピュータにログオンします。 ドメインのアカウントを使用します。
現在のサーバーの [証明書] MMC スナップインを開きます (定義済みのスナップインがないので、[スナップインの追加と削除] を使用してこのスナップインを空の MMC に追加する必要があります)。
個人用フォルダを右クリックして、[すべてのタスク] サブメニューから新しい証明書を要求するオプションを選択します。
選択する証明書の種類の一覧が表示されるので、"ユーザーの種類" を選びます。 [詳細設定] チェック ボックスをオンにしないでください。
証明書に、"発行 CA の確認" などの識別しやすく、分りやすい名前を付けます。
[完了] をクリックして、証明書を登録します。
個人用フォルダの証明書サブフォルダに進みます。 "発行 CA の確認" 証明書がここに表示されます (最初にストアを更新する必要があるかもしれません。MMC の左ペインで "証明書 - 現在のユーザー" ルート オブジェクトを右クリックして、[更新] をクリックします)。
この検証テストが失敗する場合には、この章の手順に戻って、特定された問題を修正します。 それでも問題を解決できない場合は、「第 11 章 : 公開キー基盤を管理する」の「トラブルシューティング」を参照してください。
構築後の設定
組織向けにルート CA と発行 CA を構築しましたが、未解決の設定タスクがいくつか残っています。 ここでは、それらのタスクについて説明します。
証明書テンプレートを設定する
ほとんどのタスクが、CA が発行できる証明書の種類、誰がその発行を制御するのか、および誰に証明書を発行するのかを設定することに関連しています。
発行 CA から不要なテンプレートを削除する
特定の証明書の種類が必要になるまで、証明書が誤って発行されないように CA 設定から対応するテンプレートを削除してください。 ディレクトリ内のテンプレートはいつでも使用可能であり、必要な場合に再び追加できます。
発行 CA から不要なテンプレートを削除するには
CA Admins ドメイン グループのメンバとしてログオンします。
証明機関管理コンソールから、証明書テンプレートのコンテナを選択します。
次のテンプレートの種類を削除します。
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 または証明書テンプレートのユーザーに対する登録権限を設定するときに、ユーザーとコンピュータが証明書を登録できるようにするすべてのドメインからそれらのユーザーとコンピュータを明示的に含めます。
別のドメインのユーザーとコンピュータに証明書の公開を許可するには
証明書の公開を許可するドメインのドメイン メンバにログオンします。 このドメインのドメイン管理者のメンバ、またはドメイン オブジェクトの権限を変更するのに十分な権限を持つグループのメンバである必要があります。
[Active Directory ユーザーとコンピュータ] MMC スナップインを開いて、ドメイン ノードを右クリックします。
注 : ターゲットのドメイン内で適切なアクセス許可を持っている限り、この操作を別のドメインから実行できます。 [Active Directory ユーザーとコンピュータ] からターゲットのドメインに接続する必要があります。
[制御の委任] をクリックして、委任ウィザードを起動します。
このウィザードで、[次へ] をクリックし、CA をインストールして発行したドメインから Cert Publishers グループを追加します。 [次へ] をクリックします。
[委任するカスタム タスクを作成する] を選択して、[次へ] をクリックします。
フォルダ内の "次のオブジェクトのみ" を選択します。
[ユーザー オブジェクト] を選択して、[次へ] をクリックします。
[プロパティ固有] オプションを選択します。
[userCertificate の読み取り] および [userCertificate の書き込み] オプションを選択します。
[次へ] をクリックしてから、[完了] をクリックします。
手順 3 ~ 10 を繰り返します。手順 7 では、[ユーザー オブジェクト] の代わりに [コンピュータ オブジェクト] を選択します。
この手順により、エンタープライズ CA が、このドメインのユーザーとコンピュータに証明書を正しく公開する権限を持つようになります。
CA キーおよび CA サーバーをバックアップする
ルート CA および発行 CA を構築したので、できるだけ早くバックアップして、サーバー エラーやデータの破損からキーと証明書データベースを守ります。
「第 11 章 : 公開キー基盤を管理する」の記載に従って次の手順を実行します。
発行 CA バックアップを設定する
ルート CA のバックアップを設定したり、実行したりする
CA キーと証明書をバックアップする (このタスクは、各 CA に対して実行する必要があります)
クライアントの設定
ここでは、いくつかの重要なクライアントの設定タスクについて説明します。 ほとんどのクライアント関連の設定は、すべての証明書アプリケーションに共通のタスクではなく、WLAN や 仮想プライベート ネットワーク (VPN) などの証明書サービスを使用するアプリケーションまたはサービスに固有なので、重要なクライアントの設定タスクはわずかです。
ユーザーとコンピュータの証明書自動登録を可能にする
前の「証明書の登録を管理する」に記載されている方法では、セキュリティ グループとテンプレート権限を使用して、非常に細かいレベルで自動登録を制御できます。 ただし、Windows XP クライアントの自動登録機能は、既定では無効です。 この機能を有効にするには、グループ ポリシーで正しい設定を構成する必要があります。 セキュリティ グループを使用して自動登録を制御している場合、ドメインのすべてのユーザーとコンピュータの自動登録機能を有効にし、登録セキュリティ グループを使用して、証明書の種類ごとに証明書を受け取るユーザーを決定することができます。
注意 : この処理により、ドメイン内のすべてのコンピュータとユーザーの自動登録が可能になります。 発行 CA から既定のテンプレートを削除したことを確認してから、この処理を開始して、既定のコンピュータとユーザーの証明書がドメイン内の各コンピュータとユーザーに登録されないようにします。 この処理は、「第 11 章 : 公開キー基盤を管理する」に記載されたセキュリティ グループを使用して自動登録を制御していることが前提になります。
ドメイン内のすべてのユーザーとコンピュータに自動登録を許可するには
GPO (Group Policy Creator Owners のメンバ) を作成する権限と、GPO をドメインにリンクする権限を所有するアカウントを使用してログオンします。 または、ドメイン管理者に依頼して、ユーザー用に GPO を作成してリンクし、GPO のユーザーに読み込み権限と書き込み権限を与えてもらいます。
[Active Directory ユーザーとコンピュータ] で、ドメイン オブジェクトを選択して右クリックし、[プロパティ] をクリックします。
[グループ ポリシー] タブで、[新規] をクリックして、GPO の名前 (たとえば、「ドメイン PKI ポリシー」) を入力します。
[編集] をクリックして、GPO を編集して コンピュータの下にある "コンピュータの構成\Windows の設定\セキュリティの設定" の公開キー ポリシーに進みます。
詳細ペインで、[自動登録の設定] をダブルクリックします。
次の項目が選択されていることを確認してください。
証明書を自動的に登録する
有効期限が切れた証明書を更新、保留中の証明書を更新、及び破棄された証明書を削除する
証明書テンプレートを使用する証明書を更新する
ユーザーの自動登録の設定のために、"コンピュータの構成\Windows の設定\セキュリティの設定\公開キー ポリシー" で手順 5 と 6 を繰り返します。
GPO を閉じます。
その 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 (英語) を参照してください。
特別なトピック情報
マルチフォレスト Active Directory 環境での PKI の配置の詳細については、Windows Server 2003 製品ドキュメントの「Publish certificates in a foreign Active Directory forest」https://technet.microsoft.com/ja-jp/library/cc786746.aspx を参照してください。
CAPICOM は、Microsoft ダウンロード センター Web サイト https://www.microsoft.com/download/details.aspx?displaylang=en&FamilyID=860EE43A-A843-462F-ABB5-FF88EA5896F6 からダウンロードできます (英語)。 ダウンロード センター Web サイトで "CAPICOM" を検索し、最新バージョンを取得していることを確認することもできます。
Microsoft Baseline Security Analyzer (MBSA) の使用方法については、「Microsoft Baseline Security Analyzer v1.2」https://technet.microsoft.com/ja-jp/security/cc184924.aspx (英語) を参照してください。
Active Directory ドメインの機能レベルおよびそれらの変更方法については、Windows Server 2003 製品ドキュメントの次のセクションを参照してください。
「Domain and forest functionality」https://technet.microsoft.com/ja-jp/library/cc738670.aspxでは、さまざまなドメインとフォレストのレベルについて説明されています。
「Raise the domain functional level」https://technet.microsoft.com/ja-jp/library/cc776703.aspx では、ドメインとフォレストのレベルを変更する方法について説明されています。
ADPrep ツールの詳細については、マイクロソフト サポート技術情報 Q325379「Windows ドメイン コントローラを Windows Server 2003 にアップグレードする方法」https://support.microsoft.com/?kbid=325379
および 「ADPrep」https://technet.microsoft.com/ja-jp/library/cc780339.aspxを参照してください。ADPrep 更新プログラム レベルの要件に関する情報については、マイクロソフト サポート技術情報 Q331161「Adprep /Forestprep コマンドを実行する前に Windows 2000 ドメイン コントローラにインストールする修正プログラム」https://support.microsoft.com/?kbid=331161 を参照してください。
証明書サービスの管理役割の詳細については、Windows Server 2003 製品ドキュメントの「Managing role-based administration」https://technet.microsoft.com/ja-jp/library/cc738189.aspxを参照してください。
このガイドで使用するサーバーのセキュリティの設定およびサーバー ロールの情報については、「Windows Server 2003 セキュリティ ガイド」https://www.microsoft.com/japan/technet/security/prodtech/windowsserver2003/W2003HG/SGCH00.mspx を参照してください。
証明書テンプレートの作成と修正に関する処理については、テクニカル ペーパー「Windows Server 2003 での証明書テンプレートの実装および管理」https://www.microsoft.com/japan/technet/prodtechnol/
windowsserver2003/technologies/security/ws03crtm.mspx および製品ドキュメントの「Manage certificate templates for an enterprise certification authority」セクション https://technet.microsoft.com/ja-jp/library/cc780765.aspx を参照してください。サードパーティ CA の自動的な信頼を許可しない方法については、
「To prevent users from trusting third-party root certification authorities with a Group Policy」 を参照してください。信頼されたルートのユーザー制御を管理する方法については、
「To prevent users from selecting new root certification authorities with a Group Policy」 を参照してください。証明書の自動登録の詳細については、「Certificate Autoenrollment in Windows XP」 (英語)、および「Checklist: Configuring certificate autoenrollment」 を参照してください。
高度な証明書登録の詳細については、「Advanced Certificate Enrollment and Management」https://technet.microsoft.com/ja-jp/windowsserver/2003/default.aspx を参照してください。
Web 登録の詳細については、
「Configuring and Troubleshooting Windows 2000 and
Windows Server 2003 Certificate Services Web Enrollment」https://technet.microsoft.com/ja-jp/windowsserver/2003/default.aspx を参照してください。「第 11 章 : 公開キー基盤を管理する」以外の Windows PKI の管理の詳細については、「Windows Server 2003 PKI Operations Guide」https://technet.microsoft.com/ja-jp/library/cc787594.aspx を参照してください。
目次
- 概要
- ソリューションの概要
- 第 1 章 : ソリューションの概要
- 設計ガイドの概要
- 第 2 章 : セキュリティで保護されたワイヤレス LAN ネットワークの構築方針を決定する
- 第 3 章 : セキュリティ保護されたワイヤレス LAN ソリューション アーキテクチャ
- 第 4 章 : 公開キー基盤を設計する
- 第 5 章 : ワイヤレス LAN のセキュリティに対応した RADIUS インフラストラクチャを設計する
- 第 6 章 : 802.1X を使用してワイヤレス LAN のセキュリティを設計する
- 構築ガイドの概要
- 第 7 章 : 公開キー基盤を実装する
- 第 8 章 : RADIUS インフラストラクチャを実装する
- 運用ガイドの概要
- 第 9 章 : ワイヤレス LAN のセキュリティに対応したインフラストラクチャを実装する
- 第 10 章 : 運用ガイドの紹介
- 第 11 章 : 公開キー基盤を管理する
- 第 12 章 : RADIUS およびワイヤレス LAN のセキュリティ インフラストラクチャを管理する
- テスト ガイドの概要
- 第 13 章 : テスト ガイド
- 付録
- 付録 A: Windows のバージョン サポート表
- 付録 B: スクリプトとサポート ファイル
- 付録 C: 配信ガイド
- 付録 D: WPA のサポート