Проблема с получением сертификата из-за конфликта CNAME и TXT
Categories:
CNAME и TXT с одинаковым префиксом не могут сосуществовать
Те, кто сталкивался с доменами, возможно, знают, что записи (A, AAAA) не могут сосуществовать с CNAME, но вряд ли сталкивались с конфликтом TXT и CNAME.
В каких случаях TXT и CNAME могут использовать один и тот же префикс одновременно?
Один из сценариев - это получение сертификата LetsEncrypt с использованием вызова DNS-01 для подтверждения права собственности на домен.
- Certbot использует ackey и acsecret или токен для создания записи TXT
_acme-challenge.example.com - Letsencrypt запрашивает TXT запись, чтобы подтвердить, что заявитель имеет право создавать DNS-записи, доказывая право собственности на домен.
- Letsencrypt выдает сертификат
- Certbot удаляет запись TXT
_acme-challenge.example.com
Если при создании записи TXT уже существует запись CNAME _acme-challenge.example.com, запись TXT может не создаться, что приведет к сбою проверки домена.
Почему может появиться запись CNAME _acme-challenge.example.com?
Недавно Alibaba Cloud представила ESA (Edge Security Acceleration), похожую на Cloudflare, это улучшенная версия прежнего DCDN (全站加速). Раньше она не поддерживала самостоятельное получение поддоменов, поэтому я использовал скрипт для периодической загрузки своих поддоменных сертификатов, что было немного неудобно. Позже появилась функция управляемого DCV, позволяющая самостоятельно получать и обновлять поддоменные сертификаты. Следуя инструкциям, действительно можно управлять поддоменными сертификатами самостоятельно. Однако спустя несколько месяцев я обнаружил скрытую проблему. Эта запись CNAME продолжает существовать, что может помешать созданию записи TXT с тем же префиксом, в результате чего я не смогу подтвердить право собственности на домен в другом месте.
Решения
Решение 1: Не использовать управляемый DVC
Для управляемого DVC требуется записать _acme-challenge.example.com с указанным значением, что по сути означает передачу домена третьей стороне, и вы больше не имеете контроль над этим доменом.
Для получения поддомена можно использовать скрипт для периодической загрузки поддоменного сертификата на ESA через API.
Решение 2: Не использовать DNS-01 для подтверждения права собственности на домен
Certbot предоставляет несколько методов подтверждения права собственности на домен (вызовы, challenge), кроме проверки корневого домена (DNS-01), также можно использовать HTTP-01 и TLS-ALPN-01.
Методы HTTP-01 и TLS-ALPN-01 требуют наличия сервиса, подтверждения доступности, а затем получения сертификата.
DNS-01 позволяет получить сертификат до настройки сервиса.
Решение 3: Разрушить барьер между ESA и DNS облачного разрешения
Оба сервиса принадлежат Alibaba Cloud, но каждый реализует свой API DNS. Если ESA сможет самостоятельно настраивать CNAME или TXT записи в DNS облачного разрешения, получать сертификат, а затем удалять записи, это не повлияет на использование DNS-01 в другом месте.
Решение 4: Не использовать Alibaba ESA
На Cloudflare таких проблем нет, сертификаты выдаются без проблем.