Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — 最初の締め切りはもう過ぎている
SC-081v3が実際に定めた日程 — 原文の2つの表
投票結果が語ること — 2019年と2025年
Let's Encryptの実際の移行日 — 90→64→45
6日間の証明書とIP証明書 — すでに一般提供中
更新タイミングをハードコードするな — ACME ARI(RFC 9773)
まだ来ていないもの — DNS-PERSIST-01の現在地
では、何を準備すべきか
おわりに
参考資料

はじめに — 最初の締め切りはもう過ぎている

2026年3月15日、公開信頼(publicly-trusted)TLS証明書の最大有効期間が398日から200日に縮みました。この記事を書いている時点でちょうど4か月前の出来事です。年1回の手作業更新でしのいできたチームなら、今年の更新時にもう体感しているはずですし、まだ体感していないなら、いま使っている証明書が失効する日に体感することになります。

これは始まりに過ぎません。2025年4月にCA/B Forumで可決された投票SC-081v3は、2029年3月までに最大有効期間を47日まで下げる日程を確定させました。ところが、このテーマは要約記事ごとに日付が微妙に食い違って出回っています。そこで本稿は、投票文とTLS Baseline Requirements(BR)原文から段階別の日付を直接確認するところから始めます。そのうえで、Let's Encryptが公表した実際の移行日、そしてこの日程で生き残るための道具 — ACMEプロファイル、6日間の短期証明書、ARI(RFC 9773)、DNS-PERSIST-01 — を、現時点での実際の対応状況とあわせて整理します。

なお、証明書まわりのもう一つの大きな潮流であるポスト量子移行については、PQ証明書がまだ来ていない理由編で別途扱いました。両者は連動します — 有効期間が短いほどアルゴリズム切り替えも速まるからです。本稿は有効期間と自動化だけを扱います。

SC-081v3が実際に定めた日程 — 原文の2つの表

BR6.3.2節の最大有効期間の日程です。現行BR(v2.2.8、2026-06-16)にも投票当時の文言がそのまま載っていることを確認しました。

発行日基準	この日付まで	最大有効期間
—	2026-03-15	398日
2026-03-15以降	2027-03-15	200日
2027-03-15以降	2029-03-15	100日
2029-03-15以降	—	47日

各段階にはSHOULD NOTの上限が1日ずつ低く設定されています(397・199・99・46日)。BRは1日を86,400秒と定義し、これを1秒でも超えると1日多く数えると明記しています。そのため「上限ぴったりで発行してはならない(SHOULD NOT)」という文言も併記されています — 後述するLet's Encryptの45日という数字はここから来ています。

そして、同じ投票が改定した4.2.1節のドメイン・IP検証データ再利用の日程です。

発行日基準	この日付まで	検証データ再利用の上限
—	2026-03-15	398日
2026-03-15以降	2027-03-15	200日
2027-03-15以降	2029-03-15	100日
2029-03-15以降	—	10日

最後の行をもう一度見てください。有効期間は47日に「縮む」だけですが、ドメイン検証(DCV)の再利用は10日に「崩れます」。再利用期間が証明書の有効期間より短くなる、初めての区間です。つまり47日の証明書を更新するたびに、前回の検証を再利用できない可能性が高いということで、事実上「更新=毎回再検証」になります。ドメイン・IP以外の主体識別情報(OVの組織情報など)の再利用も、2026-03-15から825日から398日に縮みます。

この日程が何を狙っているかは投票文自身が語っています — 証明書は発行時点の事実を証明するスナップショットであり、時間が経つほど現実との乖離が広がること、そして失効(revocation)インフラがインターネット規模での拡張性・信頼性・利用者コストの面で機能していないため、有効期間そのものを短くして保護を「確実に」しようというものです。興味深い点が一つ — 自動化の普及は、投票文自身が「副次的な利益(ancillary benefit)」と書いています。自動化させるために有効期間を縮めるのではなく、有効期間を縮めたついでに自動化がついてくる、という順序です。

投票結果が語ること — 2019年と2025年

こうした試みは今回が初めてではありません。2019年のSC22投票は最大有効期間を1年に縮める案でしたが、CA側の投票で賛成11対反対20(棄権2)で否決されました。賛成率35%です。一方でブラウザ側(Apple、Cisco、Google、Microsoft、Mozilla、Opera、360)は7票全員が賛成でした。結果としては否決をよそに、BR改定履歴によれば2020-09-01付で最大398日が発効しています — ルートプログラム側がフォーラムの投票の外で方向を決めたということです。

2025年のSC-081v3はまったく違う構図です。AppleのClint Wilsonが発議し、Sectigo・Google Chrome・Mozillaが賛同者となり、2025-04-11に締め切られた投票では、CA側30票のうち賛成25、反対0、棄権5(Entrust、IdenTrust、Japan Registry Services、SECOM Trust Systems、TWCA)で可決されました。ブラウザ側は4票全員が賛成です。2019年に反対票を投じたGoDaddy・GlobalSign・D-TRUST・Izenpe・SwissSignは今回は賛成に転じ、2019年の反対派のうちSECOMとTWCAは棄権に回りました。反対0票という結果は業界がこの方向を受け入れたことを意味する一方で、ルートプログラムがどのみち強制できるという2020年の学習効果が反映された結果だと見るのが正直なところでしょう。

Let's Encryptの実際の移行日 — 90→64→45

BRの日程は上限であり、運用者が実際に体感するのは自分が使うCA自身の日程です。Let's Encryptは2025年12月に90日から45日に縮める計画を公表し、日付を確定させました。移行はACMEプロファイル単位で進みます。

2026-05-13 — tlsserverプロファイルが45日証明書に移行。オプトインのプロファイルなので、アーリーアダプターやテスト用です。これはすでに実施済みで、現在のプロファイル文書にも45日と反映されています。
2027-02-10 — 既定プロファイルのclassicが64日証明書+認証(authorization)再利用10日に移行。プロファイルを特に選ばなかった全ユーザーが対象です。
2028-02-16 — classicが45日証明書+認証再利用7時間に移行。

各変更は、本番の約1か月前にまずステージングへ配備されます。目を引く点が2つあります — 45は47より小さいこと(前述の86,400秒ルールと「上限で発行するな」というBR文言に対する余裕分)、そして2028-02-16という日付はBRが47日を強制する2029-03-15よりおよそ13か月早いということです。Let's EncryptはBRの締め切りより1年早く動いています。

現在の本番ディレクトリが公開する3つのプロファイルを、文書ベースで比較するとこうなります(2026-07-14更新版基準)。

属性	classic	tlsserver	shortlived
証明書の有効期間	90日	45日	160時間(6日強)
認証再利用	30日	7時間	7時間
チャレンジ完了期限	7日	1時間	1時間
注文の有効期間	7日	8時間	8時間
CN / KE-KU / SKID	含む	除外	除外
最大名前数	100	25	25
識別子タイプ	DNS	DNS	DNS、IP

tlsserverの認証再利用が7時間になっているのには理由があります — BRが発行8時間前以内のCAA再確認を要求しているため、再利用を7時間に設定すれば再確認自体が不要になるからです。更新量への懸念については、Let's Encryptが別途回答を出しています — 90日証明書を60日目に更新していたのが45日証明書を30日目に更新する形に変わると、更新リクエストは2倍になりますが、更新はレートリミットの対象外なので、新規ドメイン発行の上限(アカウントあたり1日300件)には影響しません。

6日間の証明書とIP証明書 — すでに一般提供中

日程の終着点(47日)よりさらに先を行く選択肢も、すでに存在します。Let's Encryptのshortlivedプロファイルは2026年1月15日付で一般提供されています。有効期間160時間 — BRが2026-03-15から「短期証明書(Short-lived Subscriber Certificate)」として認める上限7日(604,800秒)の範囲内です。短期証明書に分類されると、BR上の失効対応義務は必須ではなく任意になります。鍵が漏えいしても6日で失効期限を迎えて終わるので、信頼できない失効インフラに頼る代わりに、有効期間そのもので守るという発想です。ただし現時点でもこのプロファイルの証明書にはCRL URLがまだ含まれています — 削除する議論はboulder#7673で継続中です。

2025年7月に初めて発行され、shortlivedと同時にGAとなったIPアドレス証明書は、必ずshortlivedでなければなりません — IPはドメインより所有者が変わりやすいという理由でLet's Encryptが定めたポリシーです。certbot側の対応は今年3月に整理されました — プロファイル選択フラグ--preferred-profileはcertbot 4.0から、--ip-addressフラグは5.3から、webrootモードのIP対応は5.4からです。ただしnginx・apacheのインストーラープラグインはまだIP証明書に対応しておらず、デプロイフックで直接つなぐ必要があります。

Let's Encrypt自身が短期プロファイルについて「このプロファイルは万人向けではない」と書き、既定値にする計画はないと明言している点は、そのまま書き留めておく価値があります。160時間の証明書は、更新パイプラインが4日ほど止まっただけで失効に直結します。自動化を完全に信頼できるようになるまでは、選ばないのが正解です。

更新タイミングをハードコードするな — ACME ARI(RFC 9773)

「失効30日前に更新」といったハードコードは90日時代の遺物です。有効期間が90→64→45と動くたびに閾値を手直しし続ける代わりに、CAが更新タイミングを教えてくれる標準がすでにあります — 2025年6月に発行されたRFC 9773、ACME Renewal Information(ARI)です。2021年9月の最初のドラフトから標準化まで4年かかっており、Let's Encryptはドラフト段階だった2021年末からサーバー側(Boulder)で対応してきました。現在の本番ディレクトリにrenewalInfoエンドポイントが実際に立っていることも確認しました。

仕組みは単純です。クライアントが証明書のAKIとシリアル番号から識別子を作って問い合わせると、サーバーが推奨更新ウィンドウを返します。

GET {renewalInfo}/base64url(AKI keyIdentifier).base64url(Serial)

HTTP/1.1 200 OK
Retry-After: 21600

{
  "suggestedWindow": {
    "start": "2025-01-02T04:00:00Z",
    "end":   "2025-01-03T04:00:00Z"
  },
  "explanationURL": "https://acme.example.com/docs/ari"
}

クライアントはウィンドウ内の無作為な時点を選んで更新し、Retry-Afterの間隔でウィンドウが変わっていないか再確認します。更新の注文にはreplacesフィールドで直前の証明書を指定でき、これがCAのポリシーに応じて更新の識別やレートリミット処理に使われます。失効済みの証明書についてはこれ以上問い合わせない(MUST NOT)ことまでRFCが定めています。

このプロトコルの本当の価値は、平時ではなく事故時に発揮されます。CAが大量失効をしなければならない状況 — Let's Encryptは2022年1月、TLS-ALPN-01検証のバグでおよそ200万枚を失効させたことがあります — では、CAは更新ウィンドウを前倒しして応答し、ARIを見ているクライアントは失効が執行される前に入れ替えを終えられます。24時間・5日といった失効期限の中で人が介在するプロセスは、ほとんどのサイトには間に合いません。Shopifyの事例が教科書的です — 数百万ドメインを「失効30日前+0〜72時間のジッター」で運用していたところから、Ruby acme-clientジェムにARI対応を直接コントリビュートし、更新タイミングの判断をCAに委ねました(効果の記述はShopify自身の報告であり、定量的な数値は公開されていません)。

クライアント別の対応状況はこうです。すべて原文のチェンジログや文書で確認したものです。

certbot — 4.1.0(2025-06-10)からcertbot renewがARIを自動確認します。Let's Encrypt基準ではおおむね有効期間の3分の2の時点で更新になり、5.0.0からはRetry-Afterを実行間で保持します。
lego — CLIが明示的に無効化しない限りARIを確認し、replacesフィールドまで実装されています。
Caddy/CertMagic — READMEがRFC 9773の全面対応を明記しています。
cert-manager — 最も遅く合流しました。v1.21.0(2026-07-08)がACMEUseARIフィーチャーゲートの背後にARI対応を追加しました。2023年5月に開いた要望イシューが3年越しに動いた形ですが、まだ既定で有効ではありません。Kubernetesで証明書を運用しているなら — cert-manager実践編で扱ったあのスタックです — アップグレードとゲートの有効化を別途対応する必要があるということです。

ARIのないクライアントに残る次善策は、Let's Encryptの推奨どおり「有効期間の3分の2の時点で更新」を守ることです。45日証明書なら30日目です。固定60日周期のような設定は、45日時代にはただの障害です。

まだ来ていないもの — DNS-PERSIST-01の現在地

有効期間短縮の最後のピースは検証の自動化です。再利用期間が崩れると検証を頻繁に行う必要が出てきますが、いまのDNS-01は更新のたびに新しいトークンをTXTレコードとして書く必要があり、DNS APIの資格情報が発行パイプラインのあちこちを流れることになります。そこで出てきたのがDNS-PERSIST-01です — 一度設置すれば更新のたびに書き換える必要のない、CAとACMEアカウントを指名する常設の認可レコードです。

_validation-persist.example.com. IN TXT (
  "letsencrypt.org;"
  " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"
)

policy=wildcardを付ければワイルドカード・サブドメインまでカバーでき、常設の認可が不安ならpersistUntilで失効日を設定できます。制度面の整備は完了しています — CA/B Forumの投票SC-088v3が2025年10月に満場一致で可決され、現行BRの3.2.2.4.22節("DNS TXT Record with Persistent Value")として組み込まれ、IPアドレス用の_ip-validation-persist変種も併せて収録されました。

ですが、実物はまだです。2月の発表時点の目標は「ステージングは第1四半期末、本番は第2四半期」でしたが、現時点の実際の状態はこうです — ステージングにはドラフト実装が上がっており(4月末のdraft-01反映でaccounturiがチャレンジオブジェクトの必須フィールドになりました)、本番は開放されていません。Let's Encryptのエンジニアが6月25日にコミュニティフォーラムに残した回答が現状を正確にまとめています — ドラフトのイシュー#64(レコードにクライアント側で計算した情報を含めるかどうか)が解決するまでは配備しない、というものです。5月には「IETFの合意が遅れれば第3四半期にずれ込む可能性がある」という回答もありました。公式のチャレンジタイプ文書にもまだ掲載されていません。要するに、いまDNS-PERSIST-01を前提にアーキテクチャを組んではいけません。できるのはステージングでの実験までです。

設計上のトレードオフについても、発表文自身が正直に指摘しています — DNS書き込みの資格情報をパイプラインから排除する代わりに、常設の認可がACMEアカウントに紐づくため、アカウントキーが新たな最重要シークレットになります。アカウントキーの保管とローテーション体制を整えないまま使えば、リスクを移し替えただけになります。

では、何を準備すべきか

日程表を運用の言葉に翻訳するとこうなります。

まずインベントリから。手動で更新している証明書 — 年1回のカレンダーリマインダー、四半期ごとのチケット、機器コンソールへのファイルアップロード — を洗い出すのが最初の仕事です。200日の時代なら年2回の手作業でしのげますが、100日なら年4回、47日ならほぼ毎月です。手作業の問題は回数そのものではなく、回数が増えるほど1回あたりの取りこぼし確率が掛け合わさっていく点にあります。
クライアントのバージョンとARI。certbot 4.1未満、ARIのない自前スクリプト、固定周期のcronがあるなら、今すぐアップグレードしてください。更新タイミングの判断をCAに委ねることが、この日程全体に対する最も安い保険です。
監視は更新の成功ではなく、失効間近であることを見るべきです。更新パイプラインが静かに死んでいるケースは、うるさく失敗するケースより危険で、有効期間が短くなるほど「静かに死んだまま持ちこたえられる期間」も短くなります。45日証明書では、2週間の休暇シーズンの障害がそのまま失効事故になります。
検証経路の自動化。2027-02-10からLet's Encryptの既定プロファイルの認証再利用が10日に縮み、2028年には7時間になります。更新だけが自動で、検証(特にDNS-01のTXT更新)が半自動な構成は、ここで破綻します。DNS-PERSIST-01が本番に来るまでは、DNS資格情報の管理を引き受けるか、HTTP-01/TLS-ALPN-01に移るかの判断が必要です。
短期プロファイルは最後に。失効の心配を消してくれる6日証明書は魅力的ですが、その前にまず45日で無事故のまま数四半期を過ごすのが順序です。

逆に、この日程が強制しないことも明確にしておきます。BRの適用範囲は「インターネットからアクセス可能なサーバー認証用」の公開信頼証明書です。プライベートCAで運用する内部PKI、閉域網の機器、mTLS用の内部証明書は、この日程とは無関係に自分たちで有効期間を決められます。公開信頼が必ずしも必要ない内部システムが47日周期に耐えられないなら、自動化の代わりにプライベートPKIへ移すのも一つの正解です — この判断自体は無停止更新プレイブックで扱った運用原則の延長線上にあります。

おわりに

まとめます。日付は確定しています — 200日(すでに施行済み)、2027-03-15から100日、2029-03-15から47日、そして同じ日に検証再利用10日。Let's Encryptはそこに自社の日程を上乗せしています — 2027-02-10に既定64日、2028-02-16に既定45日。道具もほとんど揃っています — ARIはRFCになり主要クライアントに入り、6日証明書はGAです。まだ来ていないのはDNS-PERSIST-01の本番投入だけで、それすら制度とステージングは終わっています。

つまり残る変数は標準でもCAでもなく、それぞれの運用です。47日時代の失敗モードは「更新を忘れた」ではなく「自動化が静かに死んでいた」です。いまやるべきことは、カレンダーに更新リマインダーをもっと細かく打ち込むことではなく、リマインダーなしでも回るパイプラインと、そのパイプラインが死んだときに鳴る警報を作ることです。