私はこれまでに数多くの CA/Browser Forum の会議に参加してきましたが、証明書の有効期間に関する議論は、実質的な理解よりも感情的な対立を生みやすいテーマであると感じています。すでにスケジュールは決定しており、TLS の有効期間は 2026 年 3 月に 200 日へ短縮され、2027 年には 100 日、さらに 2029 年 3 月までに 47 日へと短縮されます。同じタイムラインで、ドメイン検証の再利用期間も 10 日に短縮されます。

この内容をお客様に説明すると、よくある反応があります。「秘密鍵が侵害されているという証拠はあるのか。もしそうなら、もっと大きな問題ではないか」というものです。

この指摘は間違っていません。しかし、本質を捉えているとも言えません。

Heartbleed を覚えていますか？

2014 年 4 月、OpenSSL の heartbeat 拡張の脆弱性により、攻撃者がサーバーメモリを 64KB 単位で読み取ることが可能になりました。その中にはセッショントークン、ユーザー認証情報、そして秘密鍵も含まれていました。このバグは発見されるまで 2 年間存在していました。

脆弱性そのものも重大でしたが、それ以上に問題だったのは対応です。

サーバー運用者は OpenSSL のパッチ適用、秘密鍵の再生成、新しい証明書の発行と配備を、理想的には数時間以内に行う必要がありました。

しかし実際には、多くのサーバーが侵害の可能性のある鍵を数週間、場合によっては数か月間使用し続けました。証明書の配置場所が把握されておらず、自動更新の仕組みもなく、緊急時のローテーション手順も整備されていなかったためです。

当時の証明書は最大 5 年間有効でした。その前提で構築された運用体制では、危機に対応できなかったのです。

これこそが、有効期間短縮が解決しようとしている本質的な問題です。日常的な鍵侵害ではなく、次の Heartbleed に耐えることです。

重要なのはアジリティ

ブラウザベンダーは運用負荷を理解した上で、意図的にこの変更を推進しています。頻繁な証明書更新を強制することで、実際の緊急対応に必要な運用能力を養うという考えです。

47 日ごとに証明書を問題なく更新できる組織は、すでに緊急時の対応能力を備えています。自動化、可視性、検証済みプロセスが整っているためです。

一方で、スプレッドシートと手動管理に依存している場合、次の重大な脆弱性が発生した際に深刻な影響を受ける可能性があります。

副次的なメリットもあります。有効期間が短くなることで、従来から課題とされてきた失効（OCSP や CRL）への依存度が低下します。証明書が短期間で失効することで、仮に失効処理が機能しなくてもリスク期間は限定されます。

量子コンピュータとの関係

私は現在、耐量子コンピュータ暗号に多くの時間を費やしていますが、基本的な証明書管理ができていない組織は、今後の変化に対応できない可能性が高いと感じています。

量子コンピュータ対応への移行では、すべての証明書に対して複数回の変更が必要になる可能性があります。

この変化に対応できるのは、今から暗号アジリティを構築している組織です。証明書の完全な把握、自動化された配備、アルゴリズムの柔軟な切り替えが求められます。

有効期間の短縮は、こうした近代化を促進するための手段でもあります。

今取るべき対応

準備の時間はありますが、十分とは言えません。証明書ライフサイクル管理の自動化をまだ開始していない場合、今すぐ着手する必要があります。

そのために設計されたのが Trust Lifecycle Manager です。発行元の 認証局に依存せず、証明書の可視化、自動化、迅速な対応を可能にします。要件は今後も変化し続けます。

セキュリティインフラは橋に似ています。崩壊するまで注目されません。業界は次の崩壊を防ぐために先手を打とうとしています。実装の議論は別として、より柔軟でレジリエントな Web PKIを構築するという方向性は正しいものです。