2008年04月02日(Wed) [長年日記]
● [n810] opensshを更新
Application managerのCheck for updatesで表示されたopensshを更新したらopenssh-clientとopnessh-serverがopnessh-commonがみつからないからと言って更新できなくなりました。一度3つともUninstallしてからopenssh-serverとopenssh-clientのみ入れたらそれでも動くのでヨシとする。
● SSL/TLS用語は難しい
先週から冷や汗をかきながらつくってきた、おうちhttpsサーバがやっと稼動しはじめました。さっそくシゴトに活躍してるよ。正しい手順を踏んで設定できたかどうかいまいち自信がないので、今はここには公開しません。参考にさせてもらったサイトのみなさん、ありがとうございました。
で、ぼんやりとわかってきたこと。
まず、SSL/TLSもsshやgpgと同じく公開鍵暗号と対称鍵暗号を使うということ。公開鍵暗号で相手を確かめ、対称鍵暗号のための鍵のやりとりをして、対称鍵暗号でデータのやりとりをするようです。
sshやgpgと違うのは、通信の両端ではない第三者としてCAが重要なことでしょうか。クライアントが期待通りのサーバに接続できたかどうかを判断するのに、サーバ証明書を確認するし、サーバが接続してきているのが期待通りのクライアントかどうかを判断するのに、クライアント証明書を確認するようです。ここで確認のためにはCAの証明書を使います。…これだではさっぱりわからなかったのですが、「証明書」を「署名された公開鍵」とするとなんとなくわかってくる。クライアントにもサーバにも、信頼できると決めたCAの証明書(公開鍵)があり、相手から提出された証明書(CAの私有鍵で署名された、通信のための公開鍵)の、CAによる署名を確認する。(サーバ証明書が、オレオレ証明書だったり、CAcert.ogが署名した証明書だったりする場合には、これらのCAを信頼すると決める代わりに、サーバ証明書そのものを信頼すると決めることもできますね。)
一方、通信内容を暗号化するためには、サーバにもクライアントにも、証明書(公開鍵)に対応する私有鍵が必要ですよね。少なくともSafariでは、クライアント証明書(p12形式)をインポートすると、「証明書」(CAに署名された公開鍵)、「鍵」(たぶん私有鍵)、と「CAのルート証明書」(クライアント証明書を発行する時に署名したCAの公開鍵)が保存されるようです。なるほど。CAの証明書は、サーバがクライアント証明書を確認するのに必要なだけなので、クライアント側には不要な気もします。いっぽう、Firefoxでは、「Your Certificate」のなかに一つだけエントリーが増えるだけです。この証明書をViewすると、「Could not verify this certificate for unknown reason」と表示される。きっとオレオレCAの証明書が無いからだよね。
というわけでまだまだ理解したとは言い難いSSl/TLSについてメモしました。まだまだべんきょーしたいところだけど、とりあえずサーバが動いちゃうとそれもままならないのでした。
(追記) サーバ/クライアント証明書には、それぞれの公開鍵だけじゃなくて、Common Nameとか所在地とかも含まれますね。CAはそういう情報にも署名する。
● しかしクライアント証明書をクライアント側で検証しようとするのはなんとなく変だよねえ。うまく接続させてもらえそうか確認するということなのかな…
最近のツッコまれどころ