CAA レコード自体は鍵を持たないため、「CAA の鍵」を回す作業はありません。ローテーションの対象になるのは、証明書の秘密鍵と ACME アカウントの鍵で、CAA はそれらを入れ替えるときに発行を止めないための確認項目になります。この記事では、定期的な鍵の入れ替えと、鍵が漏れた疑いがあるときの緊急の入れ替えを手順に落とし込み、それぞれの段階で CAA の何を確かめればよいかを説明します。
ACME アカウントを作り直したときに accounturi を書き換える個別の手順は、ここでは要点だけにとどめ、ローテーションを運用として回すことに重点を置きます。
回る鍵と、CAA が関わる場面
| 入れ替えるもの | CAA の変更 | CAA の確認 |
|---|---|---|
| 証明書の秘密鍵（同じ認証局・同じアカウント） | 不要 | 要る（発行のたびに参照されるため） |
| ACME アカウントの鍵（鍵の付け替え） | 通常は不要 | 要る |
| ACME アカウントそのもの（作り直し） | accounturi を使っていれば要る |
要る |
| 認証局の乗り換え | 要る | 要る |
認証局は証明書を発行するたびに CAA を調べます。鍵を入れ替える作業は、そのまま新しい証明書の発行を伴うので、CAA を変えない場合でも「今の CAA で発行が通るか」を確かめる意味があります。
ローテーションの頻度が上がっている
公開証明書の有効期間は、CA/ブラウザフォーラムの決定により段階的に短くなる予定です。公表されている計画では、2026年3月から最長200日、2027年3月から100日、2029年3月から47日へと短縮されます（2026年10月現在の計画。最新の状況は認証局の告知で確認してください）。Let's Encrypt も、より短い有効期間の証明書を提供する方針を示しています。
有効期間が短くなるほど発行の回数が増え、CAA が参照される回数も増えます。CAA の設定ミスが表に出るまでの時間も短くなるため、ローテーションを手作業ではなく自動化し、その流れに CAA の確認を組み込んでおくことが大切になります。
定期ローテーション：証明書の秘密鍵
鍵が実際に入れ替わっているかを確かめる
Certbot は、既定では更新のたびに新しい秘密鍵を作ります。--reuse-key を指定した証明書だけは同じ鍵を使い続けます。どちらになっているかは、更新の前後で公開鍵の指紋を比べると分かります。
# 現在の証明書の公開鍵の指紋（SHA-256）を表示する
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -pubkey \
| openssl pkey -pubin -outform DER | openssl dgst -sha256
# 証明書ごとの設定（reuse_key の有無など）
sudo grep -H reuse_key /etc/letsencrypt/renewal/*.conf更新後に指紋が変わっていれば、鍵は入れ替わっています。DANE（TLSA）やアプリ側の公開鍵ピンニングで鍵を固定している環境では、鍵の入れ替えで照合が外れるため、--reuse-key で鍵を固定するか、新しい鍵の値を先に公開する運用が必要です。
更新の前に CAA を確かめる
自動更新の前に、CAA が想定どおりかを確かめる処理を入れておくと、発行の失敗を前もって知ることができます。Certbot の --pre-hook で簡単な確認を走らせる例です。
#!/bin/bash
# /usr/local/bin/caa-precheck.sh（例）: 許可したい値が CAA に無ければ警告する
NAME="example.com"
WANT='issue "letsencrypt.org"'
if ! dig +short "$NAME" CAA | grep -qF "$WANT"; then
logger -t caa-precheck "CAA に $WANT が見つかりません: $NAME"
fi
exit 0sudo certbot renew --pre-hook /usr/local/bin/caa-precheck.shこの例は警告を記録するだけで、更新は止めません。--pre-hook は更新対象の証明書があるときだけ実行されます。accounturi などのパラメーターを付けた行を使っている場合は、WANT を実際の行の書き方に合わせてください。CAA が空（未設定）の場合はどの認証局でも発行できるため、未設定の状態を許容するかどうかは運用に合わせて判断してください。
ステージングで試す
certbot renew --dry-run は Let's Encrypt のステージング環境で発行を試します。ステージングでも CAA は確認されます。ここで注意したいのが accounturi です。ステージングのアカウントは本番とは別の URL になるため、CAA に本番アカウントの accounturi だけを書いていると、ドライランは失敗します。ドライランを定期点検に使うなら、ステージングのアカウント URL も許可するか、ドライランの失敗理由を読み分ける必要があります。
定期ローテーション：ACME アカウントの鍵
ACME（RFC 8555）には、アカウントの URL を変えずに鍵だけを付け替える仕組み（key rollover）があります。この方法なら accounturi は変わらないため、CAA の変更は要りません。ただし、ACME クライアントによってこの機能への対応状況は異なります。お使いのクライアントが対応していない場合、鍵の入れ替えはアカウントの作り直しになり、accounturi の更新が必要になります。
Certbot の場合、アカウントの URL は次のファイルで確かめられます。
sudo find /etc/letsencrypt/accounts -name regr.json -exec grep -H '"uri"' {} \;CAA に accounturi を書いている場合は、ここに出る URL と CAA の値が一致しているかを、ローテーションの前後で確かめます。アカウントを作り直すときは、新旧両方の accounturi を一時的に許可し、新しいアカウントで発行できたことを確かめてから旧い行を外す、という順序にすると発行を止めずに済みます。
緊急ローテーション：鍵が漏れた疑いがあるとき
秘密鍵がバックアップの誤公開やサーバー侵害で漏れた疑いがある場合は、次の順で進めます。
- 新しい鍵で証明書を取り直す。 更新を強制して、新しい鍵の証明書を発行し、ウェブサーバーに反映します。
``bash sudo certbot renew --cert-name example.com --force-renewal
- 古い証明書を失効させる。
--cert-nameで指定すると「今の証明書」、つまり取り直したばかりの新しい証明書が対象になってしまいます。古い証明書はarchive配下のファイルを直接指定します。
``bash # 番号は環境に合わせる（取り直す前の certN.pem） sudo certbot revoke --cert-path /etc/letsencrypt/archive/example.com/cert3.pem --reason keycompromise
keycompromise を理由にすると、認証局がその鍵での今後の発行を拒否する扱いになることがあります。
- アカウント鍵も漏れた可能性があるなら、アカウントを無効化して作り直す。 Certbot では
certbot unregisterでアカウントを無効化できます。作り直したアカウントで発行する前に、CAA のaccounturiを新しい URL に更新します。順序を間違えると、取り直しの発行が CAA で拒否されます。
- CT ログで不審な発行がないかを確かめる。 証明書は Certificate Transparency のログに記録されます。crt.sh などの検索サービスで、自分のドメインに覚えのない証明書が出ていないかを確認します。
緊急時に CAA の TTL が長いと、accounturi の変更が行き渡るまで待つことになります。普段から TTL を極端に長くしないこと、手順書に「CAA の変更が要るかどうか」の判断を書いておくことが、緊急時の時間を縮めます。
予備の認証局を CAA に入れておくか
主に使う認証局で障害や発行停止が起きたときに備え、別の認証局を CAA に許可しておく考え方があります。常に許可しておけば切り替えは速くなりますが、許可する認証局が増えるほど、意図しない発行を許す範囲も広がります。切り替えるときだけ追加する方針なら、範囲は狭く保てる代わりに、TTL の分だけ切り替えに時間がかかります。どちらを選ぶかは、サイトの重要度と、CAA を変更できる担当者がすぐ動けるかで決めます。
まとめ
- CAA に鍵はありません。回すのは証明書の秘密鍵と ACME アカウントの鍵で、CAA は発行を止めないための確認項目です。
- 証明書の鍵の入れ替えでは CAA の変更は要りませんが、発行のたびに CAA が参照されるため、更新前の確認を自動化しておくと安心です。
- アカウント鍵は付け替えなら
accounturiは変わらず、作り直しなら更新が要ります。ステージングのドライランは別アカウント扱いになる点に注意します。 - 緊急時は「新しい鍵で取り直す→古い証明書を archive のファイルで失効→必要ならアカウントと CAA を更新→CT ログを確認」の順で進めます。