CAAレコードとは？証明書の発行元を制御する

CAAレコード（Certification Authority Authorization、認証局認可）は、ドメインの所有者が、そのドメイン内の名前に対する公開TLS証明書の発行を、どの認証局に認可するかを示すためのDNSレコードです。認証局は、関連する規則で求められている場合に、発行の手続きの一環としてCAAのポリシーを確認します。このレコードは、トラフィックを暗号化せず、証明書をインストールせず、サイトが安全であることを保証するものでもありません。追加の発行制御です。ドメインが意図している証明書の発行元をDNS上で見えるようにし、ドメイン所有者のポリシーが許可していない認証局が、意図せず証明書を発行する可能性を減らす手段です。

CAAポリシーの内容

CAAレコードは、フラグ、プロパティタグ、値を使います。一般的なissueプロパティは、証明書の発行を許可された認証局を指定し、issuewildはワイルドカード証明書に適用されます。iodefプロパティは、対応している場合に、ポリシー違反のレポートの送信先を指定できます。実際のレコードの構文には、発行元の認証局が文書で定めた識別子を含めます。識別子はブランド名で置き換えられるものではないので、証明書プロバイダーが公開している値を、そのまま使ってください。ドメインは、許可する発行元を複数公開できます。ポリシーが存在する場合、リストにない発行元は、該当するDNSと認証局の処理規則に従って、発行を妨げられることがあります。

CAAポリシーは、DNS名の関係に従います。独自のCAAデータを持たない名前は、ドメインの階層でより上位にある、最も近い関連ポリシーを継承することがあります。また、CNAMEがあると、DNSの規則に従って、適用されるデータが見つかる場所が変わることがあります。そのため、ルートドメインだけでなく、証明書を要求する正確な名前を確認することが重要です。ワイルドカード証明書の発行にも、別に注意が必要です。issuewildがある場合、通常の名前について認証局を許可するポリシーが、ワイルドカード証明書についても同じ意図を伝えるとは限りません。特定の解釈に頼る前に、最新の標準と認証局の指示を確認してください。

制限を公開する前に変更を計画する

制限的なCAAレコードは、ホスティングプラットフォームや証明書の自動化が使う認証局を含めていない場合、正当な証明書の更新を妨げることがあります。追加する前に、そのドメインの証明書を取得しているすべてのサービスを洗い出してください。サブドメイン、マネージドホスティング、CDNのエンドポイント、公的に信頼される証明書を使うステージング環境も含まれます。各プロバイダーに、公式のCAA識別子と、必要なレコードを尋ねます。そのうえで、レコードを公開し、値を公に問い合わせて確認します。変更は更新のスケジュールと調整し、構文的に有効なレコードがあれば、すべての連携が正しく設定されていると思い込むのではなく、次の発行または更新を監視してください。

• CAAの値は、認証局の最新のドキュメントにある内容を、そのまま使います。
• ルートの名前と、証明書を受け取る特定のサブドメインの両方を確認します。
• ワイルドカード証明書のポリシーは、別に考慮します。
• すべての証明書の自動化を移行し終えるまで、現在の発行元を削除しません。
• DNSプロバイダーの変更や、証明書プラットフォームの移行のあとは、CAAのデータを再確認します。

CAAが解決しないこと

CAAは、証明書の発行を統制する層の1つであり、DNSアカウントの保護、ドメイン登録の保全、証明書の更新、HTTPSの正しい設定の代わりにはなりません。既存の証明書をそれだけで失効させることはなく、ドメインやアカウントの侵害の可能性をすべて防げるわけでもありません。このレコードは、ウェブサイトが現在提供している証明書が有効かどうかも、ブラウザーには伝えません。ブラウザーは、接続の際に提示された証明書を検証します。証明書が欠けている、あるいは誤っている場合は、DNSポリシーだけでなく、稼働中のTLSエンドポイントも確認してください。

発行の失敗をトラブルシューティングするときは、DNSの応答を確認し、発行元の識別子を検証し、要求されたホスト名がポリシーを継承しているか、上書きしているかを調べます。公開されているデータを、証明書プロバイダーの最新の要件と比較してください。CAAで使われるDNSの一般的な用語については、DNSレコードタイプの解説をご覧ください。CAAは、運用の担当者が更新の経路を理解していれば価値のあるレコードですが、不用意な制限は、自動化された証明書の更新期限が来たまさにその瞬間に、障害を招くことがあります。1回きりのセキュリティのチェック項目ではなく、ライフサイクルを通じた保守が必要な設定として扱ってください。

CAAポリシーを証明書の自動化と整合させる

証明書の発行は、複数のサービスが同時に自動化していることがあります。ホスティングプロバイダーがメインサイトの証明書を発行し、CDNがエッジの証明書を更新し、別のプラットフォームがカスタマーポータルを担当している、といった具合です。CAAを制限する前に、証明書の名前、発行元、ワイルドカードの使用、更新の担当者を記載した簡単な棚卸し表を作成してください。インフラやドメインの所有者が変わるたびに、見直します。ポリシーの更新後に更新が失敗した場合は、制限を丸ごと外す前に、実際のホスト名、継承されたポリシー、発行元の識別子を確認します。範囲を慎重に絞った修正を公開し、プロバイダーが更新を完了できることを確認してください。この方法なら、認可された発行というセキュリティ上の価値を保ちつつ、どの証明書のフローがブロックされているか分からないまま、すべてのサービスの担当者が広い許可を追加しようと慌てる緊急事態を避けられます。