- - PR -
クライアント証明書への秘密キーのインポート
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-01-27 21:05
加納様
ご教授有難うございます。 =============================================== >PKI的には「クライアント証明書」を「発行」したのと「同時」および「後」 >に、秘密鍵の「生成」は不可能です。 =============================================== windowsのユーザインターフェースだと、証明書の要求と秘密鍵の エクスポートがボタンのクリック一つで出来てしまうので、 同時に行っているように見え、昨日（1/26）のような記述になって しまったのですが、内部的には 秘密鍵の作成→証明書の要求 の順番になっているはずです。 =============================================== >そもそもが難しいので、「初心者用」の書籍だと「クライアント証明書」に秘密鍵を >インポート、と記述してあるかもしれません。 =============================================== あと、インポートという言葉ですが、参考書等から持ってきた言葉で、 どういう言葉が適切なのかはっきり分からないのですが、「署名」 という言葉の方がふさわしいかもしれません。 コマンドの方が伝わりやすいですかね。 opensslだと以下のようなコマンドになると思います。 cat XXX.key YYY.crt /usr/share/ssl/CA/local/AAAcert.pem | openssl pkcs12 -export -out ZZZ.p12 -name "XXX.key" ※ XXX.keyが秘密鍵 クライアント証明書をユーザにFD等の媒体でお渡ししますが、 その媒体を使って正規でないユーザが勝手にクライアント 証明書をインストール出来ないようにするため、 クライアント証明書に秘密鍵を署名(？)しました。 またお気付きの点ございましたら、ご指摘頂けると助かります。 | ||||||||
|
投稿日時: 2006-01-27 23:58
残念ながらそういうわけにはいきません。何故ならクライアント証明書には有効期限を設定する必要があるからです。もちろん、２０年くらいに設定しておけば事実上無期限ということになりますが、そういう運用をするのであれば、はたまたクライアント認証を採用するメリットが失われてしまうことになります。 | ||||||||
|
投稿日時: 2006-01-28 13:30
要するに「秘密鍵」と「電子証明書」(とやら)をあわせて 「クライアント証明書」 を作成するつもりなんですよね。クライアント証明書を 「SSLでクライアントアクセスするための情報群」 と定義すれば、絶対に間違ってるとは言い切れません。 http://www.drh-consultancy.demon.co.uk/pvk.html にpvktoolというのが載っています。 あと、 http://www.syslabo.co.jp/~hanada/hanada/sig3.html も参考に(というか、まんまのようですが) ということで、今までの手順を勘案して。 ちなみに、以下の手順は、鍵ペアを作りながらも なぜか手動で「電子証明書」と「秘密鍵」の関連を生成してます。 で、結果が「クライアント証明書」です。 (1)サーバ(CA?ほんとはIISというべき気がする)のほうで鍵ペアを生成 ->証明書要求(CSR)と秘密鍵が出来る (2)そのCSRでプライベートCAが「電子証明書」を作る。 (3)で対象クライアントの「電子証明書」(.cer?ファイル)と「秘密鍵」 (.pvkファイル?)をCAから取り出してくる (4)pvktool -in 「秘密鍵」(.pvk)(一人分) -out key1.pem (5)openssl pkcs12 -inkey key.pem -out clientcert1.p12 -keypass abcde のような感じで、「クライアント証明書」を作る。五人いれば(4)-(5)を五回繰り返す (例だとパスワードかacbcd) (6)作った「クライアント証明書」をそれぞれのユーザに配布します(パスワードも それぞれ知らせます) 上記のコマンドは単なる例ですので、動くかどうかは試していません。
それは「署名」とはいいません。原理上、言ってはいけません。 本来の「署名」と区別がつかなくなるからです。まぁ、そういう意味なら 「インポート」がの方が正しいです。厳密にはPKCS#12データの生成といいます。 「インポート」と呼ばないのは、PKCS#12ファイルをユーザの証明書ストアに 「インポート」すると称するので、その「インポート」と混乱するからです。 | ||||||||
|
投稿日時: 2006-01-28 13:37
そもそも「クライアント証明書」に何が書いてあるか知らないのでは。 きっとブラウザに出てくる「画面」が「クライアント証明書」 だと思ってるよ、きっと。「画面に出てきた」有効期限を変更するのは どうするんですか?などと言いかねませんね。 少なくもと、この質問対象のシステム運用であればデメリットばっかりなので 顧客には推奨しないですよね。 「厳密に」設計し運用する要件があるならともかく、とくに条件がないわけですから。 「簡単に」「楽に」つかうために、とりあえずPKIというよく分からない枠組み を導入しようとしてるわけですから、PKIのメリットを導入できるわけがありません。 | ||||||||
|
投稿日時: 2006-01-28 23:29
余談になりますが、まあＰＫＩを全く知らずしてＳＳＬを導入している技術者が８割を軽く超えているのが実情だとは思いますけどね。ＳＳＬが暗号化するだけのものだと思って導入している人も結構いるのではないでしょうか。ブラウザに警告画面を表示させたくないだけならＶ社もっと安い料金で発行してもらえる認証局があるはずなのに・・・。 あと、Apache でのサーバ運用で、以下のような訳の分からない手順を情報をネット上で公開している人が山のようにいるのですから。 $ openssl genrsa -des3 -out server.key 1024 ... $ openssl rsa -in server.key -out server.key.nopass これでは、何のために genrsa 時に -des3 オプションを付けているのかサッパリ。 こんなことをするくらいなら、最初から秘密鍵を暗号化しなければよいと思うんですけどね。 $ openssl genrsa -out server.key.nopass 1024 | ||||||||
|
投稿日時: 2006-01-29 21:04
簡単にpvk to PKCS#12にする方法。
上記で「pvktool」を紹介しましたが、自分がコンパイルできませんでした(苦笑) ということで、もっと簡単にPKCS#12にする方法です。 ほとんどMicrosoft謹製、なので問題ないと思います。 (1)http://www.microsoft.com/japan/msdn/vba/technical/pvk.htm から「PVK Digital Certificate Files Importer (英語版)」をダウンロードする。 (2)解凍(一回起動する)した後インストールする。以下の例では C:\\Program Files\\pvkにインストールした。 (3)以下のように起動する。 "C:\\Program Files\\pvk\\PVKIMPRT.EXE" -pfx mypvk.cer mypvk.pvk mypvk.cerは電子証明書(クライアント用) mypvk.pvkは秘密鍵。 パスワードとかをいろいろ聞かれるので、適当に答える。 PVKIMPRT.EXEのUsageには、「電子証明書」を「SPCファイル」あるが 普通に電子証明書のファイルでも問題ないです。「SPCファイル」というのは 要するにPKCS#7データ(.p7b)のことなので、別に関係ないっす。出来なかったら Cert2SPC.exeしてSPCファイルにしてもいい(少なくともWindows XP上では 不要) するとpfxの出力自体はウィザード形式で聞かれますので、その順番で やれば出力できます。ウィザード形式なので分かりやすいかと。 | ||||||||
|
投稿日時: 2006-01-29 21:35
ですね。そのお蔭様で、PKI系の場合、顧客に「一桁」違う見積もりを出しても、 そのまま受け入れられてしまうこともあります。PKIなんて言っても簡単なので、 仕事自体はすぐ終わってしまったことは、ときた〜まありますね。一ヶ月暇してるとか。 そもそも「PKI」といっただけで誰も、中身も実現性も、分からないので、 困難度を見積もれないらしい。その仕事は、課長が師匠筋だったので予算リスク (「予算がないから「残業」せずにとにかくやれっ」とか)もないので 楽だったなぁ。 ソフトウェア開発で「予算リスク」「技術リスク」(どのような技術を 使うか分からないし、使い方も分からない) がほぼ0で見積もれるなら、確実にできるとはいいませんが、まぁ失敗しない でしょ。 開発プロセスが完全か、というのは問題が残りましたけど、、、 そんな「細かい」レベルで今の惨状があるわけではないでしょ。
確かにSSLに「暗号化」以外がある、というと大抵驚かれますね。 しかも「警告」画面の意味が分かってないは多い。。だから警告を「ださない」 ためだけにべりサイン社に「お布施」の意味あいで払う(もちろんべりサイン社は 「お布施」だと思ってないだろうけど)人もよくいる気がしますね。 まぁ、そういうビジネスに乗っかってる(?)私が言うのもなんですが。 他国も、日本国以外も同様なんですかねぇ。SSLを知らないこともそうですが。 私なんか自慢ではありませんが、給料は下がってますよ(苦笑)。 ・技術が分かる(SSLサーバ証明書を発行するCAはSSLを使用するレベルによって ランク付けして決定するべきである) ・技術が分からない(SSLの証明書とやらは、SSLを使う際のお布施と思ってる) だと後者のほうが偉かったりしますからね。 だから、「技術者」が知らなくても無理はない、と思ってます。 それが正しい状態なのかは、、、 | ||||||||
|
投稿日時: 2006-01-30 18:41
加納様、あんとれ様
ご教授有難うございます。 PVKIMPRTのツールの使い方ですが、貴重なお時間を割いて、 実際に試した上でご回答を頂き、有難うございます。 私の方でもpvkimprtを実際に使ってみて、PKCS#12を作成することが できました。 =============================================== ＞残念ながらそういうわけにはいきません。何故ならクライアント証明書には有効期限 ＞を設定する必要があるからです。 =============================================== 実は、2年くらいしか使わないシステムでして、とりあえず、 レジストリを変更して、証明書の有効期限を延長出来ることを 確認致しました。 本当に有難うございました。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。