Let’s Encrypt証明書の自動更新を本番で安定稼働させる｜certbotタイマーとリロード設計の判断

Let’s Encryptの証明書は90日で失効します。更新忘れによる障害は今も起きており、「cronで回しているから大丈夫」という認識が現場に残っている間は油断できません。2026年現在、certbotの推奨インストール形式はsnapに移行しており、設定の置き場所やタイマーの扱いが旧来の手順と異なります。本記事では、systemdタイマーによる自動更新の仕組みの把握から、Webサーバーのリロード設計の判断、検証と切り戻しまでを一貫して整理します。

なぜcronではなくsystemdタイマーなのか

かつてはcrontabにcertbot renewを書くパターンが主流でした。しかし現行のcertbot（snap版を含む）は、インストール時にsystemdのタイマーユニットを自動生成します。snap.certbot.renew.timerまたはcertbot.timerがそれです。

systemdタイマーには、cronにはない特性があります。タイマーはシステムの再起動後も自動で有効になり、実行履歴はjournalctlで追跡できます。また、OnCalendarのほかにRandomizedDelaySecを設定することで、Let’s Encryptサーバーへのリクエストが特定の時刻に集中しにくくなります。これはサービス全体の安定性に寄与する設計です。

まず現在の状態を確認します。

# snap版の場合
systemctl status snap.certbot.renew.timer

# apt版（Debian/Ubuntu系の一部）の場合
systemctl status certbot.timer

Active: active (waiting)と表示されれば、タイマーは生きています。cronと二重に登録していないかも確認しておく価値があります。crontab -lと/etc/cron.d/以下を目視で確認し、certbot関連の行があれば削除またはコメントアウトを検討してください。

deploy-hookによるリロード設計：何をいつ実行させるか

証明書が更新された後、Webサーバーに新しい証明書を読み込ませる処理が必要です。certbotが提供するフックは複数ありますが、本番での用途は主に--deploy-hookです。

--deploy-hookは「証明書が実際に更新された場合のみ」実行されます。これに対し--post-hookは更新の成否を問わず実行される点が異なります。更新がなかった日（90日更新のうち88日はこれに該当します）にWebサーバーを無用にリロードしないためには、--deploy-hookを使うのが適切です。

設定の置き場所は/etc/letsencrypt/renewal-hooks/deploy/です。このディレクトリに実行可能なシェルスクリプトを置くと、certbotが自動で呼び出します。nginx環境であれば次のような内容になります。

#!/bin/bash
# /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
systemctl reload nginx

chmod +xで実行権限を付与することを忘れないでください。Apacheの場合はsystemctl reload apache2またはsystemctl reload httpdに読み替えます。

ここで設計上の判断が必要になります。systemctl reloadはプロセスを停止せずに設定を再読み込みします。一方、systemctl restartはプロセスを一度落とすため、接続中のセッションが切断されるリスクがあります。高トラフィック環境ではreloadを選ぶべきです。ただし、nginxのreloadが失敗するケース（設定ファイルに誤りがある場合など）は、失敗してもタイマー自体は正常終了するため、アラートを別途設けておく必要があります。

本番投入前のdry-run検証と実機確認の流れ

自動更新の設定を変更したら、必ず検証してから本番稼働に移行します。certbotには--dry-runオプションがあり、実際には証明書を更新せずに更新フローを通過させられます。

certbot renew --dry-run

このコマンドはステージング環境のACMEエンドポイントに接続し、更新処理全体をシミュレートします。deploy-hookも実際に実行されるため、リロードが想定どおり走るかを事前に確認できます。

dry-runが成功したら、次は実際の更新日を待たずに手動で強制更新して動作を確認する方法があります。

certbot renew --force-renewal

ただし、--force-renewalはすべての証明書を無条件に更新しようとします。Let’s Encryptにはレートリミット（同一ドメインに対して1週間で5件まで）があるため、本番環境での多用は避けてください。テスト用途であればステージングエンドポイントを使う方が安全です。

更新後は証明書の有効期限を直接確認します。

openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -dates

notAfterが今日から90日後になっていれば、更新は成功しています。

更新失敗時の切り戻しと障害対応パターン

自動更新が失敗するのは、多くの場合、チャレンジの失敗（DNS解決の問題、80番ポートのブロック）かdeploy-hookの異常終了です。まず失敗の原因を特定します。

# journalctlでタイマー実行ログを確認
journalctl -u snap.certbot.renew.service --since "7 days ago"

# certbot独自のログ
cat /var/log/letsencrypt/letsencrypt.log

証明書の更新は失効の30日前から可能です。certbotのデフォルト設定では有効期限が30日を切った時点で更新を試みます。つまり、失敗しても30日以内に原因を解消すれば証明書切れを防げます。タイマーが1日2回実行される設定（snap版のデフォルト）であれば、実質的にリカバリの余地は十分あります。

一方、何らかの事情で旧証明書に戻す必要が生じた場合、certbotは/etc/letsencrypt/archive/に過去の証明書を保持しています。しかし、古い証明書への手動切り戻しは推奨されません。有効期間が残っていても、Let’s EncryptはOCSPによる失効チェックを行うため、意図せず失効済みの証明書をつかんでしまうリスクがあります。

現場でよく見られる対応として、証明書の更新が失敗した際に管理者へメールを送る仕組みを--post-hookに組み込むパターンがあります。更新成否に関わらず実行される--post-hookで終了コードを評価し、失敗時にのみ通知するスクリプトを置いておくと、問題の検知が早くなります。

2026年時点の現行環境差分

2026年に向けて、Let’s Encryptとcertbotをめぐるエコシステムにはいくつかの変化が生じています。

まず、certbotのsnapパッケージへの移行が事実上完了しています。Debian/Ubuntu向けのaptパッケージは非推奨とされており、公式ドキュメントはsnapによるインストールを案内しています。snap版ではバイナリが/snap/bin/certbotに置かれ、設定ファイルは引き続き/etc/letsencrypt/に置かれますが、タイマーユニット名がsnap.certbot.renew.timerとなる点に注意が必要です。

次に、ACME v3（RFC 8555）の普及に伴い、Let’s EncryptはACME v2を段階的に縮小しています。古いcertbotをそのまま使い続けている環境では、エンドポイントへの接続に失敗するケースが報告されています。certbot --versionで現在のバージョンを確認し、旧来のaptパッケージを使っている環境ではsnapへの移行を検討する時期に来ています。

また、ワイルドカード証明書を利用する場合はDNS-01チャレンジが必要であり、DNSプロバイダーのAPIとcertbot-dnsプラグインを組み合わせる構成が標準化しています。snap版ではプラグインもsnap install certbot-dns-cloudflareのように個別にインストールする形になっており、旧来のapt経由のプラグインと混在させると動作しません。

Nginxのnginx -tによる設定テストをdeploy-hookの冒頭に組み込み、テストが失敗した場合はリロードをスキップするパターンも、2026年時点の現場では採用例が増えています。証明書の更新は成功しているのに設定ファイルの誤りでリロードが落ちる、という事態を防ぐための現実的な対策です。

#!/bin/bash
nginx -t 2>/dev/null && systemctl reload nginx

自動更新の設計は「設定したら終わり」ではなく、タイマーの死活監視・フックのログ確認・バージョン追従を継続的に行う運用です。インフラ変更のたびにdry-runを一本通す習慣を持っておくと、本番での予期しない失敗を大幅に減らせます。