CAAレコードを追加・変更したのに証明書の発行や更新で「CAAレコードが発行を妨げている」といったエラーが続く場合は、次の3点を順に確認します。権威サーバーが本当に新しいCAAを返しているか、認証局が実際に見る名前（サブドメインやCNAMEの先）に別のCAAが無いか、値の書き方が認証局の求める形になっているかです。CAAは認証局が発行の直前に確認するもので、反映待ちに見えても、実は別の名前のCAAが効いていることがよくあります。この記事では、認証局がCAAを探す順番、確認のコマンド、多い原因ごとの直し方を説明します。
認証局がCAAを探す順番
CAA（RFC 8659）は、証明書を発行してよい認証局をドメインの持ち主が指定するレコードです。認証局は、証明書に入れる名前ごとに、次の順でCAAを探します。
- その名前（例：
shop.www.example.com）のCAAを引く - 無ければ、ラベルを1つずつ削った親の名前（
www.example.com、次にexample.com）のCAAを引く - 最初に見つかったCAAの組だけを使う。それより上の名前のCAAとは合算しない
- どこにもCAAが無ければ、どの認証局も発行してよいことになる
名前がCNAMEになっている場合は、通常の名前解決と同じくCNAMEの先をたどってCAAを引きます。そのため、www をCDNなどのサービスに向けていると、向け先のドメインにあるCAAが効くことがあります。
この仕組みから、「example.com のCAAを直したのに、www の証明書が出ない」という場合は、www 自体かそのCNAMEの先に別のCAAがある可能性が高いと言えます。
確認のコマンド
まずは、証明書に入れるすべての名前について、上の名前までさかのぼってCAAを確かめます。
# 証明書に入れる名前と、その親の名前のCAA
dig www.example.com CAA +short
dig example.com CAA +short
# CNAMEになっていないか（CNAMEが返れば、その先のCAAも調べる）
dig www.example.com CNAME +short
# 権威サーバーに直接問い合わせて、キャッシュの影響を除く
dig example.com NS +short
dig @ns1.example-dns.net example.com CAA +norecurse古い dig や一部のツールではCAAという種類名を受け付けないことがあります。その場合は dig example.com TYPE257 のように番号で指定します。Windows では Resolve-DnsName -Name example.com -Type CAA も使えます。
権威サーバーに直接聞いた結果と、dig @1.1.1.1 などの公開リゾルバの結果が違えば、キャッシュの残りです。旧レコードのTTLが切れるまで待ちます。
原因1：管理画面で編集したDNSが権威サーバーではない
ネームサーバーを移した後に、旧DNSサービスの画面でCAAを編集していた、というのはよくある取り違えです。dig example.com NS +short で表示されたネームサーバーと、編集した管理画面のサービスが一致しているかを確認します。一致していなければ、表示されたネームサーバーの側で設定します。
原因2：サブドメインやCNAMEの先に別のCAAがある
前述のとおり、認証局は最初に見つかったCAAだけを使います。example.com に letsencrypt.org を許可するCAAがあっても、www.example.com に別の認証局だけを許可するCAAがあれば、www の証明書は Let's Encrypt から発行できません。
直し方は、サブドメインのCAAを削除して親のCAAに任せるか、サブドメインのCAAにも必要な認証局を追加することです。CNAMEの先にあるCAAは自分では変えられないことが多いため、その場合は向け先のサービスの案内に沿って、そのサービスが使う認証局を確認します。
原因3：値の書き方の誤り
CAAは「フラグ」「タグ」「値」の3つで構成されます。
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"- 値に書くのは認証局が指定するドメイン名（Let's Encrypt なら
letsencrypt.org）です。認証局の会社名やWebサイトのURLではありません。値は認証局ごとに決まっているので、利用する認証局のドキュメントで確認します - 管理画面によっては値のダブルクォートを自動で付けるため、自分でも付けると二重になり、別の値として扱われることがあります。
dig +shortの結果で、クォートが1組になっているかを見ます issuewildはワイルドカード証明書（*.example.com）の発行を制御します。issuewildが存在すると、ワイルドカードについてはissueより優先されます。上の例のように";"を書くと、ワイルドカードの発行はどの認証局にも許可しない設定になります- フラグは通常
0です。128（critical）にすると、認証局が理解できないタグがある場合に発行を止めるので、意図せずに付けないようにします
原因4：accounturi などの追加パラメータが合っていない
値の後ろに accounturi（RFC 8657）を付けると、特定のACMEアカウントからの申請だけに発行を限定できます。
example.com. 3600 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789"この設定をした後にサーバーを移し、新しいサーバーでACMEクライアントのアカウントを作り直すと、アカウントのURLが変わって発行できなくなります。更新が突然止まった場合は、CAAにこのパラメータが無いか確認し、新しいアカウントのURLに書き換えるか、いったんパラメータを外します。アカウントのURLは、Certbot ならアカウント情報の保存場所に記録されています（保存場所はインストール方法により異なります）。
原因5：DNSSECやDNSの応答の不具合
認証局がCAAを問い合わせたときに、権威サーバーが応答しない、エラーを返す、DNSSECの検証に失敗する、といった場合は、CAAの中身に関係なく発行が止まります。エラーメッセージに SERVFAIL やタイムアウトの文字が含まれる場合はこちらを疑います。
# DNSSECの検証を外すと答えが返るなら、DNSSECの不具合
dig @1.1.1.1 example.com CAA
dig @1.1.1.1 example.com CAA +cd一部の古いDNSサーバーや機器は、知らない種類のレコードへの問い合わせに正しく答えないことがあります。すべての権威サーバーに直接問い合わせて、どれもCAAに正常に答えるかを確かめます。Let's Encrypt を使っている場合は、Let's Encrypt が案内しているDNSの診断用サービス（unboundtest.com）で、同じ条件の名前解決を試すこともできます。
反映を待つときの目安
認証局は、発行の直前にCAAを確認します。業界の基準（CA/Browser Forum の Baseline Requirements）では、認証局は発行前の一定時間内（CAAのTTLか8時間の長いほう）に確認した結果を使えるとされています。権威サーバーで新しい値が返っていても、直前に失敗した申請の結果がしばらく使われることがあるため、修正後に何度も申請を繰り返すより、TTLが過ぎるのを待ってから申請するほうが、発行回数の制限にもかかりにくくなります。
CAAを変更する前には、現在の値を控えておきます。変更の予定があるなら、事前にTTLを短くしておくと、誤りに気付いたときに戻しやすくなります。認証局ごとのCAAの値や確認の運用は変わることがあります（2026年10月現在）。
まとめ
- 権威サーバーへの直接問い合わせで、新しいCAAが返っているかをまず確かめる
- 認証局は名前ごとに親へさかのぼり、最初に見つかったCAAだけを使う。サブドメインとCNAMEの先も確認する
- 値は認証局が指定するドメイン名。クォートの二重付与、
issuewildの優先、フラグ128に注意する accounturiを使っている場合は、ACMEアカウントを作り直すと発行できなくなる- SERVFAILやタイムアウトはDNSSECや権威サーバーの不具合。修正後はTTLを待ってから申請する