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

深夜3時、監視アラートが突然鳴り響きました。スマホを確認すると、サイトのSSL証明書が期限切れになっていました。無料証明書の90日間、すっかり忘れていたのです。ブラウザに表示される赤い「安全ではありません」の警告は、まるでブログのトップページに掲げられた嘲笑の旗のようでした。

その事故の後、私は丸1週間かけて Nginx SSL/TLS 設定を一から見直しました。SSL Labs の評価が F から A+ に。手動更新から完全自動化へ。パフォーマンスを犠牲にしていた状態から、ハンドシェイク時間を100ms以内まで短縮。この道のりで経験したすべての落とし穴を、今日は完全に共有したいと思います。

HTTPS は単にブラウザのアドレスバーに鍵アイコンを表示するだけではありません。Google は HTTPS を検索ランキングの要因の一つとして明言しており、実際、HTTPS を正しく設定すると検索トラフィックが 15-20% 増加するというデータがあります。さらに重要なのは、中間者攻撃による盗聴を防げることです。百度智能云のデータによると、HTTPS によりデータ漏洩リスクを83%削減できます。簡単に言えば、HTTPS を導入しないことは、公共の場所で銀行の暗証番号を大声で話しているようなものです。

この記事では、Nginx HTTPS の設定をゼロから解説します。Let’s Encrypt 証明書の取得、TLS 1.3 セキュリティ強化、SSL Labs A+ 評価設定テンプレート、そして本番環境で必須の自動更新設定まで。すべての設定はそのままコピーして使用できます。

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

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

HTTP は平文通信なので、アクセスするすべてのページ、送信するすべてのフォームがネットワーク上で裸で流れています。カフェの公共 WiFi、会社のネットワーク出口、地域の ISP 機器。どの中間ノードも、あなたが何を送信したかを見ることができます。

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 ユーザーなら最も簡単です：

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

15%割引を入手 →広告

# 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 は動作しますが、SSL Labs では 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 バージョンを指定します：

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

今すぐ始める →広告

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 は、すべてのワーカープロセスが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 で DNS サーバーを指定し、OCSP サーバーのドメイン名を解決します。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 サーバーやブログサイトでは、この値を小さくできます：

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

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+ になるはずです。

8 min read · 公開日: 2026年4月20日 · 更新日: 2026年4月20日

Easton

技術開発