Let’s Encryptの証明書が90日から64日に短縮へ　従来の自動更新では期限切れまでわずか4日に

Let’s Encryptは10月7日、TLS証明書の標準有効期間を現在の90日から64日へ短縮する計画について、2027年2月10日の移行日程を改めて告知した。2028年にはさらに45日へ短縮する計画で、今回は2026年10月14日からテスト環境を64日証明書に切り替えることも明らかにした。証明書の自動更新を設定していても、発行から60日後に更新する従来の固定設定を使い続けると、64日証明書では有効期限までわずか4日しか残らなくなる。移行までに確認すべきなのは、証明書をいつ更新するかという設定だけではない。取得した新しい証明書が、実際に利用者の接続先へ反映されるまでの仕組みも点検する必要がある。

2027年2月に64日へ短縮、業界全体の上限とは異なる日程

今回の64日化は、特別なプロファイルを指定せずに発行する標準の証明書が対象となる。2027年2月10日以降に新規発行・更新される証明書から適用され、すでに発行済みの証明書が一斉に失効するわけではない。最後に発行される90日証明書は、同年5月11日までに有効期限を迎える見込みだ。すでに45日や約6日の短期証明書プロファイルを利用している場合は、引き続きその設定が適用される。

証明書の有効期間を短縮する方針と、本番環境への移行日程は2025年12月に発表されていた。10月7日の発表は新たな方針変更ではなく、移行が近づいたことを改めて知らせ、運用担当者に準備を促すものだ。

2025年12月に発表された計画と今回の告知を整理すると、今後の主な日程は次のようになる。

日付	Let’s Encryptの変更内容
2026年10月14日	テスト用のステージング環境で64日証明書へ移行
2027年2月10日	標準の証明書を64日に短縮。ドメイン認証結果の再利用期間も10日へ短縮
2028年2月16日	標準の証明書を45日に短縮。ドメイン認証結果の再利用期間を7時間へ短縮

Let’s Encryptは、業界全体の規定よりも早い段階で、証明書の有効期間を短縮する方針を取っている。

CA/Browser Forumの要件では、公開信頼TLSサーバー証明書の最大有効期間について、2026年3月15日から200日、2027年3月15日から100日、2029年3月15日から47日と段階的に短縮することが定められている。

これは、ブラウザなどから公的に信頼される認証局が発行するTLSサーバー証明書に適用される上限だ。

したがって、2027年にすべての認証局が64日証明書へ移行するわけではない。また、CA/Browser Forumが定める47日とLet’s Encryptが予定する45日も、業界全体の上限と個別の認証局が採用する有効期間という違いがある。

証明書の更新計画を立てる際は、利用している認証局が実際にどのような日程で変更するのかを確認する必要がある。

発行60日後の固定更新では、有効期限までわずか4日

従来の90日証明書を発行から60日後に更新する運用なら、有効期限まで30日の余裕がある。しかし、同じ設定を64日証明書に適用すると、更新に失敗した場合の対応時間が大幅に短くなる。

発行から60日後に更新する固定設定では、64日証明書の有効期限まで4日しか残らない。一方、有効期間の3分の2が経過した時点で更新すれば、約21.3日の余裕を確保できる。

Let’s Encryptは、証明書の有効期間の約3分の2が経過した時点で更新する方法を目安として示している。

有効期間をL日とすると、この方式では発行から2L/3日後に更新し、有効期限までL/3日が残る。一方、発行から60日後に更新する固定方式では、残りの日数はL−60日となる。

証明書の有効期間	3分の2経過時の更新タイミング	有効期限までの残り日数	発行60日後に更新する場合
90日	発行60日後	30日	30日残る
64日	発行から約42.7日後	約21.3日	4日残る
45日	発行30日後	15日	期限を15日超過

公表された有効期間を基に、発行時点を起点として計算した目安。小数は第1位に丸めている。早期失効や配備の遅延は考慮しておらず、実際の更新日時やサービスの稼働を保証するものではない。

64日証明書でも、発行から60日後の更新が必ず失敗するわけではない。問題は、失敗した場合に対応できる時間が極端に短くなることだ。

例えば、ドメインの所有権確認に失敗したり、更新処理が何らかの理由で停止したりした場合、従来は30日あった復旧の猶予が4日しかなくなる。以前と同じ感覚で対応していると、復旧が間に合わず、証明書の期限切れを引き起こす可能性がある。

さらに2028年の45日化まで考えると、60日という固定値を単に別の数字へ変更するだけでは、根本的な解決にならない。

証明書の有効期間に応じて更新時期を自動的に判断する仕組みへ移行することが望ましい。

ARIを使えば、認証局が推奨するタイミングで更新できる

Let’s Encryptが推奨しているのが、ACME Renewal Information（ARI）と呼ばれる仕組みだ。

ACMEは、証明書の取得や更新などを自動化するためのプロトコルで、ARIはその拡張機能に当たる。RFC 9773では、認証局が証明書の更新を推奨する期間の開始時刻と終了時刻を返し、クライアントがその情報に基づいて実際の更新時刻を決める仕組みが定められている。証明書の有効期間から更新時期を機械的に計算する方式と比べ、ARIには認証局側の状況を反映できる利点がある。

例えば、更新要求が特定の時間帯に集中しないよう分散できるほか、証明書を失効させる必要が生じた場合に、通常より早い更新を促すこともできる。ただし、一度取得した推奨更新期間を保存しておくだけでは不十分だ。クライアントは認証局から示される更新期間に変更がないかを継続的に確認し、更新に失敗した場合には適切な間隔で再試行する必要がある。

ARIを導入した企業の一つがShopifyだ。同社のインフラエンジニアであるNick Silverman氏は、2026年3月の寄稿で、従来の証明書更新方式とARI導入後の違いを説明している。

Shopifyでは以前、90日証明書の有効期限が切れる30日前を基準とし、そこから0〜72時間のランダムな遅延を加えて更新していた。この方式でも自社の更新処理を時間的に分散させることはできたが、認証局全体の負荷状況や、緊急に証明書を失効させる必要が生じた場合の対応には限界があったという。ARIの導入後は、認証局が推奨する更新期間を定期的に取得し、その情報に基づいて更新時期を決める方式へ変更した。

この事例は、証明書の更新処理を自動化するだけでなく、更新のタイミングを認証局と協調して決めることの重要性を示している。ただし、紹介されている改善効果はShopify自身による運用報告であり、障害率が何％低下したといった独立した測定結果ではない。また、証明書の有効期間が短くなって更新回数が増えることと、認証局の発行制限に達することは別の問題だ。

Let’s Encryptは、90日から45日への移行によって1日当たりの更新要求が倍増すると想定する一方、通常の証明書更新についてはレート制限を引き上げる必要はないと説明している。

現行のレート制限に関する文書では、ARIの条件を満たす更新は、すべてのレート制限の対象外になるとされている。

一方、同じドメイン名の組み合わせなどから更新と判断する従来の非ARI方式では、一部の制限が引き続き適用される。

ARIによる制限免除を受けるには、新しい証明書の発行要求で置き換え対象の証明書を明示し、少なくとも一つのドメイン名を共有していることや、元の証明書がARIを利用してすでに置き換えられていないことなど、所定の条件を満たす必要がある。

証明書の短期化に備える際は、使用中のACMEクライアントがARIに対応しているかだけでなく、実際の更新処理でARIが使われているかまで確認したい。

証明書の有効期間とは別に、ドメイン認証結果の再利用期間も短縮

2028年には、ドメイン認証結果を再利用できる期間も7時間へ短縮される。

これはTLS証明書そのものの有効期間とは異なる。

認証局は証明書を発行する前に、申請者が対象のドメインを管理していることを確認する。この確認結果は、一定の期間内であれば、その後の証明書発行にも再利用できる。

Let’s Encryptの標準プロファイルでは、現在30日となっている再利用期間が、2027年には10日、2028年には7時間へ短縮される。

つまり、2028年に7時間へ短縮されるのはドメイン認証結果の再利用期間であり、45日証明書を7時間ごとに更新する必要があるという意味ではない。

再利用期間が短くなることで、過去に確認したドメインの管理権限を、長期間にわたって使い回すことが難しくなる。

ドメイン認証まで自動化されていれば、通常は追加の手作業を必要としない。しかし、以前の認証結果を長期間再利用できることを前提にした独自のACMEクライアントなどは、動作を見直す必要がある。

Let’s Encryptは、再利用期間を7時間へ短縮する目的の一つとして、CAAレコードに関する確認の適切な実施も挙げている。

CAAレコードは、特定のドメインについて、どの認証局に証明書の発行を許可するかをDNSで指定する仕組みだ。ドメイン認証結果の再利用期間を短くすることで、古い検証結果に依存する期間を減らし、発行時に必要な確認をより新しい状態に基づいて行えるようにする。

一方、証明書自体の有効期間を短縮する主な目的は、誤発行された証明書や、秘密鍵の漏えいによって悪用される証明書が、長期間使われ続けるリスクを減らすことにある。

Let’s Encryptは証明書の有効期間に関する説明で、こうした被害の抑制と、成熟した自動化への移行を短期化の理由として挙げている。

証明書の有効期間が短くなれば、問題のある証明書が自然に期限切れを迎えるまでの時間も短縮される。

ただし、攻撃者が漏えいした秘密鍵を保持し続けていたり、不正に証明書を発行できる状態が解消されていなかったりすれば、単に有効期間を短くするだけでは問題は解決しない。

秘密鍵の保護や交換、必要に応じた証明書の失効処理は、引き続き重要になる。

なお、Let’s Encryptは2025年8月に、証明書の失効状態を問い合わせるOCSPサービスを終了しているが、証明書失効リスト（CRL）による失効情報の提供は継続している。

証明書が64日や45日になったからといって、失効処理そのものが不要になるわけではない。

証明書の取得だけでなく、サーバーへの反映と外部監視も点検が必要

証明書の自動更新ツールとして広く利用されているCertbotでは、更新処理を起動する頻度と、実際に証明書を更新する頻度は異なる。

Certbotの公式ガイドによると、バージョン4.0.0以降では通常、証明書の残りの有効期間が全体の3分の1未満になった場合に更新対象と判断する。

そのため、更新確認を毎日実行していても、毎回新しい証明書が発行されるわけではない。

一方、古いバージョンでは、有効期限まで30日を切った場合に更新する固定的な判定方式が使われていた。現在導入しているCertbotのバージョンや、独自のスクリプトで更新条件を変更していないかも確認する必要がある。

証明書の発行後にも注意すべき点がある。

certbot renewが正常終了した場合でも、それは必ずしも新しい証明書が発行されたことを意味しない。更新が必要な証明書を更新できた場合だけでなく、更新対象がなく、何も変更しなかった場合も正常終了として扱われる。

新しい証明書が発行された場合にだけ配備処理を実行したり、Webサーバーへ設定の再読み込みを指示したりするには、deploy-hookを利用する方法がある。

また、証明書の取得に成功していても、実際のサービスで新しい証明書が使われているとは限らない。

例えば、証明書ファイル自体は更新されていても、ロードバランサーやWebサーバーが古い証明書を読み込んだままになっていれば、利用者の接続時に期限切れの証明書が提示される可能性がある。

そのため、証明書の発行とサーバーへの反映は、それぞれ確認する必要がある。

最終的には外部からTLS接続を行い、実際に提示される証明書の有効期限が更新されているかを検証することが重要だ。

発行処理のログだけを監視していては、証明書の取得後に配備が失敗したケースを検知できない。

2026年10月14日に予定されているステージング環境の切り替えは、64日証明書の取得や更新判定が正しく動作するかを事前に試す機会になる。

ただし、ステージング環境で発行される証明書は、通常のブラウザから信頼されるものではなく、テスト専用の証明書だ。

また、Certbotのdry-runでは、通常はdeploy-hookが実行されない。したがって、更新テストに成功したからといって、実際のサーバーへの配備や設定の再読み込みまで確認できたことにはならない。

新しい証明書を配備先へ反映する処理については、別途検証する必要がある。

Let’s Encryptは今回の発表で、証明書の更新に失敗した場合に通知を受け取れる仕組みを導入することも推奨している。

以前提供していた証明書の有効期限を知らせるメールについては、2025年に終了が告知されている。認証局からの通知メールに頼って期限切れを防ぐ運用も、見直す必要がある。

2027年2月の64日化までに、ARIまたは証明書の有効期間に応じた自動更新を利用し、更新失敗の検知からサーバーへの反映、実際に提示される証明書の有効期限の監視まで、一連の仕組みを整えておきたい。

証明書を正常に取得できたかどうかだけでなく、利用者が接続するサーバーで新しい証明書が実際に使われていることまで確認できる運用が重要になる。

そこまで自動化と監視を整備しておけば、2028年に予定される45日へのさらなる短縮にも、同じ仕組みを活用して対応しやすくなる。