Я только что заменил сертификат SSL на нескольких наших серверах (все размещены на IIS7). По предложению нашего ИТ-менеджера мы используем сертификат альтернативного имени субъекта вместо отдельных сертификатов для каждого сервера. Мы купили этот сертификат у Digicert (он не самоподписанный). Я установил сертификат на наши серверы, и сайты загружаются без предупреждения и показывают хорошие блокировки в Firefox и Internet Explorer. Однако Chrome отображает красный «x» через значок замка и зачеркнутый шрифт для https-части URL-адреса. На вкладке «Подключение» отображается следующая ошибка:
"Идентификационные данные этого веб-сайта не проверены. Идентификационные данные сервера, к которому вы подключены, не могут быть полностью проверены. Вы подключены к серверу, используя имя, действительное только в вашей сети, которое внешний центр сертификации не имеет возможности проверить. право собственности на. Поскольку некоторые центры сертификации будут выдавать сертификаты для этих имен независимо от того, невозможно гарантировать, что вы подключены к предполагаемому веб-сайту, а не являетесь злоумышленником ".
Нажатие на «Информация о сертификате» показывает мне полную цепочку сертификатов (наш сертификат, промежуточный сертификат Digicert и сертификат CA Digicert), а статус сертификата для всех трех отображается как «Этот сертификат в порядке». Я в четыре раза проверил, что имя хоста, которое я использую в URL-адресе, является точным совпадением либо с общим именем, либо с одним из альтернативных имен субъектов в сертификате. Предыдущий сертификат, который у нас был на этих сайтах, был сертификатом с подстановочными знаками для * .mycompany.local, в то время как новое общее имя и имена SAN предназначены для определенных хостов в домене mycompany.local (т.е. eng-wiki.mycompany.local).
Объяснение от Chrome почти звучит так, как если бы он обнаружил, что внутренний DNS-сервер использовался для разрешения IP-адреса сервера, но это также относилось к старому сертификату с подстановочными знаками, и если бы это было веской причиной утверждать, что личность не могла быть проверена, она должна была дать сбой так же, как и старый сертификат с подстановочными знаками (но это не так). Более того, это объяснение означало бы, что ни один внутренний сервер компании не может проверить свою личность, что наносит гораздо больший вред безопасности, чем хорошей, поскольку нам всем придется научить наших пользователей игнорировать предупреждения системы безопасности в Chrome, несмотря на то, что мы специально потратили сотни долларов на законный сертификат, чтобы избежать этого.
Буду благодарен за любую помощь.
Спасибо!
--редактировать--
Углубившись сегодня, я поискал в источнике Chromium текст сообщения об ошибке и обнаружил, что проблема вызвана тем, что Chrome пришел к выводу, что имя хоста не является уникальным. Есть другие сообщения об этой проблеме как этот с сертификатами SAN при использовании короткого имени для своего URL. Но я использую полное имя сервера, например wiki.mycompany.local
Код, определяющий мое имя хоста как неуникальное: Вот, и я вижу некоторые комментарии, в которых обсуждаются gTLD, которые, как я подозреваю, являются основной причиной. Я мало что знаю о глобальных доменах верхнего уровня, но моя компания использует псевдо-TLD .local. Википедия, кажется, говорит, что это уже не очень хорошая идея (я не могу сделать 3 ссылки, потому что моя репутация слишком низкая из-за ошибки сервера, пожалуйста, не стесняйтесь редактировать это и превращать его в ссылку en.wikipedia.org/wiki /.local), хотя это было рекомендовано много лет назад, когда наша ИТ-команда настраивала нашу сеть. Непросто попросить их изменить сейчас
У меня есть соблазн отредактировать свой вопрос, чтобы удалить элемент SAN из уравнения, за исключением того, что у меня не было этой проблемы при использовании сертификата с подстановочными знаками для mycompany.local. Так что я все еще подозреваю, что использование сертификата SAN является частью проблемы. Тем не менее благодарен за любую помощь.
Более того, это объяснение будет означать, что ни один внутренний сервер компании не может подтвердить свою личность, что наносит гораздо больший вред безопасности, чем пользу, поскольку нам всем придется научить наших пользователей игнорировать предупреждения системы безопасности в Chrome, несмотря на то, что они потеряли сотни долларов на законный сертификат специально, чтобы этого избежать.
Но они не могут подтвердить свою личность третьей стороной, какой бы дорогой ни был сертификат.
Только одна компания может «владеть» contoso.com в общедоступном Интернете, и эта компания может указать, что такое server1.contoso.com, и никто другой не может.
DigiCert (или кто-либо еще) может проверить, что запрос сертификата для server1.contoso.com поступает от той же компании, которой принадлежит contoso.com, и поэтому (вероятно) не является мошенническим запросом. Они также могут выдать один сертификат для server1.contoso.com и не более.
Любой может получить contoso.local. Множество людей одновременно. Digicert не может ничего сделать, чтобы проверить, есть ли у вас серверы с таким именем или нет. И они могут выдавать сертификаты на это имя снова и снова разным людям.
Таким образом, предупреждение системы безопасности является подлинным предупреждением: Chrome не может проверить, является ли это предполагаемым server1.contoso.local, потому что тот же самый сертификат может быть установлен на тысяче компьютеров с именем «server1.contoso.local» по всему миру.
Если вы подумываете о размещении данных своей кредитной карты на сайте, сертификат .local не должен вас сильно успокаивать.
Очевидно, IE и FireFox имеют разные взгляды на это, предпочитая делать вид, что это нормально, хотя на самом деле это не так.
Сделайте свой сервер доступным по настоящему FQDN и вместо этого купите для этого сертификат.
Это довольно просто и сводится к аутентификации. Как заявил TessellatingHeckler, предупреждение системы безопасности является подлинным, и для этого есть обходной путь. Это не дефект в Chrome, а, скорее, упреждающий подход к лучшим методам безопасности, которые IE или FF, возможно, потребуется исправить. Вы когда-нибудь задумывались, почему некоторые центры сертификации все еще продают сертификаты на 5 лет, а другие - только на 3 года? Скоро будет изменение срока действия сертификата.
Когда выдается сертификат, подтвержденный организацией (OV), центр сертификации должен подтвердить, что домен полностью зарегистрирован у регистратора доменов и что компания имеет право использовать домен. Он делает это, просматривая WHOIS и D&B, чтобы проверить эту информацию. Например, все, что есть .com / .net / .edu. С другой стороны, домен .local может принадлежать кому угодно и не может быть аутентифицирован каким-либо центром сертификации. Не знаю, как в Digicert проводилась аутентификация, но этого не должно было случиться. Когда вы покупаете сертификат SSL, вы платите больше за аутентификацию, чем за что-либо еще.
Вот ссылка с форума CA Browser, в которой говорится, что к октябрю 2016 года использование всех внутренних имен будет прекращено в целях обеспечения безопасности. Надеюсь, это прольет свет на вашу команду ИТ-менеджмента и заставит их начать проявлять упреждающий подход вместо того, чтобы ждать до последней минуты.
https://www.cabforum.org/Guidance-Deprecated-Internal-Names.pdf
Могу я спросить, сколько лет действует этот сертификат? Причина, по которой я спрашиваю, заключается в том, что на данный момент существует работа, чтобы вы могли разобраться в конфигурациях сервера относительно внутреннего имени. Когда вы создаете CSR, введите общее имя как www.yourcompany.com и в поле SAN введите «yourcompany.local». Таким образом, когда CA находится в процессе аутентификации, он может проверить, что у вас есть права на www.yourcompany.com, а в поле SAN IP-адрес yourcompany.local также будет защищен. Этот обходной путь зависит от времени, поскольку ни один центр сертификации не будет выдавать трехлетний сертификат в таких условиях, если срок его действия превышает установленное изменение.
Я надеюсь, что эта информация окажется полезной.
DigiCert не указывает Chrome как поддерживаемый браузер на их сайт. Как обсуждалось в другом местеинтерпретация SAN зависит от реализации SSL, и я подозреваю, что Chrome может делать что-то странное (tm) по сравнению с Firefox или Internet Explorer.
Вы случайно используете IP-адрес в SubjectAltName? Глядя на одно из приложений Chrome образцы кода онлайн похоже, указывает на то, что они ожидают там имени хоста (а не IP).