CAA и ACME: как DNS ограничивает выпуск SSL (issue/issuewild) и что ломает Let's Encrypt

CAA (Certificate Authority Authorization) — DNS-механизм, который позволяет владельцу домена ограничить список центров сертификации (CA), имеющих право выпускать сертификаты для домена. В реальной эксплуатации CAA чаще всего всплывает тогда, когда автоматическое продление через ACME (например, Let’s Encrypt) внезапно падает с ошибкой вида CAA forbids issuance.

Ниже — практичный разбор без «магии»: что именно проверяет CA, как устроена запись CAA, чем отличаются issue и issuewild, как это связано с ACME-челленджами, и какие DNS-ошибки встречаются чаще всего.

Что такое CAA и почему это влияет на выпуск сертификата

CAA — это DNS-запись типа CAA (RFC 8659). Её задача — задать политику выпуска сертификатов: «какие CA могут выпускать сертификаты для моего домена, а какие — нет».

Ключевые моменты для админа:

• CAA проверяет не ACME-клиент (certbot, lego, acme.sh), а сам CA перед выпуском.

• Если CAA настроен слишком жёстко или с ошибкой, выпуск и продление не пройдут даже при полностью рабочем HTTP-01/DNS-01.

То есть ACME-челлендж подтверждает контроль домена, а CAA накладывает политическое ограничение: «только этот CA имеет право выпускать».

Синтаксис CAA: флаг, тег, значение

CAA-запись состоит из трёх частей: флаг, тег, значение.

• Флаг обычно 0 или 128. Значение 128 включает «critical»: если CA не понимает тег, он обязан считать выпуск запрещённым. В продакшне это используют осторожно, чтобы не «отрубить» выпуск из‑за нестандартного тега.

• Тег — ключ. Чаще всего используются issue, issuewild, iodef.

• Значение — обычно доменное имя CA (например, letsencrypt.org) или контакт для уведомлений (для iodef).

Тег issue: разрешение на выпуск обычных сертификатов

Тег issue разрешает CA выпускать сертификаты для домена. Обычно это покрывает сертификаты для корня и поддоменов (включая SAN), но wildcard лучше регулировать явно через issuewild.

Пример: разрешаем выпуск только через Let’s Encrypt:

example.com. CAA 0 issue "letsencrypt.org"

Тег issuewild: разрешение на wildcard

Тег issuewild задаёт правило для wildcard-сертификатов, например *.example.com. Если у вас wildcard выпускается через ACME DNS-01, этот тег — критичное место, где чаще всего «ломают продление».

example.com. CAA 0 issuewild "letsencrypt.org"

Тег iodef: куда отправлять уведомления

iodef задаёт контакт для уведомлений о попытках выпуска, запрещённых CAA. На практике отчёты приходят не всегда, но запись полезна хотя бы как документация «куда стучаться» по вопросам PKI.

example.com. CAA 0 iodef "mailto:security@example.com"

CAA не заменяет проверки владения доменом (HTTP-01/DNS-01/TLS-ALPN-01). Это отдельный слой политики: даже если домен прошёл валидацию, CA обязан свериться с CAA перед выпуском.

Если вы управляете доменами через панель и параллельно держите инфраструктуру на хостинге, удобно, когда домены, DNS и продления находятся «в одном процессе». Для задач с доменами смотрите регистрацию доменов и продумывайте политику CAA заранее, до включения автопродлений.

Как CA ищет CAA в DNS: наследование по дереву имён

CAA применяется по принципу «первой найденной политики» при подъёме вверх по дереву домена.

Упрощённое правило выглядит так:

• CA запрашивает CAA для того FQDN, который указан в сертификате.

• Если CAA на этом имени нет, CA поднимается к родителю: www.example.com → example.com → далее вверх.

• Как только найдена любая CAA-запись на каком-то уровне, именно этот набор и считается политикой для проверяемого имени.

Отсюда следуют два практических вывода:

• CAA на example.com обычно будет применяться к www.example.com, если на www своих CAA нет.

• Если вы добавили хотя бы одну CAA на поддомен (например, mail.example.com), то политика для него перестаёт наследоваться от корня. Это частая причина «вчера всё работало, а сегодня — нет».

CAA и ACME: когда именно происходит проверка

Процесс выпуска по ACME примерно такой:

1. ACME-клиент запрашивает выпуск/продление у CA.

2. CA выдаёт задания на проверку контроля домена (HTTP-01, DNS-01, TLS-ALPN-01).

3. После успешной проверки контроля домена CA перед выпуском делает CAA lookup.

4. Если CAA не разрешает выпуск этому CA — выдача останавливается.

Поэтому при отладке важно разделять два класса проблем:

• челлендж не проходит (не открывается /.well-known/acme-challenge/, не создался TXT для DNS-01 и т. п.);

• политика CAA запрещает выпуск (не тот CA в issue/issuewild, запись стоит «не на том уровне», рассинхрон NS).

Если вы автоматизируете wildcard через DNS-01, полезно держать отдельный плейбук по процессу выпуска и правам на DNS. См. также материал про автоматизацию wildcard через DNS-01: Wildcard SSL и DNS-01: как безопасно автоматизировать выпуск.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Практические шаблоны CAA для продакшна

Ниже — шаблоны, которые закрывают большинство кейсов. Формат в DNS-панелях может отличаться (где-то флаг/тег/значение вводятся отдельными полями), но смысл одинаковый.

1) Разрешить выпуск только Let’s Encrypt (обычные и wildcard)

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"

Используйте, если вы хотите жёстко привязать выпуск к одному CA и у вас вся автоматизация строится вокруг него.

2) Разрешить выпуск двум CA (миграция или запасной вариант)

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "pki.goog"
example.com. CAA 0 issuewild "letsencrypt.org"

Здесь обычные сертификаты можно выпускать у двух CA, а wildcard — только у одного. Это удобная схема для миграций и «плана Б».

3) Разнести политику по поддоменам

Пример: корень и веб — Let’s Encrypt, а для почтового имени — другой CA.

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"
mail.example.com. CAA 0 issue "pki.goog"

Помните: как только на mail.example.com появилась CAA, он перестаёт наследовать политику от example.com. Значит, если для mail вам нужен и Let’s Encrypt тоже (например, для вспомогательных SAN), добавляйте разрешения явно.

Частые ошибки с CAA, issue/issuewild и Let’s Encrypt

Ошибка 1: указан issue, но забыли issuewild (wildcard не выпускается)

Симптом: сертификат для example.com и www.example.com выпускается, а *.example.com — нет.

Что проверять: есть ли issuewild для нужного CA на том уровне домена, который применяется к wildcard.

Ошибка 2: запись стоит на «не том» уровне домена

Симптом: вы уверены, что разрешили Let’s Encrypt, но CA всё равно запрещает выпуск.

Типовые причины:

• CAA добавили на www.example.com, а сертификат запрашиваете для example.com (или для другого поддомена).

• На конкретном поддомене уже есть CAA, которые перекрывают политику корня, и вы про это забыли.

Ошибка 3: значение CA указано с ошибкой

Значение должно совпадать с тем, что ожидает CA. Для Let’s Encrypt это letsencrypt.org. Лишние пробелы, «красивые» названия вроде Let's Encrypt вместо домена CA или артефакты панели DNS могут привести к тому, что CA решит: «разрешения нет».

Практика: всегда проверяйте фактический ответ DNS, а не то, что вы «ввели в форму».

Ошибка 4: рассинхрон авторитативных NS или split-horizon DNS

Симптом: вы видите корректный CAA из одной сети, но выпуск у CA падает.

Чаще всего виноваты:

• split-horizon DNS: внутри компании одна зона, снаружи другая;

• не синхронизировались зоны между авторитативными NS (часть отдаёт старые CAA);

• проблемы с DNSSEC у части резолверов (CA может получать SERVFAIL и действовать по своей политике обработки ошибок).

Ошибка 5: миграция между CA без «окна»

Если вы меняете CA (или контур выпуска), добавляйте разрешения для старого и нового CA параллельно на период миграции. Иначе можно попасть в ситуацию, когда старый сертификат ещё действует, а новый уже невозможно выпустить из-за CAA.

Как проверить CAA: dig и интерпретация

Лучше смотреть ответы от авторитативных серверов, а не только от локального резолвера. Но для первичной диагностики достаточно и обычной проверки.

Быстрая проверка CAA для домена

dig +short CAA example.com

Ожидаемый вывод выглядит примерно так:

0 issue "letsencrypt.org"
0 issuewild "letsencrypt.org"
0 iodef "mailto:security@example.com"

Проверка CAA для поддомена и учёт наследования

dig +short CAA www.example.com

Если ответ пустой, это не гарантирует, что «CAA нет»: политика может наследоваться от example.com. Проверяйте оба уровня.

Проверка авторитативных NS и согласованности ответов

dig NS example.com +short

dig CAA example.com @ns1.example-dns.net +noall +answer

dig CAA example.com @ns2.example-dns.net +noall +answer

Если ответы отличаются — сначала лечите DNS (синхронизацию/делегирование), и только потом повторяйте выпуск.

Что CAA не делает: связь с validation и реальной безопасностью

CAA часто воспринимают как «ещё одну проверку домена», но это не так. CAA не решает следующие задачи:

• Если взломан доступ к DNS/регистратору, атакующий может изменить CAA так же, как и любые другие записи.

• CAA не заменяет и не «чинит» HTTP-01/DNS-01 и не ускоряет ACME.

• CAA не устраняет TLS-проблемы на сервере (цепочки, SNI, ALPN, несовместимые конфиги и т. п.).

Рекомендации по эксплуатации: как не словить простой из-за CAA

Всегда планируйте issuewild, если используете wildcard

Wildcard почти всегда завязан на DNS-01 и часто живёт на автопродлении. Если вы внедряете CAA уже в работающую схему, добавляйте issuewild сразу, иначе продление сломается в самый неудобный момент.

Держите «окно миграции» при смене CA

При переезде между CA держите разрешение на выпуск для старого и нового CA одновременно хотя бы на период выпуска/установки новых сертификатов. После стабилизации — ужимайте политику.

Учитывайте TTL и распространение

CAA — это DNS, значит, всё упирается в TTL, кэширование и согласованность авторитативных NS. При аварийной правке CAA заранее прикиньте, через сколько времени CA увидит обновление.

Документируйте политику и добавляйте iodef

iodef не панацея, но помогает команде: становится понятно, почему политика такая и куда отправлять уведомления/вопросы по выпуску.

Если вы выпускаете сертификаты не только через Let’s Encrypt (например, для корпоративных клиентов или отдельных контуров), иногда проще держать часть проектов на управляемой инфраструктуре с предсказуемыми DNS и веб-окружением — например, на виртуальном хостинге или VDS, где вы полностью контролируете автоматизацию и логи.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Мини-чеклист: если ACME/Let’s Encrypt ругается на CAA

1. Определите тип выпуска: обычный сертификат или wildcard. Для wildcard проверяйте issuewild.

2. Проверьте CAA на точном FQDN и на родителе (учёт наследования).

3. Проверьте ответы со всех авторитативных NS: нет ли рассинхронизации.

4. Убедитесь, что значение CA указано корректно (для Let’s Encrypt — letsencrypt.org).

5. Если правки свежие — учтите TTL и время распространения.

Итог

CAA — полезный инструмент управления рисками: он ограничивает выпуск сертификатов доверенными центрами сертификации. Но именно из-за этого CAA часто ломает ACME-автоматизацию, если забыть про issuewild, повесить записи на неверный уровень домена или получить рассинхрон на авторитативных NS.

Держите CAA как часть инфраструктурной политики: документируйте, проверяйте ответы авторитативных DNS, меняйте записи с учётом TTL и миграций между CA. Тогда безопасность будет выше, а ночных инцидентов с продлением станет заметно меньше.