CAA レコード自体は鍵を持っていないため、SSL 証明書の秘密鍵を新しくするだけなら CAA を書き換える必要はありません。書き換えが要るのは、認証局を変えるとき、そして CAA の accounturi で ACME アカウントを指定していて、アカウント鍵の更新のためにアカウントそのものを作り直すときです。この記事では、鍵の更新に関わる作業ごとに CAA の変更が要るかどうかを整理し、変更が要る場合に証明書の発行を止めずに CAA を更新する手順を説明します。
CAA と「鍵」の関係を整理する
CAA（Certification Authority Authorization、RFC 8659）は、「このドメインの証明書を発行してよい認証局」を DNS で宣言するレコードです。認証局は証明書を発行する前に CAA を確認し、自分が許可されていなければ発行を断ります。CAA に書くのは認証局の識別名（Let's Encrypt なら letsencrypt.org）と、必要に応じた追加の条件だけで、公開鍵や鍵の指紋は書きません。
一方、証明書の運用には次の2種類の鍵が出てきます。
- 証明書の秘密鍵：Web サーバーが TLS で使う鍵です。証明書の更新のたびに作り直すのが一般的で、CAA とは関係しません。
- ACME アカウント鍵：certbot などの ACME クライアントが、認証局のアカウントとして署名に使う鍵です。CAA の
accounturiを使っている場合だけ、CAA と結び付きます。
もう1つ、ゾーンを DNSSEC で署名している場合の DNSSEC の鍵（ZSK・KSK）があります。この鍵の更新では CAA の内容は変わりませんが、CAA の署名が検証できなくなると認証局は発行を止めます。DNSSEC の鍵の更新時に CAA で気を付ける点は、別の話題として扱います。
作業ごとに CAA の変更が要るかを判断する
| 作業 | CAA の変更 |
|---|---|
| 同じ認証局で証明書を更新する（秘密鍵も作り直す） | 不要 |
| 同じ ACME アカウントのまま、アカウント鍵を差し替える（keyChange） | 不要（アカウント URL が変わらない） |
| ACME アカウントを作り直す（新しいアカウント鍵で登録し直す） | accounturi を使っていれば必要 |
| 認証局を変える（例: 別の認証局のサービスへ移る） | 必要（新しい認証局を許可する） |
| ワイルドカード証明書を新しく使い始める | issuewild を書いている場合は確認が必要 |
| 検証方法を変える（HTTP-01 から DNS-01 へなど） | validationmethods を使っていれば必要 |
ACME の仕様（RFC 8555）には、アカウント URL を変えずにアカウント鍵だけを差し替える keyChange という手続きがあります。ただし、ACME クライアントがこれに対応しているとは限りません。代表的な certbot には、アカウント鍵だけを差し替える機能は用意されていないと案内されることが多く、アカウント鍵を新しくしたい場合は新しいアカウントを登録し直すのが一般的です（2026年10月現在。使っている版の certbot --help で確認してください）。新しいアカウントはアカウント URL が変わるため、accounturi を使っていると、CAA を先に更新しないと証明書の発行が止まります。
accounturi とは
accounturi（RFC 8657）は、CAA の issue に付けるパラメーターで、発行を申請できる ACME アカウントを限定します。DNS を乗っ取られたり、Web サーバーの一部を書き換えられたりしても、アカウント鍵を持たない第三者には証明書を発行させない、という守りになります。
example.com. 3600 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/111111111"アカウント URL の数字は例です。自分のアカウント URL は ACME クライアントで確認できます。certbot なら次のコマンドで表示されます。
sudo certbot show_accountアカウント URL の形式は認証局が決めるもので、表示されたものをそのまま使います。推測で組み立てないでください。
発行を止めずに CAA を更新する手順
ここからは、accounturi を使っている状態で ACME アカウントを作り直す場合を例にします。認証局を変える場合も、考え方は同じです。
1. 現在の CAA を確認する
# CAA を確認する（example.com は自分のドメインに置き換える）
dig +short example.com CAA
# サブドメインの証明書なら、そのサブドメインと上位のドメインの両方を見る
dig +short www.example.com CAACAA は、証明書に含める名前から順に上位のドメインへたどって、最初に見つかったものが使われます。www.example.com に CAA がなければ example.com の CAA が適用されます。どの階層の CAA を書き換えるべきかを、ここで確かめます。権威 DNS が複数ある場合は、それぞれに dig @ネームサーバー で問い合わせ、内容が一致しているかも確認します。
2. 新しいアカウントを用意し、アカウント URL を控える
新しい ACME アカウントを登録し、そのアカウント URL を控えます。古いアカウントは、移行が終わるまで消さずに残しておきます。certbot で複数のアカウントがある場合、どのアカウントで証明書を発行・更新するかは --account オプションや、証明書ごとの更新設定（/etc/letsencrypt/renewal/ 以下）で決まります。
3. 新旧の両方を許可する CAA を追加する
古い行を消さずに、新しいアカウントの行を追加します。同じ名前に複数の issue があると、どれか1つに合えば発行が許可されます。
example.com. 3600 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/111111111"
example.com. 3600 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/222222222"ワイルドカード証明書を使っている場合は、issuewild の行にも同じ変更を入れます。issuewild がある場合、ワイルドカード証明書の発行には issue ではなく issuewild が使われます。
DNS サービスの管理画面によっては、CAA の値をフラグ・タグ・値に分けて入力する形式です。値の欄に、二重引用符の中身（letsencrypt.org; accounturi=...）を入れるのが一般的ですが、入力形式はサービスごとに異なるため、各サービスのヘルプで確認してください。
4. TTL の時間だけ待ってから、新しいアカウントで発行する
認証局は DNS のキャッシュを経由して CAA を確認することがあるため、変更前の TTL の時間が過ぎてから発行を試します。新しいアカウントで証明書を発行し、更新設定が新しいアカウントを使う状態になったことを確認します。
# 新しいアカウントで発行し直す例（アカウント ID とドメインは自分のものに置き換える）
sudo certbot certonly --cert-name example.com --account 新しいアカウントのID -d example.com -d www.example.com --force-renewal
# 更新設定がどのアカウントを使うか確認する
sudo grep '^account' /etc/letsencrypt/renewal/example.com.conf発行に失敗した場合、エラーメッセージに CAA が原因であることが示されます。そのときは手順1に戻り、アカウント URL の写し間違いや、別の階層の CAA が優先されていないかを確認します。
5. 古い許可を外す
新しいアカウントでの発行と、次回の更新が問題なく行えることを確かめてから、古いアカウントの行を CAA から削除します。急いで消すと、古いアカウントで更新しようとしている別のサーバーがあった場合に、そちらが止まります。同じドメインの証明書を複数のサーバーで取得している構成では、すべてのサーバーを移行してから外します。
つまずきやすい点
- テスト環境（ステージング）での確認が失敗する。 Let's Encrypt のステージング環境のアカウントは、本番とは別のアカウント URL を持ちます。ステージング環境でも CAA は確認されるため、本番のアカウントだけを
accounturiで許可していると、certbot renew --dry-runが CAA で失敗することがあります。ステージングでの確認を続けたい場合は、ステージングのアカウント URL を許可する行も加えます。 - レンタルサーバーの無料 SSL を使っている。 共用サーバーで WordPress を運用していて、サーバー会社が自動で証明書を発行している場合、どの認証局のどのアカウントで発行しているかは利用者から見えないことがほとんどです。この場合に
accounturiを付けると、自動更新が止まる恐れがあります。CAA を使うなら認証局の指定にとどめ、サーバー会社の案内に従ってください。 - CDN が証明書を発行している。 CDN が利用者に代わって証明書を発行する構成では、CDN が使う認証局も許可する必要があります。CDN によっては CAA に必要な値を自動で補う仕組みがありますが、扱いはサービスごとに異なるため、各サービスのドキュメントで確認してください。
CAA の変更は、誤ると証明書の更新が止まり、期限切れでサイトに警告が出る原因になります。変更前の CAA の内容を控えておき、証明書の有効期限に余裕があるうちに作業してください。
まとめ
- CAA 自体は鍵を持たないため、証明書の秘密鍵を更新するだけなら CAA の変更は不要です。
- 変更が要るのは、認証局を変えるときと、
accounturiを使っていて ACME アカウントを作り直すとき（certbot でアカウント鍵を新しくする場合は、これに当たることが多い）です。 - 更新は「新旧の両方を許可する行を追加 → TTL を待つ → 新しいアカウントで発行 → 次回の更新を確認 → 古い行を削除」の順で進めます。
- ステージング環境のアカウント、レンタルサーバーや CDN による自動発行は、
accounturiと相性が悪いので事前に確認します。