Carpe Diem

備忘録。https://github.com/jun06t

SSLのファイルの区別やら手続きの流れ

SSLは使っているけど、証明書とか公開鍵とか仕組みはどうなってるんだろう? と思って調べてまとめてみました。 色々と誤情報があふれたままSSLの解説をしているサイトが多いので、なるべく定義的なところから調べてみて理解できるようになりました。 まずファイル名からして多岐に渡っている(key, csr, crt, pemなど)ので、その辺の区別から。 秘密鍵 このファイル名はおおよそ*.keyとなっています。一部サイトでは*.pem*.key.pemとされています。秘密鍵かどうかを確認するには、ファイルの内容を確認します。「-----BEGIN RSA PRIVATE KEY-----」で始まり、「----END RSA PRIVATE KEY-----」で終わります。場合によっては「RSA」が無いものもあるようです。「PRIVATE KEY」という文字列があればほぼ間違いないでしょう。 # openssl rsa -in server.key -text でテキスト表示できます。 CSRファイル 申請者を識別する情報と、秘密鍵に対応する公開鍵が含まれます。認証局に署名してもらうために提出するファイルです。これに署名情報が入ると下のサーバ証明書になります。保存名は、*.csrとなっています。一部サイトでは*.csr.pemcsr.pemとされています。CSRファイルかどうかを確認するには、ファイルの内容を確認します。「-----BEGIN CERTIFICATE REQUEST-----」で始まり、「-----END CERTIFICATE REQUEST-----」で終わります。もしくは「-----BEGIN NEW CERTIFICATE REQUEST-----」で始まり、「-----END NEW CERTIFICATE REQUEST-----」で終わります。「CERTIFICATE REQUEST」という文字列があればほぼ間違いないでしょう。 # openssl req -in server.csr -text でテキスト表示できます。申請者情報と公開鍵が確認できます。 サーバ証明書 認証局より送り返されてくるファイルです。狭義では中身は秘密鍵に対応する公開鍵&ルート認証局の署名です。広義ではこのサーバ証明書と、下のルート認証局の自己証明書をあわせて(といってもファイルは一つです。組み込んで、と言った感じでしょうか)「サーバ証明書」と言います。ルートファイルの保存名が*.cer*.crtといったものから、certificate.txtなど、ファイルの内容を連想するにも困難なものまであります。ファイルとしては公開鍵なので、内容を確認すると「-----BEGIN CERTIFICATE-----」で始まり、「-----END CERTIFICATE-----」で終わります。 # openssl x509 -in server.crt -text でテキスト表示できます。これはWebブラウザ等で詳細を確認するときに表示されるものです。Issueの部分に署名者の情報が書かれています。 自宅サーバの設定で出てくるのは上の3つです。ただ理解のために下の2つについても書きます。 ◆ルート認証局の自己証明書(CA証明書) 中身はルート認証局の署名と、ルート認証局の公開鍵です。サーバ証明書の一要素になります。これは公的な認証局によるものと、独自の認証局によるものがあります。後者の場合、サーバ証明書オレオレ証明書などと呼ばれます。公的な認証局の場合、この証明書があらかじめWebブラウザ等に組み込まれており、下の「ルート証明書」と一致するか確認するのに使用します。解説サイトによっては独自認証局の場合、これを作成してからサイト証明書を作成するサイトもありますが、元々独自証明用のコマンドが用意されているのでこのブログの解説「SSLの設定」ではこのファイルは作成してません。 ルート証明書 クライアント側の証明書です。このルート証明書と、サーバ証明書に含まれるルート認証局の自己証明書が一致するか確認するのに利用します。本来この2つは同一のファイルです。公的な認証局の場合、Webブラウザ等にあらかじめこの証明書が入っています。独自の認証局の場合、証明書の一致が確認できないためWebブラウザ等で警告が出てきます。親切なサイトではこの独自ルート証明書をダウンロードしてインストールするように促しています。独自の場合でもルート証明書を公開し、インストールしてもらえば警告は出なくなります。 そしてSSLのサーバ・クライアント間の手続きの流れとしては ◆公的な認証局ルート証明書(クライアント)とルート認証局の自己証明書(サーバから受けとる。サーバ証明書とともに受けとる)が一致するか確認。 ②一致を確認後、ルート認証局の証明書の中に入っている公開鍵を使って,サーバー証明書に付けられた署名を検証する。具体的には,「署名をルート認証局の公開鍵で復号したデータ」と「サーバー証明書ハッシュ値」が一致するかどうかを確かめる。一致すれば,そのサーバー証明書は,確かにルート認証局から署名を受けたサーバー証明書であると判断される。 ③サーバー証明書が信頼できると判断され,サーバー証明書の中にある公開鍵も信頼できることになる。そして公開鍵を使ってSSLによる暗号化通信を実現する。 ◆独自な認証局ルート証明書を発行しインストールを促すサイト) ①クライアントにルート証明書をダウンロードし、インストールしてもらう。 ②公的な場合の①と同じ ③公的な場合の②と同じ ④公的な場合の③と同じ。 ◆独自の認証局ルート証明書を配布しない) ①公的な場合の①と同じ ②一致しない。クライアント側にルート証明書が無いため、Webブラウザやメーラーでは警告が出る。しかし普通の人の場合、OKを出さなければSSLは利用できないため、警告を無視してOKを出す。 ③ユーザにOKを出されたので、サーバー証明書の中にある公開鍵は信頼できるものとされ(実際はそうではないが)、公開鍵を使ってSSLによる暗号化通信を実現する。 となります。 こんな感じでしょうか。 ◆暗号化通信 以降の流れは図の通りになります。 ssl_act.jpg クライアントは共通鍵を生成し、それを公開鍵で暗号化し、サーバに送ります。サーバには秘密鍵があるので共通鍵を復号化できます。秘密鍵を持たないパケット盗聴者は復号化することができません。 これによってクライアント・サーバの両方のみが共通鍵を持つことができたので、この共通鍵によって通信を暗号化します。 ソース: SSL証明書インストールに関するメモ Lesson4:相手が信頼できることを確かめる「サーバー証明書」とは? opensslコマンド SSLの仕組み