Ubuntu 24.04でLet's Encrypt自動更新を確実に動かす｜Certbot snap/systemd-timer/cron 3パターン徹底比較

「Ubuntu 24.04でLet's Encryptの証明書を自動更新したいけれど、Certbotの導入は snapとaptどちらが正解で、自動更新はsystemd-timerとcronのどちらに任せるのが安全だろう？」
2026年5月時点で、Ubuntu 24.04 LTS上でCertbotを動かす方法は大きく3つ（snap版、aptパッケージ＋systemd-timer、apt＋手動cron）に分かれます。それぞれに利点と落とし穴があり、迷うのも当然です。

この記事では、Ubuntu 24.04でLet's Encryptの自動更新を確実に動かすための3パターンを、設置手順とログ確認、トラブル時の切り分けまで含めて徹底比較します。なお、汎用的な「SSL証明書更新エラー対処」の概論はすでに別記事で扱っているため、本稿はUbuntu 24.04特化の最新パターンに絞ります。

Ubuntu 24.04でCertbotを動かす3パターンの全体像

まず、3パターンの違いを俯瞰します。

項目	snap版	apt + systemd-timer	apt + 手動cron
導入元	Snapcraft（Canonical/EFF）	Ubuntu公式リポジトリ	Ubuntu公式リポジトリ
Certbot本体の更新	自動（snap側で追従）	Ubuntu 24.04の固定バージョン	Ubuntu 24.04の固定バージョン
自動更新の仕組み	snap.certbot.renew.timer（同梱）	certbot.timer（同梱）	cron + certbot renew
更新頻度	12時間ごと	12時間ごと（ランダム遅延あり）	任意（一般的に1日1～2回）
EFF推奨度	◎	○	△（互換性向け）
こんな環境に向く	本番運用全般、最新追従重視	snapを使わない方針	独自スクリプトと統合したい

各パターンを具体的に見ていきます。

パターン1：snap版Certbot（EFF公式推奨）

Let's Encrypt運営元のEFFが、Ubuntu 24.04を含む現行サポートディストロで公式推奨しているのがsnap版です。Certbotの最新機能と修正に追従できる点が最大の利点です。

1. インストール手順

Ubuntu 24.04にはsnapdが標準で同梱されています。

・既存certbotの確認：which certbotとdpkg -l | grep certbotで旧版がないか確認
・既存削除（必要時）：sudo apt remove certbot python3-certbot-nginx python3-certbot-apache
・snap coreの更新：sudo snap install core; sudo snap refresh core
・certbotのインストール：sudo snap install --classic certbot
・パスの確保：sudo ln -s /snap/bin/certbot /usr/bin/certbot

2. 自動更新タイマー

snap版Certbotは、インストール時にsystemd timerを自動配置します。

・タイマー：snap.certbot.renew.timer（12時間ごと）
・サービス：snap.certbot.renew.service
・確認：systemctl list-timers | grep certbot
・次回実行時刻：systemctl status snap.certbot.renew.timer

ユーザー側でcronを書く必要はありません。Certbotは「証明書の残り有効期限が30日以下なら更新」のロジックで動くため、12時間ごとに走っても無駄なAPI呼び出しにはなりません。

3. ログ確認

更新の実行結果は次の場所で確認できます。
・sudo journalctl -u snap.certbot.renew.service --since "1 day ago"
・sudo less /var/log/letsencrypt/letsencrypt.log（Certbot本体ログ）
・sudo certbot certificatesで証明書の現状を一覧確認

パターン2：aptパッケージ＋systemd-timer

snapに依存させたくない、あるいは社内ポリシーでsnapが禁止されている環境では、Ubuntu 24.04のaptパッケージが選択肢になります。

1. インストール手順

Ubuntu 24.04のmain/universeリポジトリにcertbotが含まれており、コマンド一発で入ります。

・certbot本体：sudo apt install certbot
・Apacheプラグイン：sudo apt install python3-certbot-apache
・Nginxプラグイン：sudo apt install python3-certbot-nginx

インストール直後にcertbot.timerがsystemd側に自動登録されます。

2. 自動更新タイマーの確認

apt版もsystemd-timerで動きます。

・タイマーファイル：/lib/systemd/system/certbot.timer
・サービスファイル：/lib/systemd/system/certbot.service
・有効化確認：systemctl is-enabled certbot.timer
・次回実行時刻：systemctl list-timers | grep certbot

標準ではOnCalendar=*-*-* 00,12:00:00に加えてRandomizedDelaySec=43200（12時間以内の任意遅延）が設定されており、Let's Encrypt APIへの集中アクセスを避ける配慮があります。

3. apt版の制約と注意点

Ubuntu 24.04のaptパッケージにあるcertbotのバージョンは、24.04リリース時点（2024年4月）のものに事実上固定されます。

・新しいACMEクライアント機能（ECDSA鍵の自動更新オプション等）が後から追加されても反映されない
・セキュリティ修正はUbuntuのアップデート経由で来る（タイムラグあり）
・26.04 LTSへのアップグレードまでは原則そのバージョンを使う前提

通常運用なら問題は少ないですが、ACMEv2の挙動変更やバグ修正にすぐ追従したい運用には不向きです。

パターン3：apt + 手動cronで完全制御

組織のスクリプト群に組み込みたい、あるいは特殊な前処理・後処理を細かく制御したい場合、手動cronで運用するパターンも依然として有効です。

1. デフォルトタイマーの無効化

aptで入れたcertbotにはcertbot.timerがついてくるため、二重実行を避けるためまず無効化します。

・sudo systemctl disable --now certbot.timer
・systemctl is-enabled certbot.timerで無効化を確認

2. cronエントリの記述例

ルートユーザーのcrontabで管理します。

・sudo crontab -eを実行
・以下を追加：17 3,15 * * * /usr/bin/certbot renew --quiet --deploy-hook "/usr/local/sbin/reload-services.sh"

1日2回（3:17と15:17）の更新チェック、--deploy-hookで証明書更新後にNginx/Apacheの再読み込みを実行します。1日2回にする理由は、Let's Encrypt公式が推奨する更新試行回数のためです。

3. deploy-hookスクリプトの例

/usr/local/sbin/reload-services.shの中身例：

・#!/bin/bash
・set -euo pipefail
・systemctl reload nginx || true
・systemctl reload apache2 || true
・logger -t certbot-deploy "Cert renewed and services reloaded"

権限はchmod 755 /usr/local/sbin/reload-services.sh、所有者はrootに設定します。

4. cron版のメリットとデメリット

・メリット：実行タイミングを細かく制御できる、独自前処理・後処理を組み込める、journald非依存
・デメリット：環境変数を渡しにくい、ログがjournaldに乗らない、systemdの並列実行制御や依存関係が使えない

3パターンの選び分け｜実務での判断軸

3パターンのどれを選ぶかの判断軸を整理します。

1. 「とにかく公式推奨に従いたい」ならsnap版

・運用ポリシー上snapが許可されている
・Certbotの最新機能をすぐ使いたい
・標準構成でEFFサポート対象でありたい

この場合はパターン1（snap版）が無難です。Let's Encryptの仕様変更にいち早く追従できます。

2. 「ディストロパッケージ縛り・stable重視」ならapt版＋systemd-timer

・社内ポリシーでsnapが使えない
・Ubuntu LTSのリリース内容にバージョンを固定したい
・標準的なsystemd運用に揃えたい

この場合はパターン2（apt+timer）が現実的です。

3. 「独自スクリプト統合・特殊環境」ならapt＋手動cron

・複数のreloadタイミングや独自処理が絡む
・systemd-timerが使えない（コンテナ内など）
・既存運用と統合させたい

この場合はパターン3（apt+cron）に倒します。ただしsnap版・apt timer版と混在しないように注意します。

共通のトラブルシューティング｜更新失敗時の切り分け

どのパターンでも、更新失敗時の切り分け手順は基本的に共通です。

1. 強制実行で挙動を観察

・sudo certbot renew --dry-runでステージング環境への試行
・sudo certbot renew --force-renewalで強制更新（テスト時のみ、本番乱用厳禁）

--dry-runはLet's EncryptのレートリミットにカウントされないAPIエンドポイントを使うため、何度でも安全に確認できます。

2. よくある失敗パターン

・80番ポート不通：HTTP-01検証ではWebルート/standaloneで80を通す必要あり
・DNS-01の認証失敗：ワイルドカード証明書ではDNS APIプラグインが必要
・nginx/apacheの設定エラー：renew後のreload失敗で旧証明書が残る
・権限エラー：cronをroot以外で動かしている、deploy-hookが実行不可

3. ログの探し場所

・/var/log/letsencrypt/letsencrypt.log（Certbot詳細ログ）
・journalctl -u snap.certbot.renew.service（snap版）
・journalctl -u certbot.service（apt+timer）
・/var/log/syslog（cron実行ログ）

Ubuntu 24.04特有の注意点｜26.04 LTSへの将来移行

Ubuntu 24.04でCertbot運用を組み立てる際は、次のLTS（26.04）への移行も視野に入れておきます。

1. snap版は移行が透明

snap版は、Ubuntu 22.04・24.04・26.04すべてで同じインストール手順・同じバージョンが動きます。do-release-upgrade後もそのまま動作するため、長期運用では移行コストが最小になります。

2. apt版は26.04リリース時に内容が更新される

26.04 LTSがリリースされると、apt版certbotのバージョンも更新されます。たとえばcertbot.timerのOnCalendar設定や、追加プラグインの提供有無に変更が入る可能性があります。移行後にタイマーの状態を確認してください。

3. /etc/letsencryptは原則そのまま

証明書本体・accountキー・renewal設定ファイル（/etc/letsencrypt/renewal/*.conf）はディストロ標準パスに残るため、24.04→26.04のdo-release-upgrade後も基本的にはそのまま継続運用できます。事前に/etc/letsencryptのバックアップを取っておくと、万一のロールバックが楽になります。

よくある質問｜Ubuntu 24.04のCertbot運用で迷うポイント

Q1. snap版とapt版を両方入れると何が起きる？

A. certbotコマンドのパス（/usr/bin/certbotと/snap/bin/certbot）が衝突し、どちらが優先されるか不定になります。さらに、systemd-timerが二重に走るため、Let's EncryptのAPIに不必要にアクセスし、レートリミットに引っかかる可能性があります。導入前にwhich certbotとdpkg -l | grep certbotで既存を確認し、片方に統一してください。

Q2. ワイルドカード証明書はどのパターンでも取れる？

A. 取れますが、DNS-01検証のためにDNSプロバイダのAPI連携が必要です。snap版ならsudo snap install certbot-dns-cloudflareのようにプラグインを追加できます。apt版でもpython3-certbot-dns-route53などのプラグインパッケージが用意されています。プロバイダごとのプラグイン有無は事前に確認してください。

Q3. cron実行時の標準出力を捨てて大丈夫？

A. cronのデフォルトでは標準出力・エラー出力がrootへメールされる設定です。--quietオプションを付けると更新が必要な場合のみメッセージが出るため、無更新時にcronメールが大量に届く問題を回避できます。ただし、/var/log/letsencrypt/letsencrypt.logはそのまま残るため、定期的なtail -F確認は別途必要です。

Q4. 更新エラー時の通知はどう仕込む？

A. systemd版ならOnFailure=ディレクティブで失敗時の別ユニットを呼び出せます。cron版ならcertbot renew || mail -s "Certbot failed" admin@example.comのように、終了コードで分岐します。snap版の場合はsnap.certbot.renew.serviceに対するoverride設定で同様の処理が可能です。

参考書籍｜Linuxサーバー運用とTLS／HTTPSを体系的に学ぶ

※本セクションには広告（PR）リンクを含みます

Let's Encryptの自動更新を確実に動かすには、Linuxのサービス管理・systemd・TLS基礎の理解が前提になります。定番書で土台を固めることをおすすめします。

・Linux教科書 LPICレベル1 Version5.0対応（翔泳社）：systemd・cron・サービス管理など、Certbotが乗る土台を体系的にカバー
・プロフェッショナルSSL/TLS（ラムダノート）：TLS仕様・証明書・OCSP・PKIの全体像を一冊で押さえられる定番書

本記事のまとめ

ポイント	内容
3つのパターン	snap版／apt+systemd-timer／apt+手動cron
EFF公式推奨	snap版（自動タイマー同梱、Certbot最新追従）
apt版の特徴	Ubuntu 24.04リリース時のバージョンに固定、stable重視向け
cron版の特徴	独自前後処理が組み込める、systemd timer無効化が前提
事故防止の鉄則	snap版とapt版の混在禁止、導入前に既存certbotを確認
トラブル時の起点	journalctl + /var/log/letsencrypt/letsencrypt.log の2点
26.04 LTS移行	snap版は透明、apt版は再構成、/etc/letsencryptは残る

Let's Encryptの自動更新は、一度動かしてしまうと普段は意識しなくなる仕組みですが、止まったときの影響は重大です。20年以上Linuxサーバーを運用してきた経験から言えば、設置直後に--dry-runで動作確認したら終わりではなく、3ヶ月後・6ヶ月後にも一度journalctlで更新ログを目視確認しておく習慣が、最終的な事故防止につながります。

証明書更新エラー対処の汎用的な内容は別記事「Let's EncryptのSSL証明書更新処理がエラーになった場合の対処」でも整理しているので、トラブル時には合わせて参照してください。

---

• 前のページへ：MySQL 8.0 EOL到来｜Linux管理者のためのMySQL 8.4 LTS移行判断フレーム
• この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る