#Что произошло и как распознать неисправность
При попытке получить TLS-сертификат удостоверяющий центр сообщает о запрете CAA. DNS-записи CAA определяют, какие удостоверяющие центры могут выпускать сертификаты для домена; ограничения могут наследоваться от родительских имён и различаться для обычного и wildcard-сертификата. Проблема не устраняется сменой браузера или отключением проверки HTTPS. Перед изменениями уточните, какой центр действительно пытается выпустить сертификат, какие CAA видит его проверка и где расположена авторитетная зона. Добавлять произвольное issue с чужим доменом бессмысленно и небезопасно.
#Причины и отличительные признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| CAA разрешает другой центрВ CAA issue указан иной удостоверяющий центр, чем выбранный в панели. | Текущая CAA отвечает issue "другой-центр", запрос выпуска отклонён. | Добавить официальное имя выбранного центра с согласованием владельца домена. |
Wildcard ограничен отдельноПолитика issuewild отличается от issue и не разрешает требуемый wildcard. | Обычный сертификат выдаётся, *.example.com — нет. | Сверить CAA issuewild с правилами выбранного CA. |
| CAA находится у родителяНа самом поддомене CAA нет, но у example.com есть ограничение. | Поиск CAA у родительского имени показывает запрет. | Исправить подходящую запись с учётом области действия. |
| Ответ CAA некорректен из-за DNSПроблема DNSSEC, SERVFAIL, делегирования или разных ответов NS мешает центру проверить CAA. | Запросы CAA иногда завершаются ошибкой вместо нормального ответа. | Сначала восстановить правильные авторитетные DNS-ответы. |
#Пошаговая диагностика и исправление
- Получите точную ошибку выдачи сертификатаВ панели хостинга или журнале ACME откройте последнее задание выпуска и запишите домен, вид сертификата (обычный или wildcard), название CA и сообщение CAA. Если ошибка относится к проверке HTTP-01 или TXT DNS-01, это другая неисправность: сначала исправьте соответствующую проверку владения, не меняя CAA.
- Прочитайте CAA у нужного доменаОткройте терминал с утилитой dig и выполните
dig example.com CAA +short, заменив домен на реальный. В ответе может быть запись вида0 issue "letsencrypt.org"— это только пример для Let's Encrypt. Отсутствие CAA на запрошенном имени не означает свободы выпуска: центр может учитывать записи родительского имени и правила следования CNAME/алиасам. - Проверьте родительские имена и авторитетные NSДля cert.example.com отдельно выполните
dig cert.example.com CAA +shortиdig example.com CAA +short. Затем запросите те же данные у авторитетных серверов черезdig @ns1.example.com example.com CAA +short. Если ответы разнятся, сначала исправьте синхронизацию зоны или укажите правильную авторитетную панель. Не редактируйте CAA у домена, которым не управляете. - Уточните тип сертификата и правильное правилоЗапись
issueограничивает выпуск обычных сертификатов;issuewildзадаёт правила для wildcard, с нюансами наследования согласно RFC 8659. Для*.example.comпроверьте политику выпуска wildcard и возможность добавления основного example.com отдельным именем сертификата. Запрет или пустое значение могут быть намеренной политикой безопасности организации. - Сверьте идентификатор центра с официальной документациейПерейдите на официальный сайт вашего удостоверяющего центра и найдите опубликованный для CAA домен issuer. У Let's Encrypt обычно используется
letsencrypt.org, но для других CA значение и дополнительные параметры могут отличаться. Не подставляйте имя сайта панели хостинга вместо идентификатора CA. При договорных ограничениях обратитесь к владельцу домена, прежде чем расширять разрешения. - Сохраните CAA и внесите минимально нужную записьВ авторитетной DNS-панели найдите раздел DNS-записей, фильтр типа CAA и сохраните весь старый набор. Если владелец домена разрешил выбранный центр, добавьте соответствующую
CAA 0 issue "официальное-имя-CA"илиissuewildпри необходимости. Уточните, как панель вводит флаг 0, тег issue и значение. Не удаляйте другие CAA без согласования — они могут защищать выпуск и отчётность. - Проверьте новую политику и устраните ошибки DNSВыполните прямой запрос CAA к каждому авторитетному серверу. Ответы должны совпадать и не иметь SERVFAIL. Если включён DNSSEC, проверьте, что валидирующие резолверы принимают исправленную зону: не отключайте валидацию ради сертификата. Дождитесь прежнего TTL у рекурсоров, иначе повторный запрос CA может видеть старые ограничения.
- Повторите выпуск и проверьте итоговый сертификатВ панели ACME запустите повторный выпуск после исправления CAA и устранения возможных других ошибок. При успехе откройте HTTPS в браузере, щёлкните значок сведений о соединении и убедитесь, что сертификат относится к нужному имени и сроку; альтернативно используйте проверку TLS. Если CAA снова отклонён, посмотрите новое точное сообщение, сравните ответы NS и при необходимости верните первоначальную политику по согласованному плану.
- Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
#Как проверить результат и что делать при неуспехе
Исправление подтверждено согласованными CAA у авторитетных NS, успешным выпуском сертификата у выбранного центра и корректным сертификатом на HTTPS. Если CA продолжает отказывать, учитывайте наследование CAA, alias и точный вид сертификата.