HTTPSとTLSの仕組みを実践的に解説

Security2026-11-10TryQuickToolBox

ブラウザの鍵アイコンを見て「安全」だと知っている方も多いでしょう。しかし、HTTPSのWebサイトを訪れたとき、実際に何が起きているのでしょうか？ブラウザはどうやって本物のサーバーと通信していると判断し、偽物ではないと確信するのでしょうか？また、TLSが時に処理を遅くするのはなぜでしょうか？このガイドでは、HTTPSとTLSを実践的な観点から分解し、Webアプリケーションの設定、デバッグ、セキュリティ保護を自信を持って行えるようにします。

HTTPSの正体

HTTPSは、TLS（Transport Layer Security）の上にHTTPを重ねただけのものです。TLSは次の3つの保証を提供します：

機密性：データは暗号化され、盗聴者に読まれません。
完全性：データは転送中に検知されずに改ざんされることはありません。
認証：サーバーは証明書を使って自身の身元を証明します。

TLSがない場合、HTTPはすべてを平文で送信します。パスワード、Cookie、個人データはネットワーク経路上の誰にでも見えてしまいます。HTTPSはこれを解決します。

平易な言葉で理解するTLSハンドシェイク

暗号化されたデータが流れる前に、クライアントとサーバーは暗号化キーに合意し、身元を確認するためにハンドシェイクを行います。典型的なTLS 1.3ハンドシェイク（現代の標準）で何が起こるかを見てみましょう：

Client Hello：ブラウザがサポートする暗号スイート、TLSバージョン、ランダム値のリストを送信します。
Server Hello：サーバーが暗号スイートを選択し、自身のランダム値を送信し、証明書チェーンを提供します。
鍵交換：双方が鍵交換アルゴリズム（ECDHEなど）を使用して、共有秘密を直接送信することなく導出します。
証明書検証：クライアントはサーバーの証明書を信頼されたルートCAに対してチェックし、ドメイン名を検証し、有効期限を確認します。
Finished：双方がMACを送信してハンドシェイクの完全性を確認し、暗号化されたアプリケーションデータの送信が始まります。

TLS 1.3ではこれが1往復（1-RTT）に短縮され、再訪問者向けに0-RTT再開もサポートされるため、TLS 1.2と比較してレイテンシが大幅に削減されます。

証明書：信頼のアンカー

証明書は公開鍵をドメイン名に結び付け、認証局（CA）によって署名されます。ブラウザやオペレーティングシステムには、信頼されたルートCAのストアが同梱されています。サーバーが証明書を提示すると、クライアントは信頼されたルートまでのチェーンを検証します。

一般的な証明書の種類：

DV（ドメイン検証）：ドメインの制御を証明します。迅速に発行され、多くの場合無料です（例：Let's Encrypt）。
OV（組織検証）：検証された組織の詳細が含まれます。発行に時間がかかります。
EV（拡張検証）：最高レベルの検証。歴史的には緑色のバーが表示されましたが、現代のブラウザではもはや強調されていません。

証明書は有効期限が切れるため、自動化が不可欠です。Certbotやリバースプロキシに統合されたACMEクライアントなどのツールが更新を自動的に処理します。

サーバーでのHTTPS設定

最新のTLS設定でHTTPSを有効にする最小限のNginx設定は次のとおりです：

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';
    ssl_prefer_server_ciphers off;

    # HSTS（テスト後に有効化）
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    location / {
        proxy_pass http://localhost:3000;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

重要なポイント：TLS 1.2と1.3のみを使用し、前方秘匿性のためにECDHE暗号スイートを優先し、HTTPをHTTPSにリダイレクトします。HSTSはブラウザにドメインで常にHTTPSを使用するよう指示しますが、長いmax-ageで有効にする前に慎重にテストしてください。

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

混合コンテンツ：HTTPSページでHTTPリソースを読み込むと鍵アイコンが壊れます。相対URLを使用するか、すべてのアセットがHTTPSであることを確認してください。
期限切れの証明書：更新を自動化し、有効期限を監視します。期限切れの証明書は即座にブラウザ警告を引き起こします。
弱いプロトコル：TLS 1.0と1.1を無効にします。これらは非推奨であり、脆弱です。
不完全な証明書チェーン：サーバーは中間証明書を送信する必要があります。そうでないと一部のクライアントが失敗します。SSL Labsなどのツールでテストしてください。
HSTSプリロードなし：最大限の保護のために、すべてのサブドメインがHTTPSをサポートすることを確認した後、ドメインをHSTSプリロードリストに登録してください。

TLS 1.2 vs TLS 1.3：何が変わったか

機能	TLS 1.2	TLS 1.3
ハンドシェイクの往復	2-RTT	1-RTT（再開時は0-RTT）
鍵交換	RSAまたはECDHE	ECDHEのみ（前方秘匿性が必須）
暗号スイート	多数、弱いものも含む	削減されたセット、すべてAEAD
0-RTTデータ	非サポート	サポート（リプレイリスクあり）

TLS 1.3はより高速でシンプルになり、レガシーアルゴリズムが削除されました。ほとんどの現代のクライアントがサポートしていますが、古いデバイスのためにTLS 1.2を維持してください。

TLS問題のデバッグ

HTTPSが失敗した場合、以下を確認してください：

openssl s_client -connect example.com:443 -servername example.comを使用して、証明書チェーンとハンドシェイクを検査します。
curl -vI https://example.comを実行して、ネゴシエートされたTLSバージョンと暗号を確認します。
サーバーログでハンドシェイクエラーを確認します。NginxはSSLエラーをエラーログに記録します。
オンラインSSLテスターを使用して、包括的な評価と推奨事項を取得します。

Nginxログを定期的に扱う場合、Nginx Log AnalyzerがTLSハンドシェイクの失敗やその他の問題を迅速に発見するのに役立ちます。

FAQ

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

HTTPSはTLS上のHTTPです。TLSは暗号化、完全性、認証を提供する暗号プロトコルです。HTTPSはTLSを使用するHTTPの安全なバージョンです。

内部サービスに証明書は必要ですか？

はい、本番環境の内部サービスには、独自のCAまたはパブリックCAからの証明書を使用してください。自己署名証明書は信頼の問題を引き起こします。プライベートPKIまたは開発用のmkcertなどのツールの使用を検討してください。

証明書はどのくらいの頻度で更新すべきですか？

現代のベストプラクティスは、Let's Encryptが提供するような90日間の証明書と自動更新です。短い有効期間は、鍵が侵害された場合のリスクを軽減します。

サイトを保護する準備はできましたか？まずSSLチェッカーで現在のTLS設定をテストし、上記のNginx設定を適用してください。Webセキュリティについてさらに深く知りたい場合は、OWASP Top 10やXSS防止に関する他のガイドもご覧ください。