Капризный 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/".
Пока всё.