HTTPSとTLSの仕組みを徹底解説：ハンドシェイクと証明書

Security2026-10-30TryQuickToolBox

HTTPSが重要な理由（そして誤解されがちな理由）

ブラウザの鍵アイコンを見て、そのサイトが「安全」だと思ったことはありませんか？しかし、それは実際には何を意味するのでしょうか？HTTPSは単なる暗号化ではなく、アイデンティティ、完全性、そして信頼に関わるものです。多くの開発者はTLSをブラックボックスとして扱い、一度設定したら忘れてしまいます。その結果、設定ミス、証明書の期限切れ、脆弱な暗号スイートなどの問題が発生します。

この記事では、HTTPSとTLSが実際にどのように機能するかを、ハンドシェイクから証明書の検証まで分解して説明し、正しい設定方法を紹介します。無駄な話は抜きで、今日から適用できる実践的な知識をお届けします。

TLSハンドシェイク：最初のバイトが送られる前に何が起こるか

クライアント（ブラウザ）がHTTPSでサーバーに接続すると、TLSハンドシェイクが実行されます。これにより安全なチャネルが確立されます。以下は簡略化したバージョン（TLS 1.3）です：

Client Hello： クライアントはサポートする暗号スイート、ランダム値、鍵共有（鍵交換用）を送信します。
Server Hello： サーバーは暗号スイートを選択し、自身のランダム値と鍵共有を送信し、証明書チェーンを提示します。
認証： クライアントは信頼されたCAに対してサーバーの証明書を検証し、ホスト名をチェックします。
鍵導出： 双方がECDHE（楕円曲線ディフィー・ヘルマン一時鍵）を使用して共有秘密を計算します。
Finished： 双方が暗号化された「Finished」メッセージを送信し、ハンドシェイクを確認します。

この後、アプリケーションデータは対称鍵で暗号化されます。TLS 1.3ではラウンドトリップが1回に削減され、レイテンシが改善されます。

鍵交換：ECDHE vs RSA

古いTLSバージョンではRSA鍵交換が使用されていましたが、これには前方秘匿性がありません。サーバーの秘密鍵が漏洩すると、過去のトラフィックが復号化される可能性があります。現代の設定ではECDHEを使用し、前方秘匿性を提供します。各セッションに固有の鍵が生成されます。

# 例：サポートされている鍵交換アルゴリズムを確認
openssl s_client -connect example.com:443 -cipher 'ECDHE'

証明書：信頼のアンカー

証明書は公開鍵をアイデンティティ（ドメイン名）に結び付けます。クライアントが信頼する認証局（CA）によって署名されています。ブラウザには信頼されたルートCAのストアが同梱されています。

サイトにアクセスすると、サーバーはチェーンを送信します：リーフ証明書（あなたのドメイン用）→ 中間CA → ルートCA。クライアントは信頼されたルートに至るまで各署名を検証します。

証明書の種類

ドメイン検証（DV）： ドメインの制御のみを証明します。迅速かつ無料（例：Let's Encrypt）。
組織検証（OV）： 検証済みの組織詳細が含まれます。
拡張検証（EV）： より厳格な審査。ブラウザはもはや緑色のバーを表示しませんが、一部の企業では依然として使用されています。

証明書検証の手順

ブラウザは以下をチェックします：

署名チェーンが信頼されたルートに至る。
証明書が有効期限内である。
ホスト名が一致する（Subject Alternative Names）。
証明書が失効していない（OCSPまたはCRL経由）。

いずれかのチェックが失敗すると警告が表示されます。本番環境ではこれらの警告を決して無視しないでください。

サーバーでのHTTPS設定

モダンなTLS設定を備えた典型的なNginxのHTTPS設定を見てみましょう。

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers off;

    # HSTS（慎重に使用）
    add_header Strict-Transport-Security "max-age=63072000" always;
}

注意点：

TLS 1.2と1.3のみを使用し、古いバージョンは無効にします。
前方秘匿性のためにECDHE暗号を優先します。
パフォーマンスのためにHTTP/2を有効にします。
HSTSはブラウザにHTTPSの使用を強制します。テスト後にのみ有効にしてください。

Let's Encryptでの証明書取得

Let's Encryptは無料のDV証明書を提供します。Certbotを使用して発行と更新を自動化します：

sudo certbot --nginx -d example.com -d www.example.com

CertbotはNginx設定を変更し、更新用のcronジョブを設定します。常に--dry-runで更新をテストしてください。

よくある落とし穴と回避方法

証明書の期限切れ： 監視と自動更新を設定します。
不完全なチェーン： 中間証明書を含めます（fullchain.pem）。
弱い暗号： RC4、DES、エクスポート暗号を無効にします。
混合コンテンツ： すべてのリソース（画像、スクリプト）がHTTPSで読み込まれるようにします。
HSTSなし： HSTSがないと、ユーザーはHTTPにダウングレードされる可能性があります。

HTTPS設定のテスト

SSL Labsなどのオンラインツールやコマンドラインツールを使用して設定を確認します。

# 証明書の詳細を確認
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -text

# TLS 1.3のサポートをテスト
openssl s_client -connect example.com:443 -tls1_3

確認するポイント：

有効な証明書チェーン。
弱いプロトコル（SSLv3、TLS 1.0、TLS 1.1）がないこと。
前方秘匿性が有効であること。
HSTSヘッダーが存在すること。

FAQ

TLSとSSLの違いは何ですか？

SSLはTLSの前身です。TLS 1.0は本質的にSSL 3.1でした。今日、「SSL」は口語的に使われることが多いですが、常にTLS 1.2または1.3を使用すべきです。

HTTPSに有料の証明書は必要ですか？

いいえ。Let's Encryptの無料DV証明書はすべての主要ブラウザで信頼されており、有料のものと同じ暗号化を提供します。有料証明書は保証とサポートを提供しますが、暗号化は同一です。

HTTPSはパフォーマンスにどのように影響しますか？

TLSはハンドシェイクによりレイテンシを追加しますが、TLS 1.3では1ラウンドトリップに削減されます。セッション再開とHTTP/2により、オーバーヘッドは最小限です。暗号化/復号化のコストは現代のCPUでは低いです。

サーバーのTLS設定を検査する準備はできましたか？Nginx Log Analyzerを使用して、異常なトラフィックパターンを特定し、HTTPS設定が期待通りに機能していることを確認してください。