Вопросы Теги

Рабочий стол Chrome и Android отказываются принимать доверенный самозаверяющий сертификат

Я создал самоподписанный сертификат, используя следующую команду, используя OpenSSL 1.1.1b (26 Февраль 2019 г.):

openssl req -nodes -new --days 900 -subj /CN=192.168.0.104:8080 -x509 -keyout server.key -out server.crt

Затем я использовал окна mmc импортировал полученный server.crt в Корневой каталог консоли -> Сертификаты - Текущий пользователь -> Доверенные корневые центры сертификации -> Сертификаты

Когда я перехожу на страницу в chrome tho по адресу 192.168.0.104:8080, он сообщает мне страница "Небезопасна" (хотя, если я посмотрю на информацию о сертификате, в статусе сертификата в разделе «Путь сертификации» указано: «Этот сертификат в порядке».

Я проделал аналогичный процесс на своем телефоне Android, загрузив его на свой телефон, добавив сертификат в раздел настроек шифрования и учетных данных.

Однако, когда Я перехожу на страницу, она сообщает мне, что «сертификат сервера не соответствует URL-адресу».

Что я здесь делаю не так?

Обновление:

Теперь я использую req.conf 

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = CA
L = Belmont
O = N/A
OU = N/A
CN = 192.168.0.104
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.0 = localhost
IP.0 = 192.168.0.104

И создание сертификата и ключа с помощью:

openssl req -x509 -nodes -days 999 -newkey rsa:2048 -keyout server.key -out server.crt -config req.conf

Затем я перезапустил Chrome в Windows (я не могу поверить, что перезапуск программ для того, чтобы настройки вступили в силу, все еще необходимо в 2019 году) . Windows Chrome тогда распознает это нормально.

Однако на Android я даже не могу установить этот сертификат - он сообщает мне: «Для установки сертификата требуется закрытый ключ». Это еще больше сбивает с толку.

2
задан 6 October 2019 в 06:17
1 ответ
  1. Chrome требует SAN. Уже два года Chrome использует расширение альтернативного имени сервера (SAN) в сертификате, а НЕ атрибут CommonName (CN) в теме, как это было в прошлом веке. (Другие браузеры, все TTBOMK и почти все клиенты сегодня предпочитают SAN, но при необходимости будут использовать Subject CN; Chrome этого не сделает.) Вы не сообщаете нам, что находится в вашем файле конфигурации OpenSSL , или какую версию вы используете. OpenSSL 1.1.1 теперь имеет параметр командной строки -addext to req -new -x509 , но в противном случае вам нужно установить SAN в файле конфигурации хотя бы логически - хотя в Unix, и я полагаю, что WSL, вы можете заставить оболочку создать этот файл конфигурации как автоматический временный файл с помощью <(команды) (или в zsh = (команды) ). См .:

Создание самозаверяющего сертификата с помощью openssl, который работает в Chrome 58
Невозможно избавиться от ошибки net :: ERR_CERT_COMMON_NAME_INVALID в Chrome с самозаверяющими сертификатами
https: //security.stackexchange .com / questions / 172440 / generate-x509-err-cert-common-name-invalid
https://security.stackexchange.com/questions/74345/provide-subjectaltname-to-openssl-directly-on-command -line
https://security.stackexchange.com/questions/158632/burp-suite-although-my-configurations-are-correct-still-chrome-doesnt-allows

, но обратите внимание, что эти вопросы касаются сертификат для доменного имени,который использует DNS типа записи SAN; для IP-адреса вам необходимо использовать IP.

  1. Не указывайте порт. Даже для браузеров / клиентов, которые все еще используют Subject CN, это должно быть имя хоста или IP-адрес без порта. (Для SAN вы не можете ошибиться, потому что синтаксис SAN только разрешает DNS: dommainname или IP: IPv4or8addr и без порта.)

PS: 8080 обычно используется для альтернативного HTTP, а 8443 - для альтернативный HTTPS. Использование 8080 для HTTPS сбивает с толку.

3
ответ дан 3 December 2019 в 10:31

Теги

Похожие вопросы