CAA-запись: кто может выпускать сертификаты для вашего домена

Технически любой публично доверенный удостоверяющий центр может выпустить сертификат для любого домена. Система держится на том, что каждый центр как следует проверяет контроль над доменом, и в истории есть примеры, когда это давало сбой. CAA-запись (Certification Authority Authorization) — ваш способ сузить круг: DNS-запись, которая говорит «сертификаты для этого домена могут выпускать только эти удостоверяющие центры». Центр, которого в списке нет, обязан отказать.

Это ничего не стоит, занимает пять минут и может навредить ровно одним способом: если забыть о записи при смене удостоверяющего центра. В этой статье разобраны обе стороны.

Что CAA делает, а чего нет

CAA определена в RFC 8659 (который заменил исходный RFC 6844), и с сентября 2017 года Базовые требования (Baseline Requirements) CA/Browser Forum обязывают каждый публично доверенный удостоверяющий центр проверять CAA перед выпуском сертификата.

Её проверяет удостоверяющий центр в момент выпуска. Браузеры на неё никогда не смотрят. Сертификат, выпущенный, пока CAA это разрешала, остаётся действительным, даже если вы потом измените запись.
Нет CAA-записи — нет ограничений. Выпускать может любой центр, как и раньше.
Она снижает риск ошибочного выпуска через центр, которым вы не пользуетесь, например кем-то, кто ненадолго получил контроль над веб-сервером или почтовым ящиком и пробует центр с более слабым методом проверки. Она не остановит злоумышленника, контролирующего ваш DNS, потому что он может изменить и CAA-запись.
Это не механизм отзыва и не замена мониторингу журналов Certificate Transparency.

Из чего состоит CAA-запись

example.com.   3600   IN   CAA   0 issue "ca.example"
;                                │ │     └ value
;                                │ └ tag
;                                └ flags

Флаги практически всегда равны 0. Значение 128 устанавливает бит «critical»: центр, который не понимает тег, выпускать сертификат не должен.

Теги:

Тег	Значение
`issue`	Названный центр может выпускать сертификаты для этого имени. Распространяется и на wildcard-сертификаты, если нет `issuewild`.
`issuewild`	Правила только для wildcard-сертификатов. Если тег есть, для wildcard-запросов он заменяет `issue`.
`iodef`	Куда центр может сообщить о запросе, нарушившем политику (`mailto:` или `https:`). Поддержка среди центров ограничена; считайте тег необязательным.
`issuemail`	Такой же контроль для сертификатов S/MIME (RFC 9495).

Значение для issue/issuewild — идентифицирующее доменное имя, которое каждый центр указывает в своей документации, например на странице о CAA или в CPS. Это не всегда бренд или сайт центра, а центры, перепродающие чужие сертификаты, используют идентификатор вышестоящего центра. Найдите его в документации, не угадывайте. Специальное значение ";" означает «никто».

Примеры

Один центр, без wildcard, с адресом для сообщений:

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issuewild ";"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

Два центра (скажем, ваш ACME-центр и тот, которым пользуется ваша CDN):

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issue "ca-two.example"

Домен, у которого сертификатов быть не должно никогда:

parked.example.  IN  CAA  0 issue ";"

Wildcard-сертификаты от другого центра, чем обычные:

example.com.  IN  CAA  0 issue "ca-one.example"
example.com.  IN  CAA  0 issuewild "ca-two.example"

Как центр находит нужную запись

Вот здесь чаще всего ошибаются. Для запроса сертификата на www.shop.example.com удостоверяющий центр:

запрашивает CAA на www.shop.example.com;
если там набора CAA-записей нет, запрашивает shop.example.com;
затем example.com, и так далее вверх по дереву;
останавливается на первом имени, у которого есть хоть какие-то CAA-записи, и использует только их.

Следствия:

Запись на example.com покрывает каждый поддомен, у которого нет собственной CAA.
Записи не объединяются. CAA на shop.example.com полностью заменяет запись на example.com для всего, что находится под shop. Этим можно пользоваться намеренно, чтобы дать одному поддомену другой центр.
CNAME учитываются. Если shop.example.com — CNAME на stores.saas.example, на CAA-запрос для shop.example.com отвечают CAA-записи цели. Поэтому CAA-политика SaaS-провайдера может распространяться на ваше имя хоста. По действующему RFC центр не поднимается по дереву цели; если у цели CAA нет, подъём продолжается у вашего родителя, example.com.
Сбой запроса — не то же самое, что «записи нет». Если центр не может получить чистый ответ (тайм-аут, SERVFAIL, сломанный DNSSEC), он не должен выпускать сертификат. Ненадёжный авторитетный DNS проявляется как неудавшиеся продления.

Каждое имя в сертификате на несколько имён проверяется отдельно.

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

RFC 8657 добавляет параметры, которые делают CAA заметно сильнее для пользователей ACME:

example.com. IN CAA 0 issue "ca-one.example; accounturi=https://acme.ca-one.example/acct/12345"
example.com. IN CAA 0 issue "ca-one.example; validationmethods=dns-01"

accounturi ограничивает выпуск одной учётной записью ACME, так что кто-то другой с учётной записью в том же центре не получит сертификат, даже пройдя проверку. validationmethods ограничивает, как можно доказывать контроль. Оба параметра работают только с центрами, которые их реализовали; прежде чем на них полагаться, сверьтесь с документацией центра и не забудьте обновить запись, если когда-нибудь пересоздадите учётную запись ACME.

Как добавить CAA, ничего не сломав: чек-лист

Выясните, кто выпускает сертификаты для вас сегодня. Осмотрите сертификаты на каждом имени хоста или поищите свой домен в журналах Certificate Transparency. Типичные сюрпризы: CDN, управляемые сертификаты балансировщика, хостинг магазина, страница статуса, почтовый сервис и внутренняя команда, использующая другой ACME-центр.
Соберите CAA-идентификаторы каждого центра из его документации.
Проверьте поддомены, которые являются CNAME на сторонние сервисы: запросите у них CAA и посмотрите, что вернётся.
Опубликуйте записи в вершине зоны с умеренным TTL (3600). Центры могут кэшировать результат проверки CAA не дольше TTL записи или 8 часов, смотря что больше.
Сразу протестируйте продление (certbot renew --dry-run выполняет полную проверку в тестовой среде, которая у большинства ACME-центров включает проверку CAA), а не узнавайте о проблеме через 60 дней.
Задокументируйте там, куда посмотрит следующий человек при смене CDN или центра.

Запросите, что опубликовано:

$ dig +short example.com CAA
0 issue "ca-one.example"
0 issuewild ";"
$ dig +short www.shop.example.com CAA      # пусто → центр поднимется выше

Частые ошибки

Сменить CDN или хостинг-провайдера и забыть, что новый использует другой центр. Новый сертификат молча не выпускается, а старый истекает. См. истёк SSL-сертификат: что делать.
Использовать маркетинговое название центра вместо задокументированного CAA-идентификатора.
issuewild ";", пока где-то используется wildcard-сертификат.
Верить, что issue в вершине зоны и другой issue на поддомене складываются. Набор поддомена побеждает в одиночку.
DNS-провайдер без поддержки типа CAA, где запись пытаются сохранить как TXT. Это ничего не даёт.
Ошибки с кавычками в панелях управления: значение — строка в кавычках, флаг и тег — нет.
Ожидать, что CAA аннулирует существующие сертификаты. Она влияет только на новый выпуск.
Переехать на другие серверы имён и не скопировать CAA-записи; они среди тех, что теряются чаще всего, как отмечено в статье смена серверов имён без простоя.

Проверьте в OrbitProbe

Проверка DNS-записей в OrbitProbe запрашивает среди прочих типов и CAA, с TTL, в том виде, в каком публичные резолверы возвращают её в этот момент. Запустите её сначала для корневого домена, затем для каждого поддомена, который является CNAME на внешний сервис, чтобы увидеть, какую политику центр на самом деле там найдёт. Общая картина того, как CAA соотносится с другими типами записей, есть в статье типы DNS-записей.