SSL 自動更新の仕組みと現実解
目次
この記事でわかること
- 自動更新（ACME プロトコル）がどう動いているか、ざっくりとした全体像
- 自動更新が壊れる代表的なパターン
- 「壊れていることに気付かない」を防ぐ監視の仕込み方
- 商用証明書を使う場合の自動化の限界
SSL の役割や仕組みの基礎から確認したい方は SSL とは｜Web 担当者向けにわかりやすく解説 を先に読むと、本記事が理解しやすくなります。
なぜ自動更新が必須になったのか
SSL 証明書の有効期間は、業界として段階的に短縮されていきます。CA/Browser Forum（認証局とブラウザベンダーの業界団体）が 2025 年 4 月に可決した Ballot SC-081v3 により、最長有効期間は次のスケジュールで短縮される予定です。
- 2026 年 3 月以降: 最長 398 日 → 200 日
- 2027 年 3 月以降: 100 日
- 2029 年 3 月以降: 47 日
加えて Let's Encrypt は以前から 90 日を既定とし、さらに短い有効期間の証明書（short-lived certificate）の提供も進めています。「年に 1 回更新」という運用は、現実として崩壊しつつあります。手動運用は人為ミスの温床なので、自動化はサイト運営者でも避けて通れない論点です。
ACME プロトコルの動き方（仕組みのざっくり理解）
Let's Encrypt をはじめとする無料証明書のほとんどは、ACME（Automated Certificate Management Environment、RFC 8555） という自動発行プロトコルで動いています。動きをざっくり追うと:
- アカウント鍵の登録: クライアント（certbot 等）が認証局にアカウント鍵を登録
- 発行リクエスト: 「このドメインに証明書がほしい」と認証局に依頼
- 所有確認チャレンジ: 認証局から「ドメインの管理者であることを証明して」と言われる。代表的な方式は 2 つ
- HTTP-01: 指定のファイルを
http://example.co.jp/.well-known/acme-challenge/<token>に配置できれば管理者と認める - DNS-01: 指定の TXT レコードを
_acme-challenge.example.co.jpに追加できれば認める
- HTTP-01: 指定のファイルを
- 証明書発行: チャレンジが通ると、認証局が証明書を発行
- 証明書のインストール: クライアントが証明書を Web サーバーに配置し、リロードを実行
このフローを cron や systemd timer で 60〜80 日ごとに走らせる、というのが「自動更新」の中身です。
自動更新が壊れる代表的なパターン
「設定したら勝手に動き続ける」と思われがちですが、現場では次のような故障モードが頻発します。
1. acme クライアントが落ちている
サーバー再起動後、自動起動の設定が無く certbot が動かなくなっているケース。systemd-timer なら systemctl status certbot.timer で稼働確認できます。cron なら /etc/cron.d/certbot の存在を確認してください。
2. HTTP-01 のチャレンジファイルが配置できない
.well-known/acme-challenge/ パスが、リライトルールで HTTPS にリダイレクトされたり、メンテナンスページに置き換わったりすると認証が失敗します。別のフレームワーク（WordPress、Next.js 等）に乗せ替えたタイミングで起きやすい故障です。
3. DNS-01 の API 権限切れ
DNS-01 を使っている場合、Cloudflare や Route 53 等の API トークンに有効期限がある or スコープを変更されると失敗します。エラーログには permission denied が出ます。
4. 80 番ポートが塞がれている
セキュリティ強化で 80 番ポートを閉じた瞬間、HTTP-01 が機能しなくなります。本来は HTTPS だけで運用したいケースでも、ACME のために 80 番は開けておくか DNS-01 への切り替えが必要です。
5. CAA レコードの不一致
CAA レコードで「Let's Encrypt 以外発行禁止」と設定しているのに、別の認証局を使おうとして失敗するケース。ドメイン側の設定変更時にチェック漏れが発生しがちです。
「壊れていることに気付かない」を防ぐ
サイト運営で一番起きるのは「自動更新は動いているはずなのに、いつの間にか止まっていて気付いた時には期限切れ目前」というパターンです。これを防ぐには 更新を実行する側 と 期限を見張る側 の 2 系統を独立して持つのが安全です。
仕込み 1: 更新ログを毎週確認
certbot なら /var/log/letsencrypt/letsencrypt.log に最終実行時刻が記録されます。週 1 で確認するのは現実的でないため、ログ監視ツール（Datadog、Mackerel、Grafana 等）で「直近 30 日に renew が成功したか」をチェックする監視ジョブを設定するのが王道です。
仕込み 2: 外部から期限を監視
CT log を経由して、現に発行されている証明書の not_after を外部からチェックします。サーバー内部の自動更新に依存しないため、仮にサーバー側が壊れていても期限の接近に気付けるのが利点です。SSL 証明書 単発チェック では crt.sh と CertSpotter を使った外部視点での期限確認ができます。
仕込み 3: 期限前アラートを複数チャネルへ
サーバー内部の通知（メール）と、外部監視サービスの通知（チャットツール）の 2 系統を、期限の 30 日前・14 日前・7 日前・1 日前で段階的に発火させます。担当者の異動や長期休暇でも取りこぼしません。
商用証明書（Cybertrust 等）と自動化の限界
国内認証局の商用証明書（Cybertrust、GMO グローバルサイン、セコム等）は、企業実在確認や審査プロセスが介在するため、ACME 完全自動化は基本的にできません。EV 証明書はさらに厳しく、年次の審査が必要です。
選択肢は 2 つに整理できます。
- A. 商用証明書を継続し、更新を半自動化: 期限の 60 日前から自動的に通知を発火させ、認証局のマイページからの更新作業だけ手動で行う運用
- B. 用途を分けて Let's Encrypt に寄せる: ブランド表示が必須でない管理画面・API・キャンペーン用ドメイン等は Let's Encrypt で自動化、コーポレートサイトのトップだけ商用を維持
EV / OV / DV 各証明書の選び方は SSL 証明書の種類（DV / OV / EV）の違い で詳しく解説しています。
現実解
リソースの限られたサイト運営者では、次の構成が最もトラブルが少ないです。
- メインドメイン: Let's Encrypt + ACME 自動更新
- 監視: 外部から期限を見張るサービス（自社で組む or 外部に委託）
- 棚卸し: 年 1 回、保有ドメインと証明書の棚卸し
- 緊急時の連絡経路: 期限切れ警告が出た時の連絡先（複数人）を事前に決めておく
SSL 棚卸し・自動更新支援（5 万円〜）では、ここまでの一連を初回セットアップとして対応します。「自動更新を入れたいが何から手を付けていいか分からない」段階のご相談も歓迎します。
まずは現状を把握しましょう
自社の SSL がどう設定されているか分からない場合は、まず SSL 証明書 単発チェック で 30 秒の現状診断をどうぞ。発行元 CA、有効期限、HSTS の設定、HTTP/2 / 3 対応までまとめて確認できます。
総合的にメール認証・DNS まで含めて点検したい方は 無料のドメイン診断 もご利用ください。具体的なご相談は お問い合わせフォーム からお気軽にどうぞ。