Как заставить chrome доверять сертификату?

Question

[bellerofonte]

Добрый день!
Хочу защитить вебсокетный трафик между мной и моим прилоением, работающей на AWS EC2.

Сделал себе самоподписной сертификат по этой инструкции:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 3650 -nodes
# настройки сертификата
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:Moscow
Locality Name (eg, city) []:Moscow
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Test LLC
Organizational Unit Name (eg, section) []:Test
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:a@b.c

Добавил его в Keychain (у меня macOS) и заставил систему доверять ему:


Перезапустил хром и обратился с приложению. Хром по-прежнему не доверяет моему сертификату.


хотя если ткнуть в хроме на сертификат, откроется Keychain, в которой сертификат указан как доверенный (см. рис.1).

Пробовал также следующее:

• при создании сертификата в CN указывать *
  
• при создании сертификата в CN указывать IP-адрес 10.10.1.91
  
• при создании сертификата в CN указывать домен test.local и прописывать в /etc/hosts 10.10.1.91 test.local
  

Нажимать "дополнительно - бла-бла-бла" не вариант, т.к. весь трафик от моего приложения идет по веб-сокету, а попытка подключиться к wss:// всегда завершается ошибкой, если хром не принимает сертификат как достоверный.
Ничего из вышеперечисленного не помогает. Как же все-таки заставить хром доверять моему сертификату, если я этого хочу?

Comments

[Sand]

"дополнительные" открывали?

[bellerofonte]

Sand, я не могу каждый раз тыкать "дополнительные - доверять бла бла бла", т.к.

1. 1. это лишние действия сами по себе
   
2. 2. (самое важное) - для веб-сокетов нет такой кнопки, попытка подключиться в wss:// всегда завершается ошибкой, если хром не принимает сертификат как достоверный. а именно по веб-сокету идет весь трафик от моего приложения
   

[Valentin Barbolin]

С каждым годом все больше людей которым лень читать.

У тебя прямо в ошибке написано CERT_COMMON_NAME_INVALID.

- укажи в сертификате COMMON_NAME (домен), можно выбрать почти любое (наприме mycoolaws.org)
- пропиши на компе в hosts mycoolaws.org AWS_IP

И наслаждайся.

[bellerofonte]

Andrey Barbolin,

С каждым годом все больше людей которым лень читать.

лучше и не скажешь! тем временем в конце вопроса:

при создании сертификата в CN указывать домен test.local и прописывать в /etc/hosts 10.10.1.91 test.local

[Valentin Barbolin]

bellerofonte, Наверное лыжи не едут) В сертификате просто test написано, без local. Common name так же пустой.


и судя по скриншоту - заходишь ты на сайта по IP, а не по доменному имени.

[bellerofonte]

Andrey Barbolin, tl;dr, пробовал. не работает как Вы предлагаете.

[Valentin Barbolin]

bellerofonte, У меня работает.

[bellerofonte]

Andrey Barbolin, потрясающе! сделал как на Вашем скриншоте, но со своим IP - работает. аналогично делаю через -c config.cnf - не работает. Лень разбираться, что не так с конфигом, использую Ваш код. Спасибо за решение!

[Valentin Barbolin]

bellerofonte, Тогда отметь как решение.

Answer 1

[Valentin Barbolin]

Необходимо
- сгенерировать сертификат
- указать справильный CN,
- добавить IP и domainname(CN) в hosts
- добавить сертификат в доверенный (macOS - keychain, windows - certmgr.msc)
- зайти на сайт по domainname

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
  -keyout example.key -out example.crt -subj "/CN=myawsdomain.com" \
  -addext "subjectAltName=DNS:www.myawsdomain.com,DNS:myawsdomain.com,IP:10.11.10.11"

Comments

[Михаил]

Valentin Barbolin подскажите пожалуйста, почему при выполнении команды в терминале выдает сообщение обратиться к "Справке", в команде поменял CN и DNS на свои данные
req: Use -help for summary.

[Valentin Barbolin]

Михаил, Возможно ты используешь не Linux и некоторые ключи могут отличаться. У меня выполнилась без вопросов на Debian 11.

[Михаил]

Valentin Barbolin, да, я работаю из под винды. Спасибо, попробую разобраться с ключами.

Answer 2

[ky0]

Сертификат может быть доверенным, но не валидным из-за того, что он отдаётся не по тому имени.

Имхо, сейчас стало настолько просто выпустить нормальный сертификат через Let`s Encrypt, что геморроиться с самоподписанными могут только очень упёртые люди :)

Comments

[bellerofonte]

Let's encrypt хорошо, но
Что делать, если нет домена?
Что делать если таких приложух надо запустить 10? или 100?
Что делать если все это на AWS EC2, которые могут менять IP-адреса после выключения/включения?
Что делать, если кроме AWS могут быть отладочные экземпляры, в т.ч. не в моей локальной сети?

[ky0]

bellerofonte, бесплатный домен можно взять в куче зон второго уровня.

Если счёт приложений пошёл на десятки - как-то странно жить без собственной зоны и DNS-хостинга, всё это по сравнению с теми же вычислительными мощностями стоит копейки.

У Амазона вообще всё прекрасно интегрировано с их Route 53. Отдельные экземпляры можно настроить руками или с помощью (опять же) API автоматически.

Короче, вы зачем-то городите костыли там, где всё легко решается штатными средствами :)

[bellerofonte]

ky0, я не компетентен спорить с Вами в этом вопросе, но я решительно не понимаю, почему [в теории] создать 1 собственный сертификат и копировать его на любую нужную машину проще, чем настраивать доменные зоны, получать сертификаты от let's encrypt, и т.д. и т.п. На практике я уже понял, что самоподписной сертификат - это тлен. В любом случае, спасибо за ориентир, уже настроил сертификат от let's encrypt.