HTTPS証明書エコシステムは、ドメイン所有権検証における弱い手法から段階的に撤退し始めている。Chrome Root Program と CA/Browser Forum は、認証局向けの新たな要件を承認し、これにより11種類の「レガシー」なドメインコントロール検証（DCV）メカニズムが段階的に廃止されることになる。
その理由は明快だ。証明書に対する信頼が、メールや電話、あるいは緩やかに関連付けられた連絡先情報といった脆弱なシグナルに依存していると、攻撃者はチェックをすり抜け、自分が管理していないドメインの証明書を取得する機会を得てしまう。こうした抜け穴は、いま意図的に塞がれつつあり、重心は自動化され、暗号学的に検証可能な手法へと移行している。
これらの変更は投票 SC-080、SC-090、SC-091 に明文化されており、サイト運営者が最新の検証方式へ移行する時間を確保できるよう、段階的に導入される。完全な影響が現れるのは2028年3月と見込まれており、その時点で旧式のチェックは完全に廃止される。これらの改革は、2022年に公表された「Moving Forward, Together」ロードマップと結び付けられている。当初は戦略的な方向性に過ぎなかったものが、TLS ベースライン要件の更新を通じて拘束力のある業界ポリシーへと発展し、すでに共有標準として成熟している、より広範なセキュリティ施策の波を継続する形となっている。
DCV は、証明書がドメインの正当な運営者にのみ発行され、なりすましに発行されないようにするための重要な安全策である。堅牢な検証がなければ、攻撃者は他人のサイト向けに一見「有効」な証明書を取得し、それをなりすましやトラフィック傍受に利用しつつ、形式上は信頼チェーンの範囲内にとどまり続けることができてしまう。現代的な検証は通常、チャレンジ・レスポンスモデルに従う。すなわち、認証局がランダムな値を発行し、申請者はそれを DNS TXT レコードなどあらかじめ定められた場所に配置することでコントロールを証明し、その後、認証局がレスポンスを検証する。
しかし歴史的には、所有権の間接的な指標に依存するさまざまな手法も認められてきた。WHOIS の連絡先情報や、「それらしく見える」アドレスとのやり取りなどがその例である。まさにこうした慣行が、いま問題視されている。段階的な廃止の一環として、ドメインや IP の連絡先に対してメール、FAX、SMS、郵便で送信されるメッセージに基づくチェックは排除され、「構成された」ドメインメールアドレスや、DNS CAA または DNS TXT レコードに記載された連絡先への通知も同様に廃止される。同じ運命は電話ベースの確認にも及び、ドメイン連絡先、DNS TXT や CAA レコードに埋め込まれた電話番号、IP 連絡先情報を用いるもの、さらには逆引き IP アドレス検索スキームも対象となる。
一般的なブラウザ利用者にとって、これらの変更はほとんど目に見えないものとなる――そしてそれは意図された設計である。しかし舞台裏では、古く不透明なシグナル、例えば古い連絡先レコード、電話やメールシステムにおける複雑な転送チェーン、長年引き継がれてきた管理上の遺物などを悪用して認証局を欺くことが、これまでよりもはるかに困難になる。
最終的な結果として、業界全体が標準化された、現代的で監査可能な DCV 手法へとシフトし、ACME のような自動化フレームワークへの依存度も高まる。同時に、これらの改革は証明書ライフサイクル管理の迅速化と簡素化も促進する。究極的な目標は、安全なインターネット接続に対する信頼が依拠するプロセスから最も弱いリンクを切り離し、この基盤インフラをすべての人にとってより強固なものにすることにある。
