注意: この記事はLLMによって英語から翻訳されたものです。正確性については保証いたしかねますので、あらかじめご了承ください。英語の原文はこちら。
ブログをS3とCloudFormationに移行する際、AWS Certificate Managerを使って新しい証明書を生成する必要があった。しかし、正しいDNSレコードを作成し、伝播を待った後も、AWSは理由を示さずに生成リクエストを拒否し続けた。
何が起きているのか理解しようと多くの時間を費やした結果、自分のドメイン名に対してAmazonの認証局がSSL証明書を発行することを許可していなかったため、検証が失敗していることがわかった。これはCAA(認証局認可)DNSレコードを追加することで設定すべきものだった。
CAAフィールドは何のために使われるのか?#
CAA DNSエントリは、特定のドメインに対してどの認証局が証明書を生成できるかを指定するものである。証明書の誤発行を防ぐことを目的としている。
CAAの設定#
基本的な例を見てみよう。以下はdig CAA ixonae.comコマンドの出力の抜粋である。
ixonae.com. 16 IN CAA 0 issuewild "letsencrypt.org"
ixonae.com. 16 IN CAA 0 iodef "mailto:[redacted to prevent crawling]@ixonae.com"
ixonae.com. 16 IN CAA 0 issue "amazon.com"
ixonae.com. 16 IN CAA 0 issue "letsencrypt.org"この応答は、AmazonとLet’s Encryptの両方がドメインixonae.comおよびそのサブドメインの証明書を生成できるが、ワイルドカード証明書を生成できるのはLet’s Encryptのみであることを示している。認証局が証明書生成の無効なリクエストを受け取った場合、指定されたメールアドレスにメッセージを送信する必要がある。0の値はフラグであり(issue、issuewild、iodefはタグ)、CAAエントリを理解できない場合でも気にせず、次のエントリを読もうとするよう認証局に伝えるものである。
フラグ#
フラグ値は2つある:
0(非クリティカル)がデフォルト。認証局がエントリを理解できない場合、単に無視できる1(クリティカル)は、プロパティを理解できない場合、認証局は証明書の発行を続行できず、(iodefで提供された値を使って)所有者に失敗を通知しなければならないことを示す
CAAのスコープ#
この例では、すべてのエントリがixonae.comに対して定義されているが、www.ixonae.comやtest.www.ixonae.comなどの特定のドメインに対してもエントリを定義できる。
ルールの優先順位は最も具体的なものから最も一般的なものへとなる。つまり、test.subdomain.domain.comの証明書を生成したい場合、認証局はまずtest.subdomain.domain.comにルールが存在するか確認する。存在しなければ、subdomain.domain.comにルールがあるか確認し、最後にdomain.comを確認する。
もう一つ注意すべき点は、issueエントリのみがある場合、リストされた認証局はワイルドカード証明書の発行も許可されるということである。ただし、issuewildエントリがある場合、そのフラグを持つエントリのみがワイルドカード証明書を生成できる。
最後に興味深い特性として、認証局を";"としたエントリのみを作成した場合、指定されたドメインの証明書は誰も生成できなくなる(CAAエントリがない場合は、すべての認証局が発行可能である)。
参考文献#
- https://letsencrypt.org/docs/caa/
- https://community.letsencrypt.org/t/caa-issuewild-question/159018/4
- https://www.thesslstore.com/blog/what-is-caa-record-certificate-authority-authorization/
クレジット#
- カバー写真:Scott Rodgerson(Unsplash)