CAAを使用する理由
CAは常に次の方法を使用します ドメイン検証 すべてのSSL /を確認するTLS 証明書の要求が承認されます（通常、そのドメインを使用する特定のサイトに何らかの方法でリンクされていることを確認することにより）。
たとえば、CAが要求者に特別な検証ファイルを提供する場合があります。 このファイルをWebサイトに配置すると、要求者もそのサイトを制御していることが証明されますが、 合法性 そのコントロールの。 サイトの制御を取得したハッカーは、正当な所有者になりすまして、SSL /を要求および受信する可能性があります。TLS CAの標準チェックに合格した証明書 と思われる 正当な。 その後、彼らは振り返ってそのSSL /を使用することができますTLS そのサイトまたは他の場所でのいたずら用の証明書。
CAAは、ドメインの証明書の発行を許可するCAを定義する（または証明書の発行を完全に制限する）ことで、この種のエクスプロイトをブロックするのに役立ちます。 これにより、ハイジャッカーが与える可能性のある損害が制限されます。サイトを管理している場合でも、不正なSSL /をスコアリングするためのオプションが大幅に少なくなります。TLS 証明書。
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 はフラグです（ゼロがデフォルトです。これについては以下で説明します）。 タグは 問題 値（引用符内）は ssl.com、一緒にプロパティを構成します。
フラグ
フラグには現在、厳密に定義されたXNUMXつの状態のみがあります。 0 （非重要）および 1 （クリティカル）。 クリティカルフラグはCAに しなければなりません 続行するには、プロパティタグを完全に理解してください。 RFC 6844では、ユーザー定義のフラグを使用できる他の可能性が残されています（これらについても以下で説明します）。
タグ
RFC 6844は、XNUMXつの一般的なタグの使用を定義しています。 問題, ワイルド および ヨーデフ。 （フラグと同様に、他の潜在的なカスタマイズされたタグタイプを許可します。）
問題 タグ
問題 タグは、このドメインの証明書を発行する権限がある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.)
CA定義のフラグとタグ
RFC 6844で説明されているCAAは、0つのフラグ状態（1とXNUMX）とXNUMXつのタグ（問題, ワイルド および ヨーデフ）。 ただし、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レコードを検証目的で使用できるようになり、それらを使用する別の正当な理由が提供されます。
…そしてマイナス
CAAの最大の問題は、すべてのCAで採用されていないことです。 CA / Bフォーラムのベースライン要件（すべての信頼できるCAが満たす）は、オンラインドキュメントでCAAをサポートする程度を指定するようにCAに指示します。 ただし、これを書いている時点では、CAAの使用は 推奨される、必要ありません。 CAAに準拠していない認証局も対象とすることができ、CAAが広く使用されるまで、ハイジャッカーは不正な証明書を発行しようとする非準拠のCAを見つけることができます。
関連する欠点は、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をサポートしているわけではありませんが、これをすべてのCAに対してより強く推奨または必須にすることについての議論があります。 CAAだけですべての証明書の発行が停止されるわけではありませんが、これは正しい方向への良い一歩であり、SSL.comはCAAレコードを自分で使用することを検討することをお勧めします。
参考文献
- RFC6844：DNS証明機関承認（CAA）リソースレコード
- RFC5070：インシデントオブジェクト記述交換形式
- RFC6546：HTTP /を介したリアルタイムのネットワーク間防御（RID）メッセージのトランスポートTLS
- RFC4033：DNSセキュリティの概要と要件
- CA / Bフォーラム投票125 – CAAレコード
- DNS証明機関の承認に関するウィキペディアのエントリ
