SSL/TLS 完全ガイド：仕組み・証明書・TLS1.3対応と運用のベストプラクティス

2025年11月18日 最終更新日時 : 2025年11月18日 エバープレイ編集部

SSL とは — 概要

SSL（Secure Sockets Layer）は、インターネット上でデータを安全に送受信するためのプロトコルとして1990年代に登場しました。現在ではSSL自体は廃止され、TLS（Transport Layer Security）という後継仕様が標準として使われていますが、一般的に「SSL」「SSL証明書」「SSL化」といった言い回しは今でも広く使われています。本稿では歴史、仕組み、運用、脆弱性と対策、実務上のベストプラクティスまでを詳細に解説します。

歴史と名称

  • SSL 1.0 は公開されず、Netscape が開発した SSL 2.0（1995年）が初の公開実装。ただし脆弱性が多く、SSL 3.0（1996年）へ改訂されました。

  • その後、TLS として標準化が進み、TLS 1.0 は RFC 2246（1999）。以降 TLS 1.1・1.2（広く採用）を経て、TLS 1.3（RFC 8446, 2018）が現在の推奨仕様です。

  • 「SSL」という呼称は残るものの、実際の暗号化通信は TLS（特に TLS 1.2 / 1.3）で行うのが現代の常識です。

基本的な仕組み（PKI と暗号方式）

SSL/TLS の目的は主に次の3点です：機密性（通信の暗号化）、完全性（改ざん検知）、認証（相手が正しいことの確認）。これを実現するために公開鍵基盤（PKI）と複数の暗号技術を組み合わせます。

  • 非対称暗号（公開鍵/秘密鍵）：サーバ（および場合によってはクライアント）が証明書と秘密鍵を持ち、公開鍵で署名検証や鍵交換の一部に使います。

  • 対称暗号：実際の通信データは高速な対称鍵暗号（例：AES-GCM）で暗号化されます。非対称暗号は主にセッション鍵の交換（鍵導出）に使われます。

  • ハッシュ関数とMAC：メッセージの改ざん検出と完全性を担保します。TLS 1.3 では AEAD（認証付き暗号）を推奨し、暗号と検証を一体化しています。

TLS ハンドシェイクの概要（代表的な流れ）

ここでは簡潔に TLS ハンドシェイク（特に TLS 1.2 / 1.3 の違いを意識しつつ）を説明します。

  • クライアントHello：クライアントは対応可能な TLS バージョン、暗号スイート、乱数（ClientRandom）、拡張（SNI、ALPN 等）を送る。

  • サーバHello：サーバは使用する TLS バージョン、暗号スイート、乱数（ServerRandom）、証明書（サーバ証明書チェーン）を送る。SNI（Server Name Indication）により複数ドメインを一つの IP で運用可能。

  • 鍵交換：従来は RSA 鍵交換や（EC）DHE による鍵共有が用いられ、TLS 1.3 では鍵導出が簡素化され高速・安全になっています（1-RTT での確立、0-RTT の注意点あり）。

  • 証明書検証：クライアントはサーバ証明書を CA から信頼できるか検証し、ホスト名や有効期間、失効状態をチェックします。

  • マスターシークレット生成と暗号化通信開始：双方が共有鍵を導出し、対称暗号で通信を開始します。

証明書（X.509）と信頼のチェーン

サーバ証明書は X.509 形式で発行され、証明書チェーン（サーバ証明書 → 中間 CA → ルート CA）を通じてクライアントの「信頼済みルートストア」に到達することで検証されます。重要なポイント：

  • ルート CA は OS/ブラウザベンダーのルートストアに格納されており、各ベンダーの審査（CA/B フォーラムの基準等）が存在します。

  • 証明書の主な種類：DV（ドメイン検証）、OV（組織検証）、EV（拡張検証）。近年は DV が多く、EV 表示の価値はブラウザの表示変更で相対的に低下しています。

  • ワイルドカード証明書（*.example.com）や SAN（Subject Alternative Name）で複数ドメインをカバー可能。

証明書の取得と自動化（Let’s Encrypt と ACME）

Let’s Encrypt は無料で自動発行できる ACME（Automatic Certificate Management Environment）プロトコルを提供し、短期間での自動更新により証明書運用のコストとリスクを大幅に低減しました。特に有効期間が短い（90日）ため、自動更新が推奨されます。

代表的な脆弱性と注意点

  • Heartbleed（2014）：OpenSSL の脆弱性によりメモリ情報漏洩。秘密鍵やセッション情報が漏れる可能性があり、該当バージョンを使っていたサーバは秘密鍵の再発行が推奨されました。

  • POODLE：SSL 3.0 の脆弱性を利用した攻撃。SSL 3.0 の無効化が必要。

  • BEAST/CRIME：TLS の歴史的脆弱性。TLS 1.0 の弱点や圧縮の無効化などが対策に。

  • RC4：バイアスにより暗号として推奨されない。

  • 証明書失効（CRL / OCSP）問題：クライアント側での失効チェックは確実ではないため、OCSP ステープリングや短い有効期間、自動更新、Certificate Transparency の活用が重要です。

TLS 1.3 の革新点

  • ハンドシェイクの簡素化と高速化（往復回数削減）、安全性向上（古い暗号や脆弱な機能の削除）。

  • 0-RTT により再接続で高速化できる一方、リプレイ攻撃のリスクがあるため注意が必要。

  • 推奨暗号は AEAD（例：AES-GCM、ChaCha20-Poly1305）で、ECDHE による前方秘匿（Perfect Forward Secrecy）を標準で利用します。

実務上のベストプラクティス

  • 最新の TLS（現時点では TLS 1.3 を優先、TLS 1.2 をサポート）を有効にする。

  • 弱いプロトコル（SSL 2.0/3.0、TLS 1.0/1.1）や弱い暗号（RC4、非 PFS モード等）を無効化する。

  • 強力なシグネチャ（SHA-2 系）を使用し、SHA-1 は使用しない。

  • HTTP → HTTPS のリダイレクト、HSTS（HTTP Strict Transport Security）導入と Preload（慎重に）を検討する。

  • OCSP ステープリング、Certificate Transparency、DNS CAA レコードの設定を行う。

  • 証明書の自動更新（Let’s Encrypt 等）と有効期限管理の監視を必須にする。

  • 安全なセッションのためにクッキー属性（Secure, HttpOnly, SameSite）を設定する。

  • 公開サーバの評価には SSL Labs（Qualys）などのツールで定期的に診断を行う。

TLS 運用上の注意点（ロードバランシング、終了点）

大規模構成ではロードバランサや CDN で TLS 終端（termination）を行うケースが多く、内部ネットワークでの暗号化の有無（再暗号化／エンドツーエンド）や秘密鍵管理、ログ記録との整合性などを設計上考慮する必要があります。また mTLS（相互 TLS）は API 間通信やクライアント認証で有効ですが、運用負荷と鍵管理を伴います。

ユーザー体験とブラウザ表示

ブラウザは TLS の状態により URL バーに鍵アイコンや警告を表示します。不適切な証明書（自己署名、失効、ホスト名不一致、期限切れ等）は警告を引き起こし、ユーザー離脱の原因になります。必ず正しいチェーンと設定で公開することが重要です。

まとめ

「SSL」と呼ばれる技術は進化して TLS に至り、インターネットセキュリティの基盤を支えています。導入は単に証明書を入手してサーバに設定するだけではなく、プロトコルバージョン、暗号スイート、証明書管理、失効処理、運用の自動化と監視などを含めた包括的な取り組みが必要です。最新の TLS 仕様（TLS 1.3）、自動化（ACME/Let’s Encrypt）、および定期的な脆弱性チェックを組み合わせることで、安全で信頼性の高い通信を提供できます。

参考文献

カテゴリー
IT
前の記事
XTCの名盤レコードおすすめガイド｜初心者向け聴く順とコレクター必見の選び方New!!
2025年11月18日
次の記事
ジョン・ハイアット入門：名盤・代表曲と聴きどころを徹底ガイドNew!!
2025年11月18日