Комментарии 27
Браузер может её проверить, но в RFC не говорится, что ему делать в том случае если запись не нашлась, а серт валидный.
по-моему как раз браузер должен сравнивать — кто должен был выпустить и кто реально выпустил и при несовпадении считать сертификат невалидным.
Основная идея как раз в том, чтобы в итоге все центры сертификации проверяли САА в дополнении к существующим способам проверки (почта, веб-сайт, документы).
если кто-то захочет выпустить сертификат для домена, то он его выпустит не глядя на caa.
Это механизм проверки для добросовестных УЦ, а не для злонамеренных.
по-моему как раз браузер должен сравнивать
Для браузеров предназначен другой тип записей — TLSA.
Ну так не прокати уже фраза: мы не знали
за выдачу сертификата неавторизированным цс будет моментальный бан, а шутить после симантека и востгна вряд ли найдутся желающие
Вообще, DANE предназначен для верификации клиентским софтом. Если говорить о браузерах, то ни один из них его не поддерживает. Да и вообще с поддержкой DANE очень плохо.
Браузеру это не важно.
CAA только для выдачи сертификата.
Думаю в будущем расширят, и браузеры будут палить левые сертификаты.
Каждый центр сертификации, начиная с 8 сентября 2017 года будет обязан строго следовать инструкциям, указанным в CAA-записях доменного имени или субдомена для которого запрашивается выпуск сертификата.
Вовсе не каждый. Просто ассоциация крупнейших УЦ договорилась, что ее члены в обязательном порядке будут следовать стандарту, описанному в RFC 6844. Указанный RFC имеет статус Proposed standard, обязательным не является, и это решение не имеет никакой силы для УЦ, не входящих в эту ассоциацию.
Возможно, уже есть готовые примеры записей, разрешающие выпуск этих сертификатов для своих доменов?
example.com. IN CAA 0 issue «letsencrypt.org»
А как будет это работать в случае отсутствие CAA записей? Так же, как и прежде?
CAA records are currently in beta. Please open a support ticket to request access to the beta. (Code: 1039)
DNS-запись CAA. Зачем нужна и как использовать?