DNS CAAレコードで証明書発行CAを制限する
RFC 8659とLet's Encryptの運用資料に基づき、CAAの検索規則、issue・issuewild、設定時の障害とセキュリティ上の限界を説明します。
発行・訂正窓口：infostoa · 編集基準
この記事の個別の執筆者・専門査読者の情報は提供されていません。
DNSのCAA（Certification Authority Authorization）レコードは、ドメイン保有者が証明書を発行できる認証局（CA）を指定する仕組みです。CAは発行前に対象名へ適用されるCAA情報を確認します。CAAは発行前の追加制御であり、ドメイン管理権確認や発行後の証明書検証、誤発行へのあらゆる対策を置き換えるものではありません。
CAAが制御する範囲
RFC 8659は、CAが証明書を発行する前に行う認可確認としてCAAを定義しています。適用されるCAAレコード集合がある場合、CAは申請がその集合に合致するか、証明書ポリシーまたは運用規程上の例外があるかを確認します。レコードで発行者を限定できますが、CAによる別のドメイン管理権確認をなくすものではなく、発行後にブラウザーなどが行う証明書検証も変更しません。
CAAが表すのは発行時点の認可です。DNSポリシーは後から変更できるため、現在のレコードと一致しない証明書でも、発行当時のポリシーとは一致していた可能性があります。そのためRFC 8659は、証明書利用者が現在のCAAを証明書検証の一部として使わないよう定めています。発行前の照合と、発行後の証明書確認やインシデント対応は分けて考えます。
CAが適用レコードを見つける手順
CAは証明書申請に含まれる各FQDNからDNS階層を上へたどり、最初に見つかったCAAレコード集合を適用します。すべての祖先ポリシーを合成するわけではありません。たとえばwww.example.comにレコードがなくexample.comにあれば、親の集合が適用されます。より近い子名にレコードを置けば、より具体的な方針を設定できます。RFC 8659の検索手順にはDNS別名の解決も含まれます。
申請には複数の名前やワイルドカード名を含められます。CAはそれぞれの認可を確認するため、apex名のポリシーだけでSANやワイルドカード名すべての設定を確認したことにはなりません。委任されたゾーンやCNAMEの参照先を含め、各申請名について最初に見つかるCAA集合を対応付けてください。Let's Encryptの運用資料も、最も近い名前のレコードが使われ、別名を追跡すると説明しています。
適用集合が見つからない場合、その検索ではCAAによる発行者制限はありません。iodefだけ、またはcritical flagのない、CAが認識しないプロパティだけの集合も、RFCの規則では発行を制限しません。DNSの応答が不正または取得不能な場合は、レコードがない正常応答とは別の状態です。空に見える応答をすべて発行許可と見なさず、取得結果の違いを切り分けます。
issue・issuewild・フラグの読み方
issueは通常の証明書を発行できるCAを指定し、適用されるissuewildがない場合はワイルドカード証明書にも適用されます。ワイルドカードだけ別の許可にしたい場合はissuewildを使います。対象集合にissuewildが一つでもあれば、ワイルドカード申請ではissueを無視してワイルドカード用の値を使います。同じ種類のプロパティは加算的です。複数CAを列挙すると、共同発行が必要になるのではなく、それぞれのCAが許可されます。
CAAレコードはフラグ、タグ、値で構成されます。issue値にはCA識別名と任意のパラメーターを含められ、発行者名を空にして発行を許可しない指定もできます。iodefは発行要求や違反を報告する手段を示し、許可CAの一覧そのものではありません。critical flagが付いた未知のプロパティをCAが見つけた場合、RFC 8659はその名前への発行をしないよう求めます。CAの対応を確認せずに設定すると発行失敗につながることがあります。
Let's EncryptはvalidationmethodsやaccounturiなどCA固有のパラメーターを案内しています。これらは発行時に使う認証方式やアカウントを制約できますが、意味と対応範囲はCAごとに異なります。Let's Encryptで使える値が他のCAにも通用するとは限らないため、発行を担当するCAの最新運用資料で識別名と受理値を確認します。
実務家の視点：DNS経路を試験し復旧手順を残す
設定前に、ワイルドカードを含む実際の証明書名についてCAA応答を調べます。最初に適用される祖先のレコード集合、複数のissue値が許可範囲を広げていないか、別名や委任が正しく処理されるかを確認してください。その後、CAのstagingなどで発行成功と拒否の両方を試し、自動更新に失敗した場合の変更取り消し方法も記録します。DNSプロバイダー画面の入力形式だけでなく、実際のDNS経路とCAの挙動を検証できます。
Let's EncryptのガイドはCAA照会時のSERVFAIL、DNSSEC検証問題、権威サーバー障害、未知の問い合わせ種別を拒否するDNSサービスなどの例を説明しています。CAAエラーは発行が許可された証拠ではなく、CAが適用ポリシーを判断できない状態の場合があります。権威DNSの応答とDNSSEC連鎖を確認し、応答が不正または取得できない場合はDNSプロバイダーに問い合わせます。
CAAは認可済みCA自身の誤りを防止できません。RFC 8659はCAA情報の抑制や改変を検知しやすくするため、可能な場合のDNSSEC検証を推奨していますが、DNSSECはCAAとは別のDNS完全性機構です。ドメイン保有者は許可するCA一覧を保守し、認可CAの発行統制も確認する必要があります。CAAは証明書運用における一つの追加層であり、望まない証明書が発行されない保証ではありません。