CAA レコードそのものには鍵がありません。ただし、証明書の鍵や ACME アカウントの鍵、利用する認証局（CA）を変えるときは、CAA の書き方しだいで次の証明書が発行できなくなります。この記事では、どの「鍵の更新」で CAA の修正が必要になるのかを整理し、accounturi を使っている場合の新旧併記の手順、CA を乗り換える場合の順序、反映の確認と後片付けまでを説明します。
先に結論：CAA の修正が必要になるのはどの場合か
CAA（RFC 8659）は「このドメインの証明書を発行してよい CA」を DNS で宣言するレコードです。CA は発行の直前に CAA を確認し、自分が許可されていなければ発行を断ります。鍵の更新と CAA の関係は次のとおりです。
- 証明書の秘密鍵だけを新しくする。 同じ CA、同じ ACME アカウントで取り直すなら、CAA の変更は不要です。CAA は証明書の鍵を見ていません。
- ACME アカウントの鍵を差し替える。 ACME（RFC 8555）にはアカウントの鍵だけを入れ替える手続き（key change）があり、これを使えばアカウントの URL は変わりません。
accounturiを書いていても影響はありません。 - ACME アカウントを作り直す。 サーバーの移行や certbot の再インストールで新しいアカウントを登録すると、アカウントの URL が変わります。CAA に
accounturiを書いている場合は、先に新しい URL を追加しないと発行が止まります。 - CA を乗り換える。 CAA に新しい CA の識別子を追加する必要があります。
- DNSSEC の鍵（KSK・ZSK）を更新する。 CAA の内容は変わりませんが、署名の検証に失敗すると CA が CAA を確認できず、発行が止まることがあります。これは DNSSEC の鍵更新の手順として別に管理します。
つまり、作業が必要なのは「アカウントが変わる」「CA が変わる」の2つです。以下はこの2つを中心に説明します。
現状を把握する
いまの CAA を確かめる
CA は証明書のドメイン名そのものから順に親のドメインへさかのぼり、最初に見つかった CAA を適用します。www.example.com に CAA がなければ example.com の CAA が使われます。対象の名前ごとに確認しておきます。
dig +short example.com CAA
dig +short www.example.com CAA
dig +short doh.example.com CAA
# 権威 DNS サーバーに直接聞く（キャッシュの影響を避ける）
dig +short example.com NS
dig +norec @ns1.example-dns.net example.com CAA出力は次のような形になります。
0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789"
0 issuewild ";"
0 iodef "mailto:security@example.com"issue は通常の証明書、issuewild はワイルドカード証明書の許可です。issuewild ";" はワイルドカードをどの CA にも許可しないという意味になります。先頭の 0 はフラグで、128 が付いた値は「理解できない CA は発行してはならない」という指定です。
どのサーバーが、どのアカウントで証明書を取っているか
見落としやすいのが、同じドメインの証明書を複数のサーバーが別々の ACME アカウントで取っているケースです。Web サーバー、メールサーバー、DoH リゾルバーなどでそれぞれ certbot を動かしていれば、アカウントもそれぞれ別になります。accounturi を1つしか書いていないと、ほかのサーバーの更新が失敗します。
発行済みの証明書は Certificate Transparency のログに記録されるため、crt.sh などの検索サービスでドメイン名を調べると、どの CA から、いつ、どの名前で発行されたかが一覧できます。ここで洗い出した CA とサーバーを、CAA に必要な許可の一覧として控えておきます。
certbot のアカウント URL は、比較的新しいバージョンなら certbot show_account で表示できます。表示できない場合は、/etc/letsencrypt/accounts/ 以下の regr.json に記録された uri を確認します。
sudo certbot show_account
sudo find /etc/letsencrypt/accounts -name regr.json -exec grep -H '"uri"' {} \;ACME アカウントを作り直すときの手順
1. TTL を短くしておく
作業の前日などに、CAA の TTL を 300 秒程度に下げておきます。変更が早く行き渡り、間違えたときも戻しやすくなります。なお、CA は CAA の確認結果を一定時間（業界の基準では最長8時間）使い回すことが認められているため、TTL を下げても CA 側の反映には時間がかかる場合があります。
2. 新しいアカウントを作り、URL を CAA に追加する
新しいサーバーで ACME アカウントを登録し、その URL を確認します。証明書はまだ取りません。そのうえで、旧アカウントの行を残したまま新アカウントの行を追加します。同じ名前に issue が複数あると、どれか1つに当てはまれば発行が許可されます。
example.com. 300 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789"
example.com. 300 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/987654321"
example.com. 300 IN CAA 0 iodef "mailto:security@example.com"アカウント ID の数字はダミーです。URL は一文字でも違うと一致しないため、手で打たずにコピーして貼り付けます。ステージング環境のアカウントは本番とは別の URL になる点にも注意してください。
validationmethods=dns-01 のように、許可する検証方法まで絞っている場合は、新しいサーバーでも同じ方法で検証できるかを先に確かめます。HTTP で検証する設定のまま移行すると、CAA に弾かれます。
3. 新しいアカウントで証明書を取る
TTL が切れるのを待ってから発行します。certbot なら、いきなり本番を叩かず --dry-run で試すと、CAA に弾かれるかどうかが分かります。Let's Encrypt のステージング環境も CAA を確認しますが、accounturi は本番とステージングで別のアカウントになるため、ステージング用の行を一時的に追加していなければ失敗します。その場合は本番で1回だけ試すか、ステージングのアカウント URL も一時的に書き加えます。
CAA が原因で発行が断られた場合、エラーメッセージに CAA や「CAA record prevents issuance」といった文言が含まれます。表記は CA やクライアントで異なるため、ログ全体を見て判断してください。
4. 旧アカウントの行を外す
旧サーバーを止め、旧アカウントでの更新が今後発生しないことを確かめてから、CAA から旧アカウントの行を削除します。最後に TTL を元の値（3600 秒など）に戻します。
CA を乗り換えるときの手順
考え方は同じで、「新しい CA を追加して発行を確かめ、古い CA を外す」の順に進めます。
example.com. 300 IN CAA 0 issue "letsencrypt.org"
example.com. 300 IN CAA 0 issue "pki.goog"pki.goog は Google Trust Services の識別子の例です。CA ごとの識別子は各 CA のドキュメントに記載されており、ブランド名と一致しないこともあります（ある CA のサービスが別の CA の識別子を使う例もあります）。名前から推測せず、公式の記載を確認してから書き込むのが安全です。
ワイルドカード証明書を使う場合は、issuewild にも新しい CA を加えます。issuewild が存在すると、ワイルドカードの発行には issue ではなく issuewild が使われるためです。
作業後の確認
- 対象の名前ごとに
dig +short <名前> CAAを実行し、意図した行だけが残っているかを見ます。 - 証明書の次回の自動更新で失敗しないよう、各サーバーで
certbot renew --dry-runを実行しておきます。ただし--dry-runはステージング環境のアカウントで動くため、accounturiで本番のアカウントだけを許可していると、CAA の確認で失敗することがあります。その場合はステージングのアカウント URL（https://acme-staging-v02.api.letsencrypt.org/acme/acct/...の形）を一時的に追加するか、失敗の理由が CAA のaccounturiだけであることをログで確かめたうえで判断します。 - 複数の DNS サービスを使い分けている場合（サブドメインだけ別の DNS に委任しているなど）は、委任先にも CAA があるかを確かめます。
CAA は証明書の発行時にだけ参照されます。すでに発行済みの証明書は、CAA を変えても失効しません。そのため、CAA の誤りは次の更新のタイミングで初めて表面化します。更新の前に --dry-run で確かめる習慣を付けておくと、期限切れを防げます。
まとめ
- CAA に鍵はありません。証明書の秘密鍵だけを入れ替えるなら CAA の修正は不要です。
- 修正が必要なのは「ACME アカウントが変わる」「CA が変わる」の2つで、どちらも新しい許可を追加して発行を確かめてから古い許可を外します。
accounturiを書いている場合は、ドメインの証明書を取っているすべてのサーバーのアカウント URL が含まれているかを確認します。- 事前に TTL を短くし、CA 側の確認結果の使い回し（最長8時間）も見込んで作業時間を取ります（2026年10月現在の業界基準）。
- 作業後は各サーバーで次の自動更新が通るかを確かめます。
accounturiを使っている場合、ステージングでの試験はアカウントの違いで失敗することがある点に注意します。