最終更新日: 2023年8月16日 | すべてのドキュメントを見る

CAAは、サイト所有者が自分のドメイン名を含む証明書の発行を許可する認証局 (CA) を指定できるDNSレコードの一種です。2013年に初めて標準化され、現在使用されているバージョンは2019年にRFC 8659とRFC 8657によって標準化されました。デフォルトでは、すべてのパブリックCAは、パブリックDNSの任意のドメイン名に対して、そのドメイン名の制御を検証することを条件として、証明書を発行できます。これは、多数のパブリックCAの検証プロセスにバグがある場合、すべてのドメイン名が潜在的に影響を受けることを意味します。CAAは、ドメイン所有者がそのリスクを軽減する方法を提供します。

CAAの使用

CAAに関心がない場合は、一般的に何もする必要はありません（ただし、以下のCAAエラーを参照してください）。CAAを使用して、ドメインの証明書の発行を許可する認証局を制限する場合は、CAAレコードの設定をサポートするDNSプロバイダーを使用する必要があります。そのようなプロバイダーのリストについては、SSLMateのCAAページを確認してください。プロバイダーがリストされている場合は、SSLMateのCAAレコードジェネレーターを使用して、許可するCAをリストしたCAAレコードのセットを生成できます。

レコードの配置場所

一般的に、CAAレコードは登録ドメイン（「example.org」や「mysite.co.uk」など）に設定します。こうすることで、そのドメインと、その下に作成したサブドメイン（「community.example.org」など）の両方に適用されます。

CAは、常に証明書を発行するドメイン名に最も近いCAAレコードを尊重することに注意してください。そのため、「www.community.example.org」の証明書をリクエストする場合、CAは「www.community.example.org」、「community.example.org」、「example.org」の順にチェックし、最初に見つかったCAAレコードで停止します。

これは、サブドメインのCAAをオーバーライドできることを意味します。たとえば、「example.org」を自分でホストしているが、「api.example.org」をクラウドプロバイダーに配置しているとします。「example.org」にCAAレコードを使用して、Let's Encryptのみがそのドメインとそのすべてのサブドメインに対して発行できるように指定し、「api.example.org」にCAAレコードを使用してそれをオーバーライドし、クラウドプロバイダーがその1つのサブドメインに対して証明書を発行できるようにすることができます。

また、CAAチェックは、他のすべてのDNSリクエストと同様に、CNAMEリダイレクトに従うことにも注意してください。「community.example.org」が「example.forum.com」へのCNAMEである場合、CAは「example.forum.com」に設定されているCAAレコードを尊重します。CNAMEレコードを持つドメイン名は他のレコードを持つことができないため、元の名前のCAAレコードとリダイレクト先のCAAレコードの間に競合が生じることはありません。

レコードに含める内容

すべてのCAAレコードは同じ基本フォーマットに従います

CAA <flags> <tag> <value>

flagsは単なる整数であり、ほとんどの場合、フラグが設定されていないことを示す整数0にする必要があります。必要に応じて、フラグを整数128に設定して、「クリティカルビット」が設定されており、CAがタグフィールドの内容を認識しない場合はすぐに停止して証明書を発行しないように指示できます。

tagは、このCAAレコードの種類を示す文字列です。ほとんどの場合、issueまたはissuewildのいずれかです。これらについては以下で詳しく説明します。

最後に、valueは、最大で1つのCA識別子（「letsencrypt.org」など）といくつかのオプションのセミコロン区切りのパラメーターを含む文字列です。パラメーターについても以下で説明します。

`issue`プロパティと`issuewild`プロパティ

issueタグが付いたレコードは、CAがこのドメインとそのサブドメインの証明書を発行できるかどうかを制御するだけです。一般的に、これは必要な唯一のレコードです。他のレコードがない場合、通常の（例：「example.org」）発行とワイルドカード（例：「*.example.org」）発行の両方を制御するためです。このドメインに対して発行できるCAは、CAAレコードの値部分にそのCAの識別ドメイン名を配置することで制御します。

issuewildタグが付いたレコードは、CAがワイルドカード証明書（例：「*.example.org」）を発行できるかどうかを制御します。ワイルドカード発行と非ワイルドカード発行で異なる権限が必要な場合にのみ、issuewildレコードを使用する必要があります。

同じプロパティタイプのレコードを複数持つことができ、それらは加算的であることに注意してください。これらのレコードのいずれかがCAの発行を許可する場合、発行は許可されます。

CAAのLet's Encryptの識別ドメイン名はletsencrypt.orgです。これは、CP/CPSのセクション4.2.1に公式に記載されています。

`validationmethods`パラメーター

このパラメーターは、CAの識別ドメイン名の後に配置して、CAがドメインの制御を確認するために使用できる検証方法を制御できます。これは、信頼できる方法に検証を制限するために使用できます。たとえば、CAをTLS-ALPN-01メソッドのみを使用するように制限する場合は、CAAレコード値に;validationmethods=tls-alpn-01を追加できます。

Let's Encryptは、次の検証メソッド文字列を認識します

http-01
dns-01
tls-alpn-01

`accounturi`パラメーター

このパラメーターは、CAの識別ドメイン名の後に配置して、どのACMEアカウントがドメインの発行をリクエストできるかを制御できます。これは、ドメインを一時的にハイジャックした人が、ACMEアカウントキーにアクセスできなくても、悪意のある証明書を発行できないようにするために使用できます。

Let's EncryptのアカウントURIはhttps://acme-v02.api.letsencrypt.org/acme/acct/1234567890のようになります。末尾の数字はアカウントIDです。

例

Let's Encryptが「example.org」に対して発行することを許可する簡単なCAAレコードは、次のようになります

example.org         CAA 0 issue "letsencrypt.org"

より複雑なCAAレコードセットは、次のようになります

example.org         CAA 0 issue "myca.org;validationmethods=dns-01"
example.org         CAA 0 issuewild "myca.org"
example.org         CAA 128 issue "otherca.com;accounturi=https://otherca.com/acct/123456"

この例では、MyCAは「example.org」に対して発行できますが、DNS-01検証メソッドのみを使用します。また、任意の検証方法を使用して、ワイルドカード証明書を発行することもできます。最後に、OtherCAも証明書を発行できますが、リクエストがアカウント番号123456からのものであり、OtherCAがaccounturi制限を認識し、正しく処理する方法を知っている場合に限ります。

CAAエラー

Let's Encryptは発行するすべての証明書の発行前にCAAレコードをチェックするため、CAAレコードを設定していないドメインでもエラーが発生することがあります。エラーが発生した場合、発行を禁止するCAAレコードが存在する可能性がありますが、エラーのために表示されないため、影響を受けるドメインに対して発行できるかどうかを判断する方法はありません。

CAA関連のエラーが発生した場合は、ステージング環境に対してさらに数回試して、一時的なエラーか永続的なエラーかを確認してください。永続的なエラーの場合は、DNSプロバイダーにサポートの問題を報告するか、プロバイダーを切り替える必要があります。DNSプロバイダーがわからない場合は、ホスティングプロバイダーにお問い合わせください。

CAAに慣れていない一部のDNSプロバイダーは、最初に問題レポートに「CAAレコードはサポートしていません」と返信します。DNSプロバイダーはCAAレコードを特にサポートする必要はありません。不明なクエリタイプ（CAAを含む）に対してNOERROR応答で返信するだけで済みます。認識されないqtypeに対してNOTIMPを含む他のオペコードを返すことは、RFC 1035の違反であり、修正する必要があります。

SERVFAIL

人々が遭遇する最も一般的なエラーの1つはSERVFAILです。ほとんどの場合、これはDNSSEC検証の失敗を示しています。SERVFAILエラーが発生した場合は、最初のステップとして、dnsviz.netなどのDNSSECデバッガーを使用する必要があります。それでも解決しない場合は、ネームサーバーが応答が空の場合にのみ誤った署名を生成する可能性があります。また、CAA応答はほとんどの場合空です。たとえば、PowerDNS バージョン4.0.3以下にこのバグがありました。

DNSSECが有効になっておらず、SERVFAILが発生した場合、2番目に可能性の高い理由は、権限のあるネームサーバーがNOTIMPを返したことです。これは、前述のとおり、RFC 1035の違反です。代わりに、空の応答でNOERRORを返す必要があります。この場合は、DNSプロバイダーにバグまたはサポートチケットを提出してください。

最後に、SERVFAILは、権限のあるネームサーバーの停止が原因で発生する可能性があります。ネームサーバーのNSレコードを確認し、各サーバーが使用可能であることを確認してください。

タイムアウト

CAAクエリがタイムアウトすることがあります。つまり、権限のあるネームサーバーは、複数回再試行した後でも、まったく応答しません。これは、ネームサーバーの前に、未知のqtypeを持つDNSクエリをドロップする誤って構成されたファイアウォールがある場合に最もよく発生します。DNSプロバイダーにサポートチケットを提出し、そのようなファイアウォールが構成されているかどうかを尋ねてください。

認証局認可 (CAA)