Начиная с сентября 2017 года удостоверяющим центрам предписано обязательно проверять CAA-записи в DNS перед генерацией сертификата. CAA ([[https://tools.ietf.org/html/rfc6844 RFC-6844]], Certificate Authority Authorization) позволяет владельцу домена явно определить удостоверяющий центр, который имеет полномочия для генерации сертификатов для указанного домена. При наличии CAA-записи все остальные удостоверяющие центры обязаны блокировать выдачу сертификатов от своего имени для данного домена и информировать его владельца о попытках компрометации.Например, добавление в зону домена example.com записей (для BIND 9.9.6 и более новых выпусков):
$ORIGIN example.com
. CAA 0 issue "letsencrypt.org"
. CAA 0 iodef "mailto:security@example.com"
или
. CAA 0 iodef "http://iodef.example.com/"
указывает на то, что сертификаты для example.com генерируются только удостоверяющим центром Let's Encrypt ([[https://letsencrypt.org/docs/caa/ осуществляется]] проверка владельца домена "letsencrypt.org"). В поле iodef задаётся метод оповещения о попытке генерации сертификата. Поддерживается отправка уведомления на email или информирование через запрос к web-сервису ([[https://tools.ietf.org/html/rfc6546 RFC-6546]]).При желании можно уточнить учётную запись под которой разрешено генерировать сертификаты:
. CAA 0 issue "letsencrypt.org; account=12345"
Кроме issue также поддерживается поле issuewild, через которое задаются дополнительные ограничения выдачи сертификатов с маской, охватывающей группу хостов.
Допустимо указание нескольких записей issue, при использовании сертификатов от нескольких удостоверяющих центров:
example.com. CAA 0 issue "symantec.com"
example.com. CAA 0 issue "pki.goog"
example.com. CAA 0 issue "digicert.com"Проверить корректность создания записей CAA можно командой:
dig +short +noshort example.com CAA
Также доступен [[https://sslmate.com/caa/ web-интерфейс]] для автоматической генерации конфигураций.
URL:
Обсуждается: https://www.opennet.ru/tips/info/3028.shtml
0 после CAA означает 0-вой TTL?
Если да, то зачем и чем грозит использование TTL 86400?
в RFC же все написано... это не TTL, это critical flag, точнее flags, который пока всего один.
"0" - если CA не смогло понять вашу запись, они могут выдать сертификат.
"128" (не 1!) - если CA не смогло понять вашу запись, они не могут выдавать сертификат.В принципе для того, что в rfc уже описано, не важно как вы его выставите.
Если CA не поддерживает CAA-запись в принципе, то им в любом случае насpать, а если поддерживают, то будет иметь смысл только для каких-то будущих дополнительных фишек записи.
> в RFC же все написано... это не TTL, это critical flag, точнее
> flags, который пока всего один.Благодарю.
> "0" - если CA не смогло понять вашу запись, они могут выдать
> сертификат.
> "128" (не 1!) - если CA не смогло понять вашу запись, они
> не могут выдавать сертификат.
> В принципе для того, что в rfc уже описано, не важно как
> вы его выставите.Но что-то я не понял. Конечно, при условии что CA его поддерживают, логичней выставить 128, чтобы при некорректной записи выдача сертификата не осуществлялась, если я правильно понял.
Опять же, все в rfc. Логика следующая: Если в будущем добавится какой-то тип записи, которого нет в данном rfc, как пример приводится новое поле tbs, которого нет в этом rfc. У CA которое знает только о существовании rfc6844 и не знает что делать с tbs есть два варианта - если critical flag у данного поля выставлен в 0, оно может его проигнорировать и все равно выдать сертификат, если остальные условия соблюдены (issue "ca.example.net; policy=ev") или если critical flag выставлен 128, то не выдавать сертификат.$ORIGIN example.com
. CAA 0 issue "ca.example.net; policy=ev"
. CAA 128 tbs "Unknown"Так как issue/issuewild/iodef определены в этом rfc, то особого смысла ставить 128 нет.
Либо CA должны поддерживать эти записи и соблюдать их, либо они вообще пока на CAA запись не смотрят.При некорректной записи, например CAA 0 issue "incorrect record" CA поддерживающий этот rfc не должен выдать сертификат в любом случае.
Я не уверен как оно должно реагировать на CAA 0 или 128 issue "ca.example.net; unknown=blabla", если не понимает что делать с unknown=blabla, в rfc написано, что все дополнительные параметры могут быть site-specific, т.е. определяться CA и поэтому не оговариваются в данном rfc. Можно предположить, что оно должно тоже отказывать в выдаче и наверно опять же независимо от значения critical flag.
Ну и если под некорректной записью понимается какая-то опечатка вроде CAA 128 iisue "ca.example.net; policy=ev", тогда да, CA должен отказать, а при 0 выдать, не найдя ограничений.
> Ну и если под некорректной записью понимается какая-то опечатка вроде CAA 128
> iisue "ca.example.net; policy=ev", тогда да, CA должен отказать, а при 0
> выдать, не найдя ограничений.Благодарю, именно это меня больше всего и интересовало.
Вот по этому я вижу смысл везде ставить только 128.
первый же вопрос - а если выписан самим себе? как выглядит запись?
Точно так же - указываете свой CA, который может выпускать сертификат. Правда не очень понятно зачем, но можно.. Можно указать пустой список CAA 0 issue ";", что значить что ни один CA, который соблюдает это rfc, не должен выпускать сертификат.
Эта запись в любом случае не для клиентов, а для CA - браузеры не должны ее проверять.
> Точно так же - указываете свой CA, который может выпускать сертификат. Правда
> не очень понятно зачем, но можно.. Можно указать пустой список CAA
> 0 issue ";", что значить что ни один CA, который соблюдает
> это rfc, не должен выпускать сертификат.
> Эта запись в любом случае не для клиентов, а для CA -
> браузеры не должны ее проверять.Браузеры как раз и должны проверять, что полученный сертификат выдан кем то из списка CAA. Если не из списка CAA, то это явное указание на подделку сертификата. К примеру через прокси или MITM.
> Браузеры как раз и должны проверять,В RFC-6844 такого не нашёл. Можно линк на пруф, тебе же не трудно?
в стандарте конечно только про СА написано
но выглядит это как ключ к замку, висящий рядом с дверью, и запиской "входить только хозяевам", то есть защита только от честных людей
RFC ставит целью не защиты от злых CA, а защиту от злых людей, которые могут обманом получить сертификат на чужой домен от честного CA.
А если злой человек MITM'ит трафик между клиентом и сервером, то он и из DNS может CAA-запись убрать, так что браузеры особо не защитятся. М.б. DNSSEC спас бы, да кто ж его пользует...
> А если злой человек MITM'ит трафик между клиентом и сервером, то он и из DNS может CAA-запись убрать, так что браузеры особо не защитятся. М.б. DNSSEC спас бы, да кто ж его пользует...а может ли этот злой MITM-человек -- не взирая на DNSSEC просто выполнить повторное процедуру автоматической выдачи сертификата? делая это для того CA который в прописан в CAA? (с 99.9% ожидаем что это letsencrypt)
>> А если злой человек MITM'ит трафик между клиентом и сервером, то он и из DNS может CAA-запись убрать, так что браузеры особо не защитятся. М.б. DNSSEC спас бы, да кто ж его пользует...
> а может ли этот злой MITM-человек -- не взирая на DNSSEC просто
> выполнить повторное процедуру автоматической выдачи сертификата? делая это для того CA
> который в прописан в CAA? (с 99.9% ожидаем что это letsencrypt)сам спросил -- сам отвечаю (цитатой):
> При желании можно уточнить учётную запись под которой разрешено генерировать сертификаты:
>
> . CAA 0 issue "letsencrypt.org; account=12345"
> Браузеры как раз и должны проверять, что полученный сертификат выдан кем то
> из списка CAA.Браузеры — не должны. Должен проверять CA при получении запроса на выдачу сертификата.
Очевидный вопрос: Что будет если я не добавил запись CAA, а мой CA проверяет эту запись?
очевидно ошибку должен выдать - как не прошедший DNS проверку.
Не очевидно и даже почти наверняка не должен - если нет CAA записи, то нет и запрета. Вот если запись пустая, то да.
Какой рфц описывает тоже самое для браузеров?
Нет такого для браузеров.
прост:host -t CAA comodo.com
comodo.com has CAA record 0 iodef "mailto:sslabuse@comodoca.com"
comodo.com has CAA record 0 issue "comodoca.com"host -t CAA sberbank.ru
sberbank.ru has no CAA record
Что-то я не пойму - а как это поможет-то?Сценарий - у меня сайт cutekitties.org, SSL от ведущих производителей, CAA в DNS, все дела.
Клиент заходит из сети Ростелеком. Который тупо перехватывает все запросы на 53 порт и отвечает со своего DNS сервера, на лету подгибая адрес отвечателя через SNAT. Ну, и по мелочи шаманя в ответах, типа CAA для cutekitties.org может быть только РУСОНИКС.РФ.
Вопрос - и как это поможет клиенту?
Это не для браузеров. Читай ветку https://www.opennet.ru/tips/3028_ssl_https_caa_cert_dns.shtml#10