12-2. ＷＷＷサ−バ暗号化の様子 (1) 暗号化ＷＷＷサ−バ／メ−ル * １９９６年当時からある暗号化ＷＷＷサ−バ '96 知られているものとしては Netscape Commerce Server がある。 Communications Server は暗号化に対応していないものである。Commerce Server の暗号化は Netscape 社が開発 した SSL( Secure Socket Layer ) プロトコルで実装されている。これは公開されており、 CERN や Apache にも拡張機能として実装することができる。 SSL のほかに Secure HTTP というのを Mosaic 陣営が出しているが、お目にかかったことがない。 Netscape のサ− バの値段はどうもはっきりしないが、９６年４月、ある国産ＥＷＳメ−カがもってきた見 積りによれば、実売価格は大体次のような値段だった。 ９６年８月頃 Silicon Graphics 社に Commerce Server の見積りをとったら１６万円だったが。安なったの？。 Netscape Communications Server ： ２０万円前後 (暗号化なし) Netscape Commerce Server ： ５０万円前後 (暗号化あり) Netscape Proxy Server ： ３０万円前後 Commerce Server を暗号化して稼働させるめには、Netscape Navigator 等で暗号化ファ イルを解読（複合化）するための公開鍵を含んだデジタルＩＤを、証明書発行者から取得 しなければならない。デジタルＩＤの取得は、米 VeriSign,Inc 社の日本代理店である日 本ベリサイン(株)から、サ−バ用として、印鑑証明書クラス３を発行してもらうことによ る。これには会社の登記簿謄本や印鑑証明書が必要である。クラスというのは、VeriSign が証明する際の確認のレベルである。クラス１が一番簡単な確認であり、４まである。 ================================================================================ とこんな説明や記事が目に止まるが、デジタルＩＤは自分で発行することができる。日本 ベリサインは今のところ発行せず、アメリカの http://www.verisign.com/ から取得する。 ================================================================================ クライアントの方はデジタルＩＤを取得しなくても、サ−バとクライアント間のパケット は暗号化される。デジタルＩＤはただ単に暗号化するだけでなく、安全に商取引をするた めに否認防止、盗聴防止、改竄防止、それに本人であることの証明に使われる。しかし９ 月の時点での調べでは、国内でクライアント側のデジタルＩＤをチェックするＷＷＷサイ トは１ヶ所しかないということだ。「日経パソコン」'96/09/23 日号、 "インタ−ネット は危険？リスクはこうして回避する" の記事より。 ただ Netscape Navigator は 3.0 になって、 クライアント用のデジタルＩＤをサポ−ト したので、広まっていないのは当然という見方もあるが。しかし理由はそれだけはないよ うな気がする。クライアント用のデジタルＩＤのクラスは１のみで、登録はインタ−ネッ ト経由で申請できる。一定期間は無料で使えて、その後は年間数ドルの登録料を払うこと になる。暗号化ＷＷＷと接続すると https://xxx/ というＵＲＬになっているはずである。 HTTPS がＷＷＷサ−バとクライアントの間でデ−タを暗号化するプロトコルであり、クレ ジット番号を入れても安全ということになる。 [ 用語 ] デジタルＩＤ：デジタル証明書、電子印鑑証明書、Digital ID 証明書発行者：証明権限者、ＣＡ( Certifing Authority )、以下 "認証局" と呼ぶ。 [ SSL の位置 ] SSL は TCP/IP レイヤと HTTP や FTP 等のレイヤの中間に位置す HTTP FTP SET る。基本的にはどんなアプリケ−ション・プロトコルでも暗号化し ---------------- てしまう。PCT は Netscape の SSL に対抗する Microsoft 独自の SSL PCT 暗号化プロトコルである。SET は策定中のクレジットの電子決済プ ---------------- ロトコルである。その後追記：SET は利用の繁雑さから広まること TCP/IP なく失敗に終わった。PCT もその後聞くことがなくなった。 * SSL, S/MIME, PKI など参考資料 `02/11〜 http://www.ipa.go.jp/security/rfc/RFC.html > インタ−ネット セキュリティ関連の RFC( Request for Comments ) の日本語訳がある。 RFC2311-00JA.html が "S/MIME Version 2 Message Specification" である。IETFの方 には英文で S/MIME Version 3 のドキュメントがある。 http://www.infoscience.co.jp/technical/crypto/ssleay_jp.html > "SSLeay と SSLapps に関するよくある質問"。この中にクライアントについてのリンク がある。http://www.osa.com.au/~cih/software/crypto/。 http://www.ietf.org/html.charters/smime-charter.html > IETF の Working Group の "S/MIME Mail Security"。 ここで S/MIME については決め られていく。大元の Internet-Drafts と Request for Comments がある。 http://home.netscape.com/eng/security/certs.html > Netscape Cerificate Specifications。Netscape Communicator 4.0 のデジタルＩＤの ダウンロ−ドの仕様などがある。 http://www.rsasecurity.com/standards/ > RSA 社が独自に制定している PKCS, S/MIME, OCSP 等の仕様書やＦＡＱがある。英文で ある。PKCS( Public-Key Crptgraphy Standards ) は、PKCS #1 から #15 まである。 http://www.netscape.com/ja/certificate/v1.0/faq > 日本語の Netscape サ−バのＦＡＱ。 「INTERNET magazine」 '97/11, P.258〜267。"暗号メ−ルのしくみと実践" > Netscape Communicator での VeriSign のお試しを取得するのが載っている。 「日経コミュニケ−ション」 '98/02/02, P.98〜120。 > "特集：安全なインタ−ネット・メ−ル 暗号化と認証でここまで守れる" 「UNIX MAGAZINE」 2000/01, P.50〜63, 山口英。 > "UNIX Communication Notes, ネットワ−ク管理(22) SSL を使ったサ−ビス"。OpenSSL, Apache-SSL でのＷＷＷサ−バとブラウザであるクライアントとの相互認証の話。 http://www.ipa.go.jp/security/enc/research.html > 情報処理振興事業協会。暗号認証技術の調査として、幾つかの報告書がある。 "国内で 入手可能な暗号関連製品リスト" など。`22/07 追加、/security/pki/pki.htmlの "PKI 関連技術解説"、よくまとまっている。S/MIME メ−ルの設定記事なども増えていた。 「UNIX MAGAZINE」2003/02, P.41〜50, "連載：UNIX Communication Notes、電子図書館へ > の道(8)、セキュアなＷＷＷサ−ビスを作る"、利用者が一部に限定されているような場 面では、独自作成のプライベ−トＣＡにも十分存在意義がある。と書かれている。 (2) ＷＷＷサ−バ証明の考察 '96 * VeriSign による証明をどう考える デジタルＩＤの取得は VeriSign 社からと先に書いたが、１９９６年５月頃アメリカ本社 の VeriSign 社が買収された。この世界明日のことは分からない。全世界でＷＷＷのデジ タルＩＤの発行は、VeriSign 社が主に行っている。 それにしても VeriSign 社は民間会 社であり、果たして民間会社が証明書を発行することにどれだけの意味があるのか。何ら かの責任をもってくれる、これは多分公的な機関であっても無理な話だろう。 米 RSA Data Security,Inc.： RSADSI と略して呼ばれる。 米 VeriSign,Inc ： RAS 社の子会社、競合するものではない。 確認しておくが、デ−タを暗号化することと、サイトが証明されているということとは別 である。証明というのは、加藤さんは内閣総理大臣によって確かな人物であると、ワッペ ンをもらっているようなことである。しかもそのワッペンは誰でも知っている。これが内 閣総理大臣なら、加藤さんを疑う余地はないだろう。それが加藤さんの友人の山元君がダ イジョウブだといっているのでは、話が違ってくるのでないだろうか。私は山元君なんて 知らないし、山元君じたいが信用できる人なのかどうかも分からない。これと同じことが VeriSign にもいえる。 Netscape で通信販売を利用しようとする時に、 このサイトは VeriSign が証明していま すと表示されたところで、それがどうかしたの？というのが一般的な感覚ではなかろうか。 VeriSign が一手にこの分野、ＷＷＷサ−バの証明を本気でやっていきたいのなら、 先ず その知名度を上げることがなによりも必要なのではないか。テレビでも新聞でもどんどん 広告をすべきである。現状では一般の人は VeriSign が信用できるかどうかさえ判断する ことができないのだから。 VeriSign の証明が付いている。これは通産省のグッドデザインマ−クみたいに、 誰でも 簡単にとれるものではない。こういう認識が一般に広まることが大切なのである。例えば 名もない会社が、インタ−ネットにお店を出すような場合、ユ−ザが判断する一つの材料 になるかも知れない。しかしよく知られた会社の場合は、証明の有効性の見解は異なって くる。次にこのことを議論する。 * ＷＷＷに証明が本当に必要なのか 例えば広く知られている会社、とそのＷＷＷサ−ビスのサイト。ＮＴＴの www.ntt.co.jp を考えてみよう。このサイトが第三者によって証明されるということ。何かこれに意味が あるのだろうか。ＮＴＴは誰でも知っている。www.ntt.co.jp もよく知っている。衆知さ れていることこそ、証明されていることではないのか。別に第三者により証明してもらう 必要性はない。もしクラッカ−が DNS を操作して www.ntt.co.jp というアドレスとＩＰ アドレスの対応を変更し、実際のアクセス先を偽のＷＷＷに向けることがあるかもしれな い。あるいは似たようなアドレス名で、偽のサイトを作ることはできるかもしれない。し かし同じＵＲＬ、ＩＰアドレスで偽造することはほとんど不可能ではないのか。 本物のＷＷＷサイトか偽のサイトかチェックできるように、信用のおける第三者に証明し てもらうことが必要なのだという記事をよくみかけるが。この場合、偽のサイトとは一体 何を指して言っているのだろう、分からない。証明してもらう。これも何を証明するのだ ろう。また証明する際にどんなチェックをしているのか、これも不明である。会社の登記 簿の提出を証明のために求められる。１人でやっている会社でも登記簿はあるぞ。ちゃん と受け付け嬢もいる会社が、悪徳商法やっている場合だってある。たとえば認証局が証明 審査するにあたって、日本でいえば "帝国デ−タバンク" に社会的信用の調査を依頼する とかいうのであれば話は分かるが。 証明の役割についても考えてみよう。ＷＷＷの暗号化に必要なのは、サ−バの公開鍵であ る。公開鍵がブラウザ側にちゃんと伝わればそれでＯＫである。証明の実態はこの公開鍵 が改竄されないように、認証局の秘密鍵で暗号化したものである。ブラウザはあらかじめ 認証局の公開鍵を持っていれば、間違いないサ−バの公開鍵を入手できる訳である。しか しＷＷＷの世界はリアルタイムである。電子メ−ルのように、いつ来るか分からないとい うものではない。たったいま https://www.nix.co.jj/secret とアクセスして、ただちに かえってきた公開鍵が偽物であった。119 番に電話したら "うどん屋" だった。百歩譲っ て偽物だったとしよう。結果はアクセス不能になるだけだ。 一つの可能性として、ＷＷＷホストに侵入され、コンテンツ（ファイル）を書き換えられ たらどうなるか。公開鍵は本物としよう。ファイルは電子署名され、公開鍵で元に戻され る。これはどうしようもない。電子署名はなんの役にも立たない。ＷＷＷのファイルが改 ざんされていないかは、ＷＷＷ側で管理するしかない。ＷＷＷホストはバリアネット上に 置くように言われている。アタックされても仕方ない犠牲ホストとなっている。ＷＷＷの CGI が抜け穴になって、内部ホストに侵入されることを防ぐためとされる。一体どっちに 重きをおくのか。ファイアウォ−ルの外側に置かれたＷＷＷホストは、侵入の危険にさら されている。暗号化すること自体の意味が問われる問題である。 最後に他の暗号ソフトのようすをみてみる。 電子メ−ルの PEM は VeriSign ではないが 独自の認証局による証明が必要だった。 しかし PEM の MIME 対応版では証明はいらなく なっている。同じく PGP も最初から証明は基本的には必要ない。 PGP は相手の公開鍵が 本物かどうかの判断に、公開鍵の MD5 である Fingerprint を確認すれば十分だという立 場をとっている。暗号化ＷＷＷもこれで十分じゃないのか。最初アクセスした時に公開鍵 の Fingerprint を、例えばその会社のパンフレットかなんかに載った Fingerprint と比 較確認し、同じならブラウザに一度登録してもらえばいいのである。結局、証明というの は、この確認を自動でやりましょうという仕組みなのである。 -------------------------------------------------------------------------------- しかし暗号化ＷＷＷがどんどん増えて、その度に Fingerprint を確認し、 デジタルＩＤ を自分のブラウザに登録しなければならないとしたら。実験なら許されるかもしれないが、 これはたまらない。そこでＷＷＷを VeriSign に証明してもらい、そこからデジタルＩＤ を取得する。ブラウザには最初から VeriSign のデジタルＩＤが入っているので、先の手 間はかからなくなる。 VeriSign が信用になるかということは、デジタルＩＤが入ってい るということから、Netscape や Microsoft 社がお墨付きを与えていると考えることもで きる。現実的に考えるとこのような見解が妥当な線かと思う。 -------------------------------------------------------------------------------- [ Netscape Navigator で見られる証明書 ] 自分で署名したデジタルＩＤ ------------------------------------------------------------------- |Netscape: View A Certificate | |-----------------------------------------------------------------| |This Certificate belongs to: This Certificate was issued by: | | www.nix.co.jj www.nix.co.jj | | katou@nix.co.jj www.nix.co.jj | | CAD CAD | | NIX Ltd NIX Ltd | | Anjyo, Aichi, JP Anjyo, Aichi, JP | | | |Serial Number: 00 | |This Certificate is valid from Fri Nov 8, 1996 to Sun Dec 8, 1996| |Certificate Fingerprint: | | 08:CF:4B:B5:A4:BA:AB:9C:73:16:0B:74:A8:78:48:DF << 鍵指紋だ！ | ------------------------------------------------------------------- (3) ＷＷＷの暗号化技術 '96 * 暗号化の基本技術 これまで公開鍵とか暗号とか説明なしできたが、簡単に説明しておこう。ＷＷＷサ−バの 暗号は、幾つかの暗号方式を組み合わせて成り立っている。基本のみ説明するので、後は 各自頭のなかで組立ててもらいたい。ポイントは公開鍵方式と改竄チェックの２つである。 用途 | 方式 | アルゴリズム | 特徴 ==============|====================|=================|================ | 共有鍵方式 | IDEA, DES, RC-4 | 処理が速い 暗号化、復号化|--------------------|-----------------|---------------- | 公開鍵方式 | RSA | 処理が遅い --------------|--------------------|-----------------|---------------- 改竄チェック | 一方向ハッシュ関数 | MD5, MD2, SHA-1 | 電子署名に利用 暗号化、：文書を他者に分からなくすることを暗号化といい、元に戻すことを復号化とい 復号化 う。共有鍵方式は合鍵と同じである。ここでいう鍵とは、物理的な鍵ではなく、 パスワ−ドや呪文みたいなもの、実際はコンピュ−タなのでファイルである。 公開鍵 ：２種類の鍵がある。公開鍵と秘密鍵と呼ばれる。秘密鍵は自分だけが持ってお 方式 き、公開鍵をばらまく。一方の鍵（パスワ−ドと思ってよい）でファイルを暗 号化すると、もう１つの鍵でないと復合化できない。ＷＷＷのサ−バ側は秘密 鍵で暗号化し、ブラウザ側は公開鍵で元に戻すわけである。反対にブラウザ側 からサ−バにファイルを送る場合は公開鍵で暗号化する。それを見れるのは秘 密鍵をもつＷＷＷしかない。 ダイジェ：一方向ハッシュ関数というのがある。これは一方向にファイルを変換したっき スト り、元に戻すことができないというものである。ファイルをこの関数のアルゴ リズムに通すと、ある短い全くランダムなメッセ−ジになる。このメッセ−ジ を元に戻すことはほとんど不可能となる。メッセ−ジは、ダイジェストまたは ハッシュ値と呼ぶ。ダイジェストを生成するアルゴリズムが MD5, MD2, SHA-1 である。SHA-1( Secure Hash Algorithm )は米国標準機構 NIST が制定したも のである。ハッシュ強度は MD2 < MD5 < SHA-1 で、SHA-1 が一番強い。 改竄 ：ダイジェストを利用して、ファイルの改竄を調べる。ファイルを送ろうとする チェック 場合、元ファイルとダイジェストを添付しておく。送り先でも、受けたファイ ルのダイジェストを作成する。２つのダイジェストが同じならファイルはいじ られていないことになる。ダイジェストのみ改竄され、一致しない場合も有り 得るが、どっちにせよ誰かにいじられたことは確かとなる。 電子署名：これは別にサインを本当にするわけでない。誰がファイルを作ったか保証する ための暗号化の応用である。そのファイルを自分の秘密鍵で暗号化する。秘密 鍵は自分だけしかもっていない。つまりその人の公開鍵をもつ相手がファイル を受け取って、複合化できれば確かにその人からだと判断できる。それに電子 署名はダイジェストと組み合わされ、改竄チェックの機能も含んでいる。 鍵指紋 ：特に公開鍵のダイジェストを鍵指紋 Fingerprint と呼ぶ。 * 電子署名の様子 ---------- ---------- ---------- ---------- ハッシュ値 | DIGEST | |ファイル| ---> |ファイル| |ファイル| ----------> ---------- | Ａ | | Ａ | | Ａ | ‖ 比較 ---------- ---------- 秘密鍵で ---------- 公開鍵で ---------- | DIGEST | ---------> | DIGEST'| ----------> | DIGEST | ---------- 暗号化 ---------- 復号化 ---------- 元ファイルとそのダイジェスト、そして暗号化により幾つかのパタ−ンが考えられる。上 のパタ−ンの逆で、元ファイルを秘密鍵で暗号化し、ダイジェストはそのままにするとい うのも有り得る。元ファイルとダイジェストを合わせて暗号化する。ＷＷＷサ−バなどの デジタルＩＤの電子署名は PKCS #7 というル−ルで行っている。 パタ−ンは上の図であ る。どうも普通、電子署名というとダイジェストを秘密鍵で暗号化するパタ−ンと見てい いようである。 * SSL とその安全性 Netscape Commerce Server で使われている暗号化方式 RSA は、アメリカの輸出規制によ り暗号化の程度が弱められている。元々 128 bit の暗号鍵が、40 bit に押えられている というものだ。これはパスワ−ドの長さが３倍違うと思ってもよい。このため十分な安全 性がないとも、あるとも言われる原因になっている。このことを考えるには、２つの側面 を見なければならない。 a. 解読のためのコスト b. SSL の仕組み コストについてまずみてみよう。RSA の 40 bit 鍵は、解読するのに 200 MIPS 年かかる と計算されている。５０台のＥＷＳを使えば最低２週間で解読できるそうだ。これで十分 安全なのではないか。戦争でもあるまいし、だれがそれだけのコストを払って、解読する というのだ。お宅の会社はペンタゴンなみの機密事項があるとでもいうのか。 SSL の方はどうだ。ＷＷＷの内容自体は IDEA 128 bit が使われている。Navigator で見 たいとこをクリックし、ＷＷＷからファイルが送られる。そのファイルの暗号化は共有鍵 方式の IDEA なのである。共有鍵はＷＷＷとブラウザ側で同じ鍵をもつわけだが、この鍵 は３０秒に１回変わるように SSL ではなっている。 セッションキ−と呼ばれるのがこれ である。セッションキ−を作るには、ランダムな値が元になる。この値はブラウザ側から 提供される。そして双方同期して同じ共有鍵が作られるのである。 RSA 40 bit は上記のセッションキ−を暗号化するために使われる。 RSA のところが解読 されたとしても、IDEA が十分な安全性があるなら問題はない。IDEA はスイスで開発され ているので、アメリカのような規制はないし、DES よりも安全なのでないかともいわれて いる。Netscape Commerce Server はリリ−ス直後に暗号が破られたりしたので、 余計安 全性が話題になったのだが、いわば初歩的なミスで暗号自体には問題はない。すぐに改善 されたので、十分安心してよい。 * SSL 対応ＷＷＷ＆ブラウザの仕組み ＷＷＷの暗号化を理解するには SSL 対応 Apache を設定してみるのがよい。Apache の基 本部分の設定は NCSA httpd と互換性がある。SSL の所の設定は分かってしまえば簡単で ある。今一番人気のあるフリ−のＷＷＷソフトでもあるらしい。暗号化の他、Proxy など オプションがたくさんあり、世界中で営利目的に使用できる。 Apache-SSL の証明は VeriSign はやらないみたいである。 Thawte Consulting 社が証明 してくれるようになっている。 Netscape Navigator には認証局の公開鍵情報がすでに入 っていて、VeriSign 以外にも幾つもある。 認証局は VeriSign しかないかのように記事 が書かれているが、実は複数の認証局がすでに存在しているのである。追記：９８年７月 から日本ベリサインは認証証明書を発行するようになった。 Apache を SSL 対応にするため SSL のライブラリをとってくるのだが、 このライブラリ には、自分で認証局ができるようにコマンドが用意されている。つまり VeriSign に証明 書を発行してもらわなくても、自分で発行できるわけである。ただ注意すべきは勝手に作 った認証局の情報（公開鍵）は、Navigator には入っていない。 このため Navigator で ＷＷＷにアクセスする際、警告が表示されることである。 警告のメッセ−ジに答えていく過程で、このサイトを登録しますかというのがある。これ にハイとボタンを押すと、２回目からは警告なしでアクセスできるようになる。この登録 は Site Certificate といい、特定のサイトの認証局を認めるということである。この機 能は Netscape Navigator ではバ−ジョン２以降に実装された。 Internet Explorer 3.0 の方は今のところ対応してないが、そのうち変更すると思われる。 [ 参考 ] http://www.verisign.com/japan/ http://www.thawte.com/certs/server/request.html http://home.netscape.com/newsref/std/ssl_2.0_certificate.html http://www.algroup.co.uk/Apache-SSL/ << Apache-SSL の概要がある。 http://www.psy.uq.oz.au/~ftp/Crypto/ << SSLeay and SSLapps FAQ がある。 「Netscape で始める電子商取引」ナツメ社、2,800 円。 * 暗号化ＷＷＷの実験運用 ・ともかく証明されたというフォ−マットがいる。 ・自分で証明しておけば十分である。 ・相手が確認できるよう、印刷物に Fingerprint を掲載する。 ・通常のＷＷＷサ−バはポ−ト番号 80 を使う。暗号化の方は 443 である。 ＷＷＷをはじめとする公開鍵方式での暗号化は、ユ−ザ側にその公開鍵がありさえすれば 内容を復元できる。これが基本である。しかし現在ＷＷＷの SSL に用いる公開鍵は、 第 三者による証明とワンセットになってしまっている。この証明は普通 VeriSign 社に依頼 することになっている。しかし暗号化のライブラリ SSL があると、 自分自身で証明が可 能である。ＷＷＷのデ−タはリアルタイムで来るため、公開鍵が偽造される可能性はほと んどない。念のためユ−ザが、 公開鍵が本物かどうか確認できるように Fingerprint を 会社の製品カタログや、広告などに記載しておけばよい。 ＷＷＷサ−バの稼働は、暗号化対応とそうでないものとポ−ト番号が違うので、１つのサ イトで２種類のＷＷＷサ−バを稼働させることになる。別に暗号化対応だけでも構わない が、不用意にセキュリティ意識をあおることはない。暗号化が必要なのはブラウザ側のユ −ザから住所、氏名などが送られる際。あるいはパスワ−ド制限で、特定のユ−ザだけが 見れるようにした部分だけでよい。特定のユ−ザを同じ会社の支社とすれば、仮想プラベ −トネットワ−ク（ＶＰＮ）となる。この場合ポ−ト番号を変更して支社専用のＷＷＷと し、ル−タでパケットフィルタリングするなど、セキュリティ強化すれば尚安全である。 (4) デジタルＩＤと認証局 `02/10 * 概要 日本政府の話、２００３年からの電子政府の構想。 認証局(ＣＡ)ともからんで XML が使 われていく検討がされている模様。 アメリカでは電子署名法というのが `02/06/16 法政 化に向けて動き出している。もう待ったなしで国内でも、企業間やＥＣなどで使われるよ うになっていく気がする。ＣＡの運用はどうするか。フリ−ソフトでもやれないことはな いが、専用のマシンを用意してセキュリティをしかっりして運用すべきか。あるいは市販 ソフトを使うか、外のなんらかのサ−ビスを使うか。ＣＡの必要性は。 VeriSign による ＣＡがいる場合。グル−プ企業内で有効なＣＡと言うのも考えられる。自社だけのＣＡで いい場合もある。どういう認証をとればいいのか。手続きや提出書類はどうか。セミナ− などにいって、いろいろ情報を仕入れなければ。 やれ IPSec だ PKI がどうのこうの騒がしいが、さてデジタルＩＤを入れたパソコンが盗 まれたり、デジタルＩＤをコピ−してもっていかれたりしたらどうなるか。その場合、即 入っているデジタルＩＤを無効にしたいのだ。どこかの資材調達用の暗号化ＷＷＷサ−バ にアクセスするための、個人用デジタルＩＤが入っていたとする。第三者に勝手に注文を 入れられては困るのだ。ＷＷＷサ−バにアクセスするその時に、個人用デジタルＩＤを認 証局かどこかで有効／無効を確認することができるのだろうか。CRL というデジタルＩＤ の失効リストを参照するとか。OCSP といって認証局に毎回、 相手デジタルＩＤが有効か 問い合わせる仕組みとかあるようだが、どうもまだまだのようである。 後、疑問に思っていること。ＷＷＷサ−バ、ＷＷＷブラウザ、ＶＰＮ装置、暗号化ファイ アウォ−ルのデジタルＩＤ。これらどう違うのだろうか。 基本的には X.509 のフォ−マ ットに従うはずなのだが。さらに疑問、１台のパソコンに複数の個人用デジタルＩＤが入 るのか。例えばＴ社の暗号化ＷＷＷサ−バにアクセスし、相互認証するとする。Ｔ社発行 のデジタルＩＤがいって、Ｂ社へはＢ社のが必要ということになってくるのでないか。後 日確認したところ、ブラウザには複数入れることができて、その度に選ぶようになってい た。ともかくこの認証の話、極めてややこしいものになって来てしまった。認証局だけで なく、登録局（ＲＡ）と発行局（ＩＡ）というのも出てきた。結局、運用なんてのはどの ようにでも複雑にできるわけだ。ＣＡ＝ＲＡ＋ＩＡという図式になっている。 用語：CA( Certificate Authority ) 認証局。デジタルＩＤを発行管理する。 RA( Registration Authority ) デジタルＩＤ発行を要求するところ。 IA( Issuing Authority ) デジタルＩＤの発行と失効をするところ。 CRL( Certificate Revocation List ) デジタルＩＤ失効(破棄)リスト。 VA( Validation Authority ) デジタルＩＤが有効かどうかの情報を持つ。 OCSP( Online Certificates Status Protocol ) '99/06 公開、標準化ヘの提唱。 PKI( Public Key Infrastructure ) 公開鍵基盤。９７年に Entrust 社が提唱。 * ＣＡソフト販売／サ−ビス会社 VeriSign http://www.verisign.co.jp/ > お試し認証ができるようになった。１４日間有効なＷＷＷサ−バ用の 40 bit のを数分 で発行してくれる。ユ−ザ登録はせないかんが。テスト用ル−ト証明書をブラウザに入 れること。VeriSign OnSite というＣＡソフト＆構築運用サ−ビスを販売する。登録局 を社内に、デジタルＩＤ発行局を VeriSign にアウトソ−シングするというもの。 Baltimore http://www.baltimore.co.jp/ > 日本ボルチモアテクノロジ−(株)。サイバ−トラスト(株)を `02/05 合併吸収。電子証 明書発行管理システム UniCERT PKI System。他 PKI, SSL, S/MIME, XML 用のプログラ ミング・ライブラリも販売。電子認証ホスティングサ−ビスの構築支援も行う。驚くは 現在の資本金３０億、昨年度売り上げ１２億円。著名大企業が数多く出資している。確 かドキュメントが５００万円と、Networld+Interop 2001 で聞いたような。 Entrust http://www.entrust.co.jp/ > 米 Entrust 社のもの、何や一杯ソフトがある。ネットマ−クスも扱っていて PKI シス テム スタ−タキット特別キャンペ−ンで、528 万円のを 289 万円で販売していた。米 identrus 社が定めた PKI の仕様を完全に満足するのが Entrust/PKI R5.0 で、国内で は三和銀行が初めて採用し、サポ−トはセコムがやるとあった。他、Entrust/TruePass が 354 万円、Entrust/Web Connector が 118 万円とか。いろいろいるみたいである。 帝国デ−タバンク http://www.tdb.co.jp/ > COSMOSNET/EC サ−ビス、`02/05/27 より TDB サ−バ証明書発行サ−ビス開始。ＷＷＷ サ−バが運用されているか、JPNIC または InterNIC にドメインが登録されているか調 べた上で発行する。Apache などのフリ−ソフトはだめとある。 ベリサインの Class 3 認証に TDB の認証仕様を付加したもの、8.1 万円／年。 帝国デ−タバンクの信用調査 も加味して、サイバ−トラストと認証局を共同で運用するもの、7.5 万円／年。 セコムトラストネット(株) http://www.secom.ne.jp/ `02/04/15 調べ > 電子認証サ−ビス `02/05/15 開始。セコムパスポ−ト for Web サ−ビス。実在証明書 といっている。１年で 68,250 円。Apache ＷＷＷサ−バにも発行する。 法人登記簿謄 本に代表者の印鑑証明書が必要である。デジタルＩＤの再発行はない。盗難などによる 失効の後は、新規取得となる。帝国デ−タバンクもそうなっている。 日本認証サ−ビス(株) http://www.jcsinc.co.jp/ > 富士通とＮＥＣと日立が '97/09 に設立した。 SecureSign という認証のアウトソ−シ ング・サ−ビスを行っている。その最初のユ−ザはＮＥＣと日立。顧客がＣＡを運営す るプライベ−トサ−ビスもある。費用は、低価格とは書いてあるが、記載されていない。 ＷＷＷサ−バのデジタルＩＤも、ル−トＣＡを日本認証サ−ビスで発行する。後、キ− ワ−ドだけ。SET によるクレジットカ−ド支払い、 SECE によるインタ−ネットバンキ ング。大垣銀行など銀行と証券会社が利用する。 Netscape Certificate Server > VeriSign と同じぐらい古くからある。こちらはサ−ビスでなくＣＡソフトである。 名 前を変えて、iPlanet Certificate Management System となった。Solaris 2.5/2.6 と Windows NT4.0 用がある。１００ユ−ザ６１万円からとも８１万円からとも。 2002/09 時点、また名前を変えて Sun ONE Certificate Server となった。米国サイトには、ど うもお試し版がある模様。国内サイトには Directory、Proxy、WWW のお試しはあった。 他、調べていてチェックしたこと。米の identrus 社がＣＡで著名な銀行を総なめにして いる。国内でも三和銀行や日本興行銀行が加盟している。つまり電子商取引の証明、暗号 は銀行にお任せを狙っている訳だ。http://www.identrus.com/ を見られたし。 * ＣＡのフリ−ソフト AiCA http://mars.elcom.nitech.ac.jp/security/ > 名古屋工業大学の研究室のサイトのネットワ−クセキュリティに関する研究成果。認証 局パッケ−ジソフト AiCA がある。X.509 と PKCS に対応。SSL 対応の telnet と ftp のソフトなどもあり。国内の学術目的の利用に制限される。他ＣＡの仕組みや OpenSSL など詳細記事がある。このサイト、"よい子" をリンクしてくれている、 奈良先端大の 山口英研究室の学生のホ−ムペ−ジから辿り `02/07/24 に見つけた。この時 EasyCert もあったかな。`02/11/16 再度見たら商用利用も可のフリ−ソフトとなっていた。 ICAP http://www.icat.or.jp/ > 認証実用化実験協議会９８年開発のＣＡパッケ−ジ。利用は日本国内のみ、幾つか利用 制限がある。ICAP v2.51beta 2000/05/23、ICAT Certification Authority Package と いってＷＷＷの cgi-bin プログラムとなっている。 ＷＷＷブラウザから使うようにな っている。ＧＵＩでの使用になっているが、鍵管理は大変そうである。他に POPメ−ル の暗号化版 PEPOP( Privacy Enhanced POP ) というのが、ここにあった。ICAP は企業 などで実際の使用はできないと考えた方がいい。実験程度で使うこと。 他、フリ−ソフトの OpenSSL が以前からある。全くのコマンド・レベルでの操作である。 * 個人用デジタルＩＤについて デジタルＩＤはＷＷＷサ−バ用のがよく知られているが、本人を認証するための個人用デ ジタルＩＤというのもある。ＶＰＮ装置のとか FireWall-1 のとか、ここではＷＷＷクラ イアントのデジタルＩＤについて述べる。まだ国内ではあまりその利用は、普及していな いが、大手企業では独自に認証局を運営し、何百人にもデジタルＩＤを発行するケ−スも 出てきている。個人用デジタルＩＤにはＷＷＷサ−バとブラウザの相互認証に使うものと、 暗号化メ−ルの S/MIME 用がある。Netscape Communicator ではデジタルＩＤはメ−ル用 とブラウザ用、両方で使うことができる。厳密にはデジタルＩＤを発行する際に X.509の 拡張部で、両方適用するかどちらか１つにするか指定する。IE と Outlook Express では そういう区別はなく両方でないのか。S/MIME だけの利用というのは "Secure Messenger" や "魔法便" といったメ−ルソフトのアドインソフトで使えるようになっている。 "魔法便" ちょっと紹介しておく。ＮＴＴエレクトロニクス(株)から '97/06 に 1.5 万円 で発売開始されている。Eudra Pro や Microsoft の Outlook などメ−ルソフトにアドイ ンして使うようになっている。どうも Netscape には対応してないもよう。 VeriSign の 個人用デジタルＩＤが１年分付いている。最近、プライベ−トＣＡビルダ−とのセットで 142 万円のも発売された。"魔法便" 100 ライセンスが付き、 自己署名の証明書も作成で きるというものである。先の VeriSign のデジタルＩＤの更新は、日本 VeriSign で行う。 税込み、年 1,575 円である。 実は日本 VeriSign が発行する個人用デジタルＩＤはこの 更新だけである。アメリカの VeriSign は１年分 $14.95 で発行している。それに６０日 間有効のお試し 60-days trial edition といのもあるが。 http://www.nel.co.jp/security/private/ ＮＴＴエレクトロニクス > 魔法便、プライベ−トＣＡビルダ− S/MIME と WEB 用 * デジタルＩＤの階層と内容 ＣＡは階層構造をとることができる。その最上位ＣＡをとくにル−トＣＡという。ブラウ ザにあらかじめ入っているＣＡはル−トＣＡである。ル−トＣＡはもう認証してくれると ころがないので、自分で電子署名して認証するわけである。同じＣＡでＷＷＷサ−バのも 個人用のデジタルＩＤも認証できる。しかしＣＡというのは、電子署名してもらう側から 見た言い方に過ぎず、ＣＡの実態はただのデジタルＩＤである。貴方も僕もＣＡになるこ とができる。ＣＡたる要件というのは、ＣＡの秘密鍵を厳重に管理すること。秘密鍵が悪 意のある者の手に渡ったら、そのＣＡになりすまして偽のデジタルＩＤを発行されてしま う。そうなると、それまでそのＣＡで発行、つまり電子署名されたデジタルＩＤは、全部 信頼できないということになってしまう。 下の図で A の秘密鍵が盗まれたら B,C,X,Y,Z が没になる。X の秘密鍵が盗まれたら Y,Z が没になる。ＣＡを階層にする意味である。 ル−トＣＡ ------- ------- ------- | A | ---| A | ---| B | 署名：上位ＣＡである B さんの電子署名。B さんの |-----| | |-----| | |-----| 上位ＣＡは A さんである。A さんのは A自身。 | |--| | |--- | | | A | | | B | | C | 本人：C さんの公開鍵などの情報が書かれている。C ------- | ------- ------- さんの秘密鍵は別にある。 | | ------- ------- ---| A | ---| X | デジタルＩＤ |-----| | |-----| ------------ デジタルＩＤと秘密鍵である。こ | |--| | | | 連続番号 | れらはペアになっている。 X.509 | X | | | Y | | 発行者 | のフォ−マットに従う。電子署名 ------- | ------- | 有効期限 | は署名者の秘密鍵で、拡張情報ま | | Subject | での内容を電子署名している。拡 署名と本人の上下 | ------- | 公開鍵 | 張情報のところで Netscape では、 は分かりやすくす ---| X | |----------| サ−バとブラウザの区別をする。 るため、よくある |-----| | 拡張情報 | 説明図の逆にした。 | | |==========| ---------- | Z | | 電子署名 | | 秘密鍵 | ------- ------------ ---------- * その他メモ Netscape Communicator 4.51 までの S/MIME の暗号化は、RC2 40 bit 共通キ−方式だけ だった。'99/12 米国暗号技術の輸出規制緩和発表。`02/01/14 米国商務省 128 bit も規 制緩和。`02/04 の「INTERNET magazine」日本語版 Windows 用、128 bit 暗号 Netscape Communicator 4.7 を緊急収録とある。 S/MIME Version 3 の標準化作業が IETF で進められている。かつて S/MIME は RSA 社が 独自に決めていた。 MIME と言うのはメ−ルの添付ファイルのフォ−マットみたいなもの である。GIF や JPEG のデ−タを 7 bit エンコ−ドして送受信するという機構も MIMEに は含まれる。S/MIME のデジタルＩＤは X.509 フォ−マットを使う。 暗号化アルゴリズムの DES には 40/56/128 bit がある。 56 bit のは元は 64 bit でパ リティが 8bit ある。Triple-DES は DES を３回繰り返す。56x3 = 168 bit DES。40 bit と 128 bit では全然解読コストが違う。２乗で効いてくる訳だから。 個人用デジタルＩＤといった場合、ＷＷＷブラウザ用のデジタルＩＤと S/MIME 電子メ− ル用デジタルＩＤがある。ＷＷＷサ−バ用のデジタルＩＤに対して、ＷＷＷのクライアン ト用のデジタルＩＤという場合もある。 X.509 デジタルＩＤの DN は Subject 部である。DN の構造は X.500 ディレクトリのDIT ( Directory Information Tree ) に基本をおくが、厳密な適用ではない。X.500ディレク トリでは管理対象をオブジェクトという。オブジェクトの名前を DN といっている。 (5) SSLeay でデジタルＩＤを作成する '96 * １９９６年当時の検討 [ SSL 対応 Apache のためのプログラム ] Apache のソ−ス http://www.happysize.co.jp/apache/index.html から apache_1.1.1.tar.gz をとる。 http://www.apache.org/ のミラ−サイト。 SSL 対応にするためのパッチ ftp://ftp.ox.ac.uk/pub/crypto/SSL/apache_1.1.1+1.3.ssl.tar.gz ３種類ぐらいあるが、とりあえずこれをとってきた。 SSL 用のライブラリ ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/SSLeay-0.6.4.tar.gz SSLeay 0.6.1 以上を使うこと。 SSL 用のライブラリ SSLeay を用いて、SSL 対応 Apache を作り、暗号化ＷＷＷサ−バの 実験を行った。SSLeayは ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/SSLeay-0.6.4.tar.gz をダウンロ−ドして使った。SSLeay は OpenSSL の前身である。 apache_1.1.1.tar.gz : Apache のソ−ス apache_1.1.1+1.3.ssl.tar.gz : Apache の SSL 対応パッチ SSLeay-0.6.4.tar.gz : SSL 用のライブラリ SSLeay.doc-1.5.tar.gz : SSLeay のドキュメント % cd /usr/local/source % zcat apache_1.1.1.tar.gz | tar xvf - % zcat SSLeay-0.6.4.tar.gz | tar xvf - % ls apache_1.1.1/ SSLeay-0.6.4/ [ SSL 用のライブラリを先に作る ] インスト−ルには perl があること。ないと Configure は反応しない。 /usr/local/bin/ にあることが期待されている。INDY には perl はデフォルトではインスト−ルされていな いので、インスト−ルすること。 インスト−ルすると /usr/sbin/perl になるので注意さ れたい。INSTALL と Configure ファイルは INDY で必要なところのみ記述した。他コメン トやら Windows NT での設定やらあるが、紛らわしいので削除してある。 % cd SSLeay-0.6.4 Configure INSTALL Makefile.ssl ... % Configure Usage: Configure [-Dxxx] [-Lxxx] [-lxxx] os/compiler pick os/compiler from: | irix-gcc linux-aout linux-elf nextstep purify sco5-cc solaris-sparc-cc solaris-sparc-gcc solaris-sparc-sc4 solaris-x86-gcc sunos-cc sunos-gcc INSTALL ------------------------------------- |perl util/perlpath.pl /usr/local/bin << perl のあるディレクトリ。 |make -f Makefile.ssl links |./Configure irix-gcc << マシンのタイプを入れること。 |make clean |make depend |make << ちょっと時間かかる。 |make rehash |make test |make install << /usr/local に ssl というディレクトリが できて、SSL のモジュ−ルができる。 % chmod +x INSTALL << 実行権を付けて実行する。 % INSTALL % ls /usr/local/ssl bin/ certs/ include/ lib/ private/ % ls /usr/local/ssl/lib libcrypto.a libssl.a ssleay.conf [ Apache のソ−スにパッチを当てコンパイルする ] % cd apache_1.1.1 % zcat apache_1.1.1+1.3.ssl.tar.gz | tar xvf - % ls apache_1.1.1+1.3.ssl.tar.gz CHANGES.SSL EXPORT.SSL EXTRAS.SSL LICENCE.SSL README.SSL SECURITY SSLconf/ SSLpatch << ここまでパッチのファイル。SSLpatch がパッチの本体。 | CHANGES LICENSE README cgi-bin/ conf/ htdocs/ icons/ logs/ src/ support/ % cd src % patch < ../SSLpatch % ls API.html Configuration Configure INSTALL Makefile ... % cat Configuration --------------------------------------- |SSL_INCLUDE= -I /usr/local/ssl/include << パッチをあてると SSL なんたらとい |SSL_LIB_DIR= /usr/local/ssl/lib うのが入ってくる。 |AUX_CFLAGS= -DIRIX << タ−ゲットのマシ−ン。IRIX 5.3。 % Configure Using 'Configuration' as config file << Makefile がちゃんと作られる。 ※%make httpd やただの % make は失敗する。すでに httpsd を作成するためにパッチを 当てたので、httpd は作れないのかもしれない。注意すべし！。 % make httpsd % cp httpsd /usr/local/bin/httpsd << /usr/local/bin にコピ−しておく。 [ httpd.conf ファイルの編集 ] % cd /usr/local/source/apache_1.1.1/SSLconf /conf ./SSLconf/conf/httpd.conf, mime.types mime.types のみ上書きしてコピ−。 ↓ httpd.conf は SSL の所を追加する。 ./conf/access.conf, httpd.conf, mime.types, srm.conf ./conf/httpd.conf --------------------------------- |ServerType standalone << SSL 対応は必ず standalone にすること。 |Port 443 << SSL 対応のポ−ト番号は 443 である。 |User nobody |Group #-1 << これがダメならとりあえず Group user ぐらいにする。 | |ServerRoot /usr/local/source/apache_1.1.1 |ServerName www.nix.co.jj | |#--------- ここから下追加した --------- |#SSLDisable << コメントを外すと SSL 対応でなくなる。 | |# [ その１] |# ＣＡのデジタルＩＤ。ＷＷＷサ−バを電子署名したＣＡ。 |SSLCACertificateFile /usr/local/ssl/newcert.pem |# ＷＷＷサ−バのデジタルＩＤ。秘密鍵を含めることもできる。 |SSLCertificateFile /usr/local/ssl/demoCA/cacert.pem |# ＷＷＷサ−バの秘密鍵 |SSLCertificateKeyFile /usr/local/ssl/demoCA/private/cakey.pem | |# [ その２] |# pp.pem は cacert.pem と cakey.pem を足したファイルである。 |# % cat demoCA/cacert.pem > pp.pem |# % cat demoCA/private/cakey.pem >> pp.pem |# |#SSLCACertificatePath /usr/local/ssl クライアント認証する場合に関係する。 |#SSLCACertificateFile /usr/local/ssl/newcert.pem |#SSLCertificateFile /usr/local/ssl/pp.pem | |SSLVerifyClient 0 << 値が 0 だとクライアント認証はしない。 |SSLVerifyDepth 10 |SSLFakeBasicAuth |SSLLogFile /tmp/ssl.log % /usr/local/bin/httpsd -f /usr/local/source/apache_1.1.1/conf/httpd.conf Reading certificate and key for server www.nix.co.jj:443 Enter PEM pass phrase: 12345678 % netscape https://www.nix.co.jj/ << 起動すると色々聞いてくるので答える。 INDY での Netscape Navigator は 2.02 と 2.0S で確認した。2.02 は英語バ−ジョンな ので、起動する前に %setenv LANG C と環境を英語モ−ドにすること。そうしないとパカ パカ落ちる。Windows 95 の Netscape Navigator 3.0 でも問題なくアクセスできた。 ./conf/httpd.conf 参考に ------------------------------------------------------------------------------- | | |# Set the CA certificate verification path (must be PEM encoded). |# (in addition to getenv("SSL_CERT_DIR"), I think). |#SSLCACertificatePath /usr/local/source/apache_1.3.9/SSLconf/conf | |# Set the CA certificate verification file (must be PEM encoded). |# (in addition to getenv("SSL_CERT_FILE"), I think). |#SSLCACertificateFile /some/where/somefile | |# Point SSLCertificateFile at a PEM encoded certificate. |# If the certificate is encrypted, then you will be prompted for a pass phrase. |# Note that a kill -1 will prompt again. |# A test certificate can be generated with "make certificate". |SSLCertificateFile /usr/local/apache/conf/ppp.pem ＷＷＷサ−バのデジタルＩＤ | |# If the key is not combined with the certificate, use this directive to |# point at the key file. If this starts with a '/' it specifies an absolute |# path, otherwise it is relative to the default certificate area. That is, it |# means "/private/". |SSLCertificateKeyFile /usr/local/apache/conf/qqq.pem ＷＷＷサ−バの秘密鍵 | | * 自分で証明したデジタルＩＤを作成する % setenv PATH /usr/local/ssl/bin:$PATH % cd /usr/local/ssl;ls bin/ include/ lib/ % CA.sh -newca << 順番に実行していく。CA.sh コマンドは % CA.sh -newreq /usr/local/ssl/bin にある。 % CA.sh -sign ./ssl/demoCA/cacert.pem << -newca でこれと cakey.pem ができる。 ./ssl/demoCA/private/cakey.pem ./ssl/newreq.pem << -newreq でこれができる。 ./ssl/newcert.pem << -sign でこれができる。 ※%CA.sh -newca をやるとカレントディレクトリに demoCA ディレクトリができる。何か 間違えたら demoCA を消してから再度やるとよい。 -newca で聞いてくる Common Name はＷＷＷサ−バのホスト名にすること。 % CA.sh -newca CA certificate filename (or enter to create) << ここは Return キ−を押す。 Making CA certificate ... Generating a 512 bit private key ...+++++ .......+++++ writing new private key to './demoCA/private/./cakey.pem' Enter PEM pass phrase: 12345678 Verifying password - Enter PEM pass phrase: 12345678 ----- Country Name (2 letter code) [AU]:JP State or Province Name (full name) [Queensland]:Aichi Locality Name (eg, city) []:Anjyo Organization Name (eg, company) [Mincom Pty Ltd]:NIX Ltd Organizational Unit Name (eg, section) [MTR]:CAD Common Name (eg, YOUR name) []:www.nix.co.jj ← ホスト名 Email Address []:katou@nix.co.jj % du -a demoCA /usr/local/ssl/demoCA ができた。 1 demoCA/certs 1 demoCA/crl ------------------------------- 1 demoCA/new_certs |認証局用のパスワ−ド 12345678| 2 demoCA/private/cakey.pem |ＷＷＷ用のパスワ−ド 87654321| 2 demoCA/cacert.pem ------------------------------- 1 demoCA/serial ↑ 0 demoCA/index.txt 実際はもっとシビアにすること。 % cat demoCA/cacert.pem -----BEGIN CERTIFICATE----- MIIB9jCCAaACAQAwDQYJKoZIhvcNAQEEBQAwgYUxCzAJBgNVBAYTAkpQMQ4wDAYD VQQIEwVBaWNoaTEOMAwGA1UEBxMFQW5qeW8xEDAOBgNVBAoTB05JWCBMdGQxDDAK BgNVBAsTA0NBRDEWMBQGA1UEAxMNd3d3Lm5peC5jby5qcDEeMBwGCSqGSIb3DQEJ ARYPa2F0b3VAbml4LmNvLmpwMB4XDTk2MTEwNzA0MTg1M1oXDTk2MTIwNzA0MTg1 M1owgYUxCzAJBgNVBAYTAkpQMQ4wDAYDVQQIEwVBaWNoaTEOMAwGA1UEBxMFQW5q eW8xEDAOBgNVBAoTB05JWCBMdGQxDDAKBgNVBAsTA0NBRDEWMBQGA1UEAxMNd3d3 Lm5peC5jby5qcDEeMBwGCSqGSIb3DQEJARYPa2F0b3VAbml4LmNvLmpwMFwwDQYJ KoZIhvcNAQEBBQADSwAwSAJBAJMvGwNPMzbYAhoCo4Tzk90/9hYCiadpgUYot54x 1RA1uxIN65vHOrFbCXuuMn+VOFh9sqTbuCMwJPIlOvE7LK8CAwEAATANBgkqhkiG 9w0BAQQFAANBAG8bwwOwYHy37woGdmibglwZ1feO+PL2ajLYd3J1YkqydoYPpwdw svyrhwa9h4wN109Ot04MbprMoCXDXS6kZxo= -----END CERTIFICATE----- % cat demoCA/private/cakey.pem -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,797B1CF73F69A1A8 gt7kvMC+jreCki+/9AfwbkWRY18Mbg1BP/CyVUxkAGqjiX87AoM3gcuqSFr2jbSX UjRe8IPJllOwW4sYuZ0lhtSdqdWa/C0sMKhqegIAulaotosI+NAGLZeiChJiTO++ d90bXILsSJPffjVYERZiX0coEH1GoJp2WROB/NtkNAcCKa7zndcECr+ABBbuuEXb WU8GRkjVCIbTLfRsxKHBnpEWSBF2X96J0wNaoA8sJ2HNUvMRHXxkAAvPnLVA2+y9 3qhSliDmpAggrwWoMY+HJDfQWVlLf93DoXQV6ephmHRp36r1sM/OXf0vNCud+3RG 4fCZv9ykr8klRmUYGep4aepYqJYtx08Gg29EMY60jmIm7T5c2KVO7kRHy8ZRb/YY nLW1rRe632gMqaH3XRD3kGKZEXUW21QBPJeFzyjQ3Fs= -----END RSA PRIVATE KEY----- % CA.sh -newreq Generating a 512 bit private key ..................+++++ ......................+++++ writing new private key to 'newreq.pem' Enter PEM pass phrase: 87654321 Verifying password - Enter PEM pass phrase: 87654321 ----- Country Name (2 letter code) [AU]:JP State or Province Name (full name) [Queensland]:Aichi Locality Name (eg, city) []:Anjyo Organization Name (eg, company) [Mincom Pty Ltd]:NIX Ltd Organizational Unit Name (eg, section) [MTR]:CAD Common Name (eg, YOUR name) []:www.nix.co.jj Email Address []:katou@nix.co.jj Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:87654321 An optional company name []:NIX Ltd % cat newreq.pem -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,6E8792C7F8C0A3D3 | -----END RSA PRIVATE KEY----- こんなのができる。 -----BEGIN CERTIFICATE REQUEST----- | -----END CERTIFICATE REQUEST----- % CA.sh -sign Enter PEM pass phrase: 12345678 Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName :PRINTABLE:'JP' stateOrProvinceName :PRINTABLE:'Aichi' localityName :PRINTABLE:'Anjyo' organizationName :PRINTABLE:'NIX Ltd' organizationalUnitName:PRINTABLE:'CAD' commonName :PRINTABLE:'www.nix.co.jj' emailAddress :IA5STRING:'katou@nix.co.jj' Certificate is to be certified until Nov 7 04:19:45 1997 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries issuer が認証局の方 Data Base Updated ↓ issuer :/C=JP/SP=Aichi/L=Anjyo/O=NIX Ltd/OU=CAD/CN=WWW/Email=KATOU subject:/C=JP/SP=Aichi/L=Anjyo/O=NIX Ltd/OU=CAD/CN=WWW/Email=KATOU serial :01 紙面の都合 CN=www.nix.co.jj を CN=WWW と略す。 Certificate: Email=katou@nix.co.jj を Email=KATOU と略す。 Data: -------------------------------------------- Version: 0 (0x0) Serial Number: 1 (0x1) Signature Algorithm: md5withRSAEncryption Issuer: C=JP, SP=Aichi, L=Anjyo, O=NIX Ltd, OU=CAD, CN=WWW, Email=KATOU Validity Not Before: Nov 7 04:19:45 1996 GMT Not After : Nov 7 04:19:45 1997 GMT Subject: C=JP, SP=Aichi, L=Anjyo, O=NIX Ltd, OU=CAD, CN=WWW, Email=KATOU Subject Public Key Info: Public Key Algorithm: rsaEncryption Modulus: 00:b0:45:fc:be:cd:1e:37:0f:d3:09:91:68:07:ef: 36:fd:ad:4f:5f:9e:bd:40:eb:73:14:33:b5:92:f8: 97:e9:6e:9c:63:06:6a:0e:76:53:86:3e:0c:c7:a7: f2:55:6f:96:83:40:18:8e:d7:b7:20:4a:55:6d:d0: 58:04:fa:85:05 Exponent: 65537 (0x10001) Signature Algorithm: md5withRSAEncryption 4c:0f:03:62:d2:3a:02:af:3f:25:84:c3:e5:75:37:69:c4:c6: 6b:42:da:82:60:97:8d:6c:61:71:63:9e:c5:45:6d:d0:b5:bc: 93:5e:59:37:7f:97:64:c0:47:76:f7:3a:d3:3c:ea:c8:8b:34: df:c7:c3:0b:21:b8:35:5e:d4:9c -----BEGIN CERTIFICATE----- MIIB9jCCAaACAQEwDQYJKoZIhvcNAQEEBQAwgYUxCzAJBgNVBAYTAkpQMQ4wDAYD VQQIEwVBaWNoaTEOMAwGA1UEBxMFQW5qeW8xEDAOBgNVBAoTB05JWCBMdGQxDDAK BgNVBAsTA0NBRDEWMBQGA1UEAxMNd3d3Lm5peC5jby5qcDEeMBwGCSqGSIb3DQEJ ARYPa2F0b3VAbml4LmNvLmpwMB4XDTk2MTEwNzA0MTk0NVoXDTk3MTEwNzA0MTk0 NVowgYUxCzAJBgNVBAYTAkpQMQ4wDAYDVQQIEwVBaWNoaTEOMAwGA1UEBxMFQW5q eW8xEDAOBgNVBAoTB05JWCBMdGQxDDAKBgNVBAsTA0NBRDEWMBQGA1UEAxMNd3d3 Lm5peC5jby5qcDEeMBwGCSqGSIb3DQEJARYPa2F0b3VAbml4LmNvLmpwMFwwDQYJ KoZIhvcNAQEBBQADSwAwSAJBALBF/L7NHjcP0wmRaAfvNv2tT1+evUDrcxQztZL4 l+lunGMGag52U4Y+DMen8lVvloNAGI7XtyBKVW3QWAT6hQUCAwEAATANBgkqhkiG 9w0BAQQFAANBAEwPA2LSOgKvPyWEw+V1N2nExmtC2oJgl41sYXFjnsVFbdC1vJNe WTd/l2TAR3b3OtM86siLNN/HwwshuDVe1Jw= -----END CERTIFICATE----- ↑ newcert.pem を表示している。