Создание самоподписанного сертификата для домена и поддоменов - NET:: ERR_CERT_COMMON_NAME_INVALID

Я следил за этим учебным пособием по созданию подписанных сертификатов SSL в Windows для целей разработки, и он отлично поработал для одного из моих доменов (я используя файл hosts для имитации dns). Затем я понял, что у меня много субдоменов, и это будет болью в заднице, чтобы создать сертификат для каждого из них. Поэтому я попытался создать сертификат с использованием подстановочного знака в поле Common, как это предложено в некоторых ответах на serverfault. Вот так:

Common Name: *.myserver.net/CN=myserver.net

Однако после импорта этого сертификата в доверенный корневой центр сертификации я получаю ошибку NET::ERR_CERT_COMMON_NAME_INVALID в Chrome, для основного домена и всех его подэлементов, например: https://sub1.myserver.net и https://myserver.net.

Этот сервер не может доказать, что это myserver.net; его сертификат безопасности из *.myserver.net/CN = myserver.net.

Это может быть вызвано неправильной конфигурацией или атакующем, перехватывающим ваше соединение.

Что-то не так в поле Common Name, которое вызывает эту ошибку?

Ответ 1

Как сказал Рахул, это распространенная ошибка Chrome и OSX. У меня были подобные проблемы в прошлом. На самом деле я, наконец, устал от 2 (да, я знаю, что это не так много) дополнительных кликов при тестировании локального сайта на работу.

Что касается возможного обходного пути к этой проблеме [с использованием Windows], я бы использовал одну из множества доступных утилит для самоподписывания сертификатов.

Рекомендуемые шаги:

Создать самоподписанный сертификат
Импорт сертификата в диспетчер сертификатов Windows
Импорт сертификата в диспетчере сертификатов Chrome
ПРИМЕЧАНИЕ. Шаг 3 решит проблему, возникшую после того, как Google исправит ошибку... учитывая, что время уже устарело, в обозримом будущем нет ETA. **

Столько, сколько я предпочитаю использовать Chrome для разработки, я недавно обнаружил в Firefox Developer Edition. который не имеет этой проблемы.

Надеюсь это поможет :)

Ответ 2

Chrome 58 имеет отмененную поддержку сертификатов без альтернативных имен темы.

Перемещение вперед, это может быть другой причиной, по которой вы столкнулись с этой ошибкой.

Ответ 3

Обходным путем является добавление имен доменов, которые вы используете как "subjectAltName" (альтернативное имя объекта X509v3). Это можно сделать, изменив конфигурацию OpenSSL (/etc/ssl/openssl.cnf в Linux) и изменив раздел v3_req, чтобы выглядеть так:

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.net
DNS.2 = sub1.myserver.net

При этом не забудьте использовать переключатель -extensions v3_req при создании нового сертификата. (см. также Как я могу сгенерировать самозаверяющий сертификат с помощью SubjectAltName с помощью OpenSSL?)

Ответ 4

Подстановочный знак *.example.com делает не обложку корневого домена example.com, но будет охватывать любой вариант в поддомене, например www.example.com или test.example.com

Предпочтительный метод - установить альтернативные имена объектов, такие как Fabian Answer, но имейте в виду, что Chrome в настоящее время требует, чтобы Common Name было дополнительно добавлено как один из Тема Альтернативные имена (как это правильно продемонстрировано в его ответе). Недавно я обнаружил эту проблему, потому что у меня было общее имя example.com с SAN www.example.com и test.example.com, но получено предупреждение NET::ERR_CERT_COMMON_NAME_INVALID от Chrome. Я должен был создать новый запрос подписи сертификата с example.com как для общего имени, так и для одной из SAN. Тогда Chrome полностью доверял сертификату. И не забудьте импортировать корневой сертификат в Chrome в качестве доверенного органа для идентификации веб-сайтов.

Ответ 5

Создайте файл openssl.conf:

[req]
default_bits = 2048
default_keyfile = oats.key
encrypt_key = no
utf8 = yes
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[req_distinguished_name]
C = US
ST = Cary
L = Cary
O  = BigCompany
CN = *.myserver.net

[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.net
DNS.1 = *.myserver.net

Запустите эту команду:

openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -keyout app.key -out app.crt  -config openssl.conf

app.crt app.key работают выходные файлы app.crt и app.key.

Ответ 6

Я думаю, что это может быть ошибка в Chrome. Давным-давно была похожая проблема: смотрите.

Попробуйте в другом браузере. Я думаю, что это должно работать нормально.

Ответ 7

Если вы устали от этой ошибки. Вы можете заставить Chrome не действовать так. Я не говорю, что это лучший способ сказать это способом.

В качестве обходного пути можно создать ключ реестра Windows, чтобы позволить Google Chrome использовать commonName сертификата сервера для соответствия имени хоста, если в сертификате отсутствует расширение subjectAlternativeName, если оно успешно проверяет и связывает его с локальным -установленных сертификатов CA.

Тип данных: Boolean [Windows: REG_DWORD] Место расположения реестра Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Политики\Google\Chrome Имя предпочтения Windows/Mac/Linux/Android: EnableCommonNameFallbackForLocalAnchors Значение: 0x00000001 (Windows), true (Linux), true (Android), (Mac) Чтобы создать раздел реестра Windows, выполните следующие действия:

Откройте Блокнот Скопируйте и вставьте следующий блок в блокнот Редактор реестра Windows версии 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome] "EnableCommonNameFallbackForLocalAnchors" = DWORD: 00000001 Откройте Файл > Сохранить как Имя файла: any_filename.reg Сохранить как тип: Все файлы

Выберите предпочтительное местоположение для файла

Нажмите Сохранить

Дважды щелкните по сохраненному файлу для запуска

Нажмите "Да" в редакторе реестра.

Обнаружена эта информация на странице поддержки Symantec: https://support.symantec.com/en_US/article.TECH240507.html