Windows Server 2012での証明書サービスの実装手順

Windows Server 2012ではインターフェイスの大幅な変更があり、色々なことに苦しめられる毎日です。
スタートメニューがどこだかわからなくなったり、
Active Directoryドメインサービスをインストールするためのdcpromoがなくなったりと、
慣れるまで、ストレスの連続なのでしょう。
今回紹介するAcitve Directory証明書サービスの実装も少しトリッキーだったりします。

備忘録代わりに実装方法を載せております。

■ ■ ■

サーバーマネージャーから役割と機能の追加ウィザードを実行し、[Active Directory証明書サービス]を追加して、
次へをクリックします。

AD1-34

一緒にインストールする機能の一覧が表示されますが、特に追加するものがなければ、そのまま次へをクリックします。

AD1-35

そのまま次へをクリックします。

AD1-36

役割サービスを追加します。証明機関は必須として、その他必要な役割サービスがあれば、
チェックをつけてください。特に、Webページから証明書が発行できる
[証明書Web登録]はよく使うかもしれませんね。
選択したら次へをクリックします。

AD1-37

インストール内容を確認してインストールをクリックします。

AD1-38

インストール結果を確認して、閉じるをクリックします。

AD1-39

出来上がり!と私はここで思ったのですが、
よく考えると、証明書サーバーの構成に関する設定項目が全く何も出てきませんでした。
そうです、Windows Server 2012の役割と機能の追加ウィザードは単純に役割または機能を
インストールするだけで、役割や機能の初期設定のようなものは全くありません。
そのため、インストールが環境したら、サーバーマネージャーから[配置後の構成]を実行し、
追加した役割や機能のための初期設定を行わなければなりません。
このことは、Active Directory証明書サービスに限った話ではなく、
Active Directoryドメインサービスでも、Active Directoryフェデレーションサービスでも同じです。

AD1-40a

配置後の構成で実行するウィザードの最初は、サービスアカウントの指定です。

AD1-41

このウィザードで構成する役割サービスを選択して、次へをクリックします。

AD1-42

証明書サービスの種類を選択します。Active Directoryと連携して証明書サービスを
利用するなら、エンタープライズCAを選択します。

AD1-43

1台目の証明書サーバーなら、ルートCAを選択します。

AD1-44

秘密キーについては既に持っているものを選択する場合を除いて、
新規に作成します(つまり[新しい秘密キーを作成する]を選択します)。

AD1-45

暗号化プロバイダーとハッシュアルゴリズムの選択画面。
ついついデフォルトのまま、進みたくなりますが、
SHA1は既に米国標準の暗号技術ではないので、そのことを気にする人は
SHA256以上にしておきます。

AD1-46

CAの名前を指定して、次へをクリックします。

AD1-47

証明書の有効期間を指定して、次へをクリックします。

AD1-48

データベースの場所を指定して、次へをクリックします。

AD1-49

設定内容を確認して、構成をクリックします。

AD1-50

構成が完了したことを確認して、閉じるをクリックします。

AD1-51

 

繰り返しますが、Windows Server 2012では、役割と機能の追加ウィザードは
単純にコンポーネントを追加するだけのウィザードとなっており、追加した後の初期設定は
[配置後の構成]から実行することになっています。

証明書の発行先を複数に設定する

マイクロソフトの証明書サーバー(Active Directory証明書サービス)を使う機会が私の周りで、にわかに増えています。
証明書サービスって、たしかWindows NT 4.0のオプションパックで提供されたのが最初だったと記憶しているのですが、
その頃に比べると、証明書を利用する場面がとても増えたように思います。

しかしながら、証明書サービスの機能について、しっかり学ぶ場って、逆に少なくなった気がするんですよね。
例えば、私がこれから紹介する「証明書の発行先を複数に設定する方法」というのも、
調べるのに結構時間がかかったりしたので、何か体系的に学べる場があると良いなと思う、この頃です。

■ ■ ■

では、ここから「証明書の発行先を複数に設定する方法」と「発行先を複数にするって、どういうこと?」
について紹介します。

証明書に記載されている属性に、「発行先」と「発行者」という情報があります。

110603-2

発行者には、証明書を発行した証明書サーバーの名前が入り、
発行先には、証明書を利用するサーバーの名前が一般的に入ります。

このとき、メールサーバーでWebメールの機能を提供するSSLサイトにおいて、
イントラネットからWebメールにアクセスするときと、
インターネットからWebメールにアクセスするときで、
異なるURLを使いたい場合には、 異なる発行先ということになりますので、証明書を2枚発行しなければなりません。

例えば、Exchange Serverでは、イントラネットからのOWAアクセスに使うURL(内部URL)と、
インターネットからのOWAアクセスに使うURL(外部URL)は明示的に別々に設定できるので、
同じサーバーにアクセスする場合でも、イントラネットとインターネットで別々のURL(FQDN)になり、
1枚の証明書を使いまわすことができず、2枚の証明書を用意する必要があります。
(FQDNが異なれば、発行先も異なるため)

110603-3

そのときには、1枚の証明書で2か所以上の発行先を指定した証明書の発行方法があります。
(2か所以上の発行先→厳密には2か所以上のFQDNを指定した[サブジェクトの別名]になります)
そのやり方とは、以下のコマンドを実行するだけです。

certutil –setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

実行したら、certsvcサービスを再起動してください。
(net stop certsvcとnet start certsvcコマンドで実行できますね)
すると、以下のような証明書を発行できるようになります。

110603-1

証明書の発行先そのものは、相変わらず1か所しか指定できなのですが、
証明書の[詳細]タブの[サブジェクトの別名]を見ると、
複数の名前(FQDN)が入っていることが確認できます。
サブジェクトの別名は発行先の代わりとして使える名前になりますので、
このような方法で、1枚の証明書で複数のFQDNをサポートできるようになります。

■最後に…
サブジェクトの別名は英語でSANと書くので、ストレージのSANと勘違いしてしまいそうです。
サブジェクトの別名を利用できるようにする設定を英語でSAN Extensionなどと言うそうなので、
関連情報を調べてみたい人は「SAN Extension」で調べてみると良いと思います。

証明書発行に失敗

SSL、IPSec、EFSなどなど、様々な場面で利用することの多い自社運用の認証局。Windows Serverでは、Active Directory証明書サービス(ADCS)という名前でサービスが提供され、実装することができますが、最近はフェデレーションを実装するときにも証明書が必要になってきているので、何かと利用することも多いのではないでしょうか?
今日は、ADCSでハマったことがあったので、書き留めておこうと思います。

ある日、SSL用の証明書をADCSから発行しようとしたところ、”失効サーバーがオフラインのため、失効の関数は失効を確認できませんでした”というエラーメッセージが出てきました。何度か再実行したのですが、同じ結果になったので、何が問題なのか調べてみることにしました。

ADCS20110504-1

まず、「失効サーバーがオフラインのため、失効の関数は失効を確認できませんでした」のメッセージは基本的に、証明書の発行要求をするときに、失効サーバー(CRLを管理するサーバー)にアクセスできないことが原因で表示されます。
失効サーバーはCRL公開ポイント(CDP)という名前で定義され、既定ではADCSのサーバーと同一のサーバーがCDPとなります。また、CDPへのアクセスもLDAP、HTTP、SMBなど用意されているので、既定の設定を変更していない限り、CDPにはアクセスできているはずです。(CDPへのネットワークアクセスが正しく行われているか、細かく確認したい場合にはWireSharkを利用するのもひとつの方法でしょう)

続いて、CRLそのものの設定はどうなっているのかな?と思い、[スタート]-[管理ツール]-[証明機関]から[失効した証明書]のプロパティを開いてみました。すると、以下のような画面が表示されるのですが、Delta CRLが更新の時間を過ぎている([CRL公開のパラメーター]タブで確認可能)のに、Delta CRLが公開されていない([CRLの表示]タブで確認可能)ことが確認できました。
(すみません、下の画面はエラーが発生した時の画面ではありません。エラー発生時はDelta CRLはまだ作られていないことを表す表示になっていました。)
ADCS20110504-2

ADCS20110504-4

そこで、ADCSのサービスを再起動すると、Delta CRLは自動的に生成され、無事に公開されるようになりました。

ADCS20110504-3

そして、再びSSL証明書の発行要求を行うと、今度は無事に証明書が発行されました。

なぜ、このような問題が発生したのかということについてですが、私が推測するに
仮想環境でADCSを動かしていることが原因なのではないかと思っています。
仮想環境だと、仮想マシンの起動と停止が簡単にできます。
そのため、仮想マシンをしばらくの間停止していると、Delta CRLは公開するタイミングを逃してしまい、
公開しなければならないCRLが公開されず、今回のようなエラーになったのだと思います。
このように、仮想マシンを使って様々なサービスを動かすと思いもよらないトラブルに巻き込まれることが
ありますが、ADCSにもこんな落とし穴があったのですね。