CAA — это тип DNS-записи, который позволяет владельцам сайтов указывать, какие Центры сертификации (CA) могут выдавать сертификаты, содержащие их доменные имена. Она была впервые стандартизирована в 2013 году, а версия, которую мы сегодня используем, была стандартизирована в 2019 в RFC 8659 и RFC 8657. По умолчанию, каждый публичный CA может выдавать сертификаты на любое доменное имя в публичных DNS, при условии, что есть подтверждение контроля этого доменного имени. Это означает, что возможная ошибка в одном из множества проверочных процессов Центров сертификации потенциально может затронуть все доменные имена. CAA позволяет владельцам доменов уменьшить этот риск.
Если вам не нужна CAA, можно ничего не делать (но см. ошибки CAA ниже). Если же вы хотели бы использовать CAA, чтобы ограничить число Центров сертификации, имеющих право выпуска сертификатов для вашего домена, нужно использовать провайдера DNS, который поддерживает настройку записей CAA. Список таких провайдеров можно найти на странице SSLMate’s CAA. Если ваш провайдер нашелся в списке, можно использовать генератор записей CAA SSLMate для создания набора записей CAA, перечисляющих центры сертификации, которые вы хотели бы разрешить.
Обычно записи CAA задаются на уровне зарегистрированного домена (например, “example.org” или “mysite.co.uk”). Таким образом, они применяются как к этому домену, так и ко всем поддоменам, которые вы создаёте внутри него, например, “community.example.org”.
Обратите внимание, что ЦС всегда учитывает запись CAA, ближайшую к доменному имени, для которого выдаётся сертификат. Поэтому если вы запрашиваете сертификат для “www.community.example.org”, ЦС проверит “www.community.example.org”, затем “community.example.org”, потом “example.org” и остановится на первой найденной записи CAA.
Это означает, что вы можете переопределять CAA для поддоменов. Например, предположим, что вы сами размещаете “example.org”, а “api.example.org” находится у облачного провайдера. Вы можете использовать запись CAA на “example.org”, чтобы указать, что только Let’s Encrypt может выпускать сертификаты для этого домена и всех его поддоменов, а также использовать запись CAA на “api.example.org”, чтобы переопределить это и разрешить облачному провайдеру выпускать сертификаты для этого конкретного поддомена.
Также обратите внимание, что проверка CAA следует за CNAME-перенаправлениями, как и все остальные DNS-запросы. Если “community.example.org” является CNAME-записью на “example.forum.com”, ЦС будет учитывать любые записи CAA, установленные на “example.forum.com”. Для доменного имени с записью CNAME не разрешается наличие любых других записей, поэтому конфликтов между записями CAA на исходном имени и записями CAA на целевом домене перенаправления возникнуть не может.
Все записи CAA имеют одинаковый базовый формат:
CAA <flags> <tag> <value>
Параметр flags представляет собой просто целое число и почти всегда должен быть равен 0, что означает, что никакие флаги не установлены. При желании вы можете установить флаги в целое число 128, что указывает на установку “критического бита” и означает, что ЦС должны немедленно остановиться и не выдавать сертификат, если они не распознают содержимое поля тег.
Параметр тег представляет собой строку, указывающую, какой именно это тип записи CAA: в большинстве случаев это issue или issuewild. Подробнее о них ниже.
И наконец, параметр value — это строка, содержащая не более одного идентификатора ЦС (например, “letsencrypt.org”) и некоторые необязательные параметры, разделённые точкой с запятой, о которых также рассказано ниже.
issue и issuewildЗаписи с тегом issue просто управляют тем, может ли ЦС выпускать сертификаты для этого домена и его поддоменов. Обычно это единственная запись, которая вам нужна, поскольку при отсутствии других записей она управляет выдачей как обычных (например, “example.org”), так и wildcard-сертификатов (например, “*.example.org”). Вы управляете тем, какой ЦС может выпускать сертификаты для этого домена, помещая идентифицирующее доменное имя этого ЦС в часть value записи CAA.
Записи с тегом issuewild управляют тем, может ли ЦС выпускать wildcard-сертификаты (например, “*.example.org”). Записи issuewild нужны только в том случае, если вы хотите установить разные разрешения для выдачи wildcard- и обычных сертификатов.
Обратите внимание, что у вас может быть несколько записей с одним и тем же типом свойства, и они действуют совместно: если хотя бы одна из этих записей разрешает выпуск сертификатов данному ЦС, то выпуск разрешён.
Идентифицирующее доменное имя Let’s Encrypt’s для CAA — letsencrypt.org. Это официально задокументировано в Разделе 4.2.1 нашего CP/CPS.
validationmethodsЭтот параметр может быть указан после идентифицирующего доменного имени ЦС и позволяет управлять тем, какие методы проверки может использовать данный ЦС для подтверждения контроля над доменом. Это можно использовать для ограничения проверки методами, которым вы больше доверяете. Например, если вы хотите разрешить ЦС использовать только метод TLS-ALPN-01, вы можете добавить ;validationmethods=tls-alpn-01 к значению вашей записи CAA.
Let’s Encrypt поддерживает следующие строки методов проверки:
http-01dns-01tls-alpn-01accounturiЭтот параметр может быть указан после идентифицирующего доменного имени ЦС и позволяет управлять тем, какие ACME-аккаунты могут запрашивать выдачу сертификатов для данного домена. Это можно использовать, чтобы гарантировать, что кто-то, кто временно захватил ваш домен, но не имеет доступа к ключу вашего ACME-аккаунта, не сможет выпустить вредоносные сертификаты.
URI аккаунтов Let’s Encrypt выглядят как https://acme-v02.api.letsencrypt.org/acme/acct/1234567890, где числа в конце — это идентификатор вашего аккаунта.
Простая запись CAA, которая разрешает Let’s Encrypt выпускать сертификаты для “example.org”, может выглядеть так:
example.org CAA 0 issue "letsencrypt.org"
Более сложный набор записей CAA может выглядеть так:
example.org CAA 0 issue "myca.org;validationmethods=dns-01"
example.org CAA 0 issuewild "myca.org"
example.org CAA 128 issue "otherca.com;accounturi=https://otherca.com/acct/123456"
В этом примере MyCA может выпускать сертификаты для “example.org”, но только с использованием метода проверки DNS-01. Он также может выпускать wildcard сертификаты, используя любой метод проверки. И наконец, OtherCA также может выдавать сертификаты, но только если запрос поступает с аккаунта 123456, и только если OtherCA распознаёт и знает, как правильно обрабатывать ограничение accounturi.
Так как Let’s Encrypt проверяет CAA записи перед подписанием каждого сертификата, иногда мы получаем ошибки даже для доменов, у которых не установлена запись CAA. Когда мы получаем ошибку, нет способа узнать, разрешено ли нам подписывать конкретный домен, т. к. могут быть CAA записи, которые запрещают подпись, но не видны из-за ошибки.
Если вы получаете ошибки, связанные с CAA, сделайте еще несколько попыток, используя наше тестовое окружение, чтобы определить, является ли ошибка временной или постоянной. Если они постоянны, Вам необходимо создать запрос в поддержку своего DNS провайдера или сменить его. Если Вы не уверены, какой у Вас DNS провайдер, спросите у Вашего хостинг провайдера.
Некоторые DNS-провайдеры, не знакомые с CAA, изначально отвечают на сообщения о проблемах фразой “Мы не поддерживаем записи CAA”. Ваш DNS-провайдер не обязан специально поддерживать записи CAA; ему достаточно отвечать ответом NOERROR на запросы неизвестных типов (включая CAA). Возврат других кодов, включая NOTIMP, на нераспознанные типы запросов является нарушением RFC 1035 и должен быть исправлен.
Одной из самых распространенных ошибок, с которыми сталкиваются пользователи, является SERVFAIL. Чаще всего это указывает на ошибку проверки DNSSEC. Если вы получили ошибку SERVFAIL, первым делом используйте отладчик DNSSEC, например, dnsviz.net. Если это не помогло, возможно, ваши серверы имен генерируют неправильные подписи только тогда, когда ответ пуст. А ответы CAA чаще всего пусты. Например, у PowerDNS была эта ошибка в версии 4.0.3 и ниже.
Если у вас не включен DNSSEC и вы получили SERVFAIL, вторая наиболее вероятная причина заключается в том, что ваш полномочный сервер имен возвратил NOTIMP, что, как описано выше, является нарушением RFC 1035; вместо этого он должен вернуть NOERROR с пустым ответом. В таком случае отправьте сообщение об ошибке или запрос в службу поддержки вашему провайдеру DNS.
Наконец, ошибки SERVFAIL могут быть вызваны перебоями в работе ваших полномочных серверов имен. Проверьте записи NS для ваших серверов имен и убедитесь, что каждый сервер доступен.
Иногда запросы CAA заканчиваются таймаутом. То есть полномочный сервер имен не отвечает даже после множества попыток. Чаще всего это происходит, если перед вашим сервером имен неправильно настроен файервол, который отвергает запросы DNS с неизвестным типом. Подайте заявку в службу поддержки вашего DNS-провайдера и спросите об их настройках файервола.