CAAを使用する理由
コンピュータ科学者の Phillip Hallam-Baker 氏と Rob Stradling 氏は、公的に信頼されている証明機関のセキュリティに関する懸念の高まりに応えて CAA を開発しました。この取り組みは、インターネットの主要な標準開発組織 (SDO) である Internet Engineering Task Force (IETF) の管轄下にあります。IETF は、インターネット ユーザー、ネットワーク オペレーター、機器ベンダーによって広く採用される自主的な標準を作成し、インターネットの進化に影響を与えています。
IETFはRFC（Requests for Comments）と呼ばれる出版物で技術標準を文書化しています。これらの文書は、アドレス指定、ルーティング、トランスポート技術など、インターネットインフラストラクチャの重要な側面を概説しています。CAAは具体的に次のように定義されています。 RFC 6844.
認証局（CA）は常に以下の方法を使用します。 ドメイン検証 すべてのSSL /を確認するTLS 証明書の要求が承認されます（通常、そのドメインを使用する特定のサイトに何らかの方法でリンクされていることを確認することにより）。
たとえば、CAが要求者に特別な検証ファイルを提供する場合があります。 このファイルをWebサイトに配置すると、要求者もそのサイトを制御していることが証明されますが、 合法性 そのコントロールの。 サイトの制御を取得したハッカーは、正当な所有者になりすまして、SSL /を要求および受信する可能性があります。TLS CAの標準チェックに合格した証明書 と思われる 正当な。 その後、彼らは振り返ってそのSSL /を使用することができますTLS そのサイトまたは他の場所でのいたずら用の証明書。
CAAは、ドメインの証明書の発行を許可するCAを定義する（または証明書の発行を完全に制限する）ことで、この種のエクスプロイトをブロックするのに役立ちます。 これにより、ハイジャッカーが与える可能性のある損害が制限されます。サイトを管理している場合でも、不正なSSL /をスコアリングするためのオプションが大幅に少なくなります。TLS 証明書。
CNAME とは何ですか?
CNAMEレコードは、1つのドメイン（例えば、 住所、例えば、別の人の別名として行動する マイビジネスIP アドレスの変更を反映するために複数の A レコードを管理する代わりに、CNAME はエイリアスをターゲット ドメインにポイントすることでこれを簡素化します。このアプローチは、Web ホストまたは CDN プロバイダーを定期的に切り替える企業にとって非常に有益です。さらに、CNAME レコードは、トラフィックがプライマリ サーバーからセカンダリ サーバーに誘導され、停止中のサービスの継続性を確保するフェイルオーバー システムの構築に非常に役立ちます。
証明機関認証（CAA）のコンテキストでは、CNAMEレコードはCAAチェックをターゲットドメインにリダイレクトすることでプロセスに影響を与えます。たとえば、 ショップ CNAMEを使用してポイントする マイサイトCAAチェックを実行するCAは、記録を評価します。 マイサイト 証明書発行の権限を確認するため。CAAレコードが マイサイト CA を承認しない場合は、証明書を発行できません。これにより、ドメインが DNS エイリアスに CNAME レコードを利用する場合でも、CAA ポリシーが一貫して適用されます。
CAAの仕組み
CAAはDNSを使用します
その ドメインネームシステム （DNS）は、インターネットのインフラストラクチャの重要な部分です。 ドメインの所有者は、DNSレコードを保持します（いわゆる ゾーンファイル）サイトがホストされているIPアドレスをドメイン名にポイントし、次のように入力します google.com の代わりにブラウザウィンドウに 216.58.194.46.
DNSレコードは「インターネットの電話帳」として一般的に使用されますが、DNSは、他の情報をドメイン名に割り当てることができる他のタイプの特別なレコードも許可します。
CAAレコード
CAAは、 証明機関承認リソースレコード （CAAレコード）。 これらはDNSを使用して公開され、ドメイン所有者は他のDNSレコードと一緒にCAAレコードを追加するだけです。 CAAレコードには、 タグ と 値、タグと値のペアは、 財産。 もあります フラグ このプロパティの重要度を示します。 これは次のようになります。
example.com。 CAA 0の問題「ssl.com」
ここでは、 example.com このレコードが適用されるドメインであり、CAAはこれがどのような種類のレコードであるかを知らせます。 の 0 フラグです（デフォルトは0）。タグは 問題 値（引用符内）は ssl.com、一緒にプロパティを構成します。
フラグ
フラグには現在、厳密に定義されたXNUMXつの状態のみがあります。 0 （非重要）および 1 （クリティカル）。 クリティカルフラグはCAに しなければなりません 続行するには、プロパティ タグを完全に理解する必要があります。RFC 6844 では、ユーザー定義のフラグの使用に関して他の可能性が残されています (これについては後述します)。
タグ
RFC 6844は、XNUMXつの一般的なタグの使用を定義しています。 問題, ワイルド (NAIST) と ヨーデフ。 （フラグと同様に、他の潜在的なカスタマイズされたタグタイプを許可します。）
その 問題 タグ
その 問題 タグは、このドメインの証明書を発行する権限があるCA（ある場合）を指定します。 たとえば、ドメインexample.comの所有者は、次のDNSゾーンファイルを使用して、証明書の発行をXNUMXつのCA（ここではSSL.com）に制限できます。
example.com。 CAA0号「ssl.com」
ドメイン所有者は、ドメインに複数のゾーンファイルを設定することを選択できます。
example.com。 CAA0は「ssl.com」example.comを発行します。 CAA0号「comodoca.com」
上記のレコードはSSL /を制限しますTLS 証明書発行 example.com XNUMXつのCA（SSL.comおよびComodo.com）。
その 問題 レコードは、指定されたCAが指定されたドメインのサブドメインの証明書を発行することも許可します。 したがって、SSL.comを許可するレコードは、証明書の発行を許可できます。 example.com とサブドメインのような www.example.com, mail.example.com さらに特別なワイルドカードサブドメイン * .example.com.
CAAレコードを使用して、 制限する 証明書の発行も–このレコードはCAAを使用する認証局に、 いいえ SSL /TLS 証明書を発行する必要があります example.com とサブドメイン どれか CA：
example.com。 CAA0の問題 ";"
（この例のセミコロンは「ここでは何も許可しない「しかし、後で説明するように、カスタムパラメータの定義にも使用されます。）
標準の発行タグにより、CAは、…によって変更されない限り、ワイルドカードの証明書を発行できます。
その ワイルド タグ
このタグは、CAが所有者のドメイン（つまり、 * .example.com).
ワイルドカードは無制限のサブドメインのセットを考慮できるため、ワイルドカード証明書を発行する際には特別な注意が必要です。 ワイルド タグを使用すると、ドメイン所有者は、メインドメインやその他のサブドメインとは別に、ワイルドカードの証明書を発行できるCAを定義できます。 ワイルド タグはどのタグよりも優先されます 問題 タグ。 それらは同じ構文を使用します 問題 鬼ごっこ。 いくつかの例：
example.com。 CAA0は「ssl.com」example.comを発行します。 CAA 0 issuewild ";"
上記により、SSL.comは証明書を発行できます example.com およびすべてのサブドメイン 以下は除く ワイルドカード * .example.com。 （SSL.comも他のCAもワイルドカード証明書の発行を許可されていません。 example.com.)
example.com。 CAA0の問題 ";" example.com。 CAA 0 issuewild "ssl.com"
この例は禁止します を 証明書を発行するCA example.com およびそのサブドメイン、ただしSSL.comがワイルドカード証明書を発行できるように例外を作成します（および の ワイルドカード証明書） example.com.
その ヨーデフ タグ
XNUMX番目に定義されているタグは ヨーデフ。 このタグは、無効な証明書要求をドメイン所有者に報告するために使用でき、次のようになります。
example.com。 CAA 0 iodef "mailto：certissues@example.com" example.com。 CAA 0 iodef "certissues.example.com"
一番上のレコードは、メール通知をアドレスに送信するために必要なCA情報を提供します certissues@example.com。 XNUMXつ目は、インシデントメッセージを（ドメイン所有者がこの目的のために設定した）Webサービスに投稿するようにCAに指示します。 certissues.example.com。 （CAおよびドメイン所有者が操作をセットアップした方法に応じて、これらの方法のいずれかまたは両方を使用できます。）
ヨーデフ 投稿メッセージは、 インシデントオブジェクトの説明交換形式 またはIODEF –したがって名前。 （IODEFは RFC 6546.)
問題メールタグ S/MIME
CAAの重要な発展は、 S/MIME RFC 9495 で正式化された、(Secure/Multipurpose Internet Mail Extensions) 証明書。 S/MIME 証明書は、認証、データプライバシー、メッセージの整合性を通じて電子メールのセキュリティを提供します。CA/ブラウザフォーラムは、証明書の発行を制御するために「issuemail」と呼ばれる新しいCAAプロパティタグを導入しました。 S/MIME 証明書.
15年2024月XNUMX日より、CAはCAAチェックを実施することが推奨されます。 S/MIME 15年2025月XNUMX日までに義務的な実施が必要となる証明書. 電子メール アドレスの標準 CAA レコード フォームは次のようになります。
mail.client.example CAA 0 発行メール "authority.example"
CAAを電子メール証明書に拡張することで、ドメイン所有者は、 S/MIME これまでと同様に証明書の発行 TLS 証明書の不正発行のリスクを軽減.
CA定義のフラグとタグ
RFC 6844で説明されているCAAは、0つのフラグ状態（1とXNUMX）とXNUMXつのタグ（問題, ワイルド (NAIST) と ヨーデフ）。 ただし、CAがカスタムタグとフラグを作成して利用し、証明書の発行プロセスを定義できるように、設計は十分に開かれています。 例は次のとおりです。
example.com。 CAA0の問題「SSL.com; policy = ev」
このレコードは標準を使用します 問題 このドメインの証明書を発行するときに拡張検証（EV）ポリシーを使用するようにCAに指示する追加のパラメーターを含むタグ。
example.com。 CAA 128 pca "PCA = 12345"
ドメイン所有者は、このレコードを新しいCA定義の PCA タグを使用して、優先顧客アカウントを持っていることを示し、アカウント番号をパラメータとして設定します。 （フラグは最大255のカスタム値にすることができます。）CAがアカウントを設定する方法に応じて、これは特定の請求方法、追加のアカウント定義の検証、またはその他の特別な処理を可能にします。
長所と短所
CAA を使用する理由はいくつかあります。主な、そして最も重要な利点は、CAA が証明書の誤発行のリスクを大幅に軽減できることです。これにより、ドメイン、ビジネス、オンライン ID を保護することができます。特定の CA のソフトウェアにバグを見つけた潜在的な攻撃者は、そのバグを利用してドメインの SSL 証明書を発行することはできません。さらに、iodef タグを使用すると、エクスプロイトが試みられた場合にレポートを受け取ることができます。
CAAの設計はセキュリティを強化しますが、リソースのより詳細な割り当ても可能にします。たとえば、会社はレコードを設定して、営業およびマーケティング部門が指定されたソースからsales.example.comのSSL証明書を購入できるようにする（または制限する）ことができます。
さらに、CAAは優れた柔軟性を提供します。 ドメイン所有者の場合、独自の制御下にあり、必要に応じて変更できるDNSリソースレコードを使用するため、特定のCAに関連付けられていません（特定のドメイン名の問題レコードで複数のCAを承認できます） 。 CAの場合、カスタマイズされた使用とは別に、CA / Bフォーラム（CAおよびブラウザのセキュリティ問題の標準を設定するグループ）によって新しく採用されたルールにより、CAAレコードを検証目的で使用できるようになり、それらを使用する別の正当な理由が提供されます。
欠点の1つは、CAAレコードが存在している場合でも、ユーザーは 強制します 認証局による使用。 これらのレコードが機能するためには、CAがRFC 6844に準拠している必要があります。非準拠のCAは、CAAレコードで宣言されているドメイン所有者の明示的な要望を単に無視する場合があります。
CAAは、ドメイン所有者とCAの両方が正しく構成する必要もあります。 Let's Encrypt（CAAをサポートしています） 彼らのコードベースにマイナーな問題を報告しました 残念なことに、CAAルールは無視され、XNUMXつの証明書が誤って発行されました。 これらはどれも悪意のある例外ではありませんでした（そして、発見から数時間以内に問題を解決して報告するというLet's Encryptチームへの称賛）。 ただし、これは、準拠する認証局が しなければなりません CAAを実装する 完璧に.
もう6844つの潜在的な問題は、CAAがDNSに依存していることです。 ドメイン所有者がネームサービスを保護しない限り、これは攻撃のベクトルになる可能性があります。 RFC XNUMXは実装を提案しています ドメインネームシステムセキュリティ拡張機能（DNSSEC）、デジタル署名されたDNSレコードを使用してデータを認証し、DNSスプーフィングの脅威に対抗します。
最後に、CAAが適切に実装されていても、CAAレコードだけでは不正な証明書の発行を完全に防ぐことはできません。 CAAは攻撃者のオプションを制限するための有用で重要なツールですが、（DNSの制御やソーシャルエンジニアリングなどによって）十分なアクセス権を持つハイジャッカーが迂回できる可能性があります。
結論
認証局認可は、より広範なセキュリティ エコシステムの一部として大きな可能性を秘めており、CAA を広く採用して実装することで、証明書の誤発行を防ぐことができます。CAA だけではすべての証明書の誤発行を阻止することはできませんが、正しい方向への良い一歩であり、SSL.com では CAA レコードの使用を検討することを強くお勧めします。
参考情報
- RFC6844：DNS証明機関承認（CAA）リソースレコード
- RFC5070：インシデントオブジェクト記述交換形式
- RFC6546：HTTP /を介したリアルタイムのネットワーク間防御（RID）メッセージのトランスポートTLS
- RFC4033：DNSセキュリティの概要と要件
- CA / Bフォーラム投票125 – CAAレコード
- DNS証明機関の承認に関するウィキペディアのエントリ
