Nginx SSL/TLS 設定実践：HTTPS 証明書から A+ セキュリティ強化まで

監視アラートが突然鳴り響いた。スマホを見ると、サイトの証明書が期限切れになっていた——90 日の無料証明書を、すっかり忘れていたのだ。ブラウザの赤い「保護されていない通信」の警告が、まるで嘲笑の旗のように、ブログのトップページに掲げられていた。

あの事故のあと、1 週間かけて Nginx の SSL/TLS 設定を最初から最後まで徹底的に学び直した。SSL Labs の評価 F から A+ へ、手動更新から完全自動化へ、足を引っ張るパフォーマンスからハンドシェイク時間 100ms 以内へ。

HTTPS はブラウザのアドレスバーに小さな鍵マークを付けるだけのものではない。Google は HTTPS が検索順位の要因の一つだと明言しており、HTTPS を正しく設定すると検索流入が 15〜20% 増えることもある。さらに重要なのは、中間者による盗聴を防げることだ。HTTPS を使わないのは、公共の場で銀行カードの暗証番号を大声で話すようなものだ。

この記事では、Nginx の HTTPS をゼロから設定する方法を案内する。Let’s Encrypt 証明書の取得、TLS 1.3 によるセキュリティ強化、SSL Labs A+ 評価の設定テンプレート、そして本番環境に欠かせない自動更新の仕組みまで。すべての設定はそのままコピーして使える。

第 1 章：HTTPS の基礎概念と証明書タイプの選び方

1.1 なぜすべてのサイトに HTTPS が必要なのか

HTTP は平文で通信する。つまり、あなたが訪れるすべてのページ、送信するすべてのフォームが、ネットワーク上を裸のまま流れているということだ。カフェの公共 Wi-Fi、会社のネットワーク出口、団地のプロバイダー機器——どこか一つの中間ノードでも、あなたが何を送ったかを見ることができる。

HTTPS は HTTP と TCP の間に TLS 暗号化の層を一つ追加する。データは送信前に暗号化され、到達後に復号される。途中の盗聴者に見えるのは、ただの文字化けの羅列だけだ。

TLS の役割は暗号化だけにとどまらない。身元の検証も提供する——あなたがアクセスしているのが本物の example.com であり、DNS ハイジャックされたフィッシングサイトではないことを保証する。これこそが、ブラウザが期限切れの証明書やドメインが一致しない証明書に対して赤い警告を表示する理由だ。ブラウザは「このサイトは名乗っている相手ではないかもしれない」と伝えているのだ。

1.2 SSL 証明書の 3 大タイプ：DV、OV、EV

証明書は検証の厳格さに応じて 3 種類に分けられる：

正直なところ、ほとんどの個人プロジェクトや小規模チームには DV 証明書で十分だ。Let’s Encrypt が提供する無料 DV 証明書は有効期限 90 日で、ブラウザの信頼度は有料 DV 証明書と変わらない。唯一の「欠点」は 90 日ごとに更新が必要なことだが——自動更新を設定してしまえば、これはまったく問題にならない。

OV と EV 証明書の違いは、主にブラウザのアドレスバーでの表示にある。EV 証明書は会社名（たとえば「中国工商銀行」など）を表示するが、最近のブラウザは EV 証明書の視覚的な強調をどんどん弱めており、Chrome はデフォルトで EV 証明書の会社名を表示しなくなった。さらに OV/EV 証明書は数百〜数千元と高価で、コストパフォーマンスは決して良くない。

1.3 Let’s Encrypt：無料証明書の最良の選択肢

Let’s Encrypt は ISRG（Internet Security Research Group）が運営する非営利の認証局だ。いくつかの核心的な利点がある：

• 完全無料：DV 証明書は永久に無料
• 自動化：ACME プロトコルにより自動で発行・更新
• 広く信頼されている：主要なブラウザと OS のすべてが信頼している
• 有効期限 90 日：短期証明書はより安全で、自動化の設定を促してくれる

欠点もある。DV 証明書しかなく、OV/EV は提供されない。ワイルドカード証明書には DNS 検証が必要（少し面倒）だ。ただし 99% の個人プロジェクトや中小規模サイトにとって、これらの「欠点」はまったく問題にならない。

次は、Let’s Encrypt の公式クライアントである Certbot を使って証明書を取得しよう。

第 2 章：Let’s Encrypt 証明書の取得実践

2.1 Certbot のインストール

Certbot のインストール方法は OS によって異なる。Ubuntu ユーザーが最も簡単だ：

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

# Ubuntu 20.04+ / Debian 10+
sudo apt update
sudo apt install certbot python3-certbot-nginx

CentOS/RHEL ユーザーはまず EPEL リポジトリを有効にする必要がある：

# CentOS 8 / RHEL 8
sudo dnf install epel-release
sudo dnf install certbot python3-certbot-nginx

インストールが完了したら、certbot --version でバージョンを確認できる。問題なければ、次は証明書の取得だ。

2.2 証明書の取得

Certbot は複数の検証方式に対応しているが、最もよく使われるのは standalone（独立検証）と webroot（サイトルートディレクトリ検証）だ。Nginx がすでに稼働しているなら、webroot モードを推奨する：

# webroot モード：サイトが稼働中のときに使う
sudo certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com

-w でサイトのルートディレクトリ、-d でドメインを指定する。一度に複数ドメインの証明書を取得できる。

Nginx がまだ起動していない場合や、テスト用に一時的なサーバーを立てるだけなら、standalone モードを使う：

# standalone モード：一時的に 80 番ポートを占有する必要がある
sudo certbot certonly --standalone -d example.com -d www.example.com

このモードでは Certbot が一時的に HTTP サーバーを起動し、検証完了後に自動で停止する。検証には 80 番ポートが空いている必要があるため、Nginx がすでに稼働している場合は先に停止する必要がある。

もっと簡単な方法もある——Certbot の Nginx プラグインが自動で Nginx 設定を変更してくれる：

# 自動設定モード：Certbot が Nginx 設定を自動で変更
sudo certbot --nginx -d example.com -d www.example.com

このコマンドは証明書の取得、Nginx 設定の変更、HTTPS リダイレクトの設定を自動で行う。初心者がすぐに始めるのに適しているが、本番環境では SSL パラメータをより細かく制御するために手動設定を推奨する。

2.3 証明書ファイルの構成

取得に成功すると、証明書ファイルはデフォルトで /etc/letsencrypt/live/example.com/ ディレクトリに保存される：

/etc/letsencrypt/live/example.com/
├── cert.pem        # ドメイン証明書
├── chain.pem       # 中間証明書チェーン
├── fullchain.pem   # 完全な証明書チェーン（cert + chain）
└── privkey.pem     # 秘密鍵ファイル

Nginx の設定で使うのは 2 つのファイルだ：fullchain.pem（ssl_certificate）と privkey.pem（ssl_certificate_key）。privkey.pem は機密ファイルで、権限は 600 にすべきであり、決して漏らしてはいけない。

第 3 章：Nginx SSL の基本設定

3.1 最も基本的な HTTPS 設定

証明書が手に入ったら、次は Nginx で HTTPS を設定する。最もシンプルな設定はこうなる：

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

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

    # その他の設定...
    root /var/www/example.com;
    index index.html;
}

この設定で HTTPS は動くが、評価は D 止まりだ。問題は、TLS バージョンを指定していないため、デフォルトで TLS 1.0 と 1.1 をサポートしてしまう点にある——この 2 つのバージョンはとっくに安全でないと判定されている。

3.2 HTTP から HTTPS へのリダイレクト

HTTPS を設定するだけでは不十分だ。ユーザーが直接 HTTP 版にアクセスする可能性がある。すべての HTTP リクエストを HTTPS にリダイレクトする必要がある：

server {
    listen 80;
    server_name example.com www.example.com;

    # HTTPS へ恒久的にリダイレクト
    return 301 https://$server_name$request_uri;
}

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

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

    # その他の設定...
}

return 301 は恒久的リダイレクトで、ブラウザはこのリダイレクトをキャッシュする。次にユーザーが http:// を入力すると、ブラウザは直接 https:// にジャンプし、1 回のリクエストを節約できる。

3.3 よくある設定ミス

listen 443 ssl; の後ろに http2 を付けて listen 443 ssl http2; と書く人をよく見かける。Nginx 1.25.1 以降、HTTP/2 のサポートは http2 ディレクティブに移された：

# Nginx 1.25.1 以降の新しい書き方
server {
    listen 443 ssl;
    http2 on;  # 独立した http2 ディレクティブ
    server_name example.com;

    # ...
}

Nginx のバージョンが新しいなら、新しい書き方を使って設定の警告を避けることを推奨する。バージョンは nginx -v で確認できる。

第 4 章：TLS 1.3 セキュリティ強化設定

4.1 TLS バージョンの選択

TLS には 4 つのバージョンがある：1.0、1.1、1.2、1.3。このうち 1.0 と 1.1 はすでに廃止され、主要なブラウザはすべて 2020 年にサポートを終了した。

TLS 1.3 の核心的な利点はパフォーマンスにある。ハンドシェイクが 2-RTT（往復）から 1-RTT へ減り、理論上ハンドシェイク遅延を半分にできる。実測でも、TLS 1.3 のハンドシェイク時間は 100ms 以内に抑えられる。

Nginx の設定では ssl_protocols ディレクティブで TLS バージョンを指定する：

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

ssl_protocols TLSv1.2 TLSv1.3;

TLS 1.3 だけを有効にするのは推奨しない。2026 年にはほぼすべてのブラウザが TLS 1.3 をサポートしているが、一部の古い HTTP クライアント（特定の API 呼び出しツールや組み込み機器など）はまだ対応していない可能性がある。TLS 1.2 を互換用の選択肢として残すのが、より無難な選択だ。

4.2 Cipher Suite の設定

Cipher Suite（暗号スイート）は、暗号アルゴリズム、鍵交換方式、メッセージ認証コードを決定する。選択を誤ると、HTTPS が有名無実になりかねない。

2026 年に推奨される TLS 1.3 の cipher suite リスト：

ssl_protocols TLSv1.2 TLSv1.3;

# TLS 1.3 の cipher（Nginx は自動で OpenSSL のデフォルトリストを使用）
# この行は省略可能だが、残しておいても問題ない
ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

# TLS 1.2 の cipher（後方互換）
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

# サーバーが指定した cipher を優先
ssl_prefer_server_ciphers on;

この設定のポイント：

• ECDHE：楕円曲線鍵交換を優先。RSA より安全で高速
• AES-GCM：GCM モードは認証付き暗号を提供し、CBC モードより安全
• CHACHA20-POLY1305：モバイルでのパフォーマンスが良く、AES ハードウェアアクセラレーションのない機器に適する

迷ったときは、Mozilla SSL Configuration Generator で設定を生成できる：https://ssl-config.mozilla.org/

4.3 HSTS：HTTPS アクセスの強制

HSTS（HTTP Strict Transport Security）は、ブラウザに「このサイトは HTTPS アクセスしか受け付けない」と伝える。ユーザーが手動で http:// を入力しても、ブラウザはローカルで強制的に https:// にジャンプし、1 回のネットワークリクエストを節約できる。

# HSTS ヘッダー
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

パラメータの説明：

• max-age=31536000：有効期限 1 年（単位は秒）
• includeSubDomains：すべてのサブドメインを含む
• preload：HSTS Preload List に追加（hstspreload.org への申請が必要）

注意：HSTS は一度有効にすると、ブラウザが長時間キャッシュする。HTTP 版のテストがまだ必要なら、preload を付けないか、max-age を短めに設定しておこう。

第 5 章：SSL パフォーマンス最適化のテクニック

5.1 SSL Session Cache

TLS ハンドシェイクのたびに鍵交換と証明書検証が必要で、コストは小さくない。Session Cache は、クライアントが一定時間内に以前のセッションを再利用できるようにし、完全なハンドシェイクの流れを省略する。

# Session Cache 設定
ssl_session_cache shared:SSL:10m;  # 10MB のキャッシュ、約 40000 セッション
ssl_session_timeout 1d;            # セッション有効期限 1 日
ssl_session_tickets off;           # Session Ticket を無効化（より安全）

shared:SSL:10m は、すべての worker プロセスが 10MB のキャッシュ領域を共有することを意味する。1MB でおよそ 4000 セッションを保存でき、10MB あれば中小規模サイトには十分だ。

ssl_session_tickets off はセキュリティ上の配慮だ。Session Ticket の仕組みでは、サーバー側が Ticket を暗号化する鍵を保持する必要があり、この鍵が漏れると攻撃者は過去のすべてのセッションを復号できてしまう。無効にするとより安全だが、サーバーの負担が増える——セキュリティ要件の高い場面に適している。

5.2 OCSP Stapling

ブラウザは証明書を検証する際、証明書が失効していないかをチェックする必要がある。従来の方法は CA に OCSP クエリを送ることで、これはネットワークリクエストを 1 回増やし、ユーザーがどのサイトにアクセスしたかを露呈してしまう。

OCSP Stapling は、サーバーがブラウザに代わって OCSP の状態を問い合わせ、結果をキャッシュして、一括でブラウザに渡す。プライバシーを守りつつ、遅延も削減できる。

# OCSP Stapling 設定
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

resolver は、OCSP サーバーのドメインを解決するための DNS サーバーを指定する。Google の 8.8.8.8 と 8.8.4.4 はよく使われる選択肢だ。

設定が完了したら、OpenSSL でテストできる：

openssl s_client -connect example.com:443 -status < /dev/null 2>&1 | grep -A 17 "OCSP response"

“OCSP Response Status: successful” と表示されれば、OCSP Stapling が正しく動作していることを示す。

5.3 ssl_buffer_size のチューニング

ssl_buffer_size は TLS レコードのサイズを制御する。デフォルトは 16KB で、小さなレスポンス（API リクエストなど）には大きすぎ、TTFB（最初のバイトまでの時間）を増やしてしまう。

小さなレスポンスが中心の API サーバーやブログサイトでは、この値を小さくできる：

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

ssl_buffer_size 4k;  # 小さなレスポンスの場面に適する

大きなファイルのダウンロードサーバーには、デフォルトの 16KB を維持するか、32KB に上げる方が適している。

第 6 章：証明書の自動更新設定

6.1 Certbot の自動更新コマンド

Let’s Encrypt 証明書の有効期限はわずか 90 日なので、定期的に更新しなければならない。Certbot は renew コマンドを提供している：

# 更新テスト（実際には更新せず、チェックのみ）
sudo certbot renew --dry-run

# 実際の更新
sudo certbot renew

renew コマンドはすべての証明書の有効期限をチェックし、残り有効期限が 30 日未満の証明書だけを更新する。つまり、このコマンドを毎日実行しても安心だ——Let’s Encrypt のレート制限の割り当てを無駄にすることはない。

6.2 crontab で定期タスクを設定する

最も確実な方法は、crontab で自動更新を設定することだ：

# root ユーザーの crontab を編集
sudo crontab -e

以下の 2 行を追加する：

# 毎日 深夜 3:00 と 午後 3:00 にそれぞれ 1 回チェック
0 3 * * * /usr/bin/certbot renew --quiet --post-hook "systemctl reload nginx"
0 15 * * * /usr/bin/certbot renew --quiet --post-hook "systemctl reload nginx"

--quiet はサイレントモードで、ログを出力しない。--post-hook "systemctl reload nginx" は更新成功後に Nginx 設定をリロードし、新しい証明書を有効にする。

なぜ 1 日に 2 回チェックするのか？更新失敗が時々起こりうる（DNS の一時的な解決失敗など）ためで、複数回チェックすることで成功率を高められる。

6.3 更新テストとトラブルシューティング

更新に失敗すると、Certbot は /var/log/letsencrypt/letsencrypt.log に詳細なログを記録する。よくある問題：

1. ポートの占有：standalone モードは 80 番ポートが必要。Nginx が占有していないか確認する
2. DNS 解決の失敗：ドメインの DNS レコードが正しくサーバーを指しているか確認する
3. レート制限：Let’s Encrypt は同一証明書を週に最大 5 回まで取得可能。テスト時は --dry-run を使う
4. 証明書ディレクトリの権限：Certbot が /etc/letsencrypt/ を読み書きする権限を持っているか確認する

更新テストの完全な流れ：

# 1. まず dry-run でテスト
sudo certbot renew --dry-run

# 2. dry-run が成功したら、実際に更新
sudo certbot renew

# 3. 証明書の有効期限を確認
sudo certbot certificates

# 4. Nginx をリロード
sudo systemctl reload nginx

完全な設定テンプレート

以下は本番環境で使える Nginx SSL 設定テンプレートで、すでに SSL Labs A+ 評価に達している：

# HTTP リダイレクト
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

# HTTPS サービス
server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;

    # 証明書設定
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # TLS バージョン
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cipher Suite
    ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers on;

    # セキュリティヘッダー
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Frame-Options SAMEORIGIN always;
    add_header X-Content-Type-Options nosniff always;
    add_header X-XSS-Protection "1; mode=block" always;

    # Session Cache
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # パフォーマンスチューニング
    ssl_buffer_size 4k;

    # サイト設定
    root /var/www/example.com;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }
}

設定が完了したら、SSL Labs で評価をテストしよう：https://www.ssllabs.com/ssltest/

まとめ

HTTPS を設定すること自体は、入門は難しくない——数行の設定で動かせる。しかし SSL Labs A+ 評価に達し、同時にパフォーマンスと互換性も両立させるには、TLS バージョン、Cipher Suite、Session Cache、OCSP Stapling といった細部を理解する必要がある。

核心となる設定ポイントのおさらい：

1. 証明書の取得：Let’s Encrypt は無料で使いやすく、Certbot で自動化すれば手間いらず
2. TLS バージョン：TLS 1.2 + 1.3 を使い、1.0 と 1.1 は無効化
3. Cipher Suite：ECDHE と AES-GCM を優先し、CHACHA20 も両立
4. HSTS：HTTPS を強制し、リダイレクトのコストを削減
5. パフォーマンス最適化：Session Cache と OCSP Stapling はどちらも欠かせない
6. 自動更新：crontab で二重の保険、更新後に Nginx を自動リロード

上の設定テンプレートを自分の Nginx 設定にコピーし、ドメインと証明書のパスを書き換えれば、そのまま使える。設定が終わったら SSL Labs の評価をテストするのを忘れずに。結果はコメント欄で教えてほしい——おそらく高確率で A+ だろう。