- - PR -
PKIの通信について教えてください
1|2|3|4
次のページへ»
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-12-05 19:19
度々お世話になります。
現在、プライベートCAサーバを立てて2つの機器同士を証明書を使って通信させようと考えています。 ただ、私の知識不足で根本的なPKI通信手順が良く分からずTryしてはまってます。 詳しい方、以下につきましてお教え頂けませんでしょうか。 1)2つの機器にインストールする証明書は、それぞれの機器でCSRを作成して プライベートCAで署名し、証明書を発行してます。 Q.そもそも、これらの証明書で2つの機器が認証されるのでしょうか? 2)機器が証明書を使用して通信を開始する時、プライベートCAへ問い合わせを しにいくのでしょうか? ※2台の機器がプライベートCAにアクセスできる必要がある? 3)2)の場合に、各機器はどうやってプライベートCAの所在を(アクセス先) 知るのでしょうか? プライベートCAは、opensslを使用しております。 質問ばかりですみませんが宜しくお願い致します。 | ||||||||||||
|
投稿日時: 2007-12-05 22:14
まずは、
・秘密鍵で暗号化したデータは、対になる公開鍵で復号化できる ・公開鍵で暗号化したデータは、対になる秘密鍵で復号化できる ・署名=秘密鍵で暗号化すること ・署名の検証=署名を公開鍵で復号化して一致を検証すること ・証明書=何らかの公開鍵をCAの秘密鍵で署名したもの であることを理解しましょう。 この辺を前提にSSLの相互認証の手順を調べてみて下さい。
機器がお互いに相手の証明書の正当性を検証することで認証します。 具体的には、自身の信用するCA(この場合はプライベートCA)が 署名をした有効な証明書であることを検証することになります。 ⇒ 証明書が偽造でないことの証明(偽造にはCA証明書の秘密鍵が必要) その後は、相手が、相手の証明書の秘密鍵で署名したデータを、 自分が、相手の証明書の公開鍵で検証できれば、相手が証明書の 正当な所有者であることを検証できたことになります。 ⇒ 証明書の正当な所有者であることの証明(偽装には証明書の秘密鍵が必要) この検証を通信を行う両者が行えば、お互いを認証することができます。
通常はしません。 そんな仕組みだとしたら、VeriSignなどの有名どころのCAの トラフィックは凄まじいことになってしまいます。 ただし、CRL(証明書失効リスト)をリアルタイムに確認する場合もあります。
事前に機器側に信用するCAの証明書をリストを登録しておきます。 | ||||||||||||
|
投稿日時: 2007-12-06 18:15
あしゅ様
詳しいご回答ありがとうございます。 なぞがだいぶ明確になってきました。 今回はSSLではなくVPN接続で使用しようと考えております。←シャレではありません。 1台はVPNアプライアンス、もう1台はVPNクライアントソフトをInstallしたPCです。 ●公開鍵・秘密鍵はいずこに 両機器には「certificate enrollment」というような項目があります。 そちらでOU・CN等を登録し、作成されたrequestをプライベートCAへ 持っていき CA.sh -sign にて証明書を作成しています。 しかし、両機器をよくみると何処に公開鍵・秘密鍵があるか分かりません。謎です。 ちなみにrequestを元に署名した証明書はそれぞれの機器にインストールはできます が、クライアント側ではunable to certificate だと言われて有効ではないようです。 もう少し進展がありましたらまた投稿させて頂きます。 | ||||||||||||
|
投稿日時: 2007-12-06 19:13
秘密鍵が盗まれないように、キーストアの場所が秘密になっているのでしょうか。 ただ生成した鍵ペアはバックアップしたいですよね。 バックアップとか、エクスポートの機能は探せば普通はあると思います。 PKCS #12というフォーマットでエクスポートできるようになっていることが多いです。
ちなみにプライベートCAの証明書は各々の機器にインストールされていますよね。 もしそうでないと、相手から証明書が送られてきても、CAによる署名の検証ができません。 CAの証明書は多くの場合は機器にインストールさせる形になっていると思います。 厳密にいうと、プライベートCAの証明書、その証明書に署名したCAの証明書・・・とたどって ルート証明書までの証明書チェーンが必要です。 ただ今回のケースではopensslで作成したプライベート証明書はおそらく自己署名証明書 (ルート証明書)になっているでしょうから、それだけインストールすればよさそうに 思えます。 では。 | ||||||||||||
|
投稿日時: 2007-12-07 16:46
blunder様
鋭いご指摘有難うございます。 クライアント側機器へのCAcertはインストールしておりませんでした。 クライアント側へもCAcertをインストール後、クライアントの証明書をVerifyしてみるとやはり「unable to verify」になります。 詳細ログを確認した所「Cert chain missing or intermediate CA signature failed - Cert verification failed.」と出ました。 次にCN以外は全てCAに合わせて再度Enroll〜CAでの署名〜Certificateインストールを実施して、同様にVerify確認しましたが状況変わらずでした。 ※ちなみにCAcertをVerifyして見ると「Cert (cn=xxx,o=AAA,st=BBBBB,c=JP)verification succeeded.」と出ます。 エラー対処方を色々調べた所、有効期限を短くする。CAサーバ側の設定問題、という位の情報しか出てきません。有効期限はTryしましたが変わらずでした。 色々とアドバイスを頂きましたがお手上げです。 もしかすると、クライアント側からプライベートCAにはネットワーク的に恐らくアクセスできないのが原因では?と思ってしまいますがそうではないのですよね。 [ メッセージ編集済み 編集者: tohero0987 編集日時 2007-12-07 16:58 ] | ||||||||||||
|
投稿日時: 2007-12-07 18:01
出遅れましたw
その通り、ここのクライアントがルータを意味しているとするとCAサーバに アクセスできない状況では設定できません。 参考までにウチで行なっている手順は下記の通りです。 1.コンソール接続 2.PPPoEの確認 3.clockの確認 4.IPSECの確認 5.pingによる疎通確認 6.RSA鍵の作成 7.CA証明書の要求 8.ルータ証明書の要求 9.CAサーバサイトへ証明書の発行を依頼 10.IPSEC PEERの張りなおし 11.IPSECの確認 12.疎通確認 13.configの保存 (社内資料より項目のみ抜粋) 私自身は実際に作業しておりませんので詳細説明はできませんが・・・。 | ||||||||||||
|
投稿日時: 2007-12-07 19:02
こんばんは。
Certificate Enrollment Protocolって言うんですかね。 CAサーバに自動で証明書をオンラインで発行してもらう仕組みがあるらしいですね。
って、その話なのでしょうか。 この件、全く詳しくないので野次馬です。 蛇足ながら、
この説明はマズくないでしょうかね…。 | ||||||||||||
|
投稿日時: 2007-12-07 19:35
それは変です。 ちなみに機器への配布前の状態で(つまりプライベートCAにおいて)、ローカルにはverify できているんでしょうか。 たしか openssl verify -CAfile CAの証明書 配布する証明書 だっけかな。 もともとエラーだったりしません? |
1|2|3|4
次のページへ»