要約

  • Geoff Hustonは2026年4月21日、Let’s Encryptの試験用証明書を失効させ、発行者の失効リストにシリアル番号が載ったことを確認した。48時間後、試した三つのブラウザーバージョンは接続を認めた。
  • 後のAPNIC 62講演では、数週間たつとFirefoxが同じ証明書を拒否した一方、ChromeとSafariは彼の試験でなお通した。公表から実行までの時間差が、この話の核心だ。

失効した証明書が、まだ玄関の鍵として働いていた。Geoff Hustonは試験サイト向けにLet’s Encryptの証明書を発行し、4時間後の2026年4月21日に失効させた。発行者のリストには確かにそのシリアル番号があった。書類上の処理は済んだ。では、実際に接続する側はどうしたか。

APNICに掲載した本人の記録では、48時間後のFirefox 148.0.2、Chrome 147.0.7727.117、Safari 25.4はいずれも接続を許した。一枚の証明書と指定された版での観察である。全製品の永遠の評価表にはできないが、信頼の仕事が二段階に分かれていることは鮮明だ。発行者は失効を記録できる。TLS接続を最後に許すのはクライアントであり、リストの一行が自動的に扉を閉めるわけではない。

時間を置くと景色が少し変わった。APNIC 62の講演資料でHustonは数週間後の再試験を示し、Firefoxは拒否したが、ChromeとSafariはまだ通したと説明する。4月の記事と9月の講演は観測時点が違う。見たいのは勝ち負けの表ではなく、発行者が「失効」と告げてから利用者の画面で効くまでの長さだ。その間、同じ証明書に二つの現実がある。

情報を運ぶ方法にも代金が付く。失効リストの取得には容量が要る。オンライン照会は応答待ちと可用性の問題を増やし、どの利用者がどのサイトを訪ねたかという手がかりを発行者側に渡す。サーバーが状態情報をTLSに添付すれば往復を省けるが、失効した証明書を使うサーバーが自分から不利な証拠を差し出すとは限らない。ブラウザーが配る選別済みリストにも、更新までの時計がある。

有効期間を短くすればよい、という案もHustonは六日まで詰めて考える。90日から45日、六日へと縮めれば被害の可能な時間は減る。しかし初日に鍵が危うくなれば、期限前に止める仕組みはなお必要だ。数時間単位の更新は発行基盤の負荷を変える。そこで彼は講演の終盤、鍵情報をDNSに置き、DNSSECで保証し、短いTTLで古さの上限を決めるDANE型の設計を提案した。TLSへの検証連鎖の添付も構想に含む。現行のWebが一斉に切り替わったという話ではない。問われているのは、いま信用した情報が何分前のものか、である。