LINUX.ORG.RU

Самоподписанный сертификат перестал приниматься в Chrome

 , , ,


1

2

У меня для некоторых моих собственных сервисов, которые посещаю только я, установлен HTTPS с моими самоподписанными сертификатами. Я это завел в июле прошлого года и почти год все было нормально, до вчерашнего дня. Соответственно, на всех моих устройствах импортирован мой CA-сертификат. После вчерашнего обновления Chrome я не могу зайти ни на один такой сайт, он перестал принимать мой сертификат. Отфутболивает с ошибкой:

NET::ERR_CERT_COMMON_NAME_INVALID
Если открыть консоль разработчика и перейти на вкладку Security, то там более подробная ошибка:
Subject Alternative Name Missing
The certificate for this site does not contain a Subject Alternative Name extension containing a domain name or IP address.
Погуглив n-ное количество времени, я нашел, что за эту дрянь отвечает настройка Google policy с названием «EnableCommonNameFallbackForLocalAnchors». Ее даже можно посмотреть на странице chrome://policy. Но я не знаю, как ее отключить, она не редактируется. Как мне отключить эту дрянь?

★★★★★

Ответ на: комментарий от Vovka-Korovka

У меня нормальный сертификат. Я не собираюсь выписывать заново сертификаты для кучи серверов только потому, что какой-то дядя что-то там обновил и в результате у меня все грохнулось. И не только у меня, на let's encrypt такие же проблемы. Как отключить эту идиотскую фичу, которую внедрили в Chrome?

Rinaldus ★★★★★
() автор топика
Ответ на: комментарий от Rinaldus

Нет у ЛЕ-сертификатов такой проблемы.

imul ★★★★★
()

Может тебе сделать сертефикаты с «Subject Alternative Name extension», а в браузере ничего не трогать?

torvn77 ★★★★★
()
Ответ на: комментарий от snaf

Доменное имя в CN — это ЕМНИП старый грязный хак, который работает ещё только по воле соместимости с глюкадромами прошлого.

beastie ★★★★★
()
Ответ на: комментарий от snaf

Тут вот неплохо описано: http://stackoverflow.com/questions/5935369/ssl-how-do-common-names-cn-and-sub...

TL;DR: Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. (RFC 2818)

beastie ★★★★★
()
Последнее исправление: beastie (всего исправлений: 1)
Ответ на: комментарий от snaf

Не обязательно. В некоторых случаев хватает только CN

А в некоторых уже не хватает. Все нормальные CA заполняют. В RFC 2818 для HTTPS давно (17 лет!) объявлено устаревшим. Так что стоны не понятны.

Vovka-Korovka ★★★★★
()
Ответ на: комментарий от beastie

Теоретически - да. Но на практике и Firefox и Chrome всегда требовали, чтобы значение CommonName было поддомен, к которому относится сертификат. Иначе - отфутболивали. Зачем надо было это дело ужесточать, требовать еще каких-то левых параметров, не понимаю.

Rinaldus ★★★★★
() автор топика
Ответ на: комментарий от Rinaldus

Скорее практически — ты сам на это нарвался. CN проверяется только, если не установлен SAN. И всё идёт к тому, что будет ещё жёстче.

beastie ★★★★★
()
Последнее исправление: beastie (всего исправлений: 1)

k@null ~ % cat /etc/chromium/policies/managed/EnableForLocalAnchors.json { «EnableSha1ForLocalAnchors» : true, «EnableCommonNameFallbackForLocalAnchors» : true}

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.