証明書の更新は、自動で回っていれば存在すら忘れている作業だ。だが期限を管理表に書いて、年に一度手で入れ替えている現場もまだ珍しくない。その前提が、これから数年かけて成り立たなくなる。

Let’s Encryptが公開している証明書プロファイルの解説ページが9月8日付で更新され、いま選べる発行方式と、それぞれの有効期間や制約が改めて整理された。同じページには業界共通の上限値も書かれている。公開されているTLS証明書の有効期間は現在200日が上限で、2027年3月15日以降に発行するものは100日、2029年3月15日以降は47日までしか持てない。

上限が下がる日程はすでに決まっている

この段取りを決めたのは、認証局とブラウザベンダーが参加するCA/Browser Forumで2025年4月に可決された議案である。告知によると、公開TLS証明書の最大有効期間を398日から47日へ、2026年3月から2029年3月にかけて段階的に引き下げる内容になっている。認証局側は30票のうち25社が賛成で反対はゼロ、ブラウザ側はApple、Google、Microsoft、Mozillaの4社すべてが賛成した。特定の一社の方針ではなく、証明書を発行する側と検証する側の双方が合意した既定路線ということになる。

縮むのは証明書の寿命だけではない。ドメインの管理権を確認した結果を使い回せる期間、いわゆる認可情報の再利用期間も同時に短くなる。こちらは現在200日で、2027年3月15日以降は100日、2029年3月15日以降は10日になる。寿命が縮むだけなら更新の回数が増えて終わりだが、確認結果まで使い回せなくなると、ドメイン確認の手続きそのものを何度も走らせることになる。運用への影響は、むしろこちらのほうが重い。

短くする理由は失効の仕組みが当てにならないから

議案の背景説明は、なぜ寿命を削るのかをかなり丁寧に書いている。要点は、証明書が発行時点の事実を写し取ったものにすぎない、という指摘だ。時間が経つほど、証明書に書かれた内容と実際の状況はずれていく。ドメインが手放された、鍵が第三者の手に渡ったといった変化が起きても、証明書のほうは期限まで有効なままになる。

本来そのずれを埋めるのが失効の仕組みだが、これが十分に働いていないという評価が示されている。失効情報を配る仕組みは、閲覧者の側が第三者のサーバーへ問い合わせを出す必要があり、応答が遅れたり届かなかったりする。外部の読み込みが多いページでは表示速度にも響く。失効させるべき証明書が期待どおりに失効されない例もあると書かれている。それに対して有効期限そのものは、閲覧側が確実に守る。だから期限を短くするほうが、失効の通知に頼るより確実だという整理になっている。

もう一つ挙げられているのが、暗号方式の入れ替えを速く進められることだ。使っているアルゴリズムや実装に弱点が見つかったとき、寿命の短い証明書のほうが世代交代は早く片づく。ここも個々のサイトの都合というより、仕組み全体をどう保つかという話として書かれている。

用意された三つの発行方式

Let’s Encryptが2015年の開始時から90日という期間を選んできたのは、自動化を促すには十分に短く、それでいて手作業でも回せる程度には長い、という判断からだったと自ら説明している。当時は自動化の道具立てがまだ若かった。いまは事情が違うので、90日より短い選択肢を出すことにも抵抗がなくなった、という理由づけになっている。

現在の既定はこれまでどおりのclassicで、有効期間は90日、認可情報の再利用は30日、証明書に載せられる名前は100件までとされている。新しく用意されたtlsserverは、有効期間が45日、認可情報の再利用が7時間まで詰められている。再利用が7時間なのは、認証局が8時間ごとにCAAの再確認を求められているためで、再利用期間をその手前で切っておけば再確認の手間が要らなくなる、という理屈が説明されている。証明書の中身も整理されていて、別欄と重複するコモンネーム、いまのブラウザでは使われない鍵用途の指定、末端の証明書では意味を持たない鍵識別子の拡張が省かれている。ファイルとしては小さくなる方向だ。

三つめのshortlivedは、有効期間が160時間、つまり6日あまりしかない。ここまで短いと失効情報を載せる必要がないという扱いになり、証明書はさらに小さくなる。IPアドレスに対する証明書もこの方式でのみ発行される。IPアドレスはドメインより移り変わりが早いので、確認の頻度を上げたいという判断だそうだ。ただしtlsserverもshortlivedも、載せられる名前は25件までに絞られている。サブドメインを多数まとめて一枚に収めている構成では、ここで引っかかる可能性がある。

既定の九十日が切り替わる日も告知済み

切り替えの日程も先に出ている。2026年5月13日にtlsserverが45日発行へ移り、2027年2月10日には既定のclassicが64日発行、認可情報の再利用10日へ変わる。さらに2028年2月16日にclassicも45日、再利用7時間になる予定だ。いずれも新規発行分から適用されるので、実際に短い証明書を受け取るのはその日以降の最初の更新時ということになる。

つまり、何も設定を変えていないサイトでも、2027年2月を境に証明書は90日から64日へ、2028年にはさらに45日へと自動的に短くなる。利用者側に特別な作業を求めるものではないと書かれてはいるが、更新の周期を前提にした仕掛けを持っているなら、そこは確実に影響を受ける。なお、TLSクライアント認証の用途を含んでいた発行方式は2026年7月8日で提供を終えている。使っていた環境があれば、すでに切り替えが済んでいるはずの部分だ。

更新間隔を決め打ちした設定を見直す

実務として一番効いてくるのは、更新のタイミングをどう決めているかだ。告知では、たとえば60日という固定の間隔で更新している設定は、45日の証明書に対しては成り立たなくなると名指しで書かれている。妥当な動きとして挙げられているのは、有効期間のおよそ三分の二を過ぎたあたりで更新する、という決め方だ。

推奨されているのはARIと呼ばれる仕組みで、いつ更新すべきかを認証局の側から受け取れる。対応しているかどうかも、有効にする方法も、使っているクライアントによって違うとされている。中小規模のサイトでは、証明書の取得をレンタルサーバーの管理画面やホスティング事業者側の仕組みに任せていることが多い。その場合に確かめておきたいのは、事業者がこの仕組みに対応しているか、していないなら更新の間隔がどう設定されているか、という点になる。

もう一つ、期限切れに気づける経路があるかどうかも書かれている。更新が想定どおりに走らなかったときに、知らせが飛ぶ状態になっているか。更新の回数が年に4回から8回、さらにその先へと増えていけば、たまたま失敗した一回が期限切れに直結する確率も上がる。気づいてから手で直せる猶予は、着実に短くなっていく。

手作業の余地が消えていく

手動での更新は推奨しない、と告知にははっきり書かれている。寿命が短くなるほど手作業の回数が増えるからだ。とはいえ、自動化を阻んでいるのは面倒くささだけではない。ドメインの管理権を確認する方法はどれも、クライアントが実際の設備へ触れる必要がある。所定のファイルを置く、TLSの応答を返す、DNSのレコードを書き換える。いずれも権限を渡すことになるので、そこを避けたくて手作業を続けている現場は少なくないはずだ。

この点については、DNS-PERSIST-01という新しい確認方式の標準化が進んでいることが告知されている。更新のたびにDNSのTXTレコードを書き換える必要がなく、一度置けばそのまま使い続けられるのが特徴だ。DNSを自動で書き換える手段を持たない環境でも自動更新に乗れるようになるとされていて、2026年中の提供が見込まれている。DNSの操作権限を外部に渡さずに済むなら、運用を分担している案件でも取り回しは楽になる。

証明書の期限が近いという連絡を年に一度受け取って、手で入れ替える。その段取りは、あと数年で現実的でなくなる。すでに自動更新が回っているサイトなら、確かめるべきは更新の判断基準と、失敗したときに気づける経路の二つで足りる。まだ手で回している環境が残っているなら、上限が200日ある今のうちが、移行を考える時間としては一番余裕がある。