証明書(Certificate)

1.0.0 はじめに
2.0.0 openssl による「証明書」の作り方
3.0.0 もっと詳しくは
4.0.0 「証明書」について、苦言の追加

2002/08/29

はじめに

Pegasus での https のサポートは Plan9 4ed. の TLS ライブラリを使用している。
暗号通信を行うためには公開鍵と秘密鍵のペアを作成すれば良いはずなのだが、web の世界ではよけいな付加「価値」を付け、それによってひどく面倒になっている。公開鍵に(意味の無い)証明書を添えなければ、ブラウザが「このサーバは危ないよ」と言わんばかりの警告を発するのである。かくして CA ビジネスなるものが発生する。

Web サーバを使用してビジネスを行おうとすれば証明書を買わざるを得ないであろう。セールスマンは身だしなみを整える必要があるからである。(身だしなみはセールスマンだけではなく、詐欺師の必需品でもある。) 真の信用とは何の関係もないと分かっていても。

筆者はビジネスとは無縁の者なので、偽りの信用のために詰まらない投資をする積もりはない。以下では無料の「証明書」の作り方を解説する。(もちろん、ブラウザからアクセスすると警告メッセージが出る。)

openssl による「証明書」の作り方

「証明書」は openssl を使って作成できる。残念ながら openssl は Plan9 にはまだ移植されていない。(最近 gcc が移植されたので、誰かが openssl を移植してくれるかも知れない。) そこで他のホストの力を借りる事になる。筆者は Linux を使用した。以下はその時の記録である。役に立つかも知れない。

	[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 サーバの信頼性を確認するメカニズムを持つ方が建設的だろうと思うのだが、どうだろうか?