任意のサブジェクトを持つクライアント証明書発行 certreq.exe

前回の 任意のサブジェクトを持つクライアント証明書の発行 の失敗について、証明機関側は Windows Server 2008 Enterprise を使うことで解決したこととして、今回はクライアント側の操作について。

Windows における証明書の要求作成には Certreq.exe を利用する。仕様については Certreq.exe Syntax に記載されている。

操作手順としては How to enable LDAP over SSL with a third-party certification authority が参考になる。この記事はサーバ向け証明書の発行手順であるが、.inf の中身以外については手順は同じ。

  1. 証明書の要求内容を記載した example.inf を作成する
  2. certreq -new example.inf example.csr コマンドでCSRファイルを作成する。秘密鍵は証明書ストアに保存されている
  3. 証明機関に CSR ファイルを送付し、証明書を発行してもらう
  4. 発行された証明書を入手し、example.crt として保存
  5. 入手した証明書を certreq -accept example.crt で取り込む
  6. 証明書ストアの内容を確認する
  7. (クライアントの場合は再起動不要)

証明書ストアの内容確認については、クライアント証明書の場合 インターネットエクスプローラ のオプションから確認できる。

certreq -new の時点で指定する example.inf の内容は以下の通り。

[Version]
Signature="$Windows NT$

[NewRequest]
Subject = "CN=Fred"
KeySpec = 1
KeyLength = 1024
Exportable = TRUE
MachineKeySet = FALSE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
; ProviderName と ProviderType を調べるには certutil -csplist を実行する
ProviderName = "Microsoft Enhanced Cryptographic Provider v1.0"
ProviderType = 1
RequestType = PKCS10
; CERT_DIGITAL_SIGNATURE_KEY_USAGE, CERT_KEY_ENCIPHERMENT_KEY_USAGE
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]
; Client Authentication
OID=1.3.6.1.5.5.7.3.2

How to enable LDAP over SSL with a third-party certification authority で示される .inf と異なっている点は以下の5点

  • Subject : これは発行したい証明書に含めるSubjectなので当然
  • MachineKeySet : コンピュータ用証明書ではなく、ユーザー用証明書として格納する
  • ProviderName : クライアントマシン内で certutil -csplist を使うと一覧が得られる。また、ブラウザからWindowsServerの証明機関に繋いで普通にクライアント証明書を発行しようとした場合に表示されるものを利用
  • ProviderType : ProviderName に対応する数値を Certreq.exe Syntax を見て確認
  • EnchancedKeyUsageExtension 中のOID : 1.3.6.1.5.5.7.3.2 はクライアント用、1.3.6.1.5.5.7.3.1 はサーバ用。リファレンスとして適切と思われる資料は検索でたどりつけなかった。

ちなみにこれをやりたかった理由は、WCF Step by Step 本の中でクライアント証明書による認証に関連して。なのでこの本に出てくる名前 CN=Fred が上のサンプルになっている。俺は makecert.exe によるオレオレ証明書作成は開発目的であろうとやらない。むしろ開発者にそういう習慣をつけてしまうと後工程に対して悪い習慣が蔓延しがちなわけで、強く避ける方向で。

MSDNライセンスを持っていれば開発用のWindowsServerライセンスがあるわけだし、イマドキは仮想マシン立てるぐらいはどってことないはず。以下のような感じで開発環境構築するのがいいと思う。

  • 開発用の証明機関を立てて、開発マシンはその証明機関を信頼できるルート証明機関として登録する
  • 開発マシン*以外* 、実運用で利用している社内環境にはその証明機関を「信頼できない証明機関」として登録する。これにより間違って 信頼できるルート証明機関 として登録されても保護されるはず。
  • 外部に対しては特に何もしない。

「信頼できない証明機関」として登録する、のところはActiveDirectory管理してるのが前提で、1マシンずつ証明機関の証明書を登録するなんてことは「すべきではない」。

一方で開発マシンに対して個別にルート証明機関として登録するのはやむなしであろう。開発マシンだとActiveDirectoryに参加できない場合もあるし。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。