2026年8月24日
2026年8月24日
CAAレコードの設定方法|SSL証明書を発行できる認証局を制限する
CAA レコードは、「このドメインの SSL/TLS 証明書を発行してよい認証局(CA)」を DNS で宣言するためのレコードです。登録しておくと、指定していない認証局は証明書の発行を断るため、第三者による不正な発行や、社内の誰かが勝手に別の認証局で証明書を取るといった事態を防ぎやすくなります。この記事では、CAA レコードの仕組みと書き方、Let's Encrypt や有料証明書を使う場合の設定例、設定後に更新が止まらないようにするための確認方法を解説します。
CAAレコードの仕組み
公開されている認証局は、証明書を発行する前に、対象ドメインの CAA レコードを DNS で確認することが業界ルール(CA/Browser Forum の Baseline Requirements)で義務づけられています。CAA レコードに自分の名前が含まれていなければ、その認証局は発行を拒否します。
押さえておきたい点は次の3つです。
- CAA レコードが1件もなければ、どの認証局でも発行できる:CAA は「許可リスト」です。何も書かなければ制限はかかりません
- 親ドメインへさかのぼって探される:
www.example.comの証明書を発行するとき、認証局はwww.example.comの CAA を探し、なければexample.comの CAA を見ます。つまりexample.comに書いた CAA は、独自の CAA を持たないサブドメインすべてに効きます - 確認されるのは発行の時点だけ:すでに発行済みの証明書が CAA の追加で無効になることはありません。影響が出るのは次回の更新や新規発行のときです
最後の点が重要で、CAA を追加した直後は何も起きず、数週間〜数か月後の自動更新で初めて失敗に気づく、ということが起こりえます。設定前に「今どの認証局の証明書を使っているか」を洗い出しておくことが一番の対策です。
CAAレコードの書き方
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 を指定すると「このタグを理解できない認証局は発行してはいけない」という意味になりますが、一般的な用途では使いません。
タグは次の3種類が基本です。
issue:証明書(ワイルドカードを含む)の発行を許可する認証局を指定するissuewild:ワイルドカード証明書(*.example.com)の発行を許可する認証局を指定する。これがあると、ワイルドカード証明書についてはissueより優先されるiodef:規則に反する発行依頼があった場合の連絡先(mailto:または URL)。ただし、認証局が連絡を送ることは義務ではなく、通知が来ないことも多いので過度に期待しないでください
値には認証局ごとに決められたドメイン名を書きます。複数の認証局を許可したい場合は、issue のレコードを認証局の数だけ並べます。値を ";" にすると「どの認証局にも許可しない」という意味になり、上の例では「ワイルドカード証明書はどこにも発行させない」ことになります。
主な認証局の値
代表的な認証局の値は次のとおりです(2026年10月現在)。認証局の統合や名称変更で変わることがあるため、設定前に各認証局の公式ドキュメントで確認してください。
- Let's Encrypt:
letsencrypt.org - Google Trust Services:
pki.goog - DigiCert:
digicert.com - Sectigo:
sectigo.com - GlobalSign:
globalsign.com - AWS Certificate Manager(ACM):
amazon.comなど(AWS のドキュメントで複数の値が案内されています)
国内の販売代理店で購入する証明書は、ブランド名と実際の発行元の認証局が異なることがあります。CAA に書くのは販売店ではなく発行元の認証局です。証明書の詳細画面の「発行者」欄や、販売店の案内で発行元を確認してください。
設定の手順
- 今使っている証明書の発行元を調べる:本番サイトだけでなく、ステージング、メール(
mail.example.com)、API 用サブドメインなど、そのドメイン配下の証明書をすべて洗い出します。コマンドで調べる場合は次のようにします
# 証明書の発行者(Issuer)を表示する
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
| openssl x509 -noout -issuer
- 利用中のサービスが使う認証局を確認する:レンタルサーバーの無料 SSL、CDN、メール配信サービスなどは、サービス側が認証局を選んでいます。多くは Let's Encrypt ですが、別の認証局を使う、あるいは複数の認証局を切り替えて使うサービスもあります。各サービスのヘルプで「CAA」について案内がないか確認します
- DNS の管理画面で CAA レコードを追加する:多くの DNS サービスでは、種類に「CAA」を選ぶと、フラグ・タグ・値を別々に入力する欄が表示されます。値の引用符を自分で入れるかどうかはサービスによって異なります。CAA に対応していない DNS サービスもあるので、選択肢にない場合はサービスのヘルプを確認してください
- 登録内容を確認する:次の章のコマンドで、意図したとおりに返るかを確かめます
- 次回の更新を見届ける:自動更新の日程が近い証明書があれば、手動で更新を試すか、更新後に証明書の有効期限が延びているかを確認します
Cloudflare を使っている場合
Cloudflare のプロキシ(オレンジの雲)を通しているサイトでは、訪問者に見える証明書は Cloudflare が発行・管理しています。Cloudflare は複数の認証局を使い分けており、CAA を設定するとその認証局向けのレコードを自動で補う仕組みがあると案内されています。挙動や対象の認証局は変わることがあるため、Cloudflare のドキュメントで最新の説明を確認したうえで設定してください。オリジンサーバー側で Let's Encrypt を使っている場合は、letsencrypt.org の許可も忘れずに入れます。
より細かく制限する
Let's Encrypt など一部の認証局は、値に追加のパラメータを付けて、許可する ACME アカウントや認証方式を絞り込む拡張(RFC 8657)に対応しています。
example.com. 3600 IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01"
アカウントやドメイン認証の方式まで固定できるため、より強い制限になりますが、サーバー移行やツールの入れ替え時に更新が止まる原因にもなります。運用体制が整ってから検討するのが無難です。また、DNS の応答そのものが改ざんされると CAA も意味を持たなくなるため、重要なドメインでは DNSSEC の導入もあわせて検討してください。
設定内容の確認方法
dig コマンドで CAA レコードを問い合わせます。
# ドメインの CAA レコードを表示
dig example.com CAA +short
# サブドメインに独自の CAA があるか確認(何も返らなければ親の CAA が使われる)
dig www.example.com CAA +short
0 issue "letsencrypt.org" のように表示されれば登録できています。サブドメインで何も返らないのは正常で、その場合は親ドメインの CAA が適用されます。CNAME で外部サービスに向けているサブドメインでは、CNAME 先の名前の CAA が参照されることがあるので、そのサブドメイン名でも問い合わせておくと安心です。
CAA にも TTL があるため、書き換えた内容が認証局に見えるまで時間がかかる場合があります。設定を直した直後に再発行が失敗するときは、TTL 分待ってから試します。
よくある失敗と対処
自動更新が失敗するようになった:CAA に書いた認証局と、実際に更新を担う認証局が食い違っています。Let's Encrypt の場合、エラーメッセージに CAA レコードが発行を妨げている旨が表示されます。発行元を確認し、その認証局の値を issue に追加します。
ワイルドカード証明書だけ発行できない:issuewild を書いている場合、ワイルドカード証明書には issue の内容が使われません。ワイルドカードを使う認証局を issuewild にも書きます。
サブドメインだけ別の認証局を使いたい:そのサブドメインに独自の CAA レコードを置きます。サブドメインに CAA があると、親ドメインの CAA はそのサブドメインには使われません。
値の書き間違い:letsencrypt.com や www.letsencrypt.org のような誤りは、許可したつもりで実際には誰も許可していない状態になります。公式ドキュメントからコピーして貼り付けるのが安全です。
まとめ
- CAA レコードは、証明書を発行してよい認証局を DNS で指定する仕組み
- CAA が1件もなければ制限なし。親ドメインの CAA はサブドメインにも効く
- 確認は発行時だけなので、追加の影響は次回更新で表に出る。設定前に全サブドメインの証明書の発行元を洗い出す
issueで通常の発行、issuewildでワイルドカード、iodefで連絡先を指定する- 認証局の値は公式ドキュメントで確認し、CDN やレンタルサーバーが使う認証局も許可に含める
- 設定後は
dig 〜 CAAで確認し、次の更新が成功するところまで見届ける