CAAレコードとは？証明書を発行できる認証局の制限・設定方法・診断基準

CAAレコードとは

CAAレコード（Certification Authority Authorization）とは、「このドメインのサーバー証明書を発行してよい認証局（CA）はどこか」をDNSで宣言する仕組みです。仕様はRFC 8659（RFC 6844を廃止）で定められています。

city.example.lg.jp. 3600 IN CAA 0 issue "letsencrypt.org"
city.example.lg.jp. 3600 IN CAA 0 issue "globalsign.com"
city.example.lg.jp. 3600 IN CAA 0 issuewild ";"
city.example.lg.jp. 3600 IN CAA 0 iodef "mailto:security@city.example.lg.jp"

公的に信頼されるCAは、CA/Browser ForumのBaseline Requirementsにより、証明書を発行する前に対象ドメイン名ごとにCAAを確認し、自社が許可されていなければ発行してはならないとされています（Ballot 187、2017年9月8日発効）。

CAAがない場合は「どのCAでも発行可」という既定の状態になります。CAAを設定すると、ドメイン認証の手続きを悪用した不正発行や、組織内の別部署が把握していないCAで証明書を取得してしまう事態を、CA側の発行時点で止められる可能性が高まります。この項目は、診断対象ドメインにCAAレコードが公開されているかを確認します。

CAAレコードの構造（タグの意味）

• flags（先頭の数字）：0 または 128（critical）。critical付きで未知のタグがあると、CAは発行してはなりません。
• issue：通常の証明書の発行を許可するCAのドメイン名。複数並べると、そのいずれもが許可されます。issue ";" は全CAの発行禁止を意味します。
• issuewild：ワイルドカード証明書（*.example）専用の許可。存在する場合、ワイルドカードについては issue より優先されます。
• iodef：ポリシー違反の発行要求があった際の連絡先（mailto/http/https）。CAが通知する義務までは定められていません。
• RFC 8657の拡張により accounturi（特定のACMEアカウントに限定）や validationmethods（dns-01 などドメイン認証方式の限定）も指定できます。

代表的な設定パターン

CAAレコードの仕組み：CAはどこのCAAを見るのか

ツリークライミング（RFC 8659）

RFC 8659では、CAは証明書に含める名前から親ドメインへ向かって順にCAAを探し、最初に見つかった階層のCAAセット（Relevant RRset）を適用します。たとえば www.city.example.lg.jp の証明書なら、www.city.example.lg.jp → city.example.lg.jp → example.lg.jp → lg.jp → jp の順に探します。

したがって、組織の代表ドメイン（city.example.lg.jp）に1回設定すれば、配下のサブドメインにも適用されます。サブドメインで別のCAを使う場合は、そのサブドメインに個別のCAAを置くと、そちらが優先されます。

CNAMEしている場合

CNAMEについては、CAが利用するリゾルバが通常どおりCNAMEをたどった結果を用います（Let's Encryptの解説でも、CAA確認はCNAMEに従うと説明されています）。そのため、CDNへCNAMEしているホスト名では、CDN事業者側のCAAが参照されることがあります。

CAAレコードについてよくある誤解

• 「CAAを入れるとブラウザが不正証明書を拒否する」：CAAは発行時にCAが確認するもので、ブラウザは接続時にCAAを確認しません。すでに発行済みの証明書には影響しません。
• 「CAAがあれば不正発行は完全に防げる」：CAが従うことを前提にした仕組みです。DNS応答の改ざんに対しては、DNSSECと組み合わせると信頼性が上がります。RFC 8659はDNSSEC検証を強く推奨するにとどめていますが、Ballot SC-085v2により2026年3月15日以降、CAはCAAとドメイン認証のDNS照会で、DNSSECが設定されているドメインについては署名を検証しなければなりません。署名が壊れているドメインでは証明書の発行・更新が拒否されます。DNSSECそのものは「DNSSEC」の項目で確認します。
• 「CAAは電子メールの設定」：本診断ではDNS・メール保護カテゴリにまとめていますが、issue / issuewild はサーバー証明書のための設定で、メールの送受信には影響しません（S/MIME証明書の発行制御にはRFC 9495の issuemail タグが別にあります）。

CAAレコードの診断基準（セキュリティAIチェッカー）

取得方法

• 診断の最終URL（リダイレクト追跡後）のホスト名から先頭の www. を取り除いたドメイン（例: www.city.example.lg.jp → city.example.lg.jp）について、Google Public DNSのDNS over HTTPS（JSON API）でCAA（タイプ257）を照会します。
• 照会は通信失敗・非2xx応答時のみ最大3回試行し、それでも応答が得られない場合は「照会失敗」として扱います。

判定条件

× 要改善（fail）はありません。CAAは推奨設定であり、なくても証明書の安全性が直ちに損なわれるわけではないため、重大度はlow、重みは1です。

判定の限界

• 照会するのは「www. を除いたドメイン」の1階層のみで、CAと同じツリークライミングは行いません。たとえば kosodate.city.example.lg.jp を診断した場合、そのホスト名自体のCAAのみを確認するため、親の city.example.lg.jp にだけCAAがある構成では △ になることがあります。その場合は親ドメインのCAAを dig 等で確認してください。
• issue に記載されたCAが、実際に使っている証明書の発行元と一致しているかは判定しません。

自治体サイトでの判定例

CAAレコードがないとどんなリスクがあるか

• 不正な証明書の発行：攻撃者がドメイン認証（HTTPファイル設置、メール認証、DNS認証）の抜け道を突いたり、委託先サーバーを一時的に乗っ取ったりした場合、CAAがなければどのCAからでも証明書を取得され得ます。取得された証明書は、DNS改ざんや中間者攻撃と組み合わせて住民向けの偽サイトを「正しいHTTPS」に見せるために悪用され得ます。
• シャドーIT：部署や委託事業者が独自に証明書を取得し、期限管理されないまま運用されることがあります。CAAで発行元を限定すると、発行時点でCAに拒否されるため把握の機会になります。
• 影響範囲：CAAがないこと自体で直ちに被害が生じるわけではなく、不正発行への「追加の防壁」が欠けている状態です。重大度をlowとしているのはこのためです。

CAAレコードの設定方法（BIND・クラウドDNS）と確認方法

1. 利用中のCAを洗い出す

# 現在の証明書の発行者を確認
openssl s_client -connect www.city.example.lg.jp:443 -servername www.city.example.lg.jp </dev/null 2>/dev/null | openssl x509 -noout -issuer

本庁サイトだけでなく、サブドメインで運用している施設予約、図書館、観光、メール配信、CDN（CNAME先の事業者が自動で証明書を取得する場合を含む）を一覧にします。ここで漏れたCAを記載しないと、更新時に証明書が発行されなくなります。

2. CAの「issuer domain name」を確認する

CAAに書く値は各CAが公表しています（例: Let's Encryptは letsencrypt.org）。必ず各CAの公式ドキュメントで確認してください。

3. DNSに登録する

; BIND形式の例
city.example.lg.jp. 3600 IN CAA 0 issue "letsencrypt.org"
city.example.lg.jp. 3600 IN CAA 0 issue "globalsign.com"
city.example.lg.jp. 3600 IN CAA 0 iodef "mailto:security@city.example.lg.jp"

; ワイルドカード証明書を使わない場合
city.example.lg.jp. 3600 IN CAA 0 issuewild ";"

クラウドDNS（Route 53、Cloudflare、Azure DNS等）や国内DNS事業者の管理画面にはCAAの入力欄があります。CAAに対応していない古いDNSサービスでは、事業者に対応可否を確認します。

4. 段階的に導入する

1. まず iodef を含めず、現在使っている全CAを issue に列挙して登録する。
2. 次回の証明書更新（自動更新を含む）が成功することを確認する。
3. 必要に応じて issuewild ";" や accounturi / validationmethods で絞り込む。

5. 設定後の確認方法

dig +short CAA city.example.lg.jp
nslookup -type=CAA city.example.lg.jp
curl -s "https://dns.google/resolve?name=city.example.lg.jp&type=CAA"

CNAMEしているホスト名では、CAが実際に参照するCAAを次のように確認します。CNAME先の事業者がCAAを置いている場合、自組織の代表ドメインのCAAより先にそちらが見つかることがあります。

dig +short CNAME www.city.example.lg.jp
dig CAA www.city.example.lg.jp   # CNAMEの連鎖を含む応答を確認

設定を変えたら、セキュリティAIチェッカーで再診断し、根拠欄が「CAAレコードを確認しました。」になっていることを確認します。

サイトを壊さないための注意点（ガードレール）

• CNAME先のCDNやSaaSが証明書を自動発行している場合、その事業者のCAを許可し忘れると証明書の自動更新が失敗し、期限切れでサイトが表示できなくなります。登録前に、各サービスのドキュメントで使用CAを確認してください。
• issue ";" は発行禁止です。誤ってこれだけを登録しないよう注意します。
• critical フラグ（128）は、意味を理解している場合以外は使いません。
• CAAの変更はTTL経過後に反映されます。更新期限が近い時期の変更は避けます。
• DNSSECを導入しているドメインでは、署名の期限切れやDSの不整合があるとCAがCAAを検証できず、証明書を更新できません。証明書の更新前にDNSSECの状態も確認します。

よくある質問（FAQ）

参考資料

• RFC 8659 DNS Certification Authority Authorization (CAA) Resource Record
• RFC 8657 Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding
• CA/Browser Forum Ballot 187 – Make CAA Checking Mandatory
• CA/Browser Forum Ballot SC-085v2 – Require Validation of DNSSEC (when present) for CAA and DCV Lookups
• Let's Encrypt Certificate Authority Authorization (CAA)
• JSON API for DNS over HTTPS (DoH)（Google Public DNS）
• GlobalSign Certificate Authority Authorization: What is CAA?

「CAAレコード」と関連する診断項目

• DNSSECmedium
• 証明書期限の余裕high
• SPFレコードmedium
• SPFの終端ポリシーmedium
• DMARCレコードhigh
• DMARC強制ポリシーmedium
• DMARC集計レポート送信先low
• SPFの一意性・構文・DNS参照数high