DNSSSLセキュリティWeb 担当者

DNS CAA レコードとは|中小企業の設定手順

ドメイン番人8 分で読めます
目次

「CAA レコードを設定してください」とセキュリティ診断やベンダーから指摘され、何のことか分からず手が止まった。そんな経験を持つ Web 担当者は少なくありません。CAA は SSL 証明書の不正発行を防ぐための DNS の仕組みですが、設定を間違えると証明書の更新そのものが止まり、サイトが「保護されていません」と表示される事故につながります。

この記事では、CAA レコードとは何か、なぜ今その重要性が増しているのか、Cloudflare での具体的な設定手順、そして中小企業が押さえるべき注意点を、専門用語をかみ砕きながら解説します。

CAA レコードとは何か

CAA は Certification Authority Authorization(認証局承認)の略で、RFC 8659 で標準化された DNS レコードの一種です。役割をひとことで言うと、「自社のドメインに対して SSL 証明書を発行してよい認証局はどこか」を DNS 上で宣言する仕組みです。

通常、SSL 証明書はドメインの所有確認さえ通れば、世界中のどの認証局(CA: Certificate Authority)でも発行できてしまいます。つまり、何も設定していなければ、自社が契約していない認証局が、悪意ある第三者の手続きによってあなたのドメインの証明書を発行してしまう余地が理論上は残ります。

CAA レコードを設定しておくと、認証局は証明書を発行する前に必ずその DNS レコードを確認します。そして、自分が許可リストに載っていなければ発行を拒否します。許可された認証局だけが証明書を出せる状態を、ドメイン所有者側から DNS で指定できる。これが CAA の本質です。

なお、CAA レコードの確認は 2017 年 9 月以降、すべての公的な認証局に対して業界ルールで義務付けられています。一部の特殊な認証局だけが対応している任意機能ではなく、Let's Encrypt をはじめ主要な認証局はすべて発行前に CAA を確認します。

認証局が証明書を発行する前に CAA レコードを確認するフロー図

なぜ今 CAA の重要性が増しているのか

CAA という仕組み自体は以前から存在しましたが、ここ数年でその重要度が一段上がっています。背景にあるのは、SSL 証明書の有効期間がどんどん短くなっている流れと、証明書発行の自動化が当たり前になったことです。

かつて SSL 証明書の有効期間は 1 年以上が普通でした。しかし業界の方針として有効期間は段階的に短縮され、最終的には 47 日程度まで縮まる方向で議論が進んでいます。この全体像については SSL 証明書「47 日問題」とは何か で詳しく解説しています。有効期間が短くなれば、証明書の発行回数は年に数回から、数週間に一度のペースへと跳ね上がります。

発行回数が増えれば、当然ながら人手での更新は現実的でなくなり、ACME という仕組みを使った自動発行が主流になります。ACME は認証局とサーバーが自動でやり取りし、人が触らなくても証明書を取得・更新する仕組みです。証明書の自動更新の組み方は SSL 証明書の自動更新を仕組み化する で扱っています。

ここで CAA が効いてきます。自動発行が頻繁に走るということは、CAA レコードのチェックも頻繁に走るということです。CAA に許可していない認証局で自動更新を設定してしまうと、更新のたびに証明書発行が拒否され、気づかないうちに証明書が失効します。逆に言えば、CAA を正しく設定しておけば、自動発行の経路を自社が意図した認証局だけに絞り込め、不正発行のリスクを下げながら自動化の安全性を高められます。証明書が短命かつ自動化される時代だからこそ、CAA の設定ミスが「たまにある手作業の失敗」ではなく「定期的に必ず起きる障害」に化けるのです。

CAA レコードの構成要素を理解する

CAA レコードは、3 つの部品の組み合わせでできています。順に見ていきます。

実際のレコードはこのような形をしています。

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

この 0 issue "letsencrypt.org" の部分が中身です。

フラグ(flags): 先頭の数字です。通常は 0 を指定します。128(critical フラグ)という値もありますが、これは将来の拡張仕様を「理解できない認証局には発行させない」ための特別な指定で、一般的な中小企業のサイトで使うことはまずありません。迷ったら 0 で問題ありません。

タグ(tag): 真ん中の文字列で、レコードの種類を表します。主に次の 3 つがあります。

  • issue: 通常の証明書(ふつうのドメイン用)の発行を、指定した認証局に許可します。
  • issuewild: ワイルドカード証明書(*.example.com のように、サブドメインをまとめてカバーする証明書)の発行を許可します。issuewild を 1 つでも設定すると、ワイルドカード証明書については issue の指定が無視され、issuewild の内容が優先されます。
  • iodef: 許可していない認証局から発行要求があった場合に、その通報を受け取る連絡先(メールアドレスや URL)を指定します。

値(value): ダブルクォートで囲まれた部分で、許可する認証局の識別名を書きます。Let's Encrypt なら letsencrypt.org、Google Trust Services なら pki.goog のように、認証局ごとに決まった文字列があります。これは認証局の公式ドキュメントで必ず確認します。推測で書いてはいけません。

CAA レコードのフラグ・タグ・値の分解図

許可する認証局を選ぶだけで CAA レコードの下書きを組み立てられるSPF / DMARC / CAA レコード生成ツールも用意しています。利用中の CA の許可漏れ(証明書発行停止)を警告するので、設定前の下書き作りに便利です。

Cloudflare での CAA レコード設定手順

ここでは DNS 管理に Cloudflare を使っている前提で、設定の流れを説明します。他社の DNS サービスでも入力する項目はほぼ同じです。

  1. Cloudflare のダッシュボードにログインし、対象ドメインを選びます。
  2. 左メニューから DNSRecords(レコード) を開きます。
  3. Add record(レコードを追加) をクリックします。
  4. レコードの種類で CAA を選びます。
  5. Name(名前) にドメインを入力します(ルートドメインに設定する場合は @ を使えます)。
  6. Tagissueissuewildiodef のいずれかを選びます。
  7. CA domain name(CA ドメイン名) に、許可する認証局の識別名(例: letsencrypt.org)を入力します。
  8. 保存し、許可したい認証局ごとに同じ手順を繰り返します。

たとえば Let's Encrypt と、ワイルドカード証明書もカバーしたい場合、次の 2 つを設定するのが基本形です。

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

複数の認証局を使っているなら、それぞれを issue で追加します。許可したい認証局をすべて書き並べる形になります。

なお Cloudflare の証明書(同社のエッジ証明書)を利用している場合は、Cloudflare が使う認証局を CAA で許可しておく必要があります。Cloudflare 側で自動的にレコードが追加されることもありますが、自社で CAA を手動設定するときは、Cloudflare が使う認証局を消してしまわないよう注意してください。許可漏れがあると、Cloudflare 側の証明書更新が止まる原因になります。

中小企業が設定すべき理由と注意点

CAA は専任のセキュリティ担当がいない中小企業でも、一度設定すれば効果が続く、費用対効果の高い対策です。設定に追加費用はかからず、DNS に数行のレコードを足すだけで、自社ドメインの証明書を勝手に発行されるリスクを下げられます。最後に、設定時に必ず押さえておきたい注意点をまとめます。

自社が使う認証局を漏れなく許可する。これが最も重要です。CAA は「許可リスト」なので、リストに載っていない認証局は一律で発行を拒否されます。たとえば本番サイトは Let's Encrypt、別のサービスでは Cloudflare の証明書、社内ツールでは別の認証局、という具合に複数の認証局を使っているケースは珍しくありません。1 つでも書き漏らすと、その認証局での更新が次回からすべて失敗します。設定前に、自社が現在どの認証局で証明書を取得しているかを棚卸ししてください。

サブドメインのワイルドカード証明書に注意する*.example.com のようなワイルドカード証明書を使っているなら、issue だけでなく issuewild の指定も忘れないようにします。issuewild を 1 つでも設定すると、ワイルドカードについては issue が無視される点も覚えておきましょう。

設定後は必ず動作を確認する。CAA は「間違っていても設定直後は何も起きない」のが厄介な点です。実際に影響が出るのは次回の証明書発行・更新のタイミングで、それが数週間後の自動更新だったりします。設定を入れたら、DNS の反映を確認し、可能なら証明書の発行をテストして、意図した認証局で問題なく出せることを確かめてください。

通報先(iodef)も検討するiodef タグで連絡先を設定しておくと、許可していない認証局への発行要求があった際に通報が届く場合があります。必須ではありませんが、不正発行の兆候を早期に把握したい場合は設定しておくと安心です。

CAA は地味なレコードですが、設定ミスが証明書の失効、ひいてはサイトの停止に直結する、影響範囲の大きい設定です。証明書の有効期間が短く、自動更新が前提になる流れの中で、その重要性は今後さらに高まります。

よくある質問

CAA レコードとは何ですか?

自社ドメインに対して SSL 証明書を発行してよい認証局はどこかを DNS 上で宣言する仕組みです。認証局は証明書を発行する前に必ず CAA を確認し、許可リストに載っていなければ発行を拒否します。

CAA レコードのフラグは何を指定すればよいですか?

通常は 0 を指定します。128(critical フラグ)は将来の拡張仕様向けの特別な指定で、一般的な中小企業のサイトで使うことはまずありません。迷ったら 0 で問題ありません。

CAA 設定で最も注意すべき点は何ですか?

自社が使う認証局を漏れなく許可することです。CAA は許可リストなので、1 つでも書き漏らすと、その認証局での証明書更新が次回からすべて失敗します。設定前に、現在どの認証局で証明書を取得しているかを棚卸ししてください。

自社の DNS / SSL 設定を確認する

自社の DNS や SSL の設定が正しく組めているか不安な Web 担当者の方は、ドメイン番人の無料診断をご利用ください。CAA を含む DNS 設定や SSL 証明書の状態を自動でチェックし、見落としがちな設定漏れを洗い出します。無料でインフラ診断を試す から、数分で現状を確認できます。

次の一歩は無料診断から。