Let’s Encryptが証明書寿命を「90日→45日」へ短縮。インフラ運用は何を直すべきか（2028までのロードマップ付き）

Let’s Encryptが「発行する証明書の有効期間を段階的に短縮し、最終的に45日へ移行する」方針を公開しました。加えて、ドメイン認証（DV）後に“同じ認証結果を使い回せる期間”（authorization reuse period）も、現在の30日から2028年に7時間まで短縮されます。

インフラ担当としての結論はシンプルで、**「証明書更新の完全自動化 + 監視」**が“必須要件”になります。

---

何が変わるのか（運用的に効くポイント）

1) 証明書の有効期間が短くなる（90日→45日）

短寿命化は業界全体の流れで、侵害時の影響範囲を狭め、失効（revocation）周りの効率も上げる狙いがあります。

運用目線の影響

• 更新頻度が上がる → 失敗した時に“気づけない”と即障害化
• 「たまたま動いてた」系（手動・属人・場当たり）の更新運用は崩壊する

2) authorization reuse period が 30日→7時間（2028）

これが地味に効きます。
「前回のドメイン認証結果を使って再発行できる猶予」が縮むことで、更新時にドメイン認証（HTTP-01 / TLS-ALPN-01 / DNS-01）を“より頻繁に・確実に”通す必要が出てきます。

---

タイムライン（Let’s Encrypt側の段階的切替）

Let’s Encryptは、影響を小さくするために複数ステージで移行します（ACME Profileで切替制御が可能）。

• 2026/05/13：tlsserver profile（opt-in）が 45日証明書へ（早期導入・検証向け）
• 2027/02/10：デフォルトの classic profile が 64日（authorization reuse 10日）へ
• 2028/02/16：classic profile が 45日（authorization reuse 7時間）へ

※上記は「その日以降に発行される新規/更新分」から適用。多くの環境では次回更新タイミングで体感します。

---

インフラ担当の「今やること」チェックリスト

✅ 1) “更新タイミングのロジック”を見直す（固定60日更新はアウト）

45日証明書で「60日ごとに更新」みたいな固定スケジュールは破綻します。
推奨挙動は 証明書寿命の2/3程度で更新（例：45日なら30日程度で更新）。

チェック例

• cron / systemd timer / Kubernetes CronJob が 週2〜毎日程度で走っているか
• クライアントが「期限N日前で更新」など、寿命に追従する設計になっているか

✅ 2) ARI（ACME Renewal Information）が使えるなら最優先

Let’s Encryptは更新の“適切なタイミング”をクライアントに伝える仕組み ARI の利用を推奨しています。
使っているACMEクライアントのARI対応状況を確認し、対応しているなら有効化を検討します（設定方法はクライアント依存）。

✅ 3) 更新失敗が“即アラート”になる監視を入れる

短寿命化でいちばん怖いのは「更新が落ちてるのに気づかない」こと。

最低限やりたい監視（どれか1つでも）

• LB/Ingressの証明書期限（残日数）を監視して閾値で通知
• /etc/letsencrypt/live/.../fullchain.pem のexpireを定期チェック
• 外形監視でTLS期限をチェック（SaaSでも自前でも）

✅ 4) 「ドメイン認証の経路」を監査する（2028は“7時間”）

authorization reuseが7時間になると、更新時の検証がより“本番依存”になります。

• HTTP-01：更新時にHTTPが確実に到達できるか（WAF、強制リダイレクト、メンテ表示、経路変更）
• TLS-ALPN-01：更新時に443のALPNハンドシェイクが通るか（LB終端/パススルー構成差）
• DNS-01：更新時にDNS更新の自動化が耐えられるか（API権限、レート、TTL、伝播遅延）

---

朗報：DNS-PERSIST-01（DNSのTXTを毎回変えない）を標準化中

Let’s Encryptは、新しい検証方式 DNS-PERSIST-01 の標準化を進めており、2026年に利用可能見込みとしています。

インフラ観点のメリット

• 「ACMEクライアントにDNS API権限を持たせたくない」問題の緩和
• 秘匿性の高いインフラ（DNS/プロダクション）へのライブアクセス要件を下げられる
• “設定一回で更新だけ勝手に回る”運用に寄せやすい

---

現場あるある別：見直しポイント

Nginx/Apache + certbot

• systemd timer（certbot renew）が有効か
• 更新後の reload フックが確実か（証明書だけ更新されて、プロセスが古いままの事故）

Kubernetes（cert-manager）

• renewBefore が短寿命化に対して適切か（デフォルトでも動くが、監視は必須）
• Ingress/LB終端点ごとに「期限監視」があるか（Secret更新だけでは安心しない）

CDN / マネージドLB

• サービス側に更新が吸収される場合でも、カスタム証明書/BYOCは要確認
• “更新できてる前提”のブラックボックスは、外形で期限監視しておくと安心

---

まとめ

• 45日証明書は「来る」：2026→2028で段階移行
• 自動更新の品質（頻度・リトライ・失敗検知）がSLOに直結
• ARI対応クライアントは積極導入、非対応なら更新スケジュールを短く
• 2028の authorization reuse 7時間を見据えて、ドメイン認証経路を堅牢化
• DNS-PERSIST-01 が普及すれば運用はかなり楽になる可能性