1枚の証明書に、なぜそこまで厳重なのか
HTTPS の証明書は、ただ「このドメインは私のものです」と言う紙切れではない。ブラウザが相手先を信じてよいかを決める、Web PKI の入口そのものだ。だから発行前には、申請者が本当にそのドメインを制御しているかを確かめる。Let’s Encrypt の通常のやり方は、申請者に特定のファイルやトークンを決められた場所へ置かせ、それを CA 側が取りに行く、というものだ。
この仕組みは一見単純だが、ネットワークの途中で通信を横取りできる相手がいると崩れる。ドメインの所有者ではない第三者が、検証リクエストを別の場所へ誘導できれば、CA は「正しい持ち主が応答した」と誤認してしまう。2020 年の Let’s Encrypt の解説では、この種の攻撃は BGP を使った経路ハイジャックで起こりうると説明されている。BGP はインターネットの経路制御の基盤だが、すべての実装が強固というわけではない。RPKI や BGPsec のような防御策は進んでいるものの、そこに完全に頼れる時期がいつ来るかは分からない。Let’s Encrypt が「BGP が完全に安全になるのを待たない」と書いているのは、その不確実さを前提にしているからだ。
1か所で見ると、だまされる余地が残る
そこで出てきたのが、複数の視点から同時に確認するという発想だ。2020 年のブログでは、単一のネットワーク視点ではなく、複数の視点と自前のデータセンターから検証することで、攻撃者は同時に複数の経路をすり抜ける必要が出る、と説明されている。この時点では、主系 1 か所と複数の遠隔視点を合わせる構成だった。攻撃者に必要なのは、たまたま 1 本の経路を奪うことではなく、同じ瞬間に複数の経路を支配することになる。難易度が一段ではなく何段も上がる。
CA/B Forum でもこの考え方は制度側に取り込まれた。2024 年の Ballot SC067v3 では、Multi-Perspective Issuance Corroboration、つまり複数の Network Perspectives から domain validation と CAA check を行うことを、Baseline Requirements に入れる提案が進んでいる。背景には、BGP ハイジャックで検証をだまし、悪意ある証明書を得たとされる公開事例がある。Forum の文面はかなり率直で、ローカルな、しかも同じくらい具体的な prefix 攻撃は今なお Web PKI にとって重大な脅威だとしている。大げさな理屈ではなく、実際に HTTPS のなりすましへつながる経路がある、という認識だ。
Let’s Encrypt が受ける新しい制約
今回の Let’s Encrypt の更新は、その制度変更に合わせたものだ。コミュニティ投稿では、ドメイン検証のために新しい remote perspectives を 2 つ追加し、検証の安全性を高めると説明している。文中では、BGP attacks に対する可視性と保護を改善する、とも書かれている。しかも今回の変更で、検証要求の総数は 7 回になる。内訳は、primary datacenter から 1 回、remote perspectives から 6 回だ。以前は 4 回だったので、単なる増員ではなく、検証の立て方そのものが変わる。
この数字は地味に見えるが、運用の意味は重い。検証が 1 回増えるたび、単純にネットワーク往復が増えるだけではない。どの経路から見ても同じ応答が見えることが前提になるため、経路の偏りや地域差、途中の干渉に対して余地を小さくする。Let’s Encrypt は「ユーザーへの影響はほとんどないだろう」としている一方で、裏では失敗条件がより厳しくなる。primary server と remote perspectives の quorum が正しい challenge response を受け取らなければ発行できないからだ。
ここで気になるのは、なぜ 7 回なのかという点だ。2020 年の説明では、攻撃者は primary path と少なくとも 2 つの remote paths を同時に侵害しなければならないとされていた。では、2026 年の 7 回構成では何本の経路をどう見ているのか。CA/B Forum の要件は「少なくとも 5 つの remote Network Perspectives」を求め、しかもそれらが少なくとも 2 つの異なる Regional Internet Registries のサービス領域にまたがる必要があると書いている。Let’s Encrypt はこの基準に合わせて視点数を増やすわけだが、実際にどの視点をどう選び、どの quorum を満たすと成功になるのか、その内訳はまだ別の話になる。
どこまでが公開され、どこからがまだ先なのか
面白いのは、公式 FAQ が「どこから接続しているのかは変わる」と明言している点だ。Let’s Encrypt の検証地点は固定ではなく、時期によって変化する。2024 年の FAQ では、過去に 4 だった時期、3 に下がった時期、5 に戻った時期が説明されている。つまり、国名や IP レンジを前提にした防御や geoblocking は長続きしない。検証地点が動くなら、それに合わせて防御も組み替わるからだ。
そして今回の変更は、2026 年 10 月 27 日に staging で始まり、2026 年 11 月 10 日に production rollout する予定とされている。ここまでで見えてくるのは、検証地点の追加が単なるインフラ増強ではなく、BGP を前提にした発行プロセス全体の再設計だということだ。1 枚の証明書を出すために、なぜそこまで多くの視点が必要なのか。その答えは、攻撃者が狙うのが証明書そのものではなく、検証の視界だからだ。では、その 7 回の検証が実際にはどのように quorum を作り、どこまでの攻撃を弾けて、どこから先はまだ苦しいのか。ここから先が本番になる。
👉 続き(核心はここから)は PaPoo で読めます: https://papoo.work/doc/f422b8fc3e946e90

