Let's Encrypt は 2026 年 10 月 7 日、2027 年 2 月 10 日から、すべての利用者の証明書を既定で有効期間 64 日に切り替えると発表しました。さらに短い 45 日または 6 日を自分で選んでいる場合は除きます。この日以降に発行・更新される証明書はすべて 64 日となり、同団体の見込みでは最後の 90 日証明書は 2027 年 5 月 11 日に期限を迎えます。この切り替えに伴って既存の証明書が失効されることはありません。

スケジュール

  • 2026 年 10 月 14 日：ステージング環境で 64 日証明書の発行を開始。まずステージングで試すよう推奨されています。
  • 2027 年 2 月 10 日：既定の classic プロファイルが 64 日証明書になり、完了したドメイン検証の再利用期間が 30 日から 10 日に短縮されます。
  • 2028 年 2 月 16 日：classic プロファイルはさらに 45 日証明書となり、検証の再利用期間は 7 時間になります。

これは CA/ブラウザフォーラムのベースライン要件に基づく業界全体の変更で、Let's Encrypt だけの判断ではありません。6 日証明書の記事では、より短い証明書を自分で選ぶ方法を紹介しました。今回の変更は、既定の設定を使っているすべての人に影響します。

対応が必要なのは誰か

  • ARI に対応したクライアント：Let's Encrypt の言葉では「should be all set」、つまり準備は整っています。ARI（ACME Renewal Information）は、CA がクライアントに更新のタイミングを伝える仕組みです。お使いのクライアントが対応しているかはドキュメントで確認してください。
  • 更新タイミングを固定している場合：「期限の X 日前に更新」や固定の cron 間隔などです。Let's Encrypt は証明書の有効期間のおよそ ⅔ の時点で更新するよう改めることを推奨し、見つけ方も示しています。cron ジョブ、ラッパースクリプト、運用手順書で 83、80、60 といったよくある固定値を grep してください。
  • 検証の再利用に依存している場合：クライアントを検証の再利用を前提に設計していない限り、変更は不要です。
  • レート制限は変わらず、ACME のエンドポイントと証明書チェーンも変わりません。

証明書が短くなるほど、更新の失敗はすぐに問題になります。Let's Encrypt はこの機会にリロードやデプロイを自動化し、更新失敗のアラートを追加することも勧めています。Nginx 側の設定は Let's Encrypt の SSL 証明書の設定を、DNS 検証（dns-01）でワイルドカード証明書を発行している場合の DNS 側の設定はドメインを VPS に向けるを参照してください。

新しい選択肢：Cloudflare が公開 CA になる計画

9 月 29 日、Cloudflare は公開認証局になる意向を表明しました。Chrome、Apple、Microsoft、Mozilla のルートプログラムに申請済みで、2012 年から広く信頼されている GlobalSign のルート証明書を取得する契約も結んでいます。まだ証明書は発行していないと明言しています。公表されたルールのうち 2 点が今回の変更と直接関係します。発行は ACME が前提で、他の無料 CA からの乗り換えはディレクトリ URL を変えるだけで済むこと、そして ARI に対応したクライアントにしか発行しないことです。どの CA を使うにしても、更新のタイミングを ARI に任せるのが進むべき方向です。証明書発行のもう一つの防御線は CAA レコードで、ccTLD レジストリ乗っ取りの記事で取り上げています。