[Перевод] Форум центров сертификации и разработчиков браузеров утвердил обязательность DNS CAA
Комментарии (12)
23 мая 2017 в 14:06
0↑
↓
Да, ожидается, что при несоответствии САА-записи центр сертификации прекращает выдачу сертификата, но ведь центр сертификации может переключиться в ручной режим и принять решение о выпуске
То есть «может выдать, а может не выдать»? В чём тогда смысл?
23 мая 2017 в 15:51
+2↑
↓
Генератор CAA-записей, но не все провайдеры их поддерживают. Кто-нибудь в курсе почему не сделали валидацию через обычные TXT?23 мая 2017 в 18:43
0↑
↓
Простите мое невежество, но что такое «валидация через обычные TXT»?23 мая 2017 в 19:11
+1↑
↓
Писать разрешенные CA в TXT-запись (как сделано для SPF), а не созавать новый тип ради которого хостерам придётся дорабатывать панели.23 мая 2017 в 19:14
+2↑
↓
Не только панели :) еще и клиенты с серверами DNS
23 мая 2017 в 20:27
0↑
↓
В RHEL7 бэкпортировали поддержку CAA для BIND 9.9.4, так что на линуксе проблем быть не должно.
23 мая 2017 в 19:12
+3↑
↓
Наверное, имеется в виду что-то типа:
_caa IN TXT issue «letsencrypt.org».
Т.е. без введения нового типа записей (CAA).23 мая 2017 в 22:11
0↑
↓
Нет, если верить генератору из комментария выше, это именно новый тип.
Если верить этому генератору, то список dns серверов довольно обширен, а панели, я думаю не так много работы по внедрению нового типа записей.
23 мая 2017 в 22:11
0↑
↓
Странно, что для клиентов (браузеров) не указан очевидный путь для дополнительной проверки надёжности — сверять соответствие CAA-записи и издателя сертификата.23 мая 2017 в 23:09
0↑
↓
Ок. Будем ещё подменять DNS.23 мая 2017 в 23:17
0↑
↓
DNSSEC пока не научились подделывать. Ждем волны взломов корневых DNS.24 мая 2017 в 07:07
0↑
↓
DNSSEC весьма опциональный. И вряд ли это изменится. Так что можно рассчитывать, что в целевом браузере он будет отключён.