Что такое запись DNS CAA (Certificate Authority Authorization) и зачем она нужна
DNS CAA - это ресурсная запись DNS, которая позволяет владельцу домена явно указать, какие удостоверяющие центры (CA) имеют право выпускать TLS-сертификаты для этого домена и его поддоменов.
Это важная часть инфраструктуры безопасности, предупреждающая несанкционированный выпуск сертификатов третьей стороной.
Позвольте, но чем это отличается от проверки владения? Сегодня, перед выпуском сертификата любой удостоверяющий центр попытается выполнить проверку владения доменом: через HTTP-файл, DNS-запись или email.
Но как быть, если ваша инфраструктура оказалась скомпрометированной? Или трафик был перехвачен и подменен на этапе проверки? В этом случае злоумышленник может выпустить сертификат в стороннем CA и спокойно использовать его для MiTM или фишинга.
Да, есть Certificate Transparency, но это уже постреагирование и не все мониторят эти журналы. Поэтому был разработан способ проактивной защиты, а именно DNS CAA. С сентября 2017 года проверка CAA-записей является строго обязательной для всех публичных CA согласно требованиям CA/Browser Forum.
Таким образом вы можете указать кто именно имеет право выпускать сертификаты для вашего домена и таким образом сузить поверхность возможной атаки. Теперь ни один публичный CA не выпустит сертификат без вашего разрешения.
👉 Общий формат записи выглядит как:
example.com. IN CAA <флаг> <тег> "<значение>"
🔹 Флаг (Flag) Принимает значение от 0 до 255, но на практике сейчас активно используются только два:
▫️0 (Non-critical): Если CA не понимает или не поддерживает встреченный тег в записи, он может проигнорировать его и продолжить выпуск сертификата.
▫️128 (Critical): Если CA встречает незнакомый тег в записи с этим флагом, он обязан отказать в выпуске сертификата.
🔹 Тег (Tag) Определяет поведение и тип разрешения. Существует три стандартных тега:
▫️ issue: Разрешает указанному CA выпускать любые типы сертификатов (как обычные, так и wildcard) для данного домена.
▫️issuewild: Разрешает выпуск только wildcard-сертификатов (*.example.com). Если этот тег задан, то для wildcard-запросов правила из issue игнорируются.
▫️ iodef (Incident Object Description Exchange Format): Указывает URL (обычно mailto: или http/https), куда CA должен отправить отчет, если кто-то попытается запросить сертификат в обход правил CAA.
🔹 Значение (Value) Строка в кавычках, содержащая доменное имя разрешенного CA (например, "letsencrypt.org", "digicert.com") или параметры для iodef.
👉 Несколько примеров:
Разрешаем выпускать сертификаты только для Let's Encrypt, а в случае нарушений — слать отчеты на почту:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"
Разрешаем DigiCert выпускать только обычные сертификаты, а Let's Encrypt — только wildcard:
example.com. IN CAA 0 issue "digicert.com"
example.com. IN CAA 0 issuewild "letsencrypt.org"
Отдельная возможность – это полный запрет выпуска сертификатов для домена, например, это служебный или временно не используемый домен и выдача сертификатов дня него не предусматривается:
example.com. IN CAA 0 issue ";"
👆 Записи CAA мы можем создать как для домена, так и для любого поддомена, проверка идет по снизу вверх по дереву DNS. Если CA проверяет поддомен sub.dev.example.com, поиск записей происходит по следующей цепочке до первого совпадения:
🔸 Выполняется поиск CAA для sub.dev.example.com.
🔸 Если записей нет, проверяется dev.example.com.
🔸 Если снова пусто, проверяется корневой example.com.
Если на корневом домене example.com установлена запись CAA, она автоматически распространяется на все поддомены, если для конкретного поддомена не создана своя, переопределяющая запись CAA.
Исключение – записи CNAME, если для них не установлена CAA запись, то проверка по дереву прекращается и начинается проверка дерева домена на который указывает такая запись.
