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

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

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

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

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

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

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

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

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

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

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

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

В дальнейшем это может быть еще одной причиной возникновения этой ошибки.

Обходной путь - добавить доменные имена, которые вы используете как «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? )

Создать 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.2 = *.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работа у меня.

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

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

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

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

Для всех, кто сталкивается с этим и хочет рискнуть и протестировать его, есть решение: перейдите в режим инкогнито в Chrome, и вы сможете открыть «Дополнительно» и нажать «Перейти к some.url».

Это может быть полезно, если вам нужно проверить какой-то веб-сайт, который вы обслуживаете самостоятельно и просто тестируете как разработчик (и когда у вас еще нет настроенного сертификата разработки).

Конечно, это НЕ ДЛЯ ЛЮДЕЙ, использующих веб-сайт в производстве, где эта ошибка указывает на наличие проблемы с безопасностью веб-сайта.

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

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

Тип данных: Boolean [Windows: REG_DWORD] Расположение реестра Windows: HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ 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

Предоставленные ответы не помогли мне (Chrome или Firefox) при создании PWA для локальной разработки и тестирования. НЕ ИСПОЛЬЗУЙТЕ ДЛЯ ПРОИЗВОДСТВА! Мне удалось использовать следующее:

1. Сайт инструментов онлайн- сертификатов со следующими параметрами:
   • Общие имена: добавьте "localhost" и IP-адрес вашей системы, например 192.168.1.12.
   • Альтернативные имена субъектов: добавьте «DNS» = «localhost» и «IP» = <your ip here, e.g. 192.168.1.12>
   • В раскрывающемся списке "CRS" выбрано значение "Самостоятельная подпись"
   • все остальные параметры были по умолчанию
2. Скачать все ссылки
3. Импортировать сертификат .p7b в Windows двойным щелчком и выбрать «установить» / OSX? / Linux?
4. Добавлены сертификаты в приложение узла ... на примере Google PWA
   • Добавить const https = require('https'); const fs = require('fs'); в начало файла server.js
   • закомментируйте return app.listen(PORT, () => { ... }); внизу файла server.js
   • добавить ниже https.createServer({ key: fs.readFileSync('./cert.key','utf8'), cert: fs.readFileSync('./cert.crt','utf8'), requestCert: false, rejectUnauthorized: false }, app).listen(PORT)

У меня больше нет ошибок в Chrome или Firefox