要約

  • DNS-01 の成功が示すのは、ある ACME アカウントが秘密鍵を保持し、認証局が参照した検証名に要求されたダイジェストを出せたことだ。CNAME や NS で切り出された狭い名前空間だけでも、その能力は成立する。
  • 注文、認可、ワイルドカード範囲、CSR、発行、秘密鍵保管、配備、CT での観測、失効は別々の状態である。TXT を消すだけでは、すでに発行された証明書は無効にならない。

終了したはずの委託が DNS に残る

委託終了のチェック表には、SSO、リポジトリ、CI のシークレット、証明書ストアが並ぶことが多い。ところが _acme-challenge.example の権威経路は、アプリの資産表から見えにくい。Let's Encrypt は DNS-01 について、CNAME または NS を使って別ゾーンへ検証を委任できると説明している。これは運用分離に有用だが、親ゾーンや Web サーバーを操作できない者にも、証明書発行に足りる局所的な能力を残し得る。

このケースは特定企業の事故を指すものではない。重要なのは、アプリから利用者を削除する操作と、DNS に配置した権限を回収する操作が別だという点だ。DNSSEC が委任と応答を正しく検証しても、それは署名された名前空間がその経路を選んだ証拠でしかない。契約や社内承認が現在も有効かは判断しない。

ダイジェストが結ぶ二つの条件

RFC 8555 の DNS-01 は、使い回せる TXT パスワードではない。サーバーが少なくとも 128 ビットのエントロピーを持つトークンを出し、クライアントはそれと ACME アカウント鍵から key authorization を作る。その SHA-256 ダイジェストを base64url で表し、認可対象の識別子に対応する _acme-challenge 名へ置く。

検証時に結び付くのは、アカウント秘密鍵の保持と、その検証名に期待値を見せる能力である。トークンかアカウント鍵が変われば値も変わる。古い TXT 値をコピーしても、新しい注文の証明にはならない。

ACME の authorization は、サーバーがそのアカウントに識別子を代表させる判断を記録したものだ。valid 状態には期限があり、後に期限切れ、無効化、失効になり得る。監査記録には「ドメインを検証した」ではなく、どのアカウントが、どの識別子について、どの方式と観測経路で、いつまで有効な認可を得たかを書くべきだ。

小さい委任でも発行能力は小さくない

専用ゾーンや限定 DNS 資格情報は、アプリサーバーに親ゾーン全体の API 鍵を置くより安全にできる。しかし「限定的」と「無害」は同義ではない。最終ゾーンを操作するアカウント、CNAME と NS の全ホップ、TTL、DNSSEC 状態、認証局が見た時刻と応答を一体で管理しなければならない。親ゾーンの管理画面だけでは、実際に走った経路を証明できない。

伝播とキャッシュも状態を分ける。親で委任を削除した時刻、権威サーバーの応答が変わった時刻、各再帰リゾルバーが古い経路を捨てた時刻、認証局が観測した時刻は一致しないことがある。終了確認には TTL をまたぐ否定テストが必要だ。

ワイルドカードは別の範囲情報である

ワイルドカード注文では、RFC 8555 の authorization は *. を除いた基底名を識別子として返し、wildcard: true を持つ。そのため TXT の名前だけを見ると通常の基底ドメイン検証に見えても、発行される証明書の範囲はワイルドカードになり得る。注文、認可、CSR と一緒にフラグを保存しなければ、レビューは権限を過小評価する。

Let's Encrypt が DNS-01 をワイルドカード発行の経路として案内していることは、同社の現在の実装情報である。すべての ACME サーバーが同じチャレンジや委任規則を持つとは限らない。RFC 9444 も、サーバーポリシー次第で祖先ドメインの認可をサブドメイン注文に使う任意の仕組みを定める。観測すべきなのは、推測した名前ではなく、サーバーが実際に返した authorization identifier である。

CSR、発行、配備は別の扉

注文の識別子集合は変更できず、finalize 時の CSR はその集合と正確に一致しなければならない。検証後に余分な SAN を忍ばせることはできない。この閉鎖性は重要だが、証明書秘密鍵の正当な保持者、配備先、アプリ上の役割までは決めない。

CAA には発行面をさらに狭める選択肢がある。RFC 8657 の accounturi と validationmethods は、issue または issuewild に認証局アカウントや検証方式の条件を加える。ただし認証局が一貫して対応している場合に限り、ドメイン検証そのものを置き換えない。サブドメインの制御が委任されていれば CAA 制約が上書きされ得るという注意もある。CAA を書いたことは、残った委任を消した証拠ではない。

後片付けと失効を混同しない

TXT を削除すれば一つの応答が終わる。CNAME や NS の委任を削除すれば、キャッシュ収束後に一つの経路が終わる。アカウントや authorization の無効化も別の状態変更である。いずれも、それだけで既発行証明書を失効させない。

ACME には独立した署名付き失効要求がある。発行時のアカウント、証明書の全識別子について認可を持つアカウント、または証明書秘密鍵が、プロトコル上の失効権限を与え得る。OCSP や CRL はさらに別の状態面であり、クライアントが変化を観測できた時刻も記録する必要がある。

Certificate Transparency は予期しない発行を見つける監視信号になる。しかし SCT やログ収録は通常の証明書検証でも自動失効でもない。検知後に調査、失効、配備除去まで進める責任系統が要る。

境界ごとに失敗させる

緑色の自動更新画面より、否定テストの方が権限を説明する。アプリ権限だけを消して委任を残し、新規注文が通るか試す。アカウント鍵を交換し、旧鍵由来のダイジェストを置く。注文にない SAN を CSR に加える。ワイルドカードと通常名を同時検証し、TXT 集合とフラグを記録する。委任を削除し、TTL 前後の権威・再帰応答を比較する。

最後に、証明書を発行しても配備せず、TXT を消して証明書状態が変わらないことを確認する。各制御は、自分が守ると主張する境界で失敗しなければならない。