Layer)はインターネット上でデータを暗号化して送受信するトランスポート層のプロトコル1。Security)はSSLを元に作られたプロトコル。SSLという名称が広く普及していたことからSSLと呼ばれることも多い。多くのサイトではより安全性の高いTLSが使われている。現在のTLSの最新バージョンは1.2で、TLSがネゴシエーション時に使うバージョン番号はSSL時代からの通し番号で「3.3」になっている2。Secure)はTLSを使って、セキュアなHTTP通信をしている。サーバ証明書を取得するSSLにはサーバ証明書が必要。opensslコマンドなどを使って、証明書発行に必要な証明書要求データを作る。kirinwikiblogが詳しいので参考にした。opensslコマンドでRSA方式で2048ビットの鍵ペア(秘密鍵)を作る。modulus”と書いてあるように2048ビットなのはmodulusである。65537になっていて、これは固定っぽい。server.keyの中身を見ていこう。2048ビットは長いので32ビットで見ていく。32ビット未満は小さすぎるというエラーが出て生成できない。Mail)形式になっている。PEMはBEGINとENDのラベルとその間にBASE64でエンコードされた値を持つファイル。いう形式でエンコードしたバイナリ。blogを参照して下さい。バイナリを直接見なくても、以下のコマンドで秘密鍵の内容を知ることができる4。2バイト)になるっぽい。e$を入っているので紛らわしい。入っているからこそ、次のコマンドで証明書要求データに必要な公開鍵を含めることができるのだが......。Request)を作ってみる。Nameだけtmsanrinsha.netを入力して他は空で作ってみた。ここで出力されるserver.reqもPEM形式。拡張子をcsrで作成する場合もあり。server.keyは32ビットだと作成に失敗するので2048ビットにした。b0:98:9f:77DATAの部分に先程入力した値と公開鍵の情報が入っている。sha1WithRSAEncryptionの部分は電子署名で、秘密鍵を使って署名されている5。このファイルを認証局に送る。認証局は証明書要求データの提出者がドメインの所有者であるかを検査する。提出者にメールで秘密のパスワードを送り、提出者はそのパスワードをサイトのトップディレクトリに置く。認証局の人がそのファイルを確認できればOKのような審査だ6。審査が通るとサーバ証明書が取得できる。雰囲気をつかむために自分で証明書を作成してみよう。keyX.509という形式でserver.reqというCSRファイルから、自分の秘密鍵server.keyでserver.crtという証明書を作った。自分の秘密鍵で署名をしているため、これは自己署名証明書(オレオレ証明書)と呼ばれる証明書になっている。server.crtの中身を見てみる。6c:bc:d6:34CSRにIssuerや有効期限が追加されてたような構造になっている。署名はサーバ証明書の最初の部分をハッシュ化して、秘密鍵(通常だと認証局のもの)で暗号化して作られる。サーバ証明書の正当性は、署名を認証局の公開鍵で復号して出てきたハッシュ値と、証明書の最初の部分をハッシュ化して出てきたハッシュ値が一致するかで検証される。認証局の公開鍵は中間証明書という証明書から取得できて、これはSSL通信時にはサーバ証明書とともにサーバから送られてくる。中間証明書の正当性の検証はどう行われるか。中間証明書にも署名が入ってあり、それはルート認証局という最上位の認証局の秘密鍵で署名されている。ルート認証局の公開鍵はルート証明書から取得できて、ルート証明書はブラウザに最初から入っているので検証することができる。ルート認証局より上位の認証局はないためルート証明書は自己署名証明書になっている。このように証明書を検証する仕組みがチェーンのように連なっているので、一連の証明書のことを証明書チェーンといったりする。中間証明書はサーバ証明書とルート証明書の間にあるので、中間証明書と呼ばれている。ルート証明書と中間証明書にクロスルート設定用証明書というものが存在する場合もあるようだ。イントラネットなどでは中間証明書を介さず、いきなりルート証明書になることもあるようだ。イントラネットのルート証明書は自分でブラウザにインストールする必要がある。中間証明書(必要な場合)サーバ証明書を作るために使った秘密鍵を置く。置き場所や設定はapacheだのtomcatだのhttpサーバの設定に従う。SSL通信クライアントとサーバのやり取りは以下の通り7。ここではブラウザとウェブサーバを例にとるが、アプリとAPIサーバ、ウェブサーバとAPIサーバといった組み合わせも同じ感じだと思われる。...)にアクセスして、SSL暗号化通信で接続要求する。)をウェブサーバーへ伝える。ウェブサーバはクライアントから提示された暗号化の仕様から実際に利用するものを選択して、クライアントに通知する。ウェブサーバはサーバ証明書をクライアントに送る。中間証明書があるならそれも送るはず。同じタイミングかは不明。クライアントは受け取った証明書の署名検証を行う。クライアントは証明書の内容の検証する。(FQDN)や有効期限などに問題がないか証明書が失効してないか(認証内容の変更や暗号鍵の紛失などで認証局が証明書の失効を宣言することがある)8クライアントは証明書の検証が完了すると、サーバ証明書にあるウェブサーバの公開鍵を用いて、プリマスタシークレット(共通鍵を生成するもととなる乱数データ)を暗号化して、ウェブサーバへ送付する。ウェブサーバは受け取った暗号化されたプリマスタシークレットを自分の秘密鍵を用いて復号化する。使うのは公開鍵暗号化方式よりも処理速度が早いため9。クライアントがクライアント証明書をもって、「その証明書保有者のみが閲覧可能なサイト」を閲覧する仕組みもあるそうな10。Qiitaがわかりやすい。Qiitaに秘密鍵、公開鍵などを見る方法をが色々載っている。