Windows の CA 機能 (AD CS) についてのまとめ

コンピュータ利用時のセキュリティ意識の高まりにより、PKI は以前より身近なものになっています。 企業が Windows のセキュリティ機能を用いるために CA を導入することも増えていると思います。 この場合、昔のように 3rd パーティ製 CA ソフトウェアを用いるのではなく、Windows 付属 CA サービスを用い Active Directory と統合されたエンタプライズ CA を構築することが多いでしょう。 Microsoft が提供する情報は膨大なのですが、知りたいことがなかなか見つけられなかったりするので、今回はこの Windows CA サービスについてまとめてみました。

CA の種類

Windows Server の標準機能で構築できる認証機関には2つの種類があります。

  • エンタプライズ CA
  • スタンドアロン CA

簡単に言えば前者は Active Directory と統合された認証機関、後者は全く独立した認証機関ということになります。 なお、ここでいう「エンタプライズ」とは Windows Edition の Enterprise/Standard とは独立した概念です。 Standard Edition でも エンタプライズ CA を構築することができます。 ただし、Enterprise Edition と Standard Edition で利用できる証明書テンプレート (後述) が異なったりするので注意が必要です。

この記事では社内利用 (プライベート CA) に限定して主にエンタプライズ CA について扱います。 また Windows Server 2003 で確認した内容ですので、Windows Server 2008 では若干異なることがあるかも知れません。

Windows 環境においてどんな時に証明書を使う?

証明書を使用するありがちなケースとしては例えば以下のようなものが挙げられます。

  1. 一般的なサーバ証明書
  2. Active Directory の LDAP アクセスを SSL 化 (LDAPS) する
  3. Windows ログオン ID に紐づけたクライアント証明書の利用 (ログオン用証明書)
  4. 802.1X
  5. EFS (暗号化ファイルシステム)

用途が 1 だけならばスタンドアロン CA でも良いでしょうが、それ以外の用途ではエンタプライズ CA を利用するのが基本となるでしょう。

インストールについて

CA サービスをインストールするには、「アプリケーションの追加と削除」-「Windows コンポーネントの追加と削除」で「証明書サービス」を選択します。 一度 CA サービスを構成してしまうと後から参加ドメインやコンピュータ名を変えることはできません。 どうしても変えたければ削除後再インストールとなります。 また、CA 用証明書の有効期間も慎重に決めましょう。

Web 登録サポート (Web ブラウザで証明書発行要求ができるインターフェイス) を使用しなければ IIS のインストールは必須ではありません。 証明書のリクエストは MMC (Microsoft Management Console) の証明書スナップインからもできます。

証明書の発行対象

エンタプライズ CA の証明書は以下の3つ対して発行されます。

  • ユーザアカウント
  • サービスアカウント
  • コンピュータアカウント

先の利用例でわかりやすいものについていうと 2 はドメインコントローラのコンピュータアカウント、3 は個々のユーザアカウントに対し発行することになります。 MMC で証明書スナップインを表示するときにこれらの発行対象を適切に選択しないと操作対象を間違えることになります。

証明書テンプレート

証明書は用途別に種類があります (正確に言うと証明書の中身で用途が指定されています)。 Windows CA ではこの用途に応じたテンプレートが用意されていて、証明書要求時にはどのテンプレートを用いるか指定することになります。

テンプレートにはバージョンがあり、Windows のバージョン/エディションの差によって使用できるテンプレートのバージョンが異なります。 Windows Server 2008/2003 Standard Edition ではカスタマイズ不可の V1 テンプレートしか使えません。 Enterprise Edition で使用可能なテンプレートが使えないということです。 ただし、2008 R2 は Standard Edition でも V2、V3 テンプレートが使用可能なようです。

発行する証明書の有効期間

スタンドアロン CA で発行される証明書の有効期間は以下のレジストリの値によって決定されます。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CAName\ValidityPeriod
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CAName\ValidityPeriodUnits

エンタプライズ CA では選択した証明書テンプレートに設定された有効期間と上のレジストリ値のどちらか小さい方が発行される証明書の有効期間となります。

CRLの公開

CRL の位置は証明書に含まれるため、証明書の展開前に CRL の設定を行う必要があります。 MMC 「証明機関」スナップインより CA のプロパティを表示し、「拡張機能」タブの「CRL 配布ポイント(CDP)」で確認・設定できます。 また、CRL 公開期間は「失効した証明書」のプロパティより設定可能です。

発行済み証明書の Active Directory への格納

証明書テンプレートで設定することにより、発行した証明書を Active Directory 上に保存することができます。 設定項目の場所は MMC 「証明書テンプレート」スナップインより、テンプレートのプロパティを表示し、「全般」タブ中の「Active Directory の証明書を発行する」です。

Active Directory 上に保存されたユーザ証明書は「Active Directory ユーザーとコンピュータ」ツール (「拡張機能」をオン)を用い、ユーザプロパティの「公開された証明書」タブを見ることで確認できます。 LDAP でアクセスする際は objectClass=user の userCertificate 属性ということになります。

証明書の発行要求

MMC の証明書スナップインを利用し、「すべてのタスク」-「新しい証明書の要求」でできます (次項の図参照)。 しかし、実際のエンタプライズ環境では後述の自動発行で運用することを検討した方が良いでしょう。

複数のエンタプライズルート CA

エンタプライズ CA はフォレストに関連付けられています。 小~中規模ではフォレストレベルで単一のエンタプライズルート CA を置くケースが多いと思いますが、やろうと思えば同一ドメイン内にさえ複数のエンタープライズルート CA を構築することは可能です。 もっとも複数のルート CA を置くよりは階層化することを考えた方が良いかも知れません。 複数の CA が利用できるときは、MMC より手動で発行要求を行う際に「詳細」ボタンを押して要求対象 CA を選択できます。

ちなみに Microsoft のリソースキットなどでは「ルート CA はドメインに属さないサーバ上にスタンドアロン CA を構築してオフラインにする」、「下位 CA としてエンタプライズ CA を構築し証明書発行に用いる」という階層構成が推奨されています。 ルート CA の秘密鍵は重要なのでオフラインにしてセキュリティを高めましょうということですが、どこまで予算が確保できるかという問題がありますね。

証明書の自動発行について

証明書テンプレートの V1 までと V2 以降で自動証明書要求/発行の仕組みが異なります。 V1 の ACRS で自動登録可能なのはコンピュータアカウント用の証明書のみに限定されているので注意が必要です。

テンプレートバージョン 自動更新の仕組み
V1 ACRS (Automatic Certificate Request Settings)
V2以降 テンプレートを用いた自動登録機能

どちらもグループポリシーで有効化しますが、設定する箇所が異なります。 以下はコンピュータアカウント用証明書自動登録機能の設定箇所です。 どちらも「コンピュータの構成」-「Windows の設定」-「公開キーのポリシー」以下にありますが項目が異なります。

「自動証明書要求の設定」= ACRS (V1 テンプレート用)
「自動登録の設定」      = V2 以降のテンプレートを用いた自動登録

V2 以降では証明書テンプレートプロパティの「セキュリティ」タブで発行対象に対し「自動登録」(と「読み取り」、「登録」) が許可されていることも必要です。 MMC の「証明書テンプレート」スナップインで設定します。

MMC による発行要求や自動登録に必要な設定

CERTSVC_DCOM_ACCESS というグループが存在しなければなりませんが、インストールの仕方によっては自動作成されないこともあるようです。 そんな時は以下のコマンドを実行します。

certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG
net stop certsvc
net start certsvc

また、デフォルトで CERTSVC_DCOM_ACCESS にドメインコントローラが含まれないので「Domain Controllers」も追加しておきます (「Domain Computers」は登録されていますが、デフォルトではこれにドメインコントローラは含まれません)。

CA サービスの移行

バックアップ・リストアは証明機関管理ツールのメニューから簡単にできます。 ただし、同じコンピュータ名でないとリストアできないので注意が必要です。 詳しい手順は以下の URL で説明されています。

AD DS の SSL 化

先の例で出したように AD DS (Active Directory Domain Services) の LDAP アクセスを SSL 化するにはドメインコントローラ上のコンピュータアカウント個人ストアに証明書をインストールしますが、Windows Server 2008 では「NTDS サービス」のサービスアカウントに対し発行した証明書があればこちらが優先して使われるようになりました。 これによりコンピュータアカウントストアに複数の証明書を入れなければならないような環境でも証明書管理がしやすくなりました。

更に Windows Server 2008 では証明書更新時のサービス再起動が不要になっています。 手元で試していませんが、以下の URL の「Windows Server 2008 improvements」のところに書いてあります。

最後に

本来認証局の運用は CP/CPS (Certificate Policy/Certification Practice Statement) という文書を用意して厳格に行うべきものです。 Windows で CA サービスが実装されてお手軽に認証局を立てられるようになりましたが、せめてどのような設定でどのように動いているか把握しておきたいものです。 特に自動更新されない証明書の有効期限は要注意です。 できれば簡略なものでもよいので「CP/CPS」を用意しましょう。


2011.4.19 追記
若干書き足りない部分があったので追記しました。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です


*