3-3. HTTPS - Let’s Encrypt で証明書を取り、nginx に組み込む

所要時間: 40-60分 ゴール: 自分のドメインで https://example.com がブラウザの緑鍵で表示される コミット内容: ~/learn/infra/https/ に nginx 設定と certbot 実行ログ、リダイレクト動作確認結果

このレッスンのゴール

TLS で守られる3つの要素（機密性・完全性・認証）を語れる
Let’s Encrypt + certbot で証明書を取得・更新できる
HTTPS リダイレクトと HSTS で「全部 HTTPS」運用ができる
HTTP-01 認証と DNS-01 認証の使い分けを判断できる
強い暗号スイート設定で SSL Labs A以上を目指せる

なぜ学ぶか（実務悩みベース）

HTTPS 無しは事実上「サイトとして死亡」なので最低ライン
自動更新を仕込まないと90日ごとに切れて事故になる
「証明書失効」障害は半年に1回は遭遇する
API 連携（Stripe など）が HTTPS 必須

前章とのつながり

3-2 でドメインを向けた直後、http://example.com でアクセス可能になった。次の壁が HTTPS 化。証明書発行には DNS 設定が前提なので、3-2 と 3-3 はセット。

大前提: HTTPS は「あったらいい」ではなく「ないと終わり」

2026 年現在、HTTPS なしのサイトは:

Chrome / Safari / Firefox で 「保護されていない通信」と大きく警告される
フォーム入力は警告強化、銀行情報など問題外
Google 検索ランキングで HTTPS サイトより不利
Service Worker / HTTP/2 / Brotli / 一部の Web API（geolocation, microphone, push 通知）が HTTPS 必須
PWA、メール送信元の DKIM 連動、OAuth リダイレクトなどがすべて TLS 前提
一部の決済プロバイダ・API（Stripe, PayPal）は HTTPS なしでは連携を許さない

つまり HTTPS = サイト運用の最低ライン。Let’s Encrypt のおかげで「無料」「自動更新」「数分」で完了するようになった現代では、HTTPS にしないという選択肢は事実上ない。

このレッスンでは Let’s Encrypt + certbot + nginx で本番運用に耐える HTTPS 構成を組む。HSTS、HTTPS リダイレクト、強い暗号スイートなど、「証明書取って終わり」ではない運用面まで踏み込む。

セッション①: TLS 証明書と Let’s Encrypt（20-25分）

1. TLS / SSL の基本

HTTPS = HTTP + TLS（Transport Layer Security）。

[ブラウザ] ←(TLS で暗号化された TCP コネクション)→ [サーバー]
              ↓
       中の HTTP リクエスト・レスポンスは暗号化されている
       第三者からは「どこのサーバーと話しているか」しか見えない

TLS で守られる 3 つのこと

機密性 (Confidentiality): 通信内容を第三者が読めない（暗号化）

完全性 (Integrity): 通信途中で改竄されていないことを検証できる

真正性 (Authentication): 通信相手が「自称している人」であることを証明書で確認できる

SSL は TLS の前身。今でも口語的に「SSL 証明書」と呼ばれるが、技術的には全て TLS（SSL 3.0 は 2014 年に POODLE 攻撃で廃止された）。

2. 証明書の種類（DV / OV / EV）

種類	フルネーム	検証内容	主な用途
DV	Domain Validation	ドメインの所有権	個人サイト、SaaS、API、ほぼ全用途
OV	Organization Validation	組織の実在性	企業の正式サイト
EV	Extended Validation	組織の厳格審査	銀行、決済（昔は緑バーが出た）

現代は DV で十分な理由

かつて EV 証明書はブラウザのアドレスバーに緑色で会社名を表示し、視覚的な信頼性アピールに使われた。

2019 年頃から主要ブラウザが EV の特別表示をやめた（Chrome 77 で削除）。理由は「ユーザーが緑バーを見て信頼するという研究結果が出なかった」「フィッシングサイトでも EV を取る攻撃者がいた」など。

結果、現代では DV と EV で見た目の差がほぼゼロ。Let’s Encrypt の無料 DV で十分。

Let's Encrypt の革命

2015 年に登場した非営利の CA。それまで証明書は年 1-5 万円が相場だった世界に、無料・自動取得・自動更新 をもたらした。

2026 年現在、世界のウェブサイトの半数以上が Let’s Encrypt 証明書を使用していると言われる。HTTPS の民主化を達成した最重要インフラ。

仕組み: ACME プロトコル（RFC 8555）で「あなたがこのドメインを所有していることを証明してください」というチャレンジを CA がクライアントに送り、回答できれば証明書を発行する。

3. certbot のインストール

# Ubuntu 24.04 で snap 経由（公式推奨）
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
 
# apt 版もある（少し古い場合あり）
sudo apt install -y certbot python3-certbot-nginx

certbot は Let's Encrypt クライアントの実装の 1 つ

ACME プロトコルは標準なので、クライアントは複数ある:

certbot: 公式、Python 製、最も普及

acme.sh: シェルスクリプト、軽量、依存最少

caddy: Web サーバー Caddy に内蔵、設定不要

学習用途では certbot で十分。本番では acme.sh の方が「Web サーバーを止めない」運用ができて好まれることも。

4. nginx を準備する

すでに VPS に nginx が入っていない前提で:

sudo apt install -y nginx
sudo systemctl enable --now nginx
 
# 動作確認
curl http://localhost
# → nginx の welcome ページ HTML が返る
 
# 外からも見える
curl http://example.com

/etc/nginx/sites-available/example.com を作る:

# /etc/nginx/sites-available/example.com
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
 
    root /var/www/example.com;
    index index.html;
 
    location / {
        try_files $uri $uri/ =404;
    }
}

# 雛形 HTML
sudo mkdir -p /var/www/example.com
echo '<h1>Hello from example.com</h1>' | sudo tee /var/www/example.com/index.html
 
# 設定有効化
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t          # 構文チェック
sudo systemctl reload nginx

nginx -t を打つ習慣

nginx 設定変更 → nginx -t で必ず構文チェック → 問題なければ systemctl reload nginx。

reload は graceful（既存接続は維持しつつ新設定で受付）。restart は強制再起動なので本番では避ける。

構文チェックなしで reload する事故: 設定にタイポがあると nginx が再起動失敗、サイトがダウンする。nginx -t を癖に。

5. certbot で証明書を取得（nginx プラグイン）

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

実行すると対話的に:

連絡用メールアドレス
利用規約への同意
HSTS など追加設定の選択
HTTP → HTTPS リダイレクトを設定するか

を聞かれる。

certbot --nginx は何をしているか

このコマンド 1 発で:

HTTP-01 チャレンジ: Let’s Encrypt が http://example.com/.well-known/acme-challenge/<token> にアクセスし、certbot が用意したファイルが見えれば「このドメインの管理者だ」と判定

証明書発行: /etc/letsencrypt/live/example.com/ に証明書・秘密鍵が配置される

fullchain.pem: サーバー証明書 + 中間証明書のチェーン

privkey.pem: 秘密鍵（読み取り権限注意）

nginx 設定の自動書き換え: listen 443 ssl; ブロックを追加、ssl_certificate パスを設定

HTTP → HTTPS リダイレクトを追加（選択した場合）

systemd timer 設置: 12 時間ごとに更新チェックする certbot.timer が自動有効化

6. 取得後の nginx 設定

certbot 実行後、/etc/nginx/sites-enabled/example.com はこうなっている:

server {
    server_name example.com www.example.com;
 
    root /var/www/example.com;
    index index.html;
 
    location / {
        try_files $uri $uri/ =404;
    }
 
    listen [::]:443 ssl ipv6only=on;
    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}
 
server {
    if ($host = www.example.com) {
        return 301 https://$host$request_uri;
    }
    if ($host = example.com) {
        return 301 https://$host$request_uri;
    }
 
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 404;
}

certbot が生成する if 文の評価
nginx 公式では if の使用を非推奨としているが、certbot は生成するのでそのまま動かしてよい。

自分で書き直すなら:
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}
こちらの方がシンプル。

7. ブラウザで確認

# CLI で確認
curl -I https://example.com
# HTTP/2 200
# server: nginx/1.24.0 (Ubuntu)
# date: ...
# content-type: text/html

ブラウザで https://example.com を開き、鍵マークが緑（または閉じた鍵）であることを確認。

セッション②: 自動更新と HSTS（15-20分）

8. 自動更新の確認

# 自動更新のタイマー確認
systemctl list-timers | grep certbot
# certbot.timer が 1日 2回起動するはず
 
# ドライラン（実際の更新はせず、更新できるか試す）
sudo certbot renew --dry-run

Let's Encrypt 証明書の有効期間

90 日間。意図的に短い。理由:

侵害時の影響範囲を狭める: 万一秘密鍵が漏れても、最長 90 日で無効化される

自動更新を強制する: 「90 日ごとに手動更新は無理」 → 自動化が必須 → エコシステム全体が自動化される

失効処理 (CRL/OCSP) の問題を緩和: 古い証明書を強制的に新しいものに置換することで、失効リストの肥大化を防ぐ

certbot は 証明書が残り 30 日を切ると更新する。systemd timer が 12 時間ごとに certbot renew を実行するため、残り 30 日になった次の起動で更新される。

systemd timer と cron の違い
cron: 古典的。/etc/cron.d/ や crontab で書く。シンプル

systemd timer: systemd 統合。ログが journal に残る、サービスのライフサイクルと結合できる、OnCalendar で柔軟な時刻指定

現代の Ubuntu/Debian では systemd timer が主流。certbot もこちら。
# certbot の timer 定義
systemctl cat certbot.timer

9. HSTS の導入

# /etc/nginx/sites-available/example.com の SSL ブロックに追加
server {
    listen 443 ssl;
    server_name example.com www.example.com;
 
    # HSTS - HTTPS Strict Transport Security
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
 
    # ...
}

sudo nginx -t
sudo systemctl reload nginx
 
# 確認
curl -I https://example.com | grep -i strict
# strict-transport-security: max-age=63072000; includeSubDomains

HSTS とは何か
HSTS (HTTP Strict Transport Security) = サーバーがブラウザに「今後 N 秒間は、このドメインに必ず HTTPS でアクセスせよ」と命令するヘッダ。
Strict-Transport-Security: max-age=63072000; includeSubDomains
max-age=63072000 = 2 年間

includeSubDomains = サブドメイン全てに適用

初回アクセス以降、ブラウザは HTTP リクエストを送る前に 自動で HTTPS に書き換える。中間者攻撃（HTTPS リダイレクトに割り込んで HTTP へダウングレード）を防ぐ。

HSTS の覚悟

一度 HSTS を有効にしてブラウザにキャッシュされると、max-age 期間中は HTTP でアクセスする手段がなくなる。

実害が出るケース:

HTTPS 証明書が更新失敗して期限切れ → ユーザーが回避できない（“安全でないと知った上で続行” が押せない）

サブドメインに対応していない古いシステムがあったのに includeSubDomains を付けた

段階的導入:

max-age=300 (5分) で試す

1 日 OK だったら max-age=86400 (1 日)

1 週間 OK だったら max-age=31536000 (1 年)

完全に確信したら max-age=63072000; includeSubDomains; preload

preload は Chrome/Firefox に「HSTS をハードコード」してもらう申請。一度載ると 2 年以上削除されない。本気度の高いサイト向け。

10. HTTP → HTTPS リダイレクト確認

curl -I http://example.com
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/

301 vs 302 vs 308

リダイレクトのステータスコード:

コード意味キャッシュ
301 恒久的に移動される（ブラウザが覚える）
302 一時的に移動されない
307 一時的（メソッド維持）されない
308 恒久的（メソッド維持）される

HTTPS リダイレクトは 恒久的なので 301（certbot もデフォルト 301）。Stripe 等の決済 API もこの慣習に合わせている。

コード	意味	キャッシュ
301	恒久的に移動	される（ブラウザが覚える）
302	一時的に移動	されない
307	一時的（メソッド維持）	されない
308	恒久的（メソッド維持）	される

セッション③: 強い暗号設定と運用知識（20-25分）

11. SSL Labs テスト

ブラウザで ssllabs.com/ssltest にアクセスし、ドメインを入力。

SSL Labs の評価基準

A+ / A / B / C / F の評価が出る。チェック項目:

TLS バージョン（1.0/1.1 が許可されていないか → 弱い）

暗号スイートの強度（RC4, DES などの古い暗号が無効か）

証明書チェーンの完全性

HSTS の設定有無

Forward Secrecy の有無

目指すべきは A+ または A。certbot が用意する /etc/letsencrypt/options-ssl-nginx.conf は Mozilla の “Intermediate” 互換で、デフォルトで A 評価。

12. TLS バージョン制限

# /etc/letsencrypt/options-ssl-nginx.conf （certbot 生成、編集してもよいが上書きされ得る）
# または自分の server ブロックに直接書く
 
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
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:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";

TLS バージョンの選択

TLS 1.0 / 1.1: 2020 年以降 IETF が非推奨。ブロックする

TLS 1.2: 現役。広く対応

TLS 1.3: 2018 年標準化。速い・安全。現代の必須

TLS 1.2 + 1.3 を有効化で OK。1.0/1.1 を残すと SSL Labs で減点。

暗号スイートの方針

Mozilla SSL Configuration Generator (ssl-config.mozilla.org) で nginx 向け設定を生成するのが楽。3 モードある:

Modern: TLS 1.3 のみ、最強だが古いブラウザは切り捨て

Intermediate: TLS 1.2/1.3、現代の標準。通常はこれ

Old: IE 6 まで対応、レガシー互換用

一般的なサービスなら Intermediate で問題なし。

13. 中間証明書チェーンとは

# 証明書チェーンを確認
openssl s_client -connect example.com:443 -showcerts < /dev/null
 
# Let's Encrypt の場合のチェーン:
# 1. リーフ証明書 (example.com の)
# 2. 中間証明書 (R10 - ISRG により署名)
# 3. ルート証明書 (ISRG Root X1 - ブラウザに内蔵)

中間証明書がないと壊れる
証明書には信頼の連鎖がある:
[ルート CA (ブラウザに内蔵されている)]
    ↓ 署名
[中間 CA (Let's Encrypt R10 など)]
    ↓ 署名
[リーフ証明書 (example.com)]
サーバーは「リーフ + 中間」を返さなければならない。ルートはブラウザが持っているので不要。

Let’s Encrypt の fullchain.pem は リーフ + 中間 が連結されたファイル。cert.pem はリーフのみなので、これを使うとチェーンが切れて Android 等で「証明書が信頼できない」エラー。

必ず fullchain.pem を ssl_certificate に指定。

Apple/Android の古い端末で見える問題

古い Android（7 以前）には DST Root CA X3 しか入っていない端末がある。Let’s Encrypt は 2021 年に主ルートを ISRG Root X1 に切替え、古い端末では証明書エラーになる事案があった。

現在は ISRG Root X1 がほぼ全端末に普及しているが、超レガシー対応が必要な事業（地方自治体、組み込み機器）では事前に SSL Labs の “Handshake Simulation” で対象機種を確認。

14. ワイルドカード証明書と DNS-01 チャレンジ

# *.example.com の証明書を取得（HTTP-01 ではなく DNS-01 が必要）
sudo certbot certonly --manual --preferred-challenges dns \
    -d "*.example.com" -d "example.com"

HTTP-01 と DNS-01 の違い

Let’s Encrypt がドメイン所有を検証する 2 つの方式:

HTTP-01: http://example.com/.well-known/acme-challenge/<token> にトークン置けば OK。最も簡単。ただし ワイルドカード *.example.com には使えない

DNS-01: _acme-challenge.example.com TXT "<token>" を DNS に置けば OK。ワイルドカードに対応、サーバー側に何も準備不要

ワイルドカード証明書（*.example.com で全サブドメインに対応）は DNS-01 必須。

DNS-01 を自動化するには、DNS プロバイダの API を certbot から叩く必要がある:

Cloudflare: certbot-dns-cloudflare プラグイン

Route 53: certbot-dns-route53

その他多数

Cloudflare DNS-01 で自動更新

# プラグインインストール
sudo apt install -y python3-certbot-dns-cloudflare
 
# API トークン（Edit zone DNS 権限）を作って保存
sudo mkdir -p /root/.secrets
echo "dns_cloudflare_api_token = your_token_here" | \
    sudo tee /root/.secrets/cloudflare.ini
sudo chmod 600 /root/.secrets/cloudflare.ini
 
# ワイルドカード取得
sudo certbot certonly \
    --dns-cloudflare \
    --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
    -d "*.example.com" -d "example.com"

これで完全自動更新。

アンチパターン総まとめ

ステージング環境で本番証明書を取って rate limit
# ステージング、本番、開発 3 つのドメインで certbot を叩く
# 試行錯誤で何度も実行
# → Let's Encrypt の rate limit (週 50 件/registered domain) に到達
対策: テスト中は --staging フラグでステージング CA を使う。証明書はブラウザに信頼されないが、本番 rate limit は消費しない。
sudo certbot --nginx --staging -d example.com

自動更新を確認せず放置

90 日後に証明書失効 → サイトダウン → 慌てて手動更新。

対策: 初回取得後すぐ certbot renew --dry-run を実行して動作確認。/var/log/letsencrypt/letsencrypt.log を時々眺める。CloudWatch / Datadog 等で証明書の有効期限を監視。

cert.pem だけ指定してチェーン切れ
ssl_certificate /etc/letsencrypt/live/example.com/cert.pem;    # NG（中間が含まれない）
一部の古いクライアントで「信頼できない」エラー。必ず fullchain.pem。

秘密鍵を git にコミット
git add /etc/letsencrypt/live/example.com/privkey.pem    # 絶対 NG
秘密鍵が GitHub 公開リポに入った瞬間、その証明書は 侵害扱い。Let’s Encrypt は失効処理。サイトはダウン。

対策: .gitignore に *.pem *.key privkey* を入れておく。secret scanning（GitHub Advanced Security 等）を有効に。

TLS 1.0/1.1 を有効のまま放置

PCI DSS（クレジットカード業界基準）違反、SSL Labs で減点。TLS 1.2 + 1.3 のみ。

HSTS preload を勢いで有効化してドメイン全体を縛る

一度 preload に載ると 2 年以上 HTTP に戻せない。慎重に。

実例: certbot で nginx に Let’s Encrypt 証明書を入れる完全手順

# 0. 前提: ドメインが VPS の IP に解決されている、nginx が動いている、ufw で 80/443 開けている
 
# 1. certbot インストール
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
 
# 2. nginx 用 server ブロック作成
sudo tee /etc/nginx/sites-available/example.com > /dev/null <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/example.com;
    index index.html;
}
EOF
 
sudo mkdir -p /var/www/example.com
echo '<h1>Hello</h1>' | sudo tee /var/www/example.com/index.html
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
 
# 3. ドメインの A レコードが正しく VPS を指していることを確認
dig +short example.com
# → 自分の VPS の IP が返ってくる必要がある
 
# 4. certbot 実行
sudo certbot --nginx -d example.com -d www.example.com \
    --email admin@example.com \
    --agree-tos \
    --no-eff-email \
    --redirect    # HTTP → HTTPS リダイレクトを自動設定
 
# 5. 自動更新の動作確認
sudo certbot renew --dry-run
 
# 6. ブラウザで https://example.com を開いて鍵マーク確認
 
# 7. SSL Labs テスト
# https://www.ssllabs.com/ssltest/analyze.html?d=example.com
# → A または A+ を目指す
 
# 8. HSTS を 5 分テストから段階的に伸ばす（手動）
sudo vim /etc/nginx/sites-available/example.com
# server { listen 443 ssl; ...
#     add_header Strict-Transport-Security "max-age=300" always;
# }
sudo nginx -t && sudo systemctl reload nginx
 
# 9. 数日問題なければ max-age を 31536000 に伸ばす

セキュリティ補強

加えると一段堅くなる設定

# OCSP Stapling（証明書失効確認の高速化＆プライバシー保護）
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;
 
# セッション再開（パフォーマンス向上）
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
 
# セキュリティヘッダ群
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

これらは securityheaders.com で評価できる。A+ を目指せる。

CAA レコードと併用する効果
前回のレッスンで設定した CAA レコード:
example.com CAA 0 issue "letsencrypt.org"
これにより、別 CA（DigiCert, Sectigo 等）が誤って・悪意で example.com の証明書を発行することを CA 側のレベルで防ぐ。CAA + Let’s Encrypt のセット が現代の標準。

練習課題

自分のドメインで certbot を実行し、HTTPS 化する
ブラウザで鍵マーク（緑）を確認する
HTTP でアクセスして HTTPS にリダイレクトされることを確認（curl -I http://example.com）
SSL Labs で A 以上を取る
HSTS を max-age=300 で 1 日試運転し、問題なければ伸ばす
certbot renew --dry-run を実行し、自動更新が動くことを確認
（余裕があれば）DNS-01 でワイルドカード証明書を取ってみる
nginx の access.log / error.log を眺め、SSL ハンドシェイクの様子を観察

締め: git で証跡を残す

cd ~/learn/infra/https
 
# nginx 設定の控え
sudo cp /etc/nginx/sites-available/example.com nginx_example.com.conf
 
# certbot のログ控え
sudo cp /var/log/letsencrypt/letsencrypt.log letsencrypt.log
 
# 動作確認の結果
curl -I https://example.com > curl_https.log
curl -I http://example.com > curl_http.log    # 301 リダイレクトが見える
 
git add nginx_example.com.conf letsencrypt.log curl_*.log README.md
git commit -m "feat(https): example.com で Let's Encrypt 証明書設置とリダイレクト確認"

チェックリスト

詰まった時のチートシート

やりたいこと	コマンド
証明書取得（nginx）	`sudo certbot --nginx -d example.com -d www.example.com`
証明書取得（手動）	`sudo certbot certonly --manual -d example.com`
DNS-01（Cloudflare）	`sudo certbot --dns-cloudflare ...`
ステージング（テスト）	`sudo certbot --staging ...`
更新ドライラン	`sudo certbot renew --dry-run`
実際の更新	`sudo certbot renew`
証明書一覧	`sudo certbot certificates`
証明書失効	`sudo certbot revoke --cert-name example.com`
nginx 構文チェック	`sudo nginx -t`
nginx リロード	`sudo systemctl reload nginx`
SSL Labs テスト	https://www.ssllabs.com/ssltest/analyze.html?d=example.com
証明書チェーン確認	`openssl s_client -connect example.com:443 -showcerts`

対比表: HTTP-01 vs DNS-01 認証

観点	HTTP-01	DNS-01
仕組み	`/.well-known/acme-challenge/` に置く	TXT レコードを置く
必要なもの	ポート 80 開放、Webサーバー稼働	DNS API or 手動設定
ワイルドカード	不可	可（`*.example.com`）
内部 IP のホスト	不可	可
自動更新の手軽さ	certbot のプラグインで簡単	DNS プロバイダの API 連携が必要

「実務OK」基準

certbot を使って 5 分以内に nginx に HTTPS を設置できる
fullchain.pem と cert.pem の違いを説明できる
HSTS の段階導入手順を説明できる
HTTP-01 と DNS-01 の使い分けが分かる
certbot renew --dry-run で自動更新の健康診断ができる
SSL Labs で減点される項目（古い TLS、弱い暗号、HSTS なし）を理解している
証明書失効時の影響と Let’s Encrypt rate limit に注意できる

自己評価チェックリスト

知識レベル

TLS の3要素（機密性・完全性・認証）を語れる
HSTS の段階導入手順をイメージできる
HTTP-01 と DNS-01 の使い分けを即答できる

実行レベル

自分のドメインで「緑鍵」状態を達成した
certbot renew --dry-run でドライランが成功した
SSL Labs で A 以上の評価を得た

メタ認知

自動更新が90日以内に1回は走る仕組みを確認した
証明書失効時のアラート（監視）を仕掛けたかチェックした

さらに深掘りするなら

公式: Let’s Encrypt Documentation
公式: Mozilla SSL Configuration Generator
公式: RFC 8446 (TLS 1.3)
書籍: 『プロフェッショナル SSL/TLS』（Ivan Ristić, ラムダノート） - SSL Labs 作者
ツール: ssllabs.com/ssltest - SSL/TLS 検査の鉄板
ツール: securityheaders.com - HTTP セキュリティヘッダ検査

次のレッスン

3-4_CICD基本.md で、ここまで作った VPS + ドメイン + HTTPS にコードを自動デプロイする CI/CD の世界へ。

バックエンドマスター

エクスプローラー

3-3_HTTPS化

3-3. HTTPS - Let’s Encrypt で証明書を取り、nginx に組み込む

このレッスンのゴール

なぜ学ぶか（実務悩みベース）

前章とのつながり

大前提: HTTPS は「あったらいい」ではなく「ないと終わり」

セッション①: TLS 証明書と Let’s Encrypt（20-25分）

1. TLS / SSL の基本

2. 証明書の種類（DV / OV / EV）

3. certbot のインストール

4. nginx を準備する

5. certbot で証明書を取得（nginx プラグイン）

6. 取得後の nginx 設定

7. ブラウザで確認

セッション②: 自動更新と HSTS（15-20分）

8. 自動更新の確認

9. HSTS の導入

10. HTTP → HTTPS リダイレクト確認

セッション③: 強い暗号設定と運用知識（20-25分）

11. SSL Labs テスト

12. TLS バージョン制限

13. 中間証明書チェーンとは

14. ワイルドカード証明書と DNS-01 チャレンジ

アンチパターン総まとめ

実例: certbot で nginx に Let’s Encrypt 証明書を入れる完全手順

セキュリティ補強

練習課題

締め: git で証跡を残す

チェックリスト

詰まった時のチートシート

対比表: HTTP-01 vs DNS-01 認証

「実務OK」基準

自己評価チェックリスト

知識レベル

実行レベル

メタ認知

さらに深掘りするなら

次のレッスン

グラフビュー

目次

バックリンク