5分でわかるHTTPSと証明書：役割とよくある勘違い

HTTPSと証明書を初めて学ぶ人向けの7枚の資料です。通信を守る仕組みと、サイト自体を信用する判断を分けて説明します。

1. HTTPSと証明書

ネットで買い物をする場面から考えます。入力した情報が接続先へ届くまでの通信を、HTTPSで保護します。店の説明が正しいかは、別に確認します。

2. 通信を守るTLS

HTTPSはHTTPの通信をTLSで保護する仕組みです。暗号化は通信途中の盗み見への対策、改ざん検出は途中の変更に気付く仕組みです。通常のWeb接続ではサーバーの認証も行います。

3. 証明書と秘密鍵

証明書には公開鍵、対象の名前、有効期間などが入ります。ブラウザへ提示する証明書と、サーバー側で保管する秘密鍵は役割が違います。通常の証明書を使うTLS 1.3では、秘密鍵による署名を公開鍵で検証します。通信を暗号化する鍵は別に導出します。

4. 認証局と信頼のつながり

CA（認証局）が証明書へ署名します。ブラウザは発行者の署名などを信頼の起点へたどれるか確認します。サーバーから受け取ったルート証明書を無条件に信用するわけではありません。毎回CAへ問い合わせる流れを表した図ではありません。

5. ブラウザの代表的な確認

アクセス先の名前、有効期間、信頼のつながりを確認します。失効情報やブラウザの方針なども関係し、この三つは全確認項目の一覧ではありません。警告が出たら情報の入力を止め、日時・アドレス・警告文を確認します。

6. HTTPSとサイトの信用

通信の保護と、運営者・取引内容の信用は別の判断です。HTTPSを使う偽サイトもあり、ブラウザの接続表示を信用のお墨付きと解釈しません。公式アドレス、運営者、取引条件も確認します。

7. 理解の確認

1. 証明書と一緒に秘密鍵をブラウザへ渡す？ 答え：渡しません。
2. 期限内ならどんな名前のサイトにも使える？ 答え：対象名などの確認も必要です。
3. HTTPSなら通販の運営者を信用できる？ 答え：運営者と取引条件も確認します。

役割を図で振り返る：PKIちゃんねるのHTTPSとTLS。
通信の順序を詳しく学ぶ：TLSハンドシェイクの解説。

一次資料

- MDN：TLS
- RFC 5280：証明書パス検証
- RFC 9525：接続先の名前
- RFC 8446：TLS 1.3
- Chromium：接続表示とサイトの信用
- Let's Encrypt：認証と発行

---

資料確認と執筆にAIを使用しています。

Transcript