CAA レコードの導入は、「今どの認証局から証明書を受け取っているかを洗い出す」「その認証局をすべて許可する形で短い TTL で登録する」「次の証明書更新が通るのを見届けてから絞り込む」の3段階で進めると、発行を止めずに済みます。この記事では、WordPress サイトを運用している人が初めて CAA を入れる場面を想定し、作業前の準備、登録、確認、問題が出たときの戻し方までを、作業の順番どおりに説明します。
CAA を入れると何が変わるか
CAA（RFC 8659）は、そのドメインの証明書を発行してよい認証局を DNS で宣言するレコードです。認証局は発行の前に CAA を調べ、自分が許可されていなければ発行を断ります。CAA が無いドメインは、どの認証局でも発行できる状態です。
導入の効果は、意図しない認証局からの発行を減らせることです。一方で、許可の漏れがあると、正規の更新まで止まります。証明書の更新は数十日から数か月おきなので、設定を誤っても気づくのは次の更新時です。導入の難しさは書式ではなく、この「時間差」にあります。
手順1：発行元を洗い出す
今の証明書を調べる
まず、サイトで使われている証明書の発行元を確かめます。
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -issuer -datesissuer に出る名前から、どの認証局かが分かります。ブラウザの鍵アイコンから証明書の詳細を開いても確かめられます。
過去に発行された証明書を調べる
今の証明書だけでは、サブドメインや別のサービスが使っている認証局を見落とします。証明書は Certificate Transparency（CT）のログに記録されるので、crt.sh などの検索サービスでドメイン名を検索し、直近1年ほどに発行された証明書の発行元を一覧にします。
洗い出しで漏れやすいのは次のようなものです。
- レンタルサーバーやマネージド WordPress の無料 SSL（事業者が使う認証局は、Let's Encrypt が多いものの、事業者ごとに異なり、変わることもあります）
- CDN やセキュリティサービス（Cloudflare などは複数の認証局を使い分けることがあります）
- メール、フォーム、ヘルプデスクなど、サブドメインを CNAME で外部サービスに向けているもの
- 社内の別部署が管理しているサブドメイン
一覧を作る
調べた結果を「ホスト名・発行元・管理者・次の更新日」の表にまとめます。この表がそのまま CAA の設計の材料になり、あとで問題が起きたときの連絡先にもなります。
手順2：記述を決める
最初の登録では、洗い出した認証局をすべて許可し、絞り込みは後回しにします。代表的な認証局の識別子は次のとおりです（2026年10月現在。正確な値は各認証局の案内で確認してください）。
| 認証局 | CAA に書く値の例 |
|---|---|
| Let's Encrypt | letsencrypt.org |
| Google Trust Services | pki.goog |
| Sectigo | sectigo.com |
| DigiCert | digicert.com |
| Amazon（ACM） | amazon.com など |
Let's Encrypt と Google Trust Services を使っている場合の例です。
example.com. 300 IN CAA 0 issue "letsencrypt.org"
example.com. 300 IN CAA 0 issue "pki.goog"
example.com. 300 IN CAA 0 iodef "mailto:security@example.com"書き方の要点は次のとおりです。
issueを複数行書くと、いずれかの認証局が許可されます。1行に複数の認証局は書けません。issuewildを書かなければ、ワイルドカード証明書にもissueの許可が使われます。ワイルドカード証明書を使っていないなら、0 issuewild ";"でワイルドカードの発行だけを禁止できます。iodefは、規則に反する発行の依頼があったときの連絡先です。認証局が送ってくるとは限らないため、監視の代わりにはなりません。- 先頭のフラグは
0にします。128（critical）は、認証局が理解できないタグがあると発行を止める指定で、意図せず発行を止める原因になります。
CAA は、証明書のホスト名に無ければ親のドメインへさかのぼって参照されます。example.com に書けば、CAA を持たないサブドメインすべてに効きます。サブドメインだけ別の認証局を使う場合は、そのサブドメインに専用の CAA を書きます。子に CAA があると親の CAA は参照されないので、子には必要な認証局をすべて書きます。
手順3：短い TTL で登録する
DNS を管理しているサービス（レジストラ、レンタルサーバー、Cloudflare など）の管理画面で CAA を追加します。管理画面によっては、フラグ・タグ・値を別々の欄に入力する形式になっています。値の欄に引用符を含めるかどうかは画面ごとに異なるので、保存後の表示や dig の結果で確かめます。
最初の TTL は 300 秒程度と短くしておきます。問題が出たときに、修正が早く行き渡るからです。登録したら、権威サーバーと公開リゾルバーの両方で確かめます。
dig example.com NS +short # 権威サーバーの名前を調べる
dig @ns1.example-dns.net example.com CAA +norecurse # 権威サーバーに直接聞く（名前は上の結果に置き換え）
dig @8.8.8.8 example.com CAA +short # 公開リゾルバーから見た値
dig www.example.com CAA +short # サブドメインは空でよい（親の CAA が使われる）Cloudflare のように、自社のサービスが使う認証局の CAA を自動で補う DNS サービスもあります。管理画面に見えている行と、dig で返る行が違うことがあるため、確認は dig の結果で行います。
手順4：発行が通ることを確かめる
CAA を登録しても、その場で認証局が確認するわけではありません。次のどれかで、発行が通ることを先に確かめます。
- Let's Encrypt を自分で使っている場合：
certbot renew --dry-runでステージング環境の発行を試します。ステージングでも CAA は確認されます。 - レンタルサーバーの無料 SSL の場合：管理画面から SSL を再設定できる場合は、影響の小さいサブドメインで試すか、事業者のサポート情報で CAA への対応を確かめます。
- 有料の証明書を使っている場合：更新時期の前に、認証局のサポートに CAA の値を確認しておきます。
そのうえで、手順1の表にある「次の更新日」が過ぎ、それぞれの証明書が更新されたことを確かめます。全部の更新を見届けたら、TTL を 3600 秒などの通常の値に延ばします。
手順5：絞り込みと戻し方
更新が問題なく続くと確認できてから、使わなくなった認証局の行を外したり、issuewild ";" を加えたりして絞り込みます。一度に複数の変更をせず、1つ変えたら次の更新を見届ける、という進め方が安全です。
問題が起きたときの戻し方も決めておきます。
- 更新が CAA で失敗した場合、ログやエラーに CAA を示す文言が出ることが多いです。原因の認証局の行を追加すれば、TTL の時間が過ぎたあとに発行できるようになります。
- 原因がすぐに分からず期限が迫っている場合は、CAA の行をいったんすべて削除すれば、CAA が無い元の状態に戻ります。削除は最後の手段として、事前に手順書へ書いておきます。
DNS の変更前には、現在のレコードを書き出して保存しておきます。多くの DNS サービスにはゾーンのエクスポート機能があります。
まとめ
- CAA の導入で難しいのは書式ではなく、設定の誤りが次の更新まで表に出ない時間差です。
- 今の証明書と CT ログから発行元を洗い出し、ホスト名ごとの表を作ってから設計します。
- 最初は洗い出したすべての認証局を許可し、短い TTL で登録して
digで確かめます。 - ドライランや次の更新で発行が通るのを見届けてから、TTL を延ばし、1つずつ絞り込みます。戻し方は事前に決めておきます。