1. SSLとTLSの決定的な違い
一般的には今でも「SSL」と呼ばれることが多いですが、SSL 2.0および3.0はPOODLE等の暗号学的脆弱性により数十年前に完全に廃止されています。
現在の安全なWeb通信はTLS (Transport Layer Security)によって保護されており、最新の業界標準は TLS 1.3 (RFC 8446) です。TLSはTCP（またはHTTP/3ではQUIC）の直上で動作し、HTTPヘッダー、Cookie、ペイロードを含むすべてのデータを暗号化します。
2. TLS 1.3ハンドシェイク（1-RTT高速接続）
TLS 1.3ではECDHE（楕円曲線ディフィー・ヘルマン）鍵交換を採用し、接続確立に必要な通信往復を従来の2往復からわずか1往復（1-RTT）へと大幅に短縮しました：
1. Client Hello: クライアントが対応暗号スイートとECDHE公開鍵パラメータを先制送信
2. Server Hello: サーバーが暗号方式を選択し、サーバー側鍵パラメータ、X.509証明書、および署名を返信
3. 共通秘密鍵の算出: 双方が独立して同一の対称セッション鍵（
K_session）を導出4. 暗号化通信の即時開始: 直ちに保護されたHTTPデータの高速送受信を開始
3. X.509電子証明書とCA信頼チェーン
ブラウザは、階層化された電子署名チェーンを検証してサーバーの正当性を確認します：
- ルート認証局 (Root CA): OSやブラウザの信頼ストアに事前組み込みされた自己署名証明書（DigiCert、Let’s Encrypt ISRG Root X1 等）。
- 中間認証局 (Intermediate CA): ルートCAの秘密鍵漏洩を防ぐため、日常的な証明書発行を担当する委託認証局。
- サーバー証明書 (Leaf Certificate): ドメイン名（SANs）とサーバーの公開鍵を法的に紐付ける末端の証明書。
4. Certificate Transparency (CT) ログの必須化
不正な認証局による無断証明書発行を防ぐため、RFC 6962はすべての公的TLS証明書を公開された追記限定のマークルツリーログ（CTログ）に登録することを義務付けています。
ブラウザは、証明書内に有効なSCT（Signed Certificate Timestamp）が含まれていない場合、HTTPS接続を即座に遮断します。
5. 本番HTTPSセキュリティ強化チェックリスト
1. TLS 1.3 / 1.2 のみを強制: レガシーなTLS 1.0、TLS 1.1および脆弱なCBC暗号スイートを完全に無効化する。
2. HSTSプリロードの適用:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload を送信してSSL Strip攻撃を防御。3. ACMEによる証明書更新の完全自動化: Let’s Encrypt等のACMEクライアントを用いて60〜90日ごとの自動更新を確立する。