CNAMEとTXTの競合による証明書申請問題
Categories:
同一プレフィックスのCNAMEとTXTは共存できない
ドメインを扱ったことがある人なら、(A,AAAA)レコードとCNAMEは共存できないことを知っているかもしれないが、TXTとCNAMEが衝突する状況に遭遇したことはないかもしれない。
どのような場合にTXTとCNAMEが同じプレフィックスで使用されるのか?
その一つのシナリオは、LetsEncryptの証明書申請で_DNS-01_チャレンジを使用してドメイン所有権を検証するときである。
- Certbotはackeyとacsecret、またはtokenを使用して、
_acme-challenge.example.comのTXTレコードを作成する - LetsencryptはTXTレコードを照会し、申請者がDNSレコードを作成する権限を持っていることを確認し、ドメイン所有権を証明する
- Letsencryptが証明書を発行する
- Certbotが
_acme-challenge.example.comのTXTレコードを削除する
TXTレコードを作成する際に、すでに_acme-challenge.example.comのCNAMEレコードが存在している場合、TXTレコードの作成が失敗し、ドメインチャレンジ検証が失敗する可能性がある。
なぜ_acme-challenge.example.comのCNAMEレコードが存在するのか?
阿里云が新たにリリースしたESAエッジセキュリティアクセラレータは、cloudflareに似ており、元のDCDN全サイトアクセラレータの改名強化版である。初期使用時は、ワイルドカードドメインの申請がサポートされておらず、自分で申請したワイルドカード証明書をスクリプトで定期的にアップロードして管理していた。管理がやや不便だった。後にDCVホスティングが導入され、ワイルドカードドメイン証明書をセルフサービスで申請・更新できるようになった。説明通りに操作すれば、確かにワイルドカードドメイン証明書をセルフサービスで管理できる。しかし、数ヶ月後にようやく気づく隠れた問題が残されていた。このCNAMEレコードが継続的に存在すると、同じプレフィックスのTXTレコードを作成できず、他の場所でドメイン所有権を証明できなくなる。

解決策
ソリューション1: ホスティングDVCを使用しない
ホスティングDVCは、_acme-challenge.example.comに指定値を書き込むことを要求する。本質的にそのドメインをサードパーティに属させ、自分自身がそのドメインの管理権を失うことを宣言する。
ワイルドカードドメインが必要な場合は、タスクスクリプトを使用してESAのAPIを呼び出し、ワイルドカード証明書をESAに定期的にアップロードする方法がある。
ソリューション2: DNS-01でドメイン所有権を検証しない
Certbotは、DNS-01の根ドメイン検証以外に、HTTP-01やTLS-ALPN-01などのドメイン所有権検証(チャレンジ)方法を提供している。
HTTP-01とTLS-ALPN-01の方法は、まずサービスを用意し、アクセス可能であることを検証した後に証明書を発行する必要がある。
DNS-01は、サービスを構築する前でも証明書を取得できる。
ソリューション3: ESAとクラウドDNS解析の業務壁を打破する
この二つのサービスはいずれも阿里云に属しているが、それぞれ独自のDNS APIを実装している。もしESAがクラウドDNS解析でCNAMEやTXTレコードをセルフサービスで設定でき、証明書取得後にレコードを削除できるなら、他の場所でのDNS-01チャレンジに影響を与えない。
ソリューション4: 阿里ESAを使用しない
cloudflareにはこのような問題はない。証明書は自由に取得できる。