Kenji Arisawa E-mail: arisawa@aichi-u.ac.jp Aichi University Kurozasa 370, Miyoshi-cho Aichi, JapanPowered by Pegasus
Web サーバを使用してビジネスを行おうとすれば証明書を買わざるを得ないであろう。セールスマンは身だしなみを整える必要があるからである。(身だしなみはセールスマンだけではなく、詐欺師の必需品でもある。) 真の信用とは何の関係もないと分かっていても。
筆者はビジネスとは無縁の者なので、偽りの信用のために詰まらない投資をする積もりはない。以下では無料の「証明書」の作り方を解説する。(もちろん、ブラウザからアクセスすると警告メッセージが出る。)
[arisawa@pc web]$ openssl req -x509 -nodes -newkey rsa:1024 -keyout key.pem -out cert.pem Using configuration from /usr/share/ssl/openssl.cnf Generating a 1024 bit RSA private key ................................++++++ ...................++++++ writing new private key to 'key.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:JP State or Province Name (full name) [Some-State]:Aichi Locality Name (eg, city) []:Nagoya Organization Name (eg, company) [Internet Widgits Pty Ltd]:Aichi University Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:ar.aichi-u.ac.jp Email Address []:arisawa@aichi-u.ac.jp [arisawa@pc web]$これで key.pem (秘密鍵) と cert.pem (公開鍵) が openssl を実行したディレクトリに作成される。
http://mars.elcom.nitech.ac.jp/securityには openssl に関する詳しい解説がのっている。
http://www.tcp-ip.co.jp/~ikken/intro/www3.txtから辿ったのだが、ikken さんの記事も面白いので読まれたらよいと思う。(この人は茶道の先生らしい。それにしてもすごい趣味人ですね。)
サイトの信頼証明を与えたいのであればもっと別な方法をとるべきであろう。ホームページの入り口に、誰が信用を与えたか、それによって何を保証しているのかがはっきりと分かるやり方で。それは暗号通信と何の関係もないはずである。(電子署名はこのような場面でこそ使用されるべきである。)
Web のサーバがクラックを受けて公開鍵が書き換えられる事を恐れているのだろうか?
(あり得ることである。) しかしこの場合には単に通信不能に陥るだけである。「証明書」が添えられているか否かは全く関係が無い。
Web のサーバがクラックを受けて秘密の鍵が盗まれる事を恐れているのだろうか?
しかしこの場合には「証明書」が添えられているか否かに関わらず暗号通信が破られることになる。
インターネットは IP アドレスに基礎を置いている。さらに実際にはドメイン名と IP アドレスの対照表を持っている DNS がインターネットを支えている。
DNS サーバがクラックされる事によってユーザが偽りのホストに誘導される事がありえる。だから Web サーバの証明が必要なのだと言う。しかし、これは DNS サーバの信頼性の問題であり、Web サーバ側の問題ではない。暗号通信とはさらに関係が無い。DNS サーバの信頼性を確認するメカニズムを持つ方が建設的だろうと思うのだが、どうだろうか?