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

82

Я следовал этому руководству по созданию подписанных 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, которое вызывает эту ошибку?

ssl  dns  openssl  windows-7-x64 
— Зед
источник
Потратил много времени, пытаясь это исправить. См. Мой ответ здесь stackoverflow.com/questions/42816218/…
— Alex Vasilev

Ответы:

20

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

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

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

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

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

    Надеюсь это поможет :)
— Томас Доннелли
источник
Ошибка, с которой вы связались: A) действительна только для OS X и B) касается доменов с завершающим символом ".", Ни один из которых не действителен для @Zed.
— Филип
Хм, по какой это ссылке?
— ThomasDonnelly
Ссылка на хромовый жучок (98627)
— Филипп
Несмотря на то, что предложенное мной исправление работает и в Windows, я использовал его много раз.
— ThomasDonnelly
«Как бы я ни предпочел использовать Chrome для разработки, в последнее время я обнаружил, что использую Firefox Developer Edition. В котором нет этой проблемы». не могу больше здесь согласиться ..
— Эш
58

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

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

— Майкл Реннер
источник
2
Это руководство помогло мне создать самозаверяющий сертификат в Mac OSX: alexanderzeitler.com/articles/…
— carlosvini
1
несмотря на то, что ошибка ничего не говорит об альтернативных именах субъектов, это устранило мою проблему. Благодаря!
— Sharpiro
26

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

— Фабиан С
источник
1
Использование subjectAltName = @alt_namesполностью решило мою проблему. Я ранее привязал DNS-идентификатор к своему домену, указав его CN=*.example.com. Настройка DNS.1 = example.comи DNS.2 = *.example.comсделала свое дело. Странным (для меня) было то, что все это работало до ~ 17 марта 2017 г. и остановилось на следующий день (была запущена большая партия обновлений Windows). Но в Linux у меня ничего не сломалось, это был только Chrome , Firefox на Windows .
— bossi
@bossi: К сожалению, у меня есть эта проблема в Chrome / Ubuntu. И в сертификате нет ничего необычного, один хост, один DN (внутренний репозиторий GitLab).
— Павел Крашевский
Работало около недели назад, на сервере ничего не изменилось. 2 других сервера начали разглагольствовать из-за несоответствия верхнего и нижнего регистра (в сертификате прописные буквы, Chrome переводит адрес в нижний регистр)
— Павел Крашевски
2
@bossi Готов поспорить, ваша версия Windows находится на стадии бета-тестирования, верно? В Chrome не поддерживаются сертификаты без subjectAltName выпуска Chrome 58, который в настоящее время находится в стадии бета-тестирования. Это сильно укусило меня, потому что я не только ничего об этом не видел, но и имя ошибки вводит в заблуждение (это не обычное имя, которое недействительно!). Я был противоположностью вам; для меня это произошло только в Linux, поэтому я часами пытался исправить там свое локальное хранилище сертификатов.
— Tobias J
2
@TobyJ 58.0.3029.19 beta (64-bit)это так. Я восстановил дерево сертификатов с правильными subjectAltName-s, и теперь все работает. И я согласен, сообщение об ошибке очень вводит в заблуждение, поскольку это не CommonNameчто является недопустимым. Если появитсяsubjectAltName сообщение «Сертификат отсутствует надлежащий » , все будут намного счастливее.
— Павел Крашевски
18

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

— Аликофф Гали
источник
2
Опечатка в DNS.1 = *.myserver.net. Должно быть DNS.2 = *.myserver.net. У меня отлично работает.
— Артем Степин
2
если вы работаете в Windows, это можно сделать с помощью openssl, установленного с git, используя cmd, работающий от имени администратора, и следующее расположение: «C: \ Program Files \ Git \ usr \ bin \ openssl.exe» req -x509 -sha256 -nodes -days 3650 -newkey rsa: 2048 -keyout app.key -out app.crt -config openssl.conf
— Джордж
Я написал CN = localhost, DNS.1 = localhost, DNS.2 = * .localhost: 8080, и у меня это не работает. Что еще мне нужно изменить?
— Esqarrouth
14

Ваш подстановочные *.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 в качестве доверенного органа для идентификации веб-сайтов.

— Джефф Пакетт
источник
Если кто-то, читающий это, использует Pantheon для хостинга, он, похоже, воссоздает общее имя, связанное с вашим сертификатом, когда вы загружаете его на свою платформу, создавая эту проблему. Вы должны протестировать пользовательский статический IP-адрес, который они предоставляют, чтобы увидеть, осталось ли общее имя сертификата неизменным во время настройки.
— serraosays
1
Гениально! «Ваш подстановочный знак * .example.com не охватывает корневой домен example.com, но охватывает любой вариант в субдомене, например www.example.com или test.example.com». В этом и была проблема в моем случае. Исправление было просто включить как DNS.1 = example.comи DNS.2 = *.example.comпри [alt_names]в openssl.cnf.
— Бен Джонсон
1

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

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

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

— треп
источник
0

Если вы устали от этой ошибки. Вы можете заставить 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

— двуличный
источник
0

Предоставленные ответы не помогли мне (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

— Джеймс Нельсон
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.