Кратко

  • RFC 6844 позволил владельцу доменного имени указать, какие центры сертификации могут выдавать сертификаты для этого имени. Первое правило поиска могло пройти по CNAME или DNAME и затем подняться по родительским именам цели; поэтому политика CAA хостинг-провайдера могла попасть в проверку имени клиента.
  • RFC 8659 сохранил обычное разрешение DNS-псевдонимов, но ограничил подъём по родительским меткам проверяемым FQDN. Это чётче разделило политику клиента и дерево имён провайдера.

Ответ DNS — ещё не решение о сертификате

Возьмём условный пример: www.client.example — это CNAME для tenant.platform.example. Имя клиента проходит через пространство имён общего хостинга. Перед выдачей сертификата центр сертификации должен ответить ещё на один вопрос: какой набор CAA применяется к www.client.example?

Сложность начинается там, где запрос пересекает границу. Клиент управляет одним деревом DNS, провайдер — другим. Резолвер может пройти по псевдониму за доли секунды. Должен ли центр сертификации также подниматься по родительским именам провайдера и применять правило, которого клиент никогда не публиковал в собственной зоне?

В январе 2013 года RFC 6844 определил запись DNS Certification Authority Authorization, тип 257. Владелец доменного имени мог указать один или несколько центров сертификации, которым разрешено выдавать сертификаты для этого имени. Перед выдачей соответствующий стандарту центр должен проверить нужный набор записей CAA и отказать в выдаче, если запрос ему противоречит, кроме случаев, когда применяется исключение из политики сертификации или практик центра.

CAA поместила правило выдачи в DNS — туда, где владелец уже публиковал другие данные своего имени. У центра сертификации появился обязательный этап проверки перед выдачей. Но область действия правила зависела от того, что именно считать «нужной» записью при переходе между именами DNS.

В 2013 году поиск мог пройти по двум деревьям

Правило обработки в RFC 6844 не только поднималось от запрошенного имени к его родителям. Если запрос CAA не находил запись на данной метке, а там стоял псевдоним CNAME или DNAME, процедура могла пройти по цели и повторить поиск. Если и там записи не было, она возвращалась к родительскому имени исходного запроса.

Условные имена показывают результат. Допустим, www.client.example указывает на tenant.platform.example, а провайдер публикует CAA 0 issue "issuer.example" на platform.example. Рекурсивное правило RFC 6844 могло пройти по псевдониму, затем подняться до platform.example и найти эту политику. Запись из родительской зоны провайдера могла попасть в проверку выдачи для имени клиента.

Правило искало применимый набор CAA, а не передавало провайдеру право собственности на домен клиента. Но разрешение DNS и наследование политики двигались в одной рекурсии. Имя клиента шло по псевдониму провайдера, а затем могло встретить его родительские имена. В общем хостинге каждый клиентский псевдоним мог наследовать правило, опубликованное провайдером выше в собственном дереве.

В 2019 году подъём остался в дереве запрошенного имени

Опубликованный в ноябре 2019 года RFC 8659 заменил RFC 6844 и изменил алгоритм обработки. Центр сертификации по-прежнему запрашивает CAA для исходного FQDN по обычным правилам DNS, которые могут разрешить псевдоним. Если запрос не вернул набор CAA, алгоритм поднимается по родительским меткам проверяемого FQDN. Он больше не обходит отдельно родительское дерево каждого найденного CNAME или DNAME.

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

RFC 8659 прямо объясняет поправку в сравнении с RFC 6844: обход родительских имён как исходного FQDN, так и каждого псевдонима был неэффективен для длинных цепочек. Он также затруднял хостерам публикацию CAA-политики для собственных FQDN без применения потенциально нежелательных правил к клиентским FQDN. Новый алгоритм сузил вопрос: какой набор CAA возвращён для этого имени при обычном разрешении DNS и что говорят его собственные родительские имена?

Проверка разрешения на выдачу — дело центра сертификации

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

Сама запись CAA также не подтверждает подлинность ответа DNS. RFC 8659 настоятельно рекомендует DNSSEC для CAA, но не требует его. Если запрос заблокирован, ответ повреждён или пустой ответ обработан неверно, у центра сертификации пока нет надёжного ответа о политике. Раздел RFC о развёртывании перечисляет такие сбои: правило доступа работает, только если издатель может получить и разобрать запись.

У CAA есть несколько свойств. issue применяется к обычным сертификатам, а issuewild, если он задан, управляет запросами wildcard-сертификатов. Пустое значение издателя может означать, что ни один центр не должен выдавать сертификат для имени. Теги задают содержание политики; изменение 2019 года уточнило, в каком дереве имена следует искать.

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

Имена в примере составлены по алгоритмам; это не описание известного инцидента. RFC фиксируют предусмотренное поведение. Чтобы измерить реализацию отдельного центра сертификации, понадобились бы его журналы запросов и решений о выдаче с соответствующими именами и временными метками.

Источники