- PR -

クライアント証明書への秘密キーのインポート

投稿者投稿内容
odik
ベテラン
会議室デビュー日: 2005/02/07
投稿数: 69
投稿日時: 2006-01-20 10:02
OS:Windows Server 2003 Standard Edition
webサーバ:IIS6.0
にてwebサイトを構築しています。

ブラウザからwebサイトへのアクセスにはクライアント証明書
の提示を必須としたいと考えております。

大まかに以下の流れで作業をしております。
[1]webサーバにてスタンドアロンCAを構築する。
 (証明書サービスをインストールする)
[2]スタンドアロンCAにてサーバ証明書、クライアント証明書
を発行する。
[3]それぞれの証明書をサーバ及びクライアントへ
インストールする。
[4]webサイトの設定にて、アクセス時にクライアント証明書を
必須とするように設定する。


<質問>
スタンドアロンCAにて、クライアント証明書を発行する際に、
オプション「エクスポート可能なキーとしてマークする」を
選択し、秘密キーをファイル(拡張子pvk)にエクスポートしました。
さらに、証明書サービスにてクライアント証明書を発行しました。

次に、クライアント証明書に秘密キーをインポートしたいのですが、
その方法が分かりません。
CAPICOMコンポーネントにより実現できるようなのですが、
どなたかご存知の方がいらっしゃいましたら、ご教授下さい。
宜しくお願いします。
加納正和
ぬし
会議室デビュー日: 2004/01/28
投稿数: 332
お住まい・勤務地: 首都圏
投稿日時: 2006-01-25 02:02
引用:

kidoさんの書き込み (2006-01-20 10:02) より:
<質問>
次に、クライアント証明書に秘密キーをインポートしたいのですが、
その方法が分かりません。
CAPICOMコンポーネントにより実現できるようなのですが、
どなたかご存知の方がいらっしゃいましたら、ご教授下さい。



はぁぅぅ(嘆息)
鍵ペアの意味内容が何もわかってない。

いや、そもそも「セキュリティ」のなんらかも知ってそうにない。
CAなどのPKIは単にセキュリティを確保するための一技術に過ぎないので
「無目的」に導入してもセキュリティ向上に「全く」効果がない。

さらにしかも、プライベートCAなんて機能向上にすら、何一つ役に立たない。

たんにはりぼてが置いてあるのと大差ない。
「ここから先危険」と「捨て看板」を置いただけだ。
何かを守ってるわけではない。昨今では逆にクラッキングの踏み台目標にされるだけだ。
「何一つわかってない」ことがばればれだから。

ま、どうでもいいか。

質問を意訳すると、要するにクライアント証明書をクライアントに配布したいん
ですよね。

>秘密キーをファイル(拡張子pvk)

を拡張子pvkぢゃなくて->p12にすべく設定をがんばって、そのp12ファイルを
クライアントマシンに置いてダブルクリックすればいいです。

で、終わり。セキュリティ的にも。
俺だったら、そのシステムは、クラッキングの第三目標ぐらいには入れておくね。
システム管理者がシステムの中身を分かってなさそうだから。

なに?内部だから大丈夫?セキュリティ破りのほとんどは内部からだよ。
なんの安心にもなりゃしない。そもそもそんなシステム外部にさらしたら一発だよ。

つーことで、踏み台にして、うはうは。(完全死語)

でも、めぐりめぐって修正するの、俺だったりして(苦笑)
あんとれ
ぬし
会議室デビュー日: 2004/01/14
投稿数: 556
投稿日時: 2006-01-25 19:34
引用:

次に、クライアント証明書に秘密キーをインポートしたいのですが、
その方法が分かりません。



IIS のことについては詳しくありませんが・・・出力するファイルの形式というのを選択する画面はありませんでしたか?

あったのであれば、PKCS#12 (Personal Information Exchange, PFX) 形式で出力して下さい。拡張子は p12 または pfx です。

引用:

[1]webサーバにてスタンドアロンCAを構築する。
 (証明書サービスをインストールする)
[2]スタンドアロンCAにてサーバ証明書、クライアント証明書
を発行する。



クライアント証明書については上記で構いませんが、サーバ証明書については自分がクライアントになるのならともかく (それさえもあまり望ましくありませんが)、他の方に使ってもらうのであれば、一般的に信頼されている認証局 (Verisign, Thawte, Geotrust, etc) に署名してもらわないと、知識のないユーザはともかく、それなりに知識を持ったユーザにはそのサイトを信用してもらえず、サーバ認証に失敗してしまいます。
odik
ベテラン
会議室デビュー日: 2005/02/07
投稿数: 69
投稿日時: 2006-01-25 21:17
加納様、あんとれ様
ご教授有難うございます。

私の説明不足で構築しようとしているシステムが
伝わっていないような気がしますので、補足させて
下さい。

@本システムにアクセスするユーザは5名ほどであり、
全ユーザを把握している。

AスタンドアロンCAにて上記@のユーザ分のクライアント
証明書を発行して以後、クライアント証明書を新たに
発行することはない。

BスタンドアロンCAで作成したクライアント証明書に
秘密キーをインポートした上で、ユーザにクライアント
証明書を手渡す。その際、秘密キーのパスワードを
お教えする。

Cユーザは上記Cにて教えられたパスワードを入力しな
ければ、クライアント証明書を端末にインストールできない。

Dwebサイトへアクセスする際に、クライアント証明書
を保持していないものはアクセスを拒否する。

加納様の返信を読んでいますと、ユーザからの要求に
応じて、その都度、クライアント証明書を配布するため、
スタンドアロンCAを構築しようとしている様に思ったの
ですが。違いますか?


>PKCS#12 (Personal Information Exchange, PFX) 形式で出力して下さい。
これがモーダルになってしまって選択できないのです。

>それなりに知識を持ったユーザにはそのサイトを信用してもらえず、サーバ認証に失敗してしまいます。
本システムを使用するユーザにはサーバ証明書が一般的に信頼されている
認証局からの証明書でない旨、お伝えしてあるのですが。
(そんなのは理由にならないですかね。)
加納正和
ぬし
会議室デビュー日: 2004/01/28
投稿数: 332
お住まい・勤務地: 首都圏
投稿日時: 2006-01-26 00:22
引用:

kidoさんの書き込み (2006-01-25 21:17) より:
@本システムにアクセスするユーザは5名ほどであり、
全ユーザを把握している。

>PKCS#12 (Personal Information Exchange, PFX) 形式で出力して下さい。
これがモーダルになってしまって選択できないのです。



あ〜、その「5人だけが使用するレベル」だとSSLサーバ+Basic認証(パスワード)
で十分だと思うのだが、、なんでわざわざ「クライアント証明書」なんかを?そもそも
PIN(Personal Identity Number)は秘密キーのパスワードとして、各ユーザに
教えるんでしょ?
5人のPINをa,b,c,d,eという風に設定しとけばいいやん。で、いわゆるふつーのbasic
認証にしておけばいいのに。

機能的にはbasic認証と「クライアント証明書」で、何の違いもないよ?しかもIIS上でしょ?IISって、クライアント証明書をNTアカウントにマッピングするのでは。

まぁそれはともかく。

そもそも、kidoさんのシステムだと
「クライアント証明書」
「秘密鍵」
は関係ない気がする。
「秘密鍵」ってIISに入れてある、SSLサーバ用の秘密鍵だったりしない?
それは「クライアント証明書」とは何の関連もない。

ちなみにCAPICOMは、鍵ペアを作る「人」を、クライアント側に出来ます。
そうすると、そもそも秘密鍵はそのパソコンから出てこないので、そういう意味では
自由にできる(ただしクライアント証明書発行をクライアント側から行う必要が生じて
クライアントに不利益がある)

でもいいわけです。

、、上記だと「クライアント証明書」をサーバ側で作って配布する話をしてる気が。
どっちなんだろう?おそらく、そもそも区別がついてない気がする。

大抵の人は区別をつける理由はないのでSSLサーバ+basic認証で満足してます。
クライアント証明書を使用する必要は何?SSLサーバ証明書用に、近年で言う
「オレオレ証明書」を使う必要があるので、プライベートCAを立てるのは良くありますけど。

ということで私のお勧め

「クライアント証明書」と「秘密鍵」をサーバ側で生成して配布するシステムは、
設定する理由さえないのでさっさと止める。で、Basic認証だけ使う。

普通はクライアント証明書なんて、使いたくないけど、どうしようもないから
使うだけです。対象システムである、IISに設定するタイプの認証なんて
Basic認証で十二分。

これがまた、クライアント証明書に設定されている情報を不特定かつ多数の中から
少数だけを選別して、いろいろ振り分けなきゃいけないとか、「クライアント証明書」
が明らかに出来そうなことをしなきゃいけない場合には、残念ながら使います。

でも、この場合単に特定の「誰か」を振り分けるだけなら、全く不要ですけど。。。

これがちゃんと「クライアント証明書」と「秘密鍵」の区別がついていれば
なんとかなりますけど、そうぢゃなさそうだし。

ちなみに「クライアント証明書」使用を検討する際に「Basic認証」より「セキュリティ」
が高まる気がするから、というのがありますが、全くの誤解です。

むしろ、この場合「クライアント証明書」のデータを配る必要があるだけ面倒が増えて
るだけです。

Basic認証は、パスワードを平文で流すからセキュリティが低い、と言われてますが、
運用の仕方によっては「クライアント証明書」を配布するほうがセキュリティが高くなる
というだけです。単にほっとくのであれば、むしろセキュリティは低くなります。

たとえば「クライアント証明書」をパソコンに入れたままだと、それを抜き出されて
まんま踏み台に使われるかもしれません。それだったらBasic認証と変わらないか、
下手すると低くなってるでしょ。

通常は、ここらへんの「設計」をしてから設定するんですけど。。。
あんとれ
ぬし
会議室デビュー日: 2004/01/14
投稿数: 556
投稿日時: 2006-01-26 01:06
引用:

>それなりに知識を持ったユーザにはそのサイトを信用してもらえず、サーバ認証に失敗してしまいます。
本システムを使用するユーザにはサーバ証明書が一般的に信頼されている
認証局からの証明書でない旨、お伝えしてあるのですが。
(そんなのは理由にならないですかね。)



はい、理由になりません。クライアントがそのサーバ以外のサーバに一切接続できない環境に置かれているというのであれば話は別ですが・・・。プライベート認証局で発行したルート証明書をインポートすることは、その認証局で発行された全ての証明書を信用することになります。もし、kido さんの立てたサーバが何者かに侵入されて証明書を勝手に作成され、Web サイトを建てられたらどうなるでしょう? クライアントはその侵入者の建てた Web サイトも無条件で信用したことになってしまいます。

Verisign などの認証局は少なくとも証明書を発行するのにネットワークに繋がったマシーンを使用おらず、専用の署名室をもうけている (Verisign 社の場合) とまで聞いたことがあります。逆に言えば、クライアントに信用してもらう (ルート証明書をインポートしてもらう) にはそれだけ厳重な管理をしなければならないということです。

だからこそ、サーバ証明書に対して年間8万5000円を出す価値があると企業が判断するのでしょう。(ブランド力の方が強いような気がしなくもないですが・・・)

あと、認証局を建ててルート証明書をクライアントに取り込んでもらうというのであれば、フィンガープリント (DER 形式で出力したファイルの MD5 または SHA1 ダイジェスト, Internet Explorer では「捺印」) の確認の指導、証明書ポリシーの策定および公開 (Verisign 社の例 : https://www.verisign.com/repository/rpa.html)、 CRL 配布地点の設定および定期的な CRL の配布などをすることも検討して下さい。(非常に大変なことだと思いますが・・・)

引用:

>PKCS#12 (Personal Information Exchange, PFX) 形式で出力して下さい。
これがモーダルになってしまって選択できないのです。



少なくとも、キーペアファイルと証明書が出力できれば OpenSSL などで変換できます。
ただ、Internet Explorer でも実装しているクライアント証明書のエクスポートを IIS の CA が実装していないとは思えませんが・・・。

余談になりますが、サーバ証明書を作成するときに秘密鍵を認証局に渡さないのと同じで、クライアント証明書を作成するときもクライアントは自分で秘密鍵および証明書署名要求 (CSR) を作成し、認証局である kido さんには秘密鍵を公開しないのが本来の運用方法です。従って、本来の運用方法を採用した場合、kido さんは秘密鍵を知る余地もないことになります。

-- 2006-01-27 追加 --
クライアント認証がベーシック認証やダイジェスト認証に比べて有利な点は、発行が簡単なこと (あくまで CSR までをクライアントに作成してもらう場合の話)、キーペアの強度 (RSA の場合で 512 or 1024 ビット) が8文字程度のパスワード (ASCII コードを用いた場合で 7 x 8 = 56 ビット) よりも圧倒的に強いこと、有効期限を設定できること (つまり運用によってはキーペアの定期的な変更を強制できる)、クライアントが毎回パスワードの入力画面を見なくてもよいことなどです。デメリットは、失効は定期的に CRL を発行し、サーバに読み込ませなければならないこと、PKIに関する技術知識が必要なこと (本当はサーバ認証をやる上でも必要なことなのですが・・・) などです。

[ メッセージ編集済み 編集者: あんとれ 編集日時 2006-01-27 23:53 ]
odik
ベテラン
会議室デビュー日: 2005/02/07
投稿数: 69
投稿日時: 2006-01-26 22:21
加納様、あんとれ様
ご教授有難うございます。

夜の遅い時間にお疲れだと思いますが、
ご返信頂きまして、感謝感謝です。

お陰様で、まだまだなんとなくですが理解でき始めた
ように思えます。

何度も恐縮なのですが、まだ私の説明が不足している
と思われる箇所がありますので、お詫びして訂正させて
頂きます。
(ちゃんと理解していないので、説明が下手なのです。
 すみません。)

昨日(1/25)に、@〜Dで記述した箇所でAとBを訂正
させて下さい。

(変更前)
AスタンドアロンCAにて上記@のユーザ分のクライアント
証明書を発行して以後、クライアント証明書を新たに
発行することはない。

BスタンドアロンCAで作成したクライアント証明書に
秘密キーをインポートした上で、ユーザにクライアント
証明書を手渡す。その際、秘密キーのパスワードを
お教えする。


(変更後)
AスタンドアロンCAにて上記@のユーザ分のクライアント
証明書を発行する。その際、クライアントの秘密鍵を生成し、
エクスポートする。
以後、クライアント証明書を新たに発行することはない。

BスタンドアロンCAで作成したクライアント証明書に
上記Aでエクスポートした秘密キーをインポートした上で、
ユーザにクライアント 証明書を手渡す。
その際、秘密キーのパスワードを お教えする。


===============================================
>そもそも、kidoさんのシステムだと
>「クライアント証明書」
>「秘密鍵」
>は関係ない気がする。
===============================================
秘密鍵とクライアント認証の関係は上記の様になります。

どうであれ、アントレ様が指摘された以下の事項に
違反しておりますね。
===============================================
>認証局である kido さんには秘密鍵を公開しないのが本来の運用方法です。
===============================================

===============================================
>「クライアント証明書」と「秘密鍵」をサーバ側で生成して配布するシステムは、
>設定する理由さえないのでさっさと止める。で、Basic認証だけ使う。
===============================================
実は、業務アプリでブラウザからアクセスしたときに初期画面で
Basic認証と同じこと(ユーザ名とパスワードの入力)をやって
おります。そうすると、クライアント証明書なんて不要って
ことですかね?
該当するクライアント証明書を持っていないブラウザは、
その初期画面すら表示できない。ってことがしたかったんです。


===============================================
>もし、kido さんの立てたサーバが何者かに侵入されて証明書を勝手に作成され、Web サイトを建てられたらどうなるでしょう? クライアントは>その侵入者の建てた Web サイトも無条件で信用したことになってしまいます。
===============================================
非常に分かりやすいご説明有難うございます。
サーバ証明書はやり直しです。

お二方とも本当にどうも有り難うございます。
またお気付きの点ございましたら、ご指摘頂けると助かります。
加納正和
ぬし
会議室デビュー日: 2004/01/28
投稿数: 332
お住まい・勤務地: 首都圏
投稿日時: 2006-01-27 00:51
引用:

kidoさんの書き込み (2006-01-26 22:21) より:
(変更後)

AスタンドアロンCAにて上記@のユーザ分のクライアント
証明書を発行する。その際、クライアントの秘密鍵を生成し、
エクスポートする。
以後、クライアント証明書を新たに発行することはない。



PKI的には「クライアント証明書」を「発行」したのと「同時」および「後」
に、秘密鍵の「生成」は不可能です。

なぜ?クライアント証明書を「発行」する「前」に鍵ペアを生成しなくてはいけない
からです。ここらへんの「公開鍵認証基盤」(PKI)の意味(制約条件)が全くわかって
いらっしゃらないのでは。

PKIはなんでもかんでも成立する環境とは違います。ある前提が存在するからこそ
「認証」の基盤足りえるのですから。魔法の環境ではないのですよ。

引用:

BスタンドアロンCAで作成したクライアント証明書に
上記Aでエクスポートした秘密キーをインポートした上で、
ユーザにクライアント 証明書を手渡す。
その際、秘密キーのパスワードを お教えする。



あとPKI的には、「クライアント証明書」に秘密鍵を入れることは不可能です。
根本的には、PKIを理解してないせいかと。直接的には「クライアント証明書」
なるデータ内容を想定すらできていないのでは。

PKI的には、「クライアント証明書」というのは意味内容が厳密に定められたデータ
です。その意味内容によると、「発行」後には、データ内容が変化しません。
だから、「インポート」なり、「追加」なんてのはありえないのです(PKI的に、です。)

もちろん、純然たる意味でバイナリデータなのでデータを変更することは原理的には
可能ですが、その場合は「クライアント証明書」とはPKI的にはいえなくなります。

考えても見てください。そんな簡単に変更できちゃったら、
どうやって「クライアント証明書」を信用するんですか?

ということで、「クライアント証明書」への秘密鍵のインポート、でWebページ
を検索しても原理的にありえないので、検索がヒットしないわけです。

、、、あ〜、ここらへんの関係は、PKIの勉強でもすればすぐわかる(多分)のですが、、
そもそもが難しいので、「初心者用」の書籍だと「クライアント証明書」に秘密鍵を
インポート、と記述してあるかもしれません。

分かりやすさ、と難しさを天秤にかければ、必ずしも間違った記述ではありません。
が、「初心者用」の本をみてシステムを構築してはいけない。。。。

引用:

秘密鍵とクライアント認証の関係は上記の様になります。



うーむ、さらに謎(?)が深まっただけだ。(苦笑)
PKI的には全くありえない関係です。

引用:

===============================================
>「クライアント証明書」と「秘密鍵」をサーバ側で生成して配布するシステムは、
>設定する理由さえないのでさっさと止める。で、Basic認証だけ使う。
===============================================
実は、業務アプリでブラウザからアクセスしたときに初期画面で
Basic認証と同じこと(ユーザ名とパスワードの入力)をやって
おります。そうすると、クライアント証明書なんて不要って
ことですかね?
該当するクライアント証明書を持っていないブラウザは、
その初期画面すら表示できない。ってことがしたかったんです。



ぐはっ。ぢゃあ全く意味ないんじゃん。ちなみにBasic認証とは
ユーザ名:
パスワード:
のダイアログだけが「ぼこっ」と出てくる認証を指してます。それを
「初期画面」と言われれば、そうなのかもしれないけど

ちなみにIEだと出来ないかもしれないけど、Operaとかfirefoxだと、Basic認証
のユーザ名とパスワードを記憶できるので、ほんとにリターンだけで済みます。

引用:

非常に分かりやすいご説明有難うございます。
サーバ証明書はやり直しです。



そうなんだ。ぢゃあ「クライアント証明書」なんてやり直し以前に存在すら
しなくなるわけだ。
私だったらCA立てるなら、適当に立てちゃうけどね。もちろんリスクは分かった上で、
ですよ。といっても最初から全部分かったら、この仕事、苦労しないんだけどね。

スキルアップ/キャリアアップ(JOB@IT)