Let’s Encrypt の証明書を自動で更新しているサイトは、「90日ごとに勝手に入れ替わるから放っておいてよい」と扱われがちです。ところが、その自動更新が「発行から60日たったら更新する」という決め打ちで動いている場合、2027年2月以降は期限の4〜5日前まで更新に取りかからない設定に変わります。更新に1回失敗すれば、その数日の間に気づいて直さなければなりません。
Let’s Encrypt は10月7日のブログで、2027年2月10日から既定の証明書の有効期間を64日にすると予告しました。更新を ACME Renewal Info（ARI）に任せているクライアントなら対応は要らないとしたうえで、更新を「期限から何日」と決め打ちしている場合は、有効期間の約3分の2で更新するよう直すことを求めています。
本記事は、自社サイトや受託したサイトで Let’s Encrypt を使う保守担当者に向けて、何がいつ変わるか、使っている ACME クライアントで更新の時期がどう決まるか、どこを確かめて直すかを整理したものです。有効期間の短縮が業界全体で進む背景と、手作業で更新しているサイトの対策は、SSL証明書の有効期限の短縮の記事で扱っています。
2027年2月10日から何が変わるか
10月7日のブログと、2025年12月2日の「Decreasing Certificate Lifetimes to 45 Days」が示す日程です。
| 日付 | 変わること |
|---|---|
| 2026年10月14日 | ステージング環境で64日の証明書の発行を開始（試験用） |
| 2027年2月10日 | 既定（classic プロファイル）の証明書が64日に。認可の再利用期間は30日から10日に |
| 2027年5月11日 | 最後の90日の証明書が切れる見込み |
| 2028年2月16日 | 既定の証明書が45日に。認可の再利用期間は7時間に |
64日になるのは、2027年2月10日以降に発行・更新した証明書です。手元の90日の証明書が失効させられることはなく、次の更新から64日の証明書に置き換わります。ブログは、レート制限には影響がなく、ACME のエンドポイントや証明書のチェーンも変わらないとしています。
すでに tlsserver のプロファイル（45日）や shortlived（約6日）を選んでいるクライアントは、もともと短い証明書で動いています。プロファイルの説明は 2026年10月時点の文書でも classic を「90日・30日」としており、2027年2月10日に切り替わるのはこの既定のプロファイルです。
危ないのは「発行から何日」で数える更新
Let’s Encrypt の連携ガイドは、ARI を確かめたうえで、その予備として「有効期間の残りが3分の1になったら更新する」ことを勧めています。90日の証明書なら期限の30日前、つまり発行から60日目です。この「60日」という数字が、cron の設定や運用手順にそのまま残っていることがあります。
10月7日のブログは、自信がなければ cron のジョブ、ラッパーのスクリプト、運用手順書で 83・80・60 のような数を検索するよう勧めています。サーバーで確かめるなら、たとえば次のように探せます。
# cron と自作スクリプトから、証明書の更新に関わりそうな日数の決め打ちを探す
grep -rnE '(^|[^0-9])(60|80|83|89)([^0-9]|$)' /etc/cron* /var/spool/cron* /usr/local/bin 2>/dev/null \
| grep -iE 'cert|acme|renew|days'数字が見つかったら、それが「発行からの日数」なのか「期限までの残り日数」なのかを確かめます。発行から数える決め打ちは64日の証明書で危なくなり、残りで数える決め打ちはおおむね安全です。たとえば「残り30日で更新」は、64日の証明書では発行から34日目、45日の証明書でも15日目の更新になり、期限より前に収まります。
図の日数は、certbot と acme.sh は次の節で実際のコードを動かして求め、lego はヘルプと移行ガイドの説明から計算したものです（ARI の指示がない場合）。
使っているクライアントで更新の時期がどう決まるか
主な ACME クライアントの、更新の時期の決まり方です。いずれも各プロジェクトのリポジトリにある変更履歴とソースで確認しました（2026年10月21日）。
| クライアント | ARI | ARI がないときの既定 | 確かめる場所 |
|---|---|---|---|
| certbot | 4.1.0（2025年6月）から対応 | 4.0.0 から残り3分の1で更新。それ以前は期限の30日前 | certbot --version、/etc/letsencrypt/renewal/*.conf の renew_before_expiry |
| lego | v4.20.2（2024年11月）から既定で確認 | v5 は残り3分の1。v4 は renew --days 30（残り30日） | lego --version、cron などに書いた run・renew の引数 |
| acme.sh | 3.1.3 から対応 | 3.1.3 以降は発行から29日目、3.1.2 以前は59日目 | acme.sh --version、ドメインごとの .conf の Le_RenewalDays |
| Caddy（certmagic） | RFC 9773 に対応 | 残り3分の1（RenewalWindowRatio の既定） | 独自に比率を変えていないか |
certbot：古い版のままなら期限の30日前
certbot は 4.0.0（2025年4月）で、更新の既定を「期限の30日前」から「残り3分の1（有効期間が10日未満なら半分）」に変え、4.1.0 で ARI に対応しました。変更履歴によれば、ARI があると、Let’s Encrypt の証明書は通常、有効期間の約3分の2で更新されます。
古い版の「期限の30日前」は残りで数える方式なので、64日の証明書でも期限切れにはなりません。気をつけるのは、更新の設定ファイルに renew_before_expiry を書いている場合です。ARI の応答がないときはこの値が既定より優先されるため、短すぎる値（たとえば 3 days）が残っていると、期限の直前まで更新しません。OS のパッケージで入れた certbot は、PyPI の最新版（10月21日時点で 5.8.0）より古いことがあるため、certbot --version で版を確かめます。
lego：v4 の --days は「残り日数」、v5 は残り3分の1
lego v4 の renew --days は「証明書の残りが何日になったら更新するか」で、既定は30です。64日の証明書では発行から34日目に更新に入ります。v4.20.2 からは、無効にしない限り ARI を確かめます。v4.25.0 で加わった --dynamic は「残り3分の1（短い証明書は半分）」で更新する選択肢で、v4 のヘルプには lego v5 で既定にすると書かれていました。cron に --days 60 のような大きな値を書いていても、残りで数えるため期限切れにはなりませんが、64日の証明書では毎回すぐ更新に入ります。
2026年5月11日に出た lego v5 では、renew コマンドが run にまとめられ、--days は --renew-days に名前が変わり、--dynamic はなくなりました。移行ガイドによれば、v5 は日数を指定しなければ「残り3分の1」で更新します。64日の証明書では、certbot の既定と同じ発行から42.7日目です。v4 のまま renew --days を使っているか、v5 に上げたかで更新の時期が変わるため、lego --version と cron の引数をあわせて確かめます。
acme.sh：3.1.2以前は「発行から60日」
acme.sh は、--days を「発行から何日で更新するか」として扱います。3.1.2 までは既定が60で、発行から59日目に更新していました。3.1.3 で既定が30になり、ARI にも対応しています。3.1.4 からは、日数の決め打ちが期限を越えないよう、更新の時期を期限の1日前までで打ち切る処理も入りました。
注意が要るのは2つの場合です。1つは、3.1.2 以前のまま更新していないサーバーです。もう1つは、新しい版でも、ドメインの設定に --days 60 を明示して残している場合です。新しい版でも、ARI が示す時期がそれより早ければ ARI に従うとソースのコメントに書かれていますが、ARI を使わない設定（NO_ARI=1）にしていると、64日の証明書を期限の5日前まで更新しません。acme.sh --version と、ドメインごとの .conf に Le_RenewalDays があるかを確かめます。
Caddy：既定のままなら対応不要
Caddy が使う certmagic は ARI（RFC 9773）に対応しており、ARI がない場合も、残り3分の1で更新します。RenewalWindowRatio を独自に小さくしていなければ、手を入れる必要はありません。
レンタルサーバーや CDN が証明書を自動で発行している場合は、利用者の側で更新の時期を変えられないことがほとんどです。この場合は、事業者の告知や問い合わせ窓口で、64日の証明書への対応を確かめます（編集部の提案）。
実際のコードで更新日を計算した
2026年10月21日、編集部の検証環境（Linux、OpenSSL 3.0.13）で、有効期間が90日・64日・45日の自己署名の証明書を作り、certbot と acme.sh の更新の時期を決める関数をそのまま動かしました。
certbot は PyPI の 5.8.0 を隔離した仮想環境に入れ、ARI がないときの既定を返す内部の関数（_default_renewal_time）に証明書を渡しました。acme.sh は、3.1.6 のソースから更新の時期を計算する関数を取り出して実行し、3.1.2 の計算式（発行時刻 + 日数 − 1日）と比べました。acme.sh の発行日は 2027年2月10日としています。
certbot 5.8.0（ARI なしの既定）
90日: 発行から60.0日目に更新（残り30.0日）
64日: 発行から42.7日目に更新（残り21.3日）
45日: 発行から30.0日目に更新（残り15.0日）
acme.sh
3.1.6 既定(30) 64日: 29日目（残り35日） 45日: 29日目（残り16日）
3.1.6 --days 60 64日: 59日目（残り5日） 45日: 44日目（残り1日）
3.1.2 既定(60) 64日: 59日目（残り5日） 45日: 59日目（期限の14日後）3.1.2 の既定のまま 2028年の45日の証明書を迎えると、更新の予定日が期限の後になります。2027年の64日の時点では期限前に収まりますが、余裕は5日です。
この検証は計算だけで、Let’s Encrypt から実際に証明書を発行していません。ステージングでの発行や ARI の応答も試していないため、ARI がある場合の実際の更新日は確認していません。
監視のしきい値と、認可の再利用
「残り30日で警報」は毎回鳴る
証明書の残り日数を監視しているなら、しきい値も見直します。90日の証明書では、残り3分の1で更新するクライアントの更新日（残り30日）と「残り30日で警報」がほぼ重なっていました。64日の証明書では、certbot の既定の更新は残り21.3日なので、正常に動いていても、毎回の更新の前に約9日間、警報が出続けます。
鳴りっぱなしの警報は、本当の更新失敗を見落とす原因になります。編集部は、しきい値を有効期間の3分の1より小さくする（64日でも45日でも収まる、たとえば残り10日）か、残り日数ではなく「予定の更新日を過ぎても新しい証明書に替わっていない」ことを検知する方法を提案します。Let’s Encrypt も、更新されなかったときに知らせる監視を備えるよう勧めています。証明書の基本的な確かめ方は、SSLサーバー証明書の基礎ガイドにまとめています。
30日から10日になる認可の再利用
2027年2月10日には、ドメインの所有を確かめた結果を使い回せる期間（認可の再利用期間）も30日から10日になります。ブログは、クライアントを再利用に頼るよう特に作っていなければ、変更は不要としています。
影響がありそうなのは、DNS の TXT レコードを手作業で書き換えて所有を確かめ、その結果を使い回して別のサーバーの証明書を後日発行するような運用です。こうした運用では、10日を過ぎると確認をやり直すことになります。2028年には再利用期間が7時間になるため、手作業の確認をなくす方向で見直します（編集部の提案）。
ステージングで先に確かめる
ブログは、本番で切り替わる前にステージング環境で試すよう勧めています。ステージングは10月14日から64日の証明書を発行しています。ステージングの証明書はブラウザーに信頼されないため、検証用のホスト名や、別の作業ディレクトリで試します。
certbot の renew --dry-run はステージングを使いますが、変更履歴によれば、--dry-run では ARI を確かめません。また、更新の手順が通るかを確かめるもので、本番の証明書の更新日がいつになるかは分かりません。更新日は、上の表のクライアントの版と設定から確かめます。
確認した範囲
2026年10月21日に、letsencrypt/website リポジトリ（GitHub）のブログ原稿2件（2026年10月7日、2025年12月2日）とレート制限・プロファイル・ステージング・連携ガイドの文書、certbot・lego の変更履歴とソース（lego は v5 の移行ガイドも）、acme.sh の 3.0.7〜3.1.6 のタグと開発版のソース、certmagic のソースを確認しました（資料調査）。あわせて、自己署名の証明書を使い、certbot 5.8.0 と acme.sh 3.1.6 の更新の時期を決める関数を実行しました（実機検証）。Let’s Encrypt の本番・ステージングからの発行、ARI の応答、
--dry-run、各クライアントの OS パッケージの版、レンタルサーバーや CDN の対応は確認していません。公開前の10月21日には、letsencrypt.org のブログ2件と、ステージングで64日の証明書の発行を始めたというコミュニティの告知（10月14日）も確認しました。
自社や受託先のサーバーの証明書の更新設定の棚卸しや、監視の見直しは、開発・AI・自動化のご相談からお問い合わせください。
参考資料
- 64-Day Certificate Lifetimes Coming Feb 2027（Let’s Encrypt）
- Decreasing Certificate Lifetimes to 45 Days（Let’s Encrypt）
- 64-day certificates on the classic profile in staging（Let’s Encrypt Community）
- Shorter Certificate Lifetimes and Rate Limits（letsencrypt/website）
- Profiles（letsencrypt/website）
- Integration Guide（letsencrypt/website）
- Rate Limits（letsencrypt/website）
- certbot CHANGELOG（certbot/certbot）
- lego CHANGELOG（go-acme/lego）
- lego v5 の CLI 移行ガイド（go-acme/lego）
- lego v4 の cmd_renew.go（go-acme/lego）
- acme.sh 3.1.6 のソース（acmesh-official/acme.sh）
- certmagic（caddyserver/certmagic）
