klink0v (klink0v) wrote,
klink0v
klink0v

Капризный Chrome

Последние версии браузера Google Chrome (кажется, начиная с 58-ой версии) стали до фига капризны и требовательны к содержанию полей X509-сертификата, предоставляемого сервером.

Раньше было как. Браузер сначала смотрел на "X509v3 Subject Alternative Name". И если там пусто и/или имя сервера не соответствует тому, что там написано, то дальше глядел в "Common Name" Subject-а. В случае, когда Common Name совпадает, то сайт признается валидным.

Теперь же такое поведение по умолчанию выпилили. Лично я не бегаю за последними версиями браузеров, поэтому не могу сказать в какой именно момент. Говорят, что в FireFox-е произошло такое же ужесточение. Так что при пустом / незаполненном поле "X509v3 Subject Alternative Name" сертификата тупо даётся отлуп, и ниипёт.

Но и это ещё не все. Я тут зело удивился, когда выяснил, что Chrome одной и той же версии / номера_билда под Windows и Linux ведёт себя по-разному. Помимо вышеизложенного, Linux-овая сборка проверяет ещё и значение в поле "X509v3 Key Usage". Там обязательно должны фигурировать слова "Digital Signature", "Key Encipherment". В противном случае хромой выдаст совершенно неинформативный отлуп вида "NET::ERR_CERT_INVALID" с комментарием "этот сайт прислал вам какую-то дичь, которой раньше не присылал" (ага, как будто он помнит что было раньше). А в консоль выплюнет ошибку с кодом 8102 ("SEC_ERROR_INADEQUATE_KEY_USAGE"). Виндовый хром в этом отношении чуть более толерантный, он почему-то нормально жрёт некорректные с точки зрения своего линуксового собрата сертификаты.

Таким образом, при самостоятельном создании X509-сертификата для своего [внутреннего] сайта с целью его беспроблемного отображения в свежих версиях Google Chrome, необходимо помимо прочего обязательно заполнить поля:


  • "X509v3 Key Usage" → "Digital Signature, Key Encipherment"

  • "X509v3 Extended Key Usage" → "TLS Web Server Authentication, TLS Web Client Authentication"

  • "X509v3 Subject Alternative Name" → "DNS:www.MySuperSite.com"

И чтоб два раза не вставать. Чтобы научить линуксовый хром отправлять Kerberos-тикет на веб-сервер в рамках GSSAPI, нужно определить список "доверенных" сайтов. Под виндой оный автоматически забирается из системных настроек Internet Explorer-а. А в линуксе есть два варианта.

Первый: добавить в строку запуска хрома параметр "--auth-server-whitelist". Например, так: $ /opt/google/chrome/chrome --auth-server-whitelist="*.mysuperdomain.local" . Если же хочется сохранить данную настройку навсегда, для пользования будущими поколениями пользователей, то придётся немного пошаманить (см. второй вариант).

Второй: создаём директорию "/etc/opt/chrome/policies/managed". Следим, чтобы непривилегированные пользователи не имели туда прав на запись (а не то хром проигнорирует настройки). Туда кладём файлик "что-нибудь.json" примерно нижеследующего содержания.

{
 "AuthServerWhitelist": "*.mysuperdomain.local"
}

Перезапускаем Chrome, радуемся.

Полный список директив для настройки можно посмотреть здесь. Проверить действующие (активные) в данном сеансе директивы можно проследовав по служебному URL-у "chrome://policy/".

Пока всё.

Tags: chrome, linux, x509, администрирование, грабли, интернетное
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 2 comments