CAA-запись DNS: контроль выдачи SSL-сертификатов

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

Зачем нужна CAA-запись

Защита от мошеннического получения SSL вашего домена
Предотвращение атак типа «compromised CA»
Обязательна для организаций с высокими требованиями безопасности
Рекомендована NIST и требована некоторыми стандартами

Синтаксис CAA-записи

# Разрешить только Let's Encrypt
@    IN    CAA    0 issue "letsencrypt.org"

# Разрешить Let's Encrypt и Sectigo
@    IN    CAA    0 issue "letsencrypt.org"
@    IN    CAA    0 issue "sectigo.com"

# Разрешить Wildcard только от определённого CA
@    IN    CAA    0 issuewild "letsencrypt.org"

# Email для уведомлений об отказах
@    IN    CAA    0 iodef "mailto:security@example.com"

Центр сертификации	CAA-значение
Let's Encrypt	letsencrypt.org
DigiCert	digicert.com
Sectigo (Comodo)	sectigo.com
GlobalSign	globalsign.com
Entrust	entrust.net

Проверка CAA-записи

dig example.com CAA
# Онлайн: caatest.co.uk

💡 Если CAA нет: Отсутствие CAA-записи означает, что любой CA может выпустить сертификат для домена. Это не критично для базовых сайтов, но для финансовых и корпоративных проектов — добавьте CAA.

⚠️ Wildcard-сертификаты: Если используете Wildcard SSL, добавьте отдельную issuewild запись для того же CA. Без неё CA откажет в выпуске Wildcard, даже если есть обычная issue запись.

Частые ошибки при настройке CAA

Симптом / сообщение	Причина	Решение
Let's Encrypt: `Error creating new order :: Policy forbids issuing for this domain`	CAA-запись разрешает другой CA или не содержит `letsencrypt.org` вовсе	Добавить `0 issue "letsencrypt.org"` в зону, подождать распространения TTL записи
Обычный SSL выпускается, а Wildcard — нет	Есть запись `issue`, но отсутствует отдельная `issuewild` для того же CA	Добавить `0 issuewild "letsencrypt.org"` дополнительно к `issue`
CA выдаёт сертификат, хотя CAA явно запрещает	CAA проверяется CA только в момент выпуска нового сертификата — уже выпущенные ранее сертификаты не отзываются автоматически	Явно отозвать нежелательный сертификат через CA, если он выпущен до появления CAA
Несколько CAA-записей с разными CA конфликтуют	Это не конфликт — несколько записей `issue` работают как разрешающий список (OR), а не как исключающий	Если нужно оставить только один CA — удалить остальные записи `issue`, а не добавлять их все

Привязка к аккаунту Let's Encrypt через accounturi

Параметр accounturi в CAA-записи ограничивает выпуск сертификатов не просто конкретным CA, а конкретным ACME-аккаунтом внутри этого CA — даже сотрудник того же CA не сможет выпустить сертификат от чужого имени.

# Разрешить выпуск только определённому ACME-аккаунту Let's Encrypt
@  IN  CAA  0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567"

ID аккаунта можно найти в файле regr.json клиента Certbot или в логах ACME-клиента при первой регистрации.

Проверка перед выпуском нового сертификата

# Проверить текущие CAA-записи
dig example.com CAA +short

# Проверить, что запись видна с публичного резолвера, а не только локально
dig @8.8.8.8 example.com CAA +short

# Тестовый запрос сертификата в staging-окружении Let's Encrypt
certbot certonly --staging -d example.com

Если dig не возвращает CAA — либо записи нет вообще, либо она ещё не распространилась
Staging-окружение Let's Encrypt позволяет проверить всю цепочку без риска упереться в лимит выпуска боевых сертификатов (50 в неделю на домен)
После добавления новой CAA-записи подождите минимум её TTL перед повторной попыткой выпуска

Когда CAA может помешать

Смена CA без обновления CAA-записи — новый провайдер SSL не сможет выпустить сертификат, пока в зоне остаётся ограничение на старый CA
Использование нескольких сервисов для разных поддоменов (например, CDN с собственным SSL) — каждый CA, задействованный любым поддоменом, должен быть явно разрешён на уровне зоны или конкретного поддомена
Автоматический выпуск через сторонние платформы (Cloudflare, хостинг-панели) — если CAA настроен вручную и не включает CA этой платформы, автоматизация начнёт возвращать ошибки выпуска
Делегирование поддомена другому DNS-провайдеру — CAA проверяется в зоне того поддомена, который запрашивает сертификат, а не только в корневой зоне, см. делегирование поддомена

Наследование CAA поддоменами

CAA-запись, установленная в корне зоны, автоматически распространяется на все поддомены, если для них не задана собственная CAA-запись. Собственная запись поддомена полностью переопределяет запись родителя, а не дополняет её.

Где задана CAA	Действует ли на mail.example.com
Только на @ (корень)	Да, если у mail нет своей CAA
Отдельно на mail.example.com	Да, только запись поддомена, родительская игнорируется

Частые вопросы

Если добавить ограничительную CAA-запись сейчас, отзовётся ли уже действующий сертификат автоматически?

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

Проверяют ли браузеры посетителей CAA-запись при каждом заходе на сайт?

Нет, браузеры посетителей CAA-запись не читают и не проверяют вовсе — эта проверка относится только к удостоверяющим центрам и выполняется один раз, в момент запроса на выпуск сертификата. Для посетителя CAA остаётся полностью невидимым техническим механизмом на стороне DNS, а не частью проверки соединения, которую браузер выполняет при каждом открытии страницы.

Распространяется ли CAA-запись на сертификаты для почты (S/MIME), или только на SSL сайта?

Распространяется, если область действия записи не ограничена явно тегом под конкретный тип сертификата — стандартные теги issue и issuewild относятся к обычным и wildcard TLS-сертификатам, а для почтовых S/MIME-сертификатов существует собственный отдельный тег с иным назначением. Без правильного тега удостоверяющий центр, отвечающий за почтовые сертификаты, может не учитывать вашу CAA-запись вовсе.

Сколько времени после изменения CAA-записи может пройти, прежде чем удостоверяющий центр увидит новое значение?

Время зависит от значения TTL конкретной записи в зоне и от того, как часто резолвер удостоверяющего центра опрашивает DNS заново — пока старое значение кэшировано где-то по пути, центр сертификации способен увидеть его вместо актуального. Самый надёжный способ не гадать — подождать истечения TTL записи и только затем повторять запрос на выпуск сертификата.