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

82

Я дотримувався цього підручника для створення підписаних сертифікатів SSL у Windows для цілей розробки, і він чудово працював для одного з моїх доменів (я використовую файл hosts для імітації dns). Тоді я зрозумів, що у мене багато субдоменів, і це було б болем у дупі, щоб створити сертифікат для кожного з них. Тому я спробував створити сертифікат, використовуючи підстановні символи в Commonполі, як це пропонується в деяких відповідях за замовчуванням сервера. Подобається це:

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, що спричиняє цю помилку?

ssl  dns  openssl  windows-7-x64 
— Зед
джерело
Провів багато часу, намагаючись це виправити. Дивіться мою відповідь тут stackoverflow.com/questions/42816218/…
— Олексій Васильєв

Відповіді:

20

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

Що стосується можливого способу вирішення цієї проблеми [за допомогою Windows], я б скористався однією з багатьох доступних утиліт сертифікатів самопідпису .

Рекомендовані кроки:

  1. Створіть самопідписаний сертифікат
  2. Імпортуйте сертифікат у диспетчер сертифікатів Windows
  3. Імпортувати сертифікат у диспетчері сертифікатів Chrome
    ПРИМІТКА. Крок 3 вирішить проблему, яка виникає після того, як Google усуває помилку ... з огляду на час, який минув, очікуваного майбутнього часу немає. **

    Наскільки я вважаю за краще використовувати Chrome для розробки, я останнім часом опинився у Firefox Developer Edition . яка не має цього питання.

    Сподіваюся, це допомагає :)
— Томас.Доннеллі
джерело
Помилка, на яку ви зв’язали, A) дійсна лише для OS X, і B) стосується доменів із кінцевим ".", Жоден з яких не діє для @Zed.
— Філіп
Хм, яке це посилання?
— Томас. Доннеллі
Посилання на хромову помилку (98627)
— Філіп
Незалежно від виправлення, яке я запропонував, працює і в Windows, оскільки я використовував його багато разів.
— Томас Доннеллі,
"Оскільки я вважаю за краще використовувати Chrome для розробки, останнім часом я опинився у Firefox Developer Edition. У якого немає цієї проблеми". я не міг тут більше домовитись ...
— Еш
58

Chrome 58 припинив підтримку сертифікатів без альтернативних імен суб’єктів .

Просуваючись вперед, це може бути ще однією причиною того, що ви зіткнулися з цією помилкою.

— Майкл Реннер
джерело
2
Цей посібник допоміг мені створити самостійно підписаний сертифікат на Mac OSX: alexanderzeitler.com/articles/…
— carlosvini
1
незважаючи на помилку, яка нічого не говорить про альтернативні назви предметів, це вирішило мою проблему. Дякую!
— Шарпіро
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зробив трюк. Дивна річ (для мене) полягала в тому, що все це працювало до ~ 2017-03-17 і зупинилося на наступний день після (було запущено велику партію удатів для Windows). У мене в Linux нічого не зламалося, це був лише Chrome , Firefox у Windows .
— bossi
@bossi: На жаль, ця проблема виникає в Chrome / Ubuntu. І сертифікат - це нічого вигадливого, єдиний хост, єдиний DN (внутрішнє сховище GitLab).
— Павел Крашевський,
Це працювало близько тижня тому, на сервері нічого не змінилося. 2 інших сервери почали дзвонити через невідповідність верхнього та нижнього регістру (сертифікат - верхній регістр, Chrome переставляє адресу в нижній регістр)
— Павел Крашевський,
2
@bossi Б'юся об заклад, ваша версія Windows знаходиться на бета-версії, чи не так? Chrome не підтримує сертифікати без версії subjectAltName Chrome 58, яка зараз знаходиться в бета-версії. Це мене сильно покусало, бо я не тільки нічого про це не бачив, але і назва помилки дуже вводить в оману (це не загальноприйняте ім’я, яке є недійсним!) Я був протилежним вам; для мене це сталося лише в Linux, тому я годинами намагався виправити там свій місцевий магазин сертифікатів.
— Тобіас Дж
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, і він не працює для мене. Що ще я повинен змінити?
— Ескаррут,
14

Ваш підстановочні *.example.comзовсім НЕ покриває кореневої домен , example.comале буде охоплювати будь-який варіант на заміну -ної доменної таких якwww.example.com чиtest.example.com

Кращим методом є встановлення альтернативних імен суб’єктів, як у відповіді Фабіана, але майте на увазі, що в даний час Chrome вимагає, щоб загальне ім’я було додатково вказано як одне з альтернативних імен суб’єктів (як це правильно продемонстровано у його відповіді). Нещодавно я виявив цю проблему , тому що я мав загальне ім'я example.comз SANs 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.
— Ben Johnson
5

Я думаю, що це може бути помилка в хромі. Була подібна проблема давно: Дивіться це.

Спробуйте в іншому браузері. Я думаю, це повинно працювати нормально.

— Рахул Шрірам
джерело
1

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

Це може бути корисно, якщо вам потрібно перевірити якийсь веб-сайт, який ви підтримуєте самостійно, і просто тестуєте як розробник (і коли у вас ще не налаштований належний сертифікат розробки).

Звичайно, це НЕ ДЛЯ ЛЮДЕЙ, які використовують веб-сайт у виробництві, де ця помилка вказує на те, що існує проблема із безпекою веб-сайту.

— башміш
джерело
0

Якщо ви втомилися від цієї помилки. Ви можете змусити Chrome не діяти так. Я не кажу, що це найкращий спосіб, просто кажу, що це спосіб.

Для вирішення цього питання можна створити розділ реєстру Windows, щоб дозволити Google Chrome використовувати commonName сертифіката сервера для відповідності імені хосту, якщо в сертифікаті відсутнє розширення subjectAlternativeName, якщо він успішно перевіряє та прив’язує до локально встановленого ЦС сертифікати.

Тип даних: Логічне [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" встановлені на "Self Sign"
    • всі інші варіанти були за замовчуванням
  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.