CAAレコードは、自分のドメインに対してSSL/TLS証明書を発行してよい認証局（CA）をDNSで宣言する仕組みです。設定しておくと、許可していないCAによる誤発行や、第三者による不正な申請を防ぐ層が一つ増えます。一方で、使っているCAを書き漏らすと証明書の更新が止まるため、この記事では「いまどのCAが発行しているかの洗い出し」から、レコードの書き方、Let's Encryptでの具体例、更新失敗時の確認方法までを順に説明します。
CAAレコードの仕組み
CAAはRFC 8659で定められたDNSレコードです。業界団体CA/Browser Forumの基準により、公的に信頼されたCAは証明書を発行する前にCAAレコードを確認することが求められています。
ポイントは次の3つです。
- CAAが一つも無ければ、どのCAでも発行できます。 何も設定しない状態が従来どおりの動作です。
- CAAを1件でも置くと、そこに書かれたCAだけが発行できます。 許可リスト方式なので、書き漏らしたCAは更新も含めて発行を拒否します。
- 親ドメインへさかのぼって参照されます。
shop.example.comにCAAが無ければexample.comのCAAが使われます。サブドメインごとに別のCAを使う場合は、そのサブドメインに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"- フラグ: 通常は
0です。128は「このタグを理解できないCAは発行してはならない」という意味で、使う場面はほとんどありません。 - issue: 通常の証明書（ワイルドカード以外）を発行できるCAのドメイン名を書きます。
- issuewild: ワイルドカード証明書（
*.example.com）を発行できるCAを書きます。issuewildが無ければ、ワイルドカードにもissueの内容が適用されます。値を";"にすると「どのCAにも許可しない」という意味になります。 - iodef: ポリシー違反の申請があったときの連絡先です。CAがこれを使って報告するかどうかはCA次第なので、通知が届くことを前提にしない方が安全です。
手順1: いま使っているCAをすべて洗い出す
CAAで一番起きやすい事故は、自分が把握していなかったCAの証明書が更新できなくなることです。WordPressサイトでは、サーバーの証明書のほかにCDN、メール配信サービス、ステージング用のサブドメイン、ロードバランサーなどが別々のCAを使っていることがよくあります。
発行済みの証明書は Certificate Transparency（CT）ログに公開されているため、crt.sh などの検索サービスでドメイン名を検索すると、過去にどのCAがどのホスト名に発行したかを一覧できます。直近1〜2年分の発行元を確認し、まだ使われているものを書き出してください。
主なCAの issue に書く識別子の例です。各CAが変更や追加をすることがあるため（2026年10月現在）、設定前に各CAの公式ドキュメントで最新の値を確認してください。
- Let's Encrypt:
letsencrypt.org - Google Trust Services:
pki.goog - DigiCert:
digicert.com - Sectigo:
sectigo.com - GlobalSign:
globalsign.com - AWS Certificate Manager:
amazon.com（AWSのドキュメントでは他の識別子も併記されています）
CloudflareのようにCDN側で証明書を自動発行するサービスは、複数のCAを切り替えて使うことがあります。Cloudflareでは、CAAレコードを追加すると自社が使うCAのレコードを自動で補う仕組みがあると案内されていますが、挙動や対象プランは変わることがあるので、利用中のサービスのドキュメントで確認してください。レンタルサーバーの無料SSLも、どのCAを使っているかは事業者ごとに異なります。
手順2: TTLを短くしてレコードを追加する
洗い出したCAを issue に1件ずつ並べます。複数のCAを許可するときは、レコードを複数行に分けて書きます。
example.com. 300 IN CAA 0 issue "letsencrypt.org"
example.com. 300 IN CAA 0 issue "pki.goog"
example.com. 300 IN CAA 0 issuewild ";"
example.com. 300 IN CAA 0 iodef "mailto:security@example.com"最初はTTLを300秒程度にしておくと、更新失敗が起きたときにすぐ戻せます。数週間問題がなければ、3600秒など通常の値に延ばします。ワイルドカード証明書を使っているなら、issuewild ";" の代わりにそのCAを issuewild に書いてください。
管理画面から登録する場合、多くのDNSサービスではレコードタイプに「CAA」を選び、フラグ・タグ・値を別々の欄に入力します。値の欄にダブルクォートを含めるかどうかはサービスによって違うので、登録後に次のコマンドで実際の応答を確認します。
dig +short example.com CAA
# 0 issue "letsencrypt.org"
# 0 issuewild ";"
# のように表示されれば登録済み
# サブドメインは、自身に無ければ親の値が使われる
dig +short shop.example.com CAAshop.example.com が別名（CNAME）になっている場合、CAはCNAMEの向き先のCAAも確認します。CNAMEで外部サービスに向けているサブドメインは、向き先側のCAAが影響することがある点に注意してください。
手順3: Let’s Encryptでさらに絞り込む（任意）
Let's Encryptは、RFC 8657で定められた追加パラメーターに対応しています。accounturi で発行を特定のACMEアカウントに限定したり、validationmethods でドメイン検証の方式を限定したりできます。
example.com. 300 IN CAA 0 issue "letsencrypt.org; validationmethods=http-01"アカウントのURIは、Certbotなら /etc/letsencrypt/accounts/ 配下に保存されている情報から確認できます。ただし、サーバーを移行してACMEアカウントを作り直すと、accounturi を書き換えるまで発行できなくなります。運用担当者が変わっても把握できるよう、設定した理由を記録に残しておくのがおすすめです。対応しているパラメーターはCAごとに異なるため、Let's Encrypt以外のCAで使う前にそのCAの対応状況を確認してください。
更新に失敗したときの確認方法
CAAが原因で発行が拒否されると、Certbotなどのクライアントのエラーメッセージに「CAA」という語が含まれます。Let's Encryptの場合は、CAAレコードが発行を妨げている旨のメッセージが表示されます。次の順で確認してください。
- エラーに出ているホスト名でCAAを引く:
dig +short 対象ホスト名 CAAを実行し、親ドメインまで含めて、実際にどの値が返っているかを見ます。 - 許可リストにそのCAが入っているか: 識別子のつづり（
letsencrypt.orgをletsencrypt.comにしているなど）を確認します。 - ワイルドカードかどうか: ワイルドカード証明書なら
issuewildの値が使われます。 - CAAの問い合わせ自体が失敗していないか: 権威DNSがCAAの問い合わせにエラー（SERVFAIL）を返すと、CAは安全側に倒して発行を拒否します。
dig example.com CAAのstatus:欄がNOERRORになっているか確認します。古いDNSソフトウェアや一部の独自DNSで起きることがあります。
設定を直したら、本番の更新を待たずに試験発行で確かめます。
sudo certbot renew --dry-run--dry-run はLet's Encryptのステージング環境に対して実行され、本番の発行回数制限を消費しません。
WordPressサイトでの注意点
WordPress自体はCAAに関与しませんが、証明書が更新できないとサイト全体がブラウザ警告で開けなくなります。CAAを導入したら、証明書の有効期限を外部から監視しておくと、更新失敗に早く気づけます。ホスティング会社を移る、CDNを導入する、メール配信サービスに独自ドメインを設定するといった変更のたびに、そのサービスがどのCAを使うかを確認し、CAAに追加する作業を手順に入れておいてください。
まとめ
- CAAは「このドメインに証明書を発行してよいCA」の許可リストで、1件でも置くとそれ以外のCAは発行できなくなります。
- 導入前にCTログでいま使っているCAを洗い出し、CDNやサブドメイン、メールサービスの分も含めて
issueに並べます。 - 最初はTTLを短くし、
dig +short ドメイン CAAで応答を確認してから運用に入ります。 - 更新失敗時は、対象ホスト名のCAA、識別子のつづり、
issuewild、DNSの応答ステータスの順に確認し、certbot renew --dry-runで再確認します。