У нашей компании есть несколько веб-серверов разработки в нашем домене. Наше доменное имя довольно длинное, и, чтобы не набирать его, наши сотрудники привыкли просматривать наши веб-серверы только по имени хоста, а не по полностью определенному имени домена. Например, у нас есть webserver1, и сотрудники получают к нему доступ, перейдя по https: // webserver1 /, а не по https: // webserver1.longsubdomainname.companydomain.local /
Раньше это не было проблемой. Браузеры на компьютерах в нашем домене будут доверять сертификату webserver1, потому что он был выпущен центром сертификации нашего домена. Недавно Chrome начал отображать страницу с ошибкой сертификата с ошибкой NET :: ERR_CERT_COMMON_NAME_INVALID и, насколько я могу судить это потому, что мы не используем полное доменное имя, а хром теперь требует, чтобы CN был для полного доменного имени (см. правку ниже). Firefox и браузеры Microsoft по-прежнему считают нашу конфигурацию и сертификат действительными.
Как я могу заставить это работать с минимальными изменениями? Я представляю себе эти варианты
Так как я не могу понять, как использовать вариант 2, я склоняюсь к варианту 3. Вариант 1 кажется более подходящим, но я хотел бы, чтобы персонал был доволен более короткими URL-адресами. Есть ли веская причина, по которой мне не следует использовать вариант 3?
РЕДАКТИРОВАТЬ: Благодаря комментарию Штеффена Ульриха я понимаю, что неправильно понял проблему. Я поместил короткое имя сервера в раздел альтернативных имен субъектов, и ошибка сертификата исчезла.
Chrome 58 начинает показывать ошибки сертификата, когда сертификат полагается на общее имя и не имеет набора SAN. Я не знал, но, по всей видимости, с мая 2000 года это было запрещено.