CAA (Certificate Authority Authorization) — это относительно новый тип DNS-записи, который позволяет владельцам сайтов указывать, каким Центрам Сертификации (CA) разрешено выпускать сертификаты для их доменных имен. Он был впервые стандартизирован в 2013 году, текущая версия была стандартизирована в 2019 году в RFC 8659 и RFC 8657. По умолчанию любому публичному CA разрешено выпускать сертификаты для любого доменного имени в публичной DNS при условии, что они подтвердят контроль над этим доменным именем. Это означает, что если есть ошибка в процессе валидации любого из множества публичных CA, потенциально пострадать может каждое доменное имя. CAA предоставляет владельцам доменов способ снизить этот риск.
Использование CAA
Если вас не заботит CAA, вам обычно не нужно ничего делать (но см. раздел об ошибках CAA ниже). Если вы хотите использовать CAA для ограничения списка Центров сертификации, которым разрешено выпускать сертификаты для вашего домена, вам потребуется использовать DNS-провайдера, который поддерживает установку записей CAA. Проверьте страницу CAA от SSLMate для получения списка таких провайдеров. Если ваш провайдер есть в списке, вы можете использовать Генератор записей CAA от SSLMate, чтобы создать набор записей CAA, перечисляющих CA, которым вы хотите разрешить выдачу.
Последнее время при выпуске сертификатов часто встречаю такое предупреждение:
Следующие домены не имеют соответствующую DNS-запись CAA: example.com. Пожалуйста, добавьте для указанных доменов следующие DNS-записи CAA: ' 0 issue "globalsign.com" ', ' 0 issuewild "globalsign.com" '. В противном случае центр сертификации может отказать в выдаче сертификатаГде размещать запись
Как правило, вам нужно устанавливать записи CAA на вашем зарегистрированном домене (например, "example.com"). Таким образом, они будут применяться как к этому домену, так и к любым созданным вами поддоменам, таким как "community.example.com".
Обратите внимание, что CA всегда учитывает запись CAA, ближайшую к доменному имени, для которого он выпускает сертификат. Так, если вы запрашиваете сертификат для "www.community.example.com", CA проверит "www.community.example.com", затем "community.example.com", затем "example.com", останавливаясь на первой найденной записи CAA.
Это означает, что вы можете переопределить CAA для поддоменов. Например, предположим, что вы самостоятельно размещаете "example.com", но "api.example.com" находится у облачного провайдера. Вы можете использовать запись CAA на "example.com", чтобы указать, что только Let's Encrypt может выпускать сертификаты для этого домена и всех его поддоменов, но также использовать запись CAA на "api.example.com", чтобы переопределить это правило и разрешить облачному провайдеру выпускать сертификаты для этого конкретного поддомена.
Также обратите внимание, что проверка CAA следует за CNAME-перенаправлениями, как и все другие DNS-запросы. Если "community.example.com" является CNAME для "example.forum.com", CA будет учитывать любые записи CAA, установленные на "example.forum.com". Для доменного имени с записью CNAME не разрешено иметь любые другие записи, поэтому конфликтов между записями CAA на исходном имени и записями CAA на цели перенаправления быть не может.
Что указывать в записи
Все записи CAA следуют одному и тому же базовому формату:
CAA <флаг> <тег> <значение>- Флаг — это просто целое число, и почти всегда это должно быть число
0, указывающее, что флаг не установлен. При желании вы можете установить флаг в значение128, указывая, что установлен "критический бит", и CA должны немедленно прекратить работу и не выпускать сертификат, если они не распознают содержимое поля тега. - Тег — это строка, указывающая, какой это тип записи CAA: в большинстве случаев либо
issue, либоissuewild. Подробнее о них ниже. - Значение — это строка, содержащая не более одного идентификатора CA (например, "letsencrypt.org") и некоторые необязательные параметры, разделенные точкой с запятой, которые также обсуждаются ниже.
Свойства issue и issuewild
Записи с тегом issue просто контролируют, может ли CA выпускать сертификаты для этого домена и его поддоменов. Как правило, это единственная запись, которая вам нужна, так как она управляет как обычной (например, "example.com"), так и универсальной (wildcard, например, "*.example.com") выдачей при отсутствии других записей. Вы управляете тем, какой CA может выпускать сертификаты для этого домена, помещая идентифицирующее доменное имя этого CA в часть value записи CAA.
Записи с тегом issuewild контролируют, может ли CA выпускать универсальные (wildcard) сертификаты (например, "*.example.com"). Вам нужно использовать записи issuewild только если вы хотите установить разные разрешения для выдачи wildcard и обычных сертификатов.
Обратите внимание, что у вас может быть несколько записей с одним и тем же типом свойства, и они являются аддитивными: если хотя бы одна из этих записей разрешает CA выпускать сертификат, то это разрешено.
Идентифицирующее доменное имя Let's Encrypt для CAA — это
letsencrypt.org.
Для GlobalSign CA —globalsign.com.
Параметр validationmethods
Этот параметр можно указать после идентифицирующего доменного имени CA, чтобы контролировать, какие методы валидации этот CA может использовать для подтверждения контроля над доменом. Это можно использовать для ограничения валидации только теми методами, которым вы доверяете больше. Например, если вы хотите ограничить CA использованием только метода tls-alpn-01, вы можете добавить ;validationmethods=tls-alpn-01 к значению вашей записи CAA.
Например, Let's Encrypt распознает следующие строки методов валидации:
- http-01
- dns-01
- tls-alpn-01
Параметр accounturi
Этот параметр можно указать после идентифицирующего доменного имени CA, чтобы контролировать, какие учетные записи ACME могут запрашивать выпуск сертификатов для домена. Это можно использовать, чтобы гарантировать, что тот, кто временно захватил ваш домен, но не имеет доступа к ключу вашей учетной записи ACME, не сможет выпустить malicious-сертификаты.
URI учетной записи Let's Encrypt выглядят так: https://acme-v02.api.letsencrypt.org/acme/acct/1234567890, где числа в конце — это ваш идентификатор учетной записи (Account ID).
Примеры
Простая запись CAA, которая разрешает Let's Encrypt выпускать сертификаты для "example.com", может выглядеть так:
example.com CAA 0 issue "letsencrypt.org"Более сложный набор записей CAA может выглядеть так:
example.com CAA 0 issue "myca.org;validationmethods=dns-01"
example.com CAA 0 issuewild "myca.org"
example.com CAA 128 issue "otherca.com;accounturi=https://otherca.com/acct/123456"В этом примере MyCA может выпускать сертификаты для "example.com", но только с использованием метода валидации DNS-01. Он также может выпускать wildcard-сертификаты, используя любой метод валидации. Наконец, OtherCA также может выпускать сертификаты, но только если запрос поступает от учетной записи с номером 123456, и только если OtherCA распознает и знает, как правильно обрабатывать ограничение accounturi.
Ошибки CAA
Поскольку Let's Encrypt проверяет записи CAA перед выпуском каждого сертификата, иногда мы получаем ошибки даже для доменов, которые не устанавливали никаких записей CAA. Когда мы получаем ошибку, нет способа определить, разрешено ли нам выпускать сертификат для затронутого домена, поскольку могут существовать записи CAA, которые запрещают выпуск, но не видны из-за ошибки.
Если вы получаете ошибки, связанные с CAA, попробуйте несколько раз повторить запрос в тестовой среде (staging environment), чтобы понять, носят ли они временный или постоянный характер. Если они постоянные, вам необходимо подать запрос в службу поддержки вашего DNS-провайдера или сменить провайдера. Если вы не уверены, кто ваш DNS-провайдер, спросите у вашего хостинг-провайдера.
Некоторые DNS-провайдеры, незнакомые с CAA, изначально отвечают на сообщения о проблемах: "Мы не поддерживаем записи CAA". Вашему DNS-провайдеру не нужно специально поддерживать записи CAA; ему нужно только отвечать ответом NOERROR на неизвестные типы запросов (включая CAA). Возвращение других кодов операций, включая NOTIMP, для нераспознанных типов запросов (qtypes) является нарушением RFC 1035, и это должно быть исправлено.
SERVFAIL
Одна из самых распространенных ошибок, с которой сталкиваются люди, — это SERVFAIL. Чаще всего это указывает на сбой проверки DNSSEC. Если вы получаете ошибку SERVFAIL, вашим первым шагом должно быть использование отладчика DNSSEC, такого как dnsviz.net. Если это не сработает, возможно, ваши серверы имен генерируют некорректные подписи только тогда, когда ответ пуст. А ответы CAA чаще всего пусты. Например, в PowerDNS была такая ошибка в версиях 4.0.3 и ниже.
Если у вас не включен DNSSEC и вы получаете SERVFAIL, вторая наиболее вероятная причина заключается в том, что ваш авторитативный сервер имен вернул NOTIMP, что, как описано выше, является нарушением RFC 1035; вместо этого он должен возвращать NOERROR с пустым ответом. Если это так, заведите баг-репорт или обращение в службу поддержки вашего DNS-провайдера.
Наконец, SERVFAIL может быть вызван сбоями на ваших авторитативных серверах имен. Проверьте NS-записи для ваших серверов имен и убедитесь, что каждый сервер доступен.
Timeout
Иногда запросы CAA завершаются таймаутом. То есть авторитативный сервер имен вообще не отвечает, даже после нескольких повторных попыток. Чаще всего это происходит, когда перед вашим сервером имен настроен некорректный брандмауэр, который отбрасывает DNS-запросы с неизвестными типами (qtypes). Подайте заявку в службу поддержки вашего DNS-провайдера и спросите, настроен ли у них такой брандмауэр.
