要約

  • CA/Browser Forumの現行期間では公開TLS証明書の上限は200日で、2027年3月に100日、2029年3月に47日へ短縮される。
  • 成功とは「発行済み」ではなく、対象となる全終端が承認済みの新証明書を提示し、障害を直せる残存時間が確認された状態である。

中央の証明書サービスがACME注文を完了し、画面が緑になったとする。多くのロードバランサーは更新されたが、地域APIゲートウェイとメール終端が旧証明書を出し続けている。発行は成功したが、更新は完了していない。認証局の記録と実際の配備状態には別の時計がある。

有効期間の短縮はこの差を大きな問題にする。現行のCA/Browser Forum基準では、2026年3月15日から2027年3月15日より前に発行される加入者証明書は最長200日である。その後100日となり、2029年から47日になる。ドメイン名やIPアドレスの検証データを再利用できる期間も短くなり、2029年には10日となる。

これは最大値であり、全認証局が上限まで発行する義務ではない。Let’s Encryptは2026年5月、希望者向けに45日間のtlsserverプロファイルを開始した。後年には標準プロファイルも短くする計画で、利用者に自動化の適合確認を求めている。

短期化は処理全体を制御ループに変える

一回の更新には、把握された識別子、利用可能なドメイン制御検証、管理下にあるACMEアカウント、注文可能なクライアント、秘密情報の配布経路、再読込できるサービス、結果を外側から確かめる監視が必要になる。

RFC 8555は多くを自動化する一方、権限の所在も明らかにする。ACMEクライアントはアカウント鍵で要求に署名する。その範囲では、鍵の保有者が発行、失効、アカウント変更、鍵更新を実行し得る。これは単なるcronの付属情報ではなく、保管責任を伴う運用権限である。

また、認証局は配備先の全体を知らない。新しい証明書が秘密ストアに入っても、古いプロセスが前の証明書を提示し続けることがある。リバースプロキシ、Ingress、CDN、装置、メールサービスの一部が配布から漏れるかもしれない。そもそも忘れられた終端が台帳にない場合もある。

注文、保管、配備、再読込、外部確認は別々の状態として記録しなければならない。

ARIは時刻を調整するが、完了を証明しない

RFC 9773のACME Renewal Informationでは、認証局が推奨更新期間を示し、クライアントがどの証明書を置き換える注文かを伝えられる。通常時の負荷を分散し、例外時には更新を前倒しできる。

固定の「期限30日前」という規則は、45日証明書では意味が変わる。ARIなら、クライアントに現在の製品期間を埋め込まずに時刻を動かせる。

ただしARIは、インストール、提示中のチェーン、全エッジの更新、外部ハンドシェイク成功を証明しない。置換の開始を協調する仕組みであり、完了は依然として観測された配備状態である。

Let’s Encryptの統合ガイドは、少なくとも1日2回ARIを確認し、残存期間による予備基準を保ち、大規模な証明書群を小分けし、実行時刻を分散するよう勧める。2026年のShopify事例も、固定しきい値ではなく更新期間を保存して繰り返し参照する構成を説明する。これは出典の明確な事例であり、全利用者の実態を示すものではない。

不足するのは復旧のための時間である

短い証明書は古い資格情報が受け入れられる時間を減らす。同時に、検証失敗、アカウント鍵の問題、クライアント制限、秘密同期、再読込、未把握終端を見つけて直す時間も減らす。

重要な指標は更新回数ではなく、利用可能な復旧余裕である。最初の失敗から期限切れまでに、検知、担当決定、修正、再配備、独立検証を引いて何時間残るかを測る。

早期に小さな群で更新し、再試行を制限し、外部証明を持つ運用なら短期化を吸収できる。全量を同時更新し、注文成功だけを信じる運用は、予定作業を同期障害へ変える。

公開資料から個別組織の終端台帳、失敗率、クライアント版、鍵管理、事故履歴は分からない。短い証明書が失効や鍵漏えいを不要にする証拠もない。確実に言えるのは、前提が早く古くなるほど、置換を示す証拠の価値が高まることだ。

情報源