CAAレコードの競合とは、ドメインで許可した認証局と、実際に証明書を発行しようとするサービスが使う認証局が食い違い、どれかのサービスで証明書の発行や更新が止まる状態のことです。CDN、ホスティング会社の自動SSL、自分のサーバーの certbot など、複数のサービスが同じドメインの証明書を扱う構成で起こりやすく、CNAMEとの組み合わせで意図しないCAAが効いていることもあります。この記事では、競合の典型的な形、どこで食い違っているかの調べ方、整理して解消する手順を説明します。
同じ名前に複数のCAA行がある「重複」の整理は別の記事で扱っているため、ここでは「サービス同士・設定同士のぶつかり合い」に絞ります。
競合が起きる仕組み
認証局は証明書を発行する前に、対象の名前のCAAレコードを調べます。その名前にCAAが無ければ親の名前（shop.example.com なら example.com）へとさかのぼり、最初に見つかったCAAの組を使います。どこにもCAAが無ければ、どの認証局でも発行できます。
見つかったCAAに自分の名前が無い認証局は、発行を断ります。つまり、CAAを1行でも置いた時点で、そこに書いていない認証局はすべて締め出されます。CAAを設定したあとで新しいサービスを追加したり、サービス側が使う認証局を変えたりすると、この締め出しが競合として表面化します。
よくある競合のパターン
1. サービスごとに違う認証局を使っている
たとえば、元サーバーでは Let's Encrypt、CDNでは別の認証局、ロードバランサーでは AWS Certificate Manager の証明書、という構成です。CAAに letsencrypt.org だけを書くと、CDNやAWS側の更新が失敗します。CDNやホスティングの中には、更新のたびに複数の認証局を使い分けるものもあり、ある時期だけ失敗する、という分かりにくい症状になります。
2. CNAMEの向け先のCAAが効いている
www.example.com を CNAME でCDNやSaaSに向けている場合、www.example.com のCAAを問い合わせると、DNSはCNAMEをたどって向け先の名前のCAAを返します。向け先にCAAがあれば、それが www.example.com のCAAとして扱われます。自分のゾーンに書いたCAAとは別の内容で判定されるため、「CAAは正しく書いたのに断られる」原因になります。
なお、同じ名前にCNAMEとCAAを並べることはできません。CNAMEのある名前にCAAを足そうとして拒否されるのはこのためです。
3. issue と issuewild がぶつかっている
issuewild があると、ワイルドカード証明書（*.example.com）の判定には issue ではなく issuewild が使われます。通常の証明書は Let's Encrypt で、ワイルドカードは別の認証局で、と分けたつもりが、issuewild に必要な認証局が抜けていてワイルドカードだけ更新できない、という形の競合です。issuewild ";" はワイルドカードの発行をすべて禁止する指定です。
4. 追加パラメータが別のサービスを締め出している
accounturi で認証局のアカウントを、validationmethods で検証方法を限定できる認証局があります。自分のサーバーの certbot のアカウントに限定したところ、同じ認証局を使うホスティング会社の自動SSLが別のアカウントで申請していて断られる、というのが典型です。
5. DNSサービスが自動で足すCAAと手書きのCAA
DNSサービスによっては、自社で使う認証局のCAAを自動で追加する仕組みがあります。Cloudflare では、利用者がCAAを追加すると、Universal SSL などで使う認証局の分を自動で補うと案内されています（2026年10月現在）。自分の一覧に見えない値が応答に含まれることがあるため、判断は管理画面ではなく dig の結果で行います。
ステップ1：誰がどの認証局で発行しているかを洗い出す
まず、そのドメインの証明書を実際に発行しているサービスと認証局を把握します。証明書は Certificate Transparency のログに記録されるため、crt.sh などの検索サービスでドメイン名を調べると、過去に発行された証明書と発行元の一覧が見られます。
あわせて、今使われている証明書を名前ごとに確認します。
echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
| openssl x509 -noout -issuer -subject -dates名前（ルートドメイン、www、サブドメイン、ワイルドカード）ごとに、「どのサービスが、どの認証局で、どの検証方法で」発行しているかを表にします。CDNやホスティングの管理画面にも、使う認証局が書かれていることがあります。
ステップ2：名前ごとに実際に効いているCAAを調べる
名前ごとに、実際に判定に使われるCAAを確かめます。
dig +noall +answer www.example.com CAA
dig +noall +answer www.example.com CNAME
dig +noall +answer example.com CAAwww.example.com がCNAMEなら、最初のコマンドの結果は向け先のCAAです。何も返らなければ、親の example.com のCAAが使われます。ステップ1の表に、名前ごとの「効いているCAA」の列を足し、使われている認証局が含まれているかを照らし合わせます。含まれていない組み合わせが、競合している箇所です。
ステップ3：許可する認証局を決め直す
競合している箇所ごとに、次のどれかで解消します。
- CAAに認証局を足す: もっとも一般的な方法です。使われている認証局の識別子を
issue（必要ならissuewild）に追加します - サービス側の認証局を変える: CDNやホスティングで認証局を選べる場合は、CAAにすでにある認証局にそろえる方法もあります
- サブドメインに専用のCAAを置く: 特定のサブドメインだけ別の認証局を使うなら、その名前にCAAを置くと、親のCAAより優先されます。CNAMEの名前には置けないので、その場合は向け先側の設定に従います
認証局の識別子は、各認証局が公開している値を使います。たとえば Let's Encrypt は letsencrypt.org、Google Trust Services は pki.goog です。AWS Certificate Manager は amazon.com などの値を案内しています。識別子は認証局の公式ドキュメントで確認してから書きます。
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "pki.goog"
example.com. 3600 IN CAA 0 issue "amazon.com"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"accounturi などのパラメータは、同じ認証局を複数のサービスが使っている間は付けないほうが安全です。
ステップ4：追加してから削除する順で反映する
作業前に、DNSのレコードをエクスポートしておきます。変更は、新しく許可する認証局を先に追加し、不要になった認証局はあとで削除する順で進めます。先に削除すると、その間に更新の時期を迎えたサービスが失敗します。
反映後は権威DNSに直接問い合わせて、変更が入っているかを見ます。
dig +short NS example.com
dig @ns1.example.net +norecurse +noall +answer example.com CAACAAにもTTLがあり、認証局側が古い応答を短時間キャッシュすることもあるため、変更直後に失敗しても少し待って再試行します。
ステップ5：各サービスで発行できるかを確かめる
自分のサーバーの certbot は、テスト環境で更新を試せます。テスト環境でもCAAの確認は行われます。
sudo certbot renew --dry-runCAAで断られると、エラーにCAAが発行を妨げている旨が表示されます。CDNやホスティングの自動SSLは、管理画面で証明書の状態や再発行の操作を確認し、エラーが出ていないかを見ます。WordPressサイトでは、証明書が切れると管理画面にも入れなくなるため、更新期限の前に確かめておきます。
まとめ
- CAAに書いていない認証局はすべて締め出されるため、サービスの追加や認証局の変更で競合が表面化する
- CNAMEの名前では向け先のCAAが効き、同じ名前にCNAMEとCAAは並べられない
- ワイルドカードは
issuewildで判定され、accounturiなどは別サービスを締め出すことがある - CTログと
openssl s_clientで実際の発行元を洗い出し、名前ごとに効いているCAAと照らし合わせる - 認証局は追加してから削除する順で変え、
--dry-runや各サービスの画面で発行できるかを確かめる