CAAレコードとは？証明書更新を止めない設定・確認・戻し方

先に答え：CAAは「どの認証局が発行してよいか」をDNSで示す

CAA（Certification Authority Authorization）は、公開TLS証明書を発行してよい認証局（CA）をドメイン管理者がDNSで指定するレコードです。意図しない認証局からの誤発行リスクを減らすための追加制御であり、HTTPSを有効化したり、既に発行済みの証明書を失効させたりする機能ではありません。

CAAを一つでも設定すると、使用予定の認証局を漏れなく許可する必要があります。CDNやホスティングが利用者に代わって証明書を発行・更新する構成では、そのサービスが実際に使う認証局を事前に確認します。名前だけで推測して設定すると、自動更新日に初めて失敗することがあります。

画像を拡大 ↗

CAAでできることと、できないことを比較した図。閉じる ×

CAAを設定しても証明書運用は別に必要です。

issue・issuewild・iodefを役割で分ける

CAAの基本形は次のとおりです。

example.com.  CAA  0  issue  "letsencrypt.org"

0 はflags、issue はプロパティタグ、letsencrypt.org は認証局が公開する識別子です。識別子は会社名から推測せず、利用中の認証局またはサービスの公式資料で確認します。

画像を拡大 ↗

CAAレコードの名前、flags、tag、valueを分解した図。閉じる ×

CA識別子は公式資料で確認します。

Let's Encryptの公式資料では、issue は通常の証明書を制御し、issuewild が別にない場合はワイルドカード発行も制御します。同じタグのレコードは複数設定でき、いずれかが対象CAを許可すれば発行可能です。「複数書けば強くなる」のではなく、許可先が増えるため、運用に必要なものだけを記録します。

親ドメインからの継承とCNAMEを確認する

証明書を発行するCAは、対象名にCAAがなければ親へ遡り、最初に見つかったCAAを使います。たとえば shop.example.com にCAAがなく、example.com にあれば親の方針が適用されます。サブドメイン側にCAAを置くと、その名前の方針を上書きできます。

また、CAAの探索はCNAMEもたどります。Cloudflareの資料も、CNAME先の制限的なCAAが優先し得るため、CNAMEチェーンの各段階を確認するよう案内しています。

画像を拡大 ↗

対象ホストから親ドメインへCAAを探し、CNAME先も確認する流れ。閉じる ×

サブドメインのCAAで親の方針を上書きできます。

確認例：

dig example.com CAA +short
dig www.example.com CAA +short
dig cname-target.example.net CAA +short

Windows等で dig がない場合は、利用中DNS事業者の確認機能や、信頼できるDNS照会ツールを使います。画面の設定一覧だけでなく、権威DNSから実際に返る値を確認するのが重要です。

設定前に証明書の発行経路を棚卸しする

証明書は、Webサーバー担当者が直接取得しているとは限りません。CDN、ロードバランサー、サイト作成サービス、ホスティング、メール用ホスト、API用サブドメインがそれぞれ別のCAを使うことがあります。

画像を拡大 ↗

公開サイト、API、メール、予備経路ごとに証明書発行主体を確認する表。閉じる ×

現在の発行者名だけで次回更新CAを断定しません。

現在ブラウザーに表示される証明書の発行者名だけで、次回更新に使われるCAを断定しません。サービスがバックアップCAや将来の切替を使う場合があるため、公式の「必要なCAA値」を確認します。CloudflareはUniversal SSL利用時にゾーンへCAAを追加すると、Cloudflareが必要とするCAAを自動的に補う構成があると説明していますが、Advanced Certificates等には同じ扱いが適用されません。契約機能ごとの資料を確認します。

安全な導入手順

1. 使用中のすべてのホスト名と、証明書更新主体を一覧にする。
2. 各主体の公式資料から必要なCAA値を確認する。
3. 親ドメイン、個別サブドメイン、CNAME先で返るCAAを取得する。
4. 通常証明書とワイルドカード証明書の要否を分ける。
5. 変更前の値と取得時刻を保存する。
6. 必要なCAをすべて含むCAAを追加する。
7. 複数のDNSリゾルバーまたは権威DNSで値を確認する。
8. 本番を無理に再発行する前に、サービスが用意する検証・ステージング手段で確認する。
9. 証明書の次回更新日と監視・通知先を記録する。

画像を拡大 ↗

発行経路の棚卸し、公式値確認、DNS追加、更新監視の導入順。閉じる ×

権威DNSから返る値と次回証明書更新を確認します。

CAAはDNSキャッシュの影響を受けます。変更直後に一地点の結果だけで判断せず、TTLと権威DNSの応答を確認します。DNSSECでSERVFAILが出ていると、CAAがないように見えてもCAは「許可を確認できない」として発行を止めることがあります。

証明書更新に失敗したときの分岐

Let's EncryptはCAAを発行ごとに確認し、永続的なSERVFAILではDNSSEC検証の失敗が多いと説明しています。CAAエラーを見て証明書の秘密鍵を作り直しても、DNS側の許可確認は直りません。エラー種別に合わせて切り分けます。

そのまま使える変更依頼文

対象ドメイン：example.com
対象ホスト：example.com / www.example.com / api.example.com
現在の証明書更新主体：＿＿＿＿
公式資料で確認したCA識別子：＿＿＿＿
通常証明書：必要／不要
ワイルドカード証明書：必要／不要
追加予定：CAA 0 issue "＿＿＿＿"
issuewild：設定なし／CAA 0 issuewild "＿＿＿＿"
親・子・CNAME先の確認結果：＿＿＿＿
DNSSEC：なし／あり（検証結果：＿＿＿＿）
変更前控え：＿＿＿＿
変更後の権威DNS確認：＿＿＿＿
次回証明書更新日と通知先：＿＿＿＿

CAAは「設定すれば必ず安全」ではなく、証明書発行の運用をDNS上の許可リストと一致させる仕組みです。発行主体が分からない段階では先に棚卸しを行い、推測した値を本番へ追加しません。

SITE PORTを検討するときの確認ポイント

サイト制作を依頼する場合は、画面の見た目だけでなく、この記事で扱った設定を誰が担当するか、公開後の変更や確認をどこまで依頼できるかを先に確認します。SITE PORTの完成例と編集デモでは、完成イメージと日常的な編集の流れを確認できます。ドメイン移管、DNS、証明書、HTTPヘッダー等は通常の本文編集と同じ範囲で扱えるとは限らないため、必要な作業を具体的に伝え、対応範囲を確認してください。

関連記事

[HTTPS警告の見分け方](/articles/https-certificate-warning-check)・[DNSSECでSERVFAILになったとき](/articles/dnssec-ds-servfail-checklist)・[DNSレコードの種類](/articles/dns-record-types-practical)