DNS CAA (Certification Authority Authorization)利用が標準化
証明書の誤発行を防止するために、ドメインのDNSデータを利用する仕組みが[RFC6844]で定められている「DNS CAA」です。
以下はその原理です。
- ドメインの管理者がDNSのCAA (Certification Authority Authorization) レコードを利用し、ドメイン名とサブドメインに対して証明書を発行できる認証局 (CA) を指定できます。
- 証明書発行を依頼された認証局 (CA) はドメイン及びサブドメインのCAAを確認し、証明書を発行できる認証局 (CA) が異なる場合は、証明書を発行せず、ドメイン管理者に誤った発行申請があったことを報告します。
「DNS CAA」が定着すれば、証明書の誤発行が防げますが、2013年に [RFC6844]が定めらたものの、定着はしてきませんでした。
CAAが利用されているサイトは100サイトないし200サイトだろうといわれています。
CA/ブラウザフォーラム、CAA利用の義務化を予定
主要な認証局 (CA) とWebブラウザー開発ベンダーによって構成されているCA/ブラウザフォーラムは、認証局 (CA) の行動基準である「the Baseline Requirements」を策定しています。
2017年3月、CA/ブラウザフォーラムは、認証局 (CA) が2017年9月8日以降に証明書を発行するに当たって、[RFC6844] に準拠し、CAA (Certification Authority Authorization) レコードを確認することが義務付けられるよう、「the Baseline Requirements」を変更することを決定しました。
この決定により、以下のような要素が「the Baseline Requirements」に追加されます。
- 発行プロセスの一環として、CAは、[RFC6844] の手順に従い、発行される証明書のドメイン及びサブドメインのCAAレコードを確認し、見つかったレコードについて[RFC6844]で設定された処理手順に従う必要がある。
- CAが発行する場合は、「CAAレコードのTTL期限内、あるいは8時間以内」のうちのいずれか遅い時間以内に発行する必要がある。
- CAはそのCP (証明書ポリシー) またはCPS (認証局運用規程) で、完全修飾ドメイン名のCAAレコードの処理に関する方針または手順を記述しなければならない。
- CAはCP (証明書ポリシー) または CPS (認証局運用規程) において、自身のドメイン名が「CAA の”issue” レコードあるいは “issuewild” レコードの発行を許可されたCAのドメイン名」として、どのように記載されるべきかも明示しなければならない。
- CAは、取られたすべてのアクションを、記録しなければならない。
※この規定は認証局 (CA) に課せられる義務ですが、すべてのドメインで必ずCAAレコードが設定されていなければならないという訳ではありません。
[RFC6844] に定められているCAAレコードの仕様
CAAレコードの標準的な表示形式
CAAレコードの標準的な表示形式は次のとおりです。
CAA <flags> <tag> <value>
「Flags」：フラグ値1は、ビット7が設定されていることを意味し、無視してはならない情報の場合に設定されます。フラグ値128は、ビット0が設定されていることを意味します。その他のビット位置はすべて将来の使用のために予約されています。CAAへの将来の拡張との互換性を保証するために、このバージョンのCAA仕様に準拠するDNSレコードはすべての予約済みフラグビットをクリア（ “0”に設定）しなければなりません。
「Tag」：US-ASCII文字と数字の非ゼロシーケンスが小文字で表示されます。現時点で有効なTagは以下の3種類です。
| issue |
ドメインの証明書を発行できる認証局 (CA) のドメインを指定するために使われます。複数の認証局 (CA) のドメインを指定することもできます。 |
| issuewild |
ワイルドカード証明書を発行できる認証局 (CA) のドメインを指定するために使われます。複数の認証局 (CA) のドメインを指定することもできます。 |
| iodef |
「The Incident Object Description Exchange Format」データの送付先を指定します。 |
「Value」：値フィールドの<文字列>
具体例
具体例では以下のようになります。
example.com. 86400 IN CAA 0 issue “ca.example.net”
example.com. 86400 IN CAA 0 issuewild “ca.example.net”
example.com. 86400 IN CAA 0 iodef “mailto:security@example.com”
example.com. 86400 IN CAA 0 iodef “http://iodef.example.com/”
例で使用されているドメイン名は、それぞれ以下の役割を表しています。
86400はTTL値の例として使っています。
example.com、support.example.com、iodef.example.com
・・・証明書発行対象となるドメイン名あるいはドメイン管理者が管理しているドメイン名
ca.example.net ・・・証明書発行を許可された認証局 (CA) のドメイン名
issue Tagの例
次の例は、ドメイン名 ‘ca.example.net’の所有者またはその代理人以外、example.com の証明書を発行できないことを認証局 (CA) に通知するDNSゾーンファイルです。
この例の場合、このポリシーは、example.comのすべての下位ドメインに適用されます。
example.com. 86400 IN CAA 0 issue “ca.example.net”
issuewild Tagの例
次の例は、ドメイン名 ‘ca.example.net’の所有者またはその代理人以外、*.support.example.com ワイルドカード証明書を発行できないことを認証局 (CA) に通知するDNSゾーンファイルです。
support.example.com. 86400 IN CAA 0 issuewild “ca.example.net”
iodef Tagの例
次の例のようにドメイン名所有者が1つまたは複数のiodefプロパティを指定する場合、認証局 (CA) は無効な証明書要求をそのアドレスに報告することができます。
次の例では、ドメイン名所有者はレポート送付先として、添付ファイルでの電子メールの場合 security@example.com を、「Web service request」の場合 http://iodef.example.com を指定しています。
レポートの書式は The Incident Object Description Exchange Format (IODEF) として [RFC5070] で定義されています。
example.com. 86400 IN CAA 0 issue “ca.example.net”
example.com. 86400 IN CAA 0 iodef “mailto:security@example.com”
example.com. 86400 IN CAA 0 iodef “http://iodef.example.com/”
追加パラメータの例
以下の例のように、追加のパラメータを指定することもできます。
以下は認証局 (CA) “ca.example.net” が顧客の “example.com” のCAAレコードにCAのアカウント番号 ‘230123’ を指定するよう依頼したケースです。
example.com. 86400 IN CAA 0 issue “ca.example.net; account=230123”
CAAレコード登録確認
CAAレコードの指定状態はdigコマンドで以下のように確認できます。
例：rms.ne.jp のCAAレコードの指定状態を確認する場合
dig caa rms.ne.jp
登録されている場合は以下のような結果が得られます。
;; ANSWER SECTION:
rms.ne.jp. 86400 IN CAA 0 issuewild “digicert.com”
rms.ne.jp. 86400 IN CAA 0 issue “digicert.com”
※Windows環境でdigコマンドを利用する場合は、以下のリンク先からダウンロードし、Tools Onlyのインストールを行ってください。
