Let’s Encrypt における TLS 証明書の有効期間の変更:2027年2月より有効期間を 90日から 64日に短縮

Let’s Encrypt Cuts TLS Certificate Lifetimes From 90 to 64 Days Starting February 2027

2026/10/09 CyberSecurityNews — Let’s Encrypt は、TLS 証明書の有効期間のデフォルトを 90日から 64日に短縮する。この 2027年2月10日からの変更に合わせて、Web サイトの運営者は、証明書の自動更新設定が新しい有効期間に対応しているか確認する必要がある。この変更は、同日以降に発行または更新される証明書に適用される。その一方で、利用者は引き続き、有効期間が 45日または約 6日の、より短い証明書プロファイルの選択も可能である。

Let’s Encrypt 証明書の有効期間

10月7日の Let’s Encrypt の発表において、非営利の認証局である同組織は、今回の変更スケジュールを正式に通知した。既存の証明書は、通常の有効期限まで有効であり、移行に伴って失効させることはない。最後に発行される有効期間 90 日の証明書は、2027年5月11日に期限切れとなる見込みである。

証明書の有効期間を短縮することで、その証明書が信頼され続ける期間を制限し、秘密鍵が窃取された場合や証明書が誤って発行された場合に、その被害を低減する。一方、証明書の更新システムには、これまで以上の信頼性が求められる。特に、固定スケジュールや手動の手順に依存している運用チームにとって重要な変更となる。

今回の変更は、公開 TLS 証明書の有効期間を短縮する業界全体の流れに準じたものになる。以前にも Cybersecurity News は、CA/Browser Forum が証明書の最大有効期間が 47 日に短縮される計画について報じていた。

Let’s Encrypt は、それよりも早いペースで短縮を進めている。以前に公開した証明書の有効期間に関するロードマップでは、2028年2月16日にデフォルトのプロファイルを 45 日に変更する予定が示されている。

2026年10月14日から Let’s Encrypt は、ステージング環境で有効期間 64 日の証明書の発行を開始する。管理者は、このテスト環境を利用し、本番環境での変更に先立って証明書の更新動作を確認できる。

ステージング環境で発行された証明書はブラウザから信頼されないため、本番 Web サイトの証明書と置き換えるべきではない。

証明書の自動運用で重要になるのが、ACME Renewal Information (ARI) である。ACME とは、証明書の発行要求/更新を自動化するためのプロトコルである。

ARI を使用すると、Let’s Encrypt から対応クライアントへ向けた証明書の更新時期の通知が可能になる。これにより、固定されたスケジュールに依存することなく、短い有効期間に対応できる。管理者に求められるのは、使用している ACME クライアントのドキュメントを確認し、ARI に対応しているかどうかを調べることだ。ARI を利用できない場合には、証明書の有効期間の約 3 分の 2 が経過した時点で更新することが推奨される。

有効期間 64 日の証明書では、従来の 60 日目まで待つのではなく、約 43 日目に更新することになる。また、認証局が推奨するのは、cron ジョブ/ラッパースクリプト/ランブックを調査し、83/80/60 などの値がハードコードされていないことの確認である。

これらの数値は、有効期間 90 日の証明書を前提とした更新ルールが残っていることを示している可能性がある。こうしたルールを、今のうちに更新することで、2028年に予定されているデフォルトの有効期間 45 日への短縮にも備えられる。

Let’s Encrypt は証明書の有効期間に加え、認可の再利用期間も 30 日から 10 日に短縮する。これは、過去に実施したドメインの管理権限の確認結果を、再検証せずに別の証明書発行要求で利用できる期間を指す。

この再利用の期間は、2028年には 7 時間に短縮される。Let’s Encrypt によると、この変更は今後の検証ルールへの対応を目的としており、過去の検証データに対して Certificate Authority Authorization (CAA) を個別に再確認する必要をなくすものだという。

ACME の設定が、認可の再利用に特に依存していない限り、大半の利用者は設定を変更する必要がない。Let’s Encrypt のレート制限に関するガイダンスによると、証明書の有効期間が短縮されても、レート制限は変更されない。ACME エンドポイント/証明書の発行チェーンも変更されない。

運用担当者に求められるのは、証明書の更新処理だけでなく、証明書のデプロイ/サービスのリロードを含むワークフロー全体をテストすることである。多数の Web サイトを管理するチームは、更新された証明書がすべてのサーバに配布されていることも確認する必要がある。

さらに、各サービスのリロード後には、実際にユーザーへ提示されている証明書を、監視システムで確認することが重要となる。証明書の更新失敗を通知するアラートを設定すれば、有効期限切れになる前に問題を発見できる可能性が高まる。

更新間隔が短くなる中、実務上の最優先事項となるのは、証明書を常に最新の状態に保つための信頼性の高い自動化である。