CAA-записи и управление выпуском TLS-сертификатов

Система доменных имён (DNS) позволяет публиковать различную дополнительную информацию с привязкой к сетевому имени. Например, сведения о политиках, которые к доменной зоне должны применять Центры Сертификации: для этого используется специальная CAA-запись (различие между Центрами Сертификации и Удостоверяющими Центрами исключительно терминологическое и связано с законодательной трактовкой процессов применения цифровой/электронной подписи при определении юридической значимости того или иного действия).

Как элемент DNS, CAA-запись похожа на записи других типов: например, IP-адреса в DNS публикуются в адресных A-записях для четвёртой версии и в AAAA-записях для шестой версии IP; перечень серверов имён - публикуется в NS-записях. В CAA публикуются сведения, относящиеся к процессу проверки возможности выпуска TLS-сертификата - о действующей политике.

Под «политикой» мы здесь понимаем формальное описание того, каким Центрам Сертификации (далее - ЦС) администратор разрешает выпуск TLS-сертификатов для имён в данной зоне, сертификаты каких типов можно выпускать и какие дополнительные ограничения действуют. Политика задаётся строго, в машиночитаемом виде, чтобы системы ЦС могли обработать описание автоматически.

Механизм CAA-записей был предложен ещё в 2010 - 2011 годах, а первый документ RFC 6844, описывающий CAA, опубликован в 2013 году. С тех пор в нем появились некоторые новые элементы. Современная версия CAA - это довольно развитый инструмент управления параметрами доверия. Но базовая логика использования CAA-записи - очень проста: в DNS-зоне публикуется специальное DNS-имя, соответствующее тому ЦС, которому разрешается выпускать TLS-сертификаты. Согласно спецификации, если CAA-запись в зоне отсутствует, то выпускать TLS-сертификаты разрешается всем ЦС. А чтобы запретить выпуск всем ЦС, нужно опубликовать CAA-запись, но с пустым списком имён.

ФОРМАТ CAA-ЗАПИСЕЙ

Посмотрим на простейший пример - CAA-запись для google.com (это выдача утилиты dig из пакета BIND):

-
$ dig google.com -t CAA +short
0 issue "pki.goog"
-

Полученные в этом ответе данные означают, что выпускать сертификаты разрешено только ЦС с именем pki.goog. Это имя собственного ЦС корпорации Google. Имена, идентифицирующие ЦС (как pki.goog), определяются им самостоятельно, но необходимо, чтобы ЦС контролировал соответствующую доменную зону. Никаких дополнительных требований к формату имен не применяется: например, если ЦС Google использует pki.goog, в собственном, корпоративном домене верхнего уровня goog., то для Let's Encrypt необходимо указывать letsencrypt.org. Выбранное имя ЦС закрепляется в публичной политике, чтобы внешние клиенты, управляющие DNS-зонами, могли его узнать.

В примере выше имени ЦС предшествует небольшой набор параметров: "0 issue". Здесь цифра 0 соответствует полю флагов. На сегодняшний день ноль здесь указан в большинстве случаев. Данное поле имеет размер один байт и предназначено для использования с опциями, которые могут быть добавлены к спецификации CAA в будущем. Сейчас для поля флагов определено значение только одного бита - это старший, восьмой бит (десятичное значение 2^{8-1} = 128). Установка этого бита в единицу отмечает соответствующую опцию в строке CAA как критическую - то есть, если проверяющий ЦС не может интерпретировать данный элемент CAA-записи, а критический флаг установлен, то ЦС должен считать, что выпуск сертификатов запрещён (вне зависимости от значений других опций этой же CAA-записи). Другие биты флагов - зарезервированы. Ноль означает, что все биты - нулевые.

Опция issue разрешает или запрещает, собственно, выпуск сертификатов. В данном случае, ЦС с именем pki.goog разрешается выпускать TLS-сертификаты для имени google.com. и подчинённых имён.

CAA - инструмент сугубо информационный. Не предусмотрено никаких технических механизмов, которые сделали бы следование CAA обязательным для Центров Сертификации. Точно так же нет механизма, который запретил бы им ориентироваться на чужие имена, указанные в CAA. Например, некому ЦС "Имярек" CAA не мешает выпускать сертификаты только в том случае, если в качестве значения указан домен Let's Encrypt, который никакого отношения к "Имярек" не имеет. Однако подразумевается, что ЦС, который следует сложившимся правилам, всё же проверяет CAA и выполняет требования политики, которая в CAA опубликована администратором доменной зоны.

УПРАВЛЕНИЕ ВЫПУСКОМ WILDCARD-СЕРТИФИКАТОВ

Wildcard-сертификат - это сертификат, выпущенный не только для конкретного имени, а для набора, обозначаемого маской. Часть символов заменяется на "*" ("звёздочка"), где вместо "*" можно подставить любое значение, допускаемое форматом записи имён в TLS-сертификатах, кроме точки. Пример: *.test.ru - такой маске соответствуют имена www.test.ru, mail.test.ru, но не соответствуют имена test.ru и our.mail.test.ru. Из-за того, что wildcard-сертификаты подходят к большому количеству имён в DNS-зоне, для них спецификация CAA предусматривает отдельный способ управления: предусмотрена специальная опция для wildcard-сертификатов - issuewild. Данная опция относится только к процессу выпуска wildcard-сертификатов.

Предположим, что для имени test.ru указана опция issuewild с именем mega-ca.example.com:

---
0 issuewild "mega-ca.example.com"
---

Такое сочетание разрешает ЦС с именем mega-ca.example.com выпускать wildcard-сертификаты для test.ru.

НЕСКОЛЬКО CAA-ЗАПИСЕЙ

Опциями issue и issuewild далеко не исчерпывается возможный состав CAA. Более того, администратор DNS-зоны может указывать несколько CAA. Рассмотрим следующий пример - CAA-записи для имени cctld.ru:

---
$ dig -t CAA tcinet.ru +short
0 issuewild "globalsign.com"
0 iodef mailto:caa@tcinet.ru
0 issue "tlscc.ru"
0 issue "globalsign.com"
0 issue "letsencrypt.org"
---

Этот список записей разрешает выпуск сертификатов нескольким ЦС: ТЦИ (tlscc.ru), Let's Encrypt и GlobalSign. Последний может выпускать wildcard-сертификаты.

Здесь в пятой строке также присутствует новая опция: iodef. Она предназначена для указания способа связи с администратором зоны: ЦС могут направлять указанным в iodef способом уведомления о попытках выпуска сертификатов для имён, соответствующих CAA. В данном примере для iodef указана электронная почта - "mailto:", - и адрес email.

ВКЛЮЧЕНИЕ ДОПОЛНИТЕЛЬНЫХ СВЕДЕНИЙ

Современная версия CAA позволяет указывать дополнительную информацию. Например, флаг "cansignhttpexchanges", который указывается в составе issue и issuewild:

---
0 issue "example.com; cansignhttpexchanges=yes"
---

Данный флаг позволяет запрашивать у ЦС TLS-сертификаты со специальным расширением CanSignHttpExchanges, которое разрешает использовать ключ из сертификата для подписывания сервером HTTP-ответов (то есть, не только в TLS).

RFC 8657 определяет дополнительные возможности CAA при взаимодействии с ЦС по протоколу ACME. Так, дополнение accounturi, которое может использоваться с issue и issuewild, позволяет сузить область действия CAA до конкретного аккаунта в системе ЦС. То есть, указание accounturi, вместе с идентификатором ЦС, разрешает выпуск уже не просто конкретному ЦС, но только соответствующему пользовательскому аккаунту в определённом ЦС.

Например, в случае Let's Encrypt, можно запретить выпуск TLS-сертификатов всем другим аккаунтам, кроме заданного в CAA. В Let's Encrypt аккаунт может завести произвольный пользователь. Если этому пользователю доступен веб-сервер под соответствующим именем домена, то он сможет выпустить и TLS-сертификат для этого имени со своего аккаунта, но только если это не запрещено в CAA при помощи accounturi.

Пример:

---
0 issue "example.com; accounturi=https://acc0001.example.com/user/42"
---

Дополнение validationmethods, тоже для issue и issuewild, предназначено для указания допустимых методов проверки права управления доменом (согласно спецификации ACME). Например, dns-01 - проверка через размещение TXT-записи с кодом подтверждения.

Пример:

---
0 issue "example.com; validationmethods=dns-01"
---

ПРОВЕРКА ПРАВА УПРАВЛЕНИЯ ДОМЕНОМ

Проверка права управления доменным именем (DCV - Domain Control Validation) - это отдельная процедура, которая позволяет в автоматическом или автоматизированном режиме проверить, что сторона, запросившая выпуск TLS-сертификата, действительно управляет тем DNS-именем, для которого сертификат запрашивается. Проверка DCV необходима и в том случае, если в зоне размещается CAA-запись.

Нередко возникает вопрос: раз DCV-проверка всё равно необходима, то зачем же вообще CAA? Причина в том, что CAA решает совсем другие задачи. Так, код подтверждения DCV, даже если размещается в DNS, не обязательно привязан к конкретному ЦС, в отличие от CAA. Более того, проверка DCV не обязательно проводится через DNS, и в этом случае невозможно исключать, например, перехват злоумышленником управления веб-сервером. CAA предоставляет минимальный набор инструментов защиты от такого перехвата - если в CAA запрещён выпуск сертификатов всем УЦ, то и перехват веб-сервера не поможет получить сертификат.

РАСПРОСТРАНЕНИЕ ДЕЙСТВИЯ CAA

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

Спецификация распространяет действие CAA по дереву DNS-имён вниз. Это означает, что для конкретного имени должна применяться «ближайшая» к нему CAA-запись, но это не обязательно запись строго для указанного имени. Предположим, что задано имя mega.test.ru., однако для этого имени CAA-записи нет. В таком случае, система проверки CAA делает попытку найти CAA-запись для test.ru - то есть, для ближайшего справа DNS-имени. Если в test.ru CAA-запись обнаружена, то её политика применяется для mega.test.ru. Важно, что схема так работает только в том случае, когда для mega.test.ru CAA-записи нет; если для mega.test.ru разместить CAA-запись, то будет применяться уже она. Другими словами - предпочтение отдаётся более «специфичной» CAA-записи, но просматривается и вышестоящее дерево.

Подъём по дереву оканчивается в корневом домене (то есть, в крайней справа точке полной записи доменного имени), при этом корневой домен не включается в цепочку поиска CAA. На практике, системы ЦС могут прекращать поиск раньше - например, не рассматривать CAA из общедоступных доменных зон или зон первого уровня (ccTLD и др.).

Тут стоит отметить, что если, например, CAA-записи зоны первого уровня запрещают выпуск TLS-сертификатов всем УЦ, кроме определённого, то это способ запретить такой выпуск для всех зон уровнем ниже, которые не разместили CAA. (Естественно, требуется, чтобы УЦ следовали инструкциям из CAA для первого уровня.)

АДМИНИСТРАТИВНЫЕ ОСОБЕННОСТИ

С CAA-записями связано несколько неочевидных административных аспектов. Прежде всего, оператор серверов имён может при помощи публикации CAA-записи запретить администраторам веб-серверов, адресуемых именами в контролируемой DNS-зоне, заказывать TLS-сертификаты в каких-то конкретных УЦ. Если администратор веб-сервера не имеет возможности управления DNS-зоной, то у него нет способа преодолеть запреты, установленные в CAA.

Другой момент - ошибки в записях и неверная настройка серверов имён: если ЦС проверяет CAA, но получает ошибочные ответы, то ЦС может прийти к выводу, что определить состав CAA невозможно и отказаться выпускать сертификат (решение тут зависит от внутренних политик ЦС).

CAA очень полезный инструмент. Однако всё описанное выше - и в лучшую сторону, и в сторону дополнительных проблем - работает только в том случае, если CAA поддерживается на стороне ЦС. Современная версия требований CA/Browser Forum - делает такую поддержку обязательной.