要約

  • RFC 9538 の MI.ACMEDelegationMethod は、上流CDNが許可した範囲で下流CDNに自前の鍵ペアと証明書を持たせ、長期秘密鍵の共有を避ける。
  • 委任オブジェクト、CSR照合、CA発行は、それぞれ限定された事実の証拠である。DNSの到達先、全ノードでの有効化、正しいSNI選択、意図したコンテンツの返却は別問題だ。
  • STARの停止と非STAR証明書の失効は時間軸が異なる。権限付与から利用者の観測、終了までを一つの緑色表示にまとめてはならない。

証明書の内容が正しいのに、画面に別の顧客のページが出ることはあり得る。

下流CDNが自分で鍵を作り、認められたCSRを送り、CAから有効な証明書を受け取ったとする。それでも一部PoPは旧証明書のままかもしれない。新しいファイルは置かれていても、SNIの分岐がデフォルト証明書を選ぶかもしれない。DNSの切替が途中なら、利用者は旧クラスタと新クラスタに分かれる。TLSが正常でも、キャッシュキーの誤りで別オブジェクトを返すことがある。証明書は、これらの失敗を検知する装置ではない。

2024年2月にIETF標準トラックで公表された RFC 9538 は、DNSリダイレクトを使うCDN相互接続で生じる認証情報の問題を扱う。上流CDNから配信を委ねられた下流CDNは、コンテンツ提供者の名前に対応する証明書が必要になる。上流の長期秘密鍵を組織間で複製する代わりに、RFC 9115 の仕組みで下流が鍵を所有し、上流のIdentity Ownerが申請可能な名前と形を制約する。

メタデータが示すのは入口である

acme-delegation は下流アカウントに結び付く委任オブジェクトのHTTPS URL、time-window は証明書の有効期間である。lifetime があれば短期自動更新のSTAR、なければ非STARを意味し、lifetime-adjust はSTARの期間を調整する。IANAのCDNIレジストリ はこの型をMI/FCI向けに登録している。RFC 8006、RFC 8008、RFC 7336 は、メタデータ、能力通知、CDNIの役割を支える。

しかし、そこに全エッジの一覧はない。配置完了時刻、各PoPの証明書指紋、外部DNS観測、SNIテスト、HTTP本文の照合値もない。「委任情報を受信」と「配信準備完了」の間には、メタデータが所有しない工程が残る。

ACMEアカウントは申請権限を表す

RFC 9115では、下流のName Delegation Consumerを上流のIdentity Ownerが事前登録する。下流はアカウント鍵で、CSRテンプレートを含む委任オブジェクトを取得し、自らの鍵ペアでCSRを作る。上流はテンプレートに照らして名前、鍵、拡張を確認し、自分のCAアカウントで RFC 8555 のACME発行を進める。

この区間では通常のACMEチャレンジの代わりに、アカウント認証と事前設定された委任が権限を担う。そのためアカウント鍵の保護と、アカウントごとの正確な名前制約が要となる。しかしCSR適合は「要求の形が許可どおり」という判定であって、実装先の完全性ではない。

RFC 5280 の証明書パス、RFC 9525 のサービス識別、RFC 8446 のTLS 1.3、RFC 6066 のSNIは、提示された証明書を接続でどう評価するかを規定する。HTTPで正しい資源を返したかという問いは、その先にある。

DNSは別の決定面を持つ

RFC 9115の委任オブジェクトはCNAMEマッピングを扱う。RFC 9538は、将来 SVCB/HTTPS に拡張し得ると記す。どちらでも、名前から配信先への写像は独立した運用状態だ。

ドメイン保有者がDNSゾーンの変更権を保持すれば、下流CDNがコンテンツと検証経路を同時に支配する範囲を狭められる。CAA は発行CAを制限し、RFC 8557 はACMEアカウントや検証方式をさらに限定できる。ただし、それらは新しいRRsetが世界からどう見えるか、返ったアドレスが予定ノードかを確認しない。

必要なのは、権威DNSの変更記録、RRsetとTTL、複数地点の解決結果、各アドレスと資産台帳の対応である。証明書のシリアル番号だけではDNS切替を再現できない。

終了には二つの時計がある

RFC 8739 のSTAR証明書は短命で、自動更新される。Identity Ownerが更新をキャンセルしても、最後に発行された証明書は有効期限まで使える。停止要求の受理、最終発行、最終取得、最終有効化、期限満了を別々に記録すべきだ。

非STARではACMEの失効処理を使う。上流がCAに申請でき、秘密鍵を持つ下流も緊急時には直接失効できる場合がある。だがCAが要求を受理しても、全エッジから設定が消えたことにはならない。

Certificate Transparency は発行を見えるようにするが、配置や撤去は証言しない。RFC 9325 のTLS運用指針も、実際の観測の代わりにはならない。

証拠を隣り合わせに保存する

実務では、①コンテンツ提供者の指示、②委任オブジェクトとCSRテンプレートのハッシュ、③CSR・公開鍵指紋・注文・CA認可、④証明書のSAN・シリアル・チェーン・期間、⑤権威DNSと外部観測、⑥全エッジの有効化指紋とSNI規則、⑦独立網からのTLS・HTTP・本文確認を分離して残す。更新や停止時にも同じ鎖をたどる。

「発行済み・未配置」「PoPの92%だけ一致」「DNS切替済み・新クラスタ未完成」「STAR停止済み・最後の証明書は残り47分有効」という表示なら、担当者は行動できる。単に「安全」「稼働中」「失効済み」と表示すれば、境界は消える。

RFC 9538が過剰な約束をしているのではない。局所的なプロトコル結果を、稼働中の配信全体の証拠に読み替える側が問題を作る。

参照資料と限界

公開状況は RFC Editorの情報、IETF履歴、正誤表で確認できる。根拠はRFC 9538、9115、8739、8555、8006、8008、7336、9460、9325、9525、5280、8659、8557、8446、6066、9162とIANA表である。特定CDNの障害、配備台帳、パケット取得は調べておらず、単一地点の結果を全体へ外挿しない。