SSL/TLS証明書キャッチアップ
SSL証明書を理解するには、まず「通信を暗号化する仕組み」ではなく、相手が本物か確認するための身分証明書として捉えるとわかりやすいです。
現在は多くの場合 TLS証明書 と呼ぶのが正確です。
ただし日常的には「SSL証明書」と呼ばれることが多いです。
全体像
SSL/TLS証明書は、ざっくり言うと次を証明します。
- このドメインは本当にそのサーバーのものか
- 通信相手がなりすましではないか
- 暗号化通信に使う公開鍵は信頼できるものか
登場人物
重要なのは、サーバーは 秘密鍵 を持ち、証明書には 公開鍵 が入っていることです。
HTTPS接続の流れ
ブラウザが https://example.com にアクセスしたとき、裏側ではだいたい次のような流れになります。
実際のTLSハンドシェイクでは、鍵交換や暗号方式の合意も行われます。
最初は「サーバーが証明書を提示し、ブラウザが検証し、その後に暗号化通信が始まる」と理解すれば十分です。
証明書の中身
SSL/TLS証明書には、主に以下の情報が入っています。
特に重要なのは SAN です。
現在の証明書では、証明書がどのドメインに有効かは多くの場合 Subject Alternative Name、つまり SAN で確認されます。
例:
Subject: CN=example.com
SAN:
DNS: example.com
DNS: www.example.com
この証明書なら、以下には使えます。
https://example.com
https://www.example.com
しかし以下には使えません。
https://api.example.com
api.example.com も使いたいなら、SANに含めるか、ワイルドカード証明書などが必要です。
証明書チェーン
ブラウザは、サーバー証明書だけを見て信頼しているわけではありません。
信頼の連鎖をたどっています。
この構造を 証明書チェーン と呼びます。
ブラウザはこう考えます。
このサーバー証明書は中間CAに署名されている
その中間CAは信頼済みルートCAに署名されている
だから、このサーバー証明書は信頼できる
秘密鍵と公開鍵
SSL/TLS証明書で混乱しやすいのが、証明書と秘密鍵の関係です。
サーバー側には通常この2つが必要です。
server.crt # 証明書
server.key # 秘密鍵
証明書は公開してよいですが、秘密鍵は絶対に漏らしてはいけません。
リバースプロキシとの関係
HTTPS通信を簡易的に実現する構成として、リバースプロキシを使うことがあります。
この場合でも、SSL/TLS証明書が不要になるわけではありません。
多くの構成では、SSL/TLS証明書はリバースプロキシ側に置きます。
ブラウザから見ると、TLS接続している相手はアプリサーバーではなくリバースプロキシです。
そのため、ブラウザに証明書を提示するのもリバースプロキシになります。
このように、リバースプロキシがHTTPSを受けて、内側のアプリサーバーにはHTTPで転送する構成を TLS終端 または SSL終端 と呼びます。
この構成では、アプリサーバーは証明書を持たなくてもよいです。
アプリは通常のHTTPサーバーとして動き、HTTPSに関する処理はリバースプロキシが担当します。
例:
App: http://127.0.0.1:3000
Proxy: https://example.com
リバースプロキシが担当すること:
- 443番ポートでHTTPSを受ける
- SSL/TLS証明書を提示する
- TLSハンドシェイクを処理する
- 復号したHTTPリクエストをアプリサーバーへ渡す
- アプリサーバーのHTTPレスポンスをHTTPSで返す
アプリサーバーが担当すること:
- 通常のHTTPリクエストを処理する
- ビジネスロジックを実行する
- HTTPレスポンスを返す
つまり、リバースプロキシを使うと「証明書が不要になる」のではなく、証明書をアプリサーバーではなくリバースプロキシに集約できるということです。
Caddy、Traefik、AWS ALB、Cloudflare などは、証明書の取得・更新やTLS終端を自動化できます。
そのため「証明書をあまり意識せずにHTTPS化できる」ように見えますが、内部的には必ずSSL/TLS証明書が使われています。
証明書の種類
代表的には次のような種類があります。
| 種類 | 説明 |
|---|---|
| DV証明書 | ドメイン所有だけを確認する。一般的なWebサイトでよく使う |
| OV証明書 | 組織の実在性も確認する |
| EV証明書 | より厳格に組織確認する |
| ワイルドカード証明書 |
*.example.com のようにサブドメインに使える |
| マルチドメイン証明書 | 複数ドメインを1枚で扱う |
今の一般的なWebサービスなら、まずは DV証明書 で十分なケースが多いです。
Let's Encrypt もDV証明書です。
よくあるエラー
よく見る原因はこのあたりです。
- 証明書の有効期限が切れている
-
example.com用の証明書をapi.example.comで使っている - 中間証明書をサーバーに設定していない
- 自己署名証明書を本番で使っている
- 証明書と秘密鍵のペアが違う
最低限押さえるべきこと
SSL/TLS証明書は、以下の3点を押さえるとかなり理解しやすくなります。
- 証明書は「このドメインの公開鍵はこれです」と証明するもの
- その証明書はCA、つまり認証局によって署名される
- サーバーは証明書と秘密鍵を使ってHTTPS通信を成立させる
一言でまとめると、SSL/TLS証明書は、HTTPS通信で 相手の正当性 と 暗号化に使う公開鍵の信頼性 を保証するための仕組みです。