CAAレコードとは？SSL証明書の発行先を制限するDNS設定と変更管理
企業サイトのSSL/TLS証明書は、ホスティング、CDN、ロードバランサー、クラウドの証明書管理サービス、ACMEクライアントなど、複数の仕組みから自動発行されます。更新が自動化されているほど、担当者が「どの認証局が、どのドメインに、どの経路で発行しているか」を把握しないまま運用が続きやすくなります。そこで使えるDNSの制御がCAA（Certification Authority Authorization）レコードです。
ただし、CAAを追加すれば自動的に安全になるわけではありません。現在使っている認証局を一つでも漏らすと、新規発行だけでなく自動更新も失敗し、期限が迫ってからサイト障害へつながる可能性があります。親ドメインの設定はサブドメインへ継承され、ワイルドカード証明書と通常証明書では許可の判定が分かれ、CNAME先のCAAも影響します。設定値だけでなく、発行経路と変更手順を一緒に管理することが重要です。
結論として、CAAレコードは公開SSL/TLS証明書を発行してよい認証局をDNSで明示する制御です。最初に本番・検証環境、CDN、ホスティング、ロードバランサー、ワイルドカード、CNAME先を棚卸しし、各サービスが指定する認証局識別子だけをissueまたはissuewildで許可します。反映後はDNS応答を見るだけで終えず、許可した経路で試験発行と自動更新を確認します。CAA設定は「レコードを追加した時」ではなく、「現在の発行元と更新経路を棚卸しし、許可した認証局だけで新規発行と自動更新が成功することを確認した時」に完了します。
本記事のポイント
- CAAレコードを1件でも公開すると、明示的に許可されていない認証局からの新規発行や更新を止めるため、先に全発行経路を棚卸しする。
- 通常証明書はissue、ワイルドカードは必要に応じてissuewildで分け、親ドメインの継承とCNAME先のCAAまで確認する。
- 設定完了はDNS反映だけで判断せず、許可した認証局での試験発行、自動更新、監視、認証局変更時のロールバックまで検証する。
CAAレコードは証明書を発行してよい認証局をDNSで示す
CAAは、ドメイン所有者が「この認証局には公開証明書の発行を許可する」とDNSへ公開するリソースレコードです。IETFのRFC 8659では、準拠する認証局は証明書発行前に対象FQDNのCAAを確認し、関連するレコードセットが発行を許可していなければ発行してはならないと定めています。複数のSANを持つ証明書では、含まれる全FQDNとワイルドカード名が確認対象です。
CAAが一件も見つからない場合、CAAによる認証局の制限はありません。反対に、issueを一件でも公開すると、そこに書かれていない認証局は原則として発行できなくなります。複数の認証局を使う場合は、認証局ごとにレコードを追加します。許可は加算されるため、「主系だけを書き、予備系は暗黙に許可する」という設計にはできません。
| タグ・値 | 役割 | 判断時の注意 |
|---|---|---|
issue | 通常のFQDNへ証明書を発行できる認証局を許可する | issuewildがなければ、ワイルドカード発行にも使われる |
issuewild | ワイルドカード名へ発行できる認証局を別に許可する | 一件でも存在すると、ワイルドカード判定ではissueより優先される |
iodef | ポリシー違反の発行要求などを報告する宛先を示す | 報告は認証局の対応に依存し、これだけでは発行を制限しない |
issue ";" | どの認証局にも発行を許可しない意思を示す | 他に許可レコードがあると許可は加算されるため、単独で設計する |
flags 0 | 通常のCAAレコード | 一般的な運用は0を使う |
flags 128 | 未知のタグを認証局が理解できない場合に発行を止めるcritical指定 | 目的と認証局の対応を確認せずに使うと、自ら発行を止める恐れがある |
たとえばLet’s Encryptだけに通常証明書の発行を許可する基本形は、次のようになります。認証局の値は会社名を推測して書かず、必ず利用サービスまたは認証局の現行ドキュメントで確認します。
example.com. CAA 0 issue "letsencrypt.org"Let’s EncryptのCAA公式ドキュメントでは、同社の識別子をletsencrypt.orgとし、必要に応じてvalidationmethodsやaccounturiで検証方式やACMEアカウントを絞れると説明しています。ただし、パラメータの意味と対応状況は認証局ごとに決まります。別の認証局へ同じパラメータをそのまま流用しないでください。
CAAは「現在発行されている証明書が正しいか」をブラウザが検証する仕組みではなく、新たに発行するときの認証局側の判断材料です。既存証明書を失効させる機能でも、許可した認証局による誤発行を完全に防ぐ機能でもありません。証明書の期限や発行状況の監視、認証局アカウントの保護、DNS権限の管理と組み合わせます。
親ドメイン・ワイルドカード・CNAMEを含めて発行経路を棚卸しする
CAAの照会は、対象FQDNからDNS名の階層を上へたどり、最初に見つかったCAAレコードセットを使います。たとえばapp.example.comにCAAがなく、example.comにCAAがあれば、親側の許可が適用されます。サブドメイン側に別のCAAを置けば、その場所から下の発行方針を上書きできます。親ドメインだけを見て完了にせず、独自ポリシーを持つサブドメインゾーンや委任先も確認します。
CNAMEを使うホスト名では、CAA照会も別名を追います。CDN、SaaS、フォーム、採用サイト、ステータスページなどでCNAMEを使っている場合は、自社側のホスト名だけでなくCNAME先のCAAも発行可否へ影響します。DNSと公開基盤の関係を整理するには、Webサイト制作を内製化する手順のドメイン・DNS・ホスティングの役割分担も参考になります。
| 構成 | 棚卸し対象 | CAA設計で確認すること | 代表的な事故 |
|---|---|---|---|
| 単一ホスティング | 本番、www、リダイレクト、管理画面 | ホスティングが実際に使う全認証局と更新経路 | サービス側の認証局切替を許可できず更新失敗 |
| CDN・WAF | エッジ証明書、オリジン証明書、カスタムホスト名 | 閲覧者向けとオリジン向けの証明書を分けて把握する | 片方の証明書だけ見て必要な認証局を漏らす |
| 複数クラウド | ロードバランサー、Certificate Manager、ACME | 本番・待機系・移行中の発行元をすべて許可する | 切替先だけ発行できずロールバックもできない |
| ワイルドカード | 通常名と*.example.com | issuewildを分ける必要があるか | 通常名は発行できるのにワイルドカードだけ失敗 |
| サブドメイン委任 | 部門、海外拠点、子会社、外部運用先 | 親の継承を使うか、委任先で別ポリシーを持つか | 親の制限が委任先の発行経路と衝突する |
| CNAME連携 | CDN、SaaS、外部フォーム、採用・イベント基盤 | CNAMEチェーンと参照先のCAAを確認する | 自社ゾーンに問題がなくても参照先の方針で失敗 |
マネージド証明書では、画面に表示される現在の発行者だけを許可すればよいとは限りません。可用性や運用上の理由から、サービスが複数の認証局を使う場合があります。Google CloudのCertificate Managerベストプラクティスは、Google管理証明書の信頼性を保つため、pki.googとletsencrypt.orgの両方を手動で許可することを推奨しています。CloudflareのCAA公式資料も、同社が複数のパートナー認証局を使い、運用上の理由で一覧が変わり得ると案内しています。
そのため、台帳には「現在表示された発行者」だけでなく、「サービスが指定する許可値」「対象証明書」「自動更新担当」「代替発行元」「公式資料の確認日」を記録します。ドメインの期限、権限、DNS、証明書をまとめて管理する考え方は、企業ドメインの更新期限を見逃さない管理方法と接続すると、担当者交代時の見落としを減らせます。
CAA設定と認証局変更を6ステップで進める
CAAはDNS設定の小さな変更に見えますが、影響は証明書の発行・更新経路全体へ及びます。特に認証局変更、CDN移行、ホスティング変更、ワイルドカード追加では、旧経路と新経路が並行する期間を設け、どちらでも復旧できる状態を維持します。Web資産の責任者、承認、次回点検日を決める方法は、Webサイトのコンテンツガバナンスと同じです。
- 証明書と発行経路を一覧にする
対象FQDN、SAN、ワイルドカード、環境、証明書管理サービス、現在の発行者、自動更新主体、有効期限、CNAME先、緊急時の再発行方法を台帳化します。ブラウザで見える証明書だけでなく、CDNとオリジン、待機系、検証環境、API、メール関連のHTTPSエンドポイントも確認します。 - 必要な認証局識別子を公式資料で確定する
各ホスティング、CDN、クラウド、認証局の現行ドキュメントを確認し、issueとissuewildへ書く値を集めます。代理発行や予備認証局を使うサービスでは、現行発行者だけに絞らず、サービスが要求する全ての値を含めます。確認日と資料URLを台帳へ残します。 - 通常名・ワイルドカード・例外サブドメインの方針を設計する
親ドメインへ共通方針を置くのか、部門や外部サービスのサブドメインで上書きするのかを決めます。ワイルドカードだけ認証局を分ける必要がなければissue中心で単純化し、分離する場合はissuewildの優先関係を表でレビューします。 - 変更前後のDNS応答を保存して反映する
現在のCAA、NS、CNAME、DNSSEC状態、TTLを保存し、変更申請に対象、理由、承認者、作業者、確認時刻、ロールバック値を記録します。権威DNSと複数の公開リゾルバーでdig example.com CAA +shortなどの結果を確認し、サブドメインとCNAME先も同じ条件で照合します。 - 許可した経路で試験発行する
本番証明書の期限直前を待たず、検証可能なホスト名や認証局のステージング環境で発行を試します。通常名とワイルドカード、複数SAN、CDN、自動管理サービスなど、台帳で分けた経路ごとに結果を確認します。許可していない経路を試せる場合は、意図どおり拒否されることも確認します。 - 自動更新・監視・変更証跡を運用へ組み込む
発行成功だけで完了にせず、自動更新の開始・成功ログ、証明書の有効期限、発行者、CAA応答、DNSエラーを監視します。認証局やサービスの仕様変更、CDN移行、新しいサブドメイン追加、DNS委任の変更時には、証明書変更より先にCAA台帳を見直します。
認証局変更では、最初に新旧両方の認証局を許可し、新しい証明書の発行・配信・監視が安定した後で旧認証局の許可を外します。いきなり旧レコードを削除すると、新経路の発行に失敗した時に旧経路へ戻せません。削除後も、自動更新ジョブや待機系が旧認証局を参照していないかを確認します。
| 変更場面 | CAAを見直す時点 | 受入条件 | ロールバック条件 |
|---|---|---|---|
| 認証局変更 | 新しい証明書を要求する前 | 新旧経路で発行でき、新証明書が配信される | 発行・配信・チェーン・監視のいずれかが失敗 |
| CDN・WAF移行 | カスタムドメインを登録する前 | エッジとオリジンの証明書が分けて確認できる | 新CDNの発行が止まり、旧CDNへ戻せない |
| ワイルドカード追加 | 証明書要求の設計時 | issuewildの有無と優先関係が意図どおり | 通常名またはワイルドカードの一方だけ失敗 |
| サブドメイン委任 | NS委任・CNAME公開の前 | 親の継承と委任先の発行経路が矛盾しない | 委任先が必要な認証局を許可できない |
| マネージド証明書 | サービス契約・仕様変更時 | 提供元が要求する全認証局を許可し、更新状態が正常 | 提供元の発行者変更で更新エラーが発生 |
発行失敗は許可値・DNS応答・継承範囲の順に切り分ける
CAA関連のエラーが出たら、認証局の許可値だけを何度も書き換えるのではなく、エラーメッセージ、対象FQDN、権威DNSの応答、親ドメイン、CNAME先、DNSSEC、タイムアウトを順に確認します。Let’s Encryptは証明書を発行するたびにCAAを確認し、CAAが設定されていないドメインでも、照会エラーによって「発行を許可されている」と確認できなければ発行できない場合があると説明しています。
| 症状 | 主な原因 | 確認方法 | 対応 |
|---|---|---|---|
| 認証局が許可されていない | 識別子の誤り、必要レコードの漏れ、別認証局への切替 | サービス公式値と実際のCAA RRsetを照合 | 必要な認証局だけ追加し、試験発行する |
| 通常名は成功、ワイルドカードは失敗 | issuewildが別の認証局だけを許可している | 同じ階層のissueとissuewildを比較 | 意図した分離か確認し、許可値を修正する |
| 特定サブドメインだけ失敗 | 子側のCAA、親からの継承、委任先ポリシー | 対象名から親へ順にCAAを照会 | 最初に見つかるRRsetを発行経路へ合わせる |
| CNAMEホストだけ失敗 | CNAME先のCAAが認証局を許可していない | CNAMEチェーンと各参照先のCAAを確認 | サービス提供元と必要な許可値を調整する |
SERVFAIL | DNSSEC検証失敗、権威DNSの不正応答、障害 | 権威DNS、DNSSEC検証、複数リゾルバーを比較 | レコード追加ではなくDNS応答の原因を直す |
| CAA照会がタイムアウト | 権威DNS停止、ファイアウォールが未知のQTYPEを破棄 | 全NSへCAAクエリを送り応答差を確認 | DNS事業者へ照会し、NOERRORまたは正しい応答へ直す |
| 変更後すぐ結果が揺れる | TTLとキャッシュ、権威DNS間の同期遅れ | 変更前TTL、各NS、公開リゾルバーの応答を時系列で保存 | 伝播時間を待ち、値が揃ってから再試行する |
DNSSECを使っている場合、署名不整合や不在証明の問題がCAA照会で表面化することがあります。RFC 8659はCAAレコードの認証にDNSSECを強く推奨し、Let’s EncryptもSERVFAILの代表原因としてDNSSEC検証失敗を挙げています。CAA値が正しく見えても、権威DNSの一部だけが古い、DNSSECの署名が不整合、未知のレコード種別へ不正な応答を返すと、認証局は安全側に倒して発行を止めます。
発行失敗の調査では、証明書管理サービス側の状態だけでなくDNSの変更履歴も同じ時系列へ並べます。外部通信やセキュリティ制御をいきなり強制せず観測から始める考え方は、CSP Report-Onlyの段階導入にも共通します。CAAにはReport-Only相当がないため、変更前の棚卸し、検証用発行、旧経路を残した段階移行で安全性を確保します。
自動更新の監視と四半期レビューでCAAを陳腐化させない
CAAは一度設定して終わるレコードではありません。ホスティングやCDNが利用認証局を変更したり、新しいクラウドへ待機系を追加したり、部門が外部SaaSへサブドメインを接続したりすると、必要な許可範囲が変わります。レコードが厳しいほど安全に見えても、実際の発行経路とずれれば可用性を損ないます。
| 点検契機 | 確認内容 | 完了の証拠 |
|---|---|---|
| 新規ドメイン・サブドメイン | 発行主体、親の継承、CNAME、ワイルドカード | 台帳登録、CAA応答、試験発行結果 |
| CDN・クラウド・ホスティング変更 | 提供元が指定する認証局、旧経路、更新ジョブ | 公式資料の確認日、新旧発行結果、切替承認 |
| 証明書発行・更新失敗 | エラー、CAA、DNSSEC、権威DNS、CNAME先 | 原因、是正、再発行、監視復旧の記録 |
| 担当者・委託先の変更 | DNS編集権限、認証局アカウント、緊急連絡先 | 旧権限削除、新担当の閲覧・変更手順確認 |
| 四半期 | 全CAA RRset、発行者、期限、サービス公式要件 | 不要許可の削除候補、例外、次回確認日 |
監視では、証明書の残存日数だけでなく、自動更新ジョブの成功、証明書の発行者、対象SAN、CAA応答、DNSエラー率を見ます。Certificate Transparency（CT）監視も併用すると、自社が把握していない証明書の発行を検知する手がかりになります。ただし、CAAは現在の発行許可を示すため、過去に発行された証明書が現在のCAAと一致しないだけで直ちに不正とは判断できません。
DNS編集権限は、サイト更新権限より狭くします。CAAだけでなくA、AAAA、CNAME、MX、TXT、NS、DSの変更がWeb・メール・証明書・認証へ影響するため、変更者と承認者を分け、通常時の編集者を限定します。外部サービスが増えた環境では、企業サイトの外部スクリプト棚卸しと同様に、提供元、目的、所有者、停止・復旧方法まで台帳へ結びます。
よくある質問
CAAレコードがない場合、証明書は発行できますか？
CAAによる認証局の制限はないため、各認証局がドメイン管理権限の確認など他の要件を満たせば発行できます。ただし、CAA照会そのものがSERVFAILやタイムアウトになると、認証局が許可を確認できず発行を止めることがあります。
複数の認証局を許可してもよいですか？
必要な発行経路が複数ある場合は、認証局ごとにCAAレコードを追加できます。許可は加算されます。主系、予備系、CDN、クラウドの役割を台帳へ残し、利用していない認証局を念のために許可し続けないよう定期的に見直してください。
issueとissuewildは必ず両方必要ですか？
必須ではありません。issuewildがなければ、issueの許可が通常名とワイルドカードの両方へ使われます。ワイルドカードだけ別の認証局へ絞りたい場合にissuewildを追加します。
Google CloudやCloudflareのマネージド証明書でもCAA確認は必要ですか？
必要です。マネージド証明書は発行と更新を自動化しますが、ドメイン側のCAAがサービスの利用認証局を許可していなければ処理が失敗します。管理画面に表示された現在の発行者だけでなく、サービスの公式資料が指定する全ての許可値を確認します。
CAA変更後はどのくらい待てばよいですか？
一律の時間では決められません。変更前のTTL、権威DNS間の同期、キャッシュの状態で変わります。各権威DNSと複数の公開リゾルバーで意図したRRsetがそろい、CNAME先と親子階層も確認できてから発行を再試行します。
CAAを設定すれば不正な証明書発行を完全に防げますか？
完全には防げません。CAAは許可していない認証局からの誤発行リスクを下げる制御です。許可済み認証局での不正利用、DNS権限の侵害、既存証明書の悪用には別の対策が必要です。DNS権限、認証局アカウント、CT監視、証明書失効、インシデント対応を組み合わせます。
実務で確認できる公式資料
- RFC Editor：RFC 8659 DNS Certification Authority Authorizationでは、CAAの構文、親階層の探索、
issue、issuewild、iodef、critical flag、DNSSECを確認できます。 - Let’s Encrypt：Certificate Authority Authorizationでは、同社の認証局識別子、CNAME、検証方式・ACMEアカウントの制限、
SERVFAILとタイムアウトの切り分けを確認できます。 - Google Cloud：Certificate Managerのベストプラクティスでは、Google管理証明書で推奨されるCAA許可値と証明書監視を確認できます。
- Cloudflare：Add CAA recordsでは、複数のパートナー認証局、サブドメイン継承、CNAMEチェーン、管理証明書でのCAA運用を確認できます。
- CA/Browser Forum：TLS Baseline Requirementsでは、公開信頼TLS証明書を発行する認証局に求められるCAA確認の現行要件を確認できます。
- DigiCert：DNS CAA resource record checkでは、複数認証局、通常名、ワイルドカード、親子階層、CNAMEの実務例を確認できます。
