Небезопасные соединения с сертификатом CA

Небезопасные соединения с сертификатом CA

Я импортировал сертификат веб-сервера из CSR, поступившего с моего Cisco C9300. Сертификат поступил из центра сертификации и показывает правильный CA в конце цепочки. CLI показывает, что сертификат был установлен правильно, без проблем. Проблема в том, что когда я захожу на защищенный веб-сайт (https://) для коммутатора, он сообщает, что соединение не защищено. Я проверяю сертификат в браузере, и он показывает сертификат, который я получил от CA. Почему он отображается как небезопасный, хотя сертификат действителен?

При переходе на страницу написаноNET::ERR_CERT_COMMON_NAME_INVALID

ОБНОВЛЕНИЕ 1: Спасибо @Zac67 Я проверяю информацию Trustpoint. Когда мы получаем доступ к коммутатору для веб-страницы, мы используем https://ipaddress. Я могу создать следующее:

subject-name C=US, ST=Pennsylvania, L=My-Town, O=My-Org, OU=My-Department, CN=SWITCHNAME.DOMAIN.NET

Но когда я subject-alt-name 192.168.1.10это делаю, появляется следующая ошибка:

CRYPTO_PKI: Label cannot be made only of digits. Also, ip addresses are not permitted

Попробовал ввести адрес в CN, но это тоже не сработало. Все равно пишет, что сертификат недействителен.

ОБНОВЛЕНИЕ 2:Я использую How-To, расположенныйздесь:для создания ключа RSA. С этим ключом я использую свой CA в качестве точки доверия. Я получаю отпечаток, чтобы передать его моему Microsoft CA для сертификата WebServer. Я получаю сертификат WebServer из своего CA и импортирую его с теми же инструкциями How-TO в коммутатор. Затем я захожу на веб-страницу, и там говорится, что веб-страница недействительна. Сертификат исходит от CA для моего домена. Я не понимаю, как он считает его недействительным.

ОБНОВЛЕНИЕ 3:Итак, я рассматриваю предложения от RICK по поводу SAN. Я собираюсь изложить, что мы не используем OpenSSL, так как нам это не разрешено. МЫ должны использовать наш сетевой CA. Для CN я установил CN на IP-адрес сертификата. Для SAN у Cisco есть отдельные команды, которые говорят, ip-addressчто добавляют адрес, и там у меня есть другая команда, которая называется subject-name-alternative, из которой я не могу добавить IP-адрес к этой команде, так как это не разрешено. Итак, что я обнаружил, я могу сделать следующее:

CN может быть следующим:

  • айпи адрес
  • Имя хоста
  • Полное доменное имя

SAN (Имя субъекта-Альтернатива) может быть следующим:

  • Имя хоста
  • Полное доменное имя

IP-адрес можно добавлять или нет

Пробовал все эти вещи вперемешку, но мне все равно сообщается, что сертификат недействителен на EDGE с ошибкой: NET::ERR_CERT_COMMON_NAME_INVALID. Если вы посмотрите на сертификат из Edge, он покажет тот же сертификат, если я открою его сам по себе с теми же отпечатками.

Так каким же должен быть CN при доступе к нему с IP-адреса с помощью Edge?

ОБНОВЛЕНИЕ 4Также при выполнении следующих действий для создания CSR я добавляю строку IP-адреса. Но когда я смотрю на сертификат, то не вижу, чтобы IP-адрес был добавлен в SAN.На самом деле в сертификате ВООБЩЕ нет SAN!Кажется, что-то теряется при переводе.

crypto pki trustpoint my-trustpoint
enrollment terminal pem 
subject-name C=US, ST=Pennsylvania, L=My-Town, O=My-Org, OU=My-Department, CN=My-Switch.my-network.com
subject-alt-name my-switch.my-network.com
serial-number none
ip-address 192.168.1.51
revocation-check none
rsakeypair my-4096rsa-key
end

Есть идеи, почему IP-адрес не включается в SAN?

решение1

Разъясняя комментарий Рики: имя хоста, используемое вhttps:// долженсопоставьте либо имя субъекта сертификата (SN), либо одно из альтернативных имен субъекта (SAN). Если вы используете голый IP-адрес, он должен быть представлен как SAN. Даже малейшее несоответствие приведет к ошибке сертификата.

Также убедитесь, что корневой сертификат центра сертификации присутствует в хранилище доверенных сертификатов клиента, если вы используете собственный центр сертификации.

решение2

Если используемая вами версия Cisco IOS не позволяет определять альтернативное имя субъекта (SAN) на основе IP-адреса, то вам следует создать CSR с помощью другого инструмента, например openssl, чтобы включить IP-адрес, а затем подписать CSR с помощью вашего CA.

С помощью openssl вы будете использовать openssl.cnfфайл конфигурации и добавлять раздел, включающий SAN (это можно сделать и через CLI, но это немного сложнее).

Для использования файла конфигурации [req]раздел должен включать req_extensionsпараметр, например:

req_extensions = req_ext

Значение, которое вы предоставляете, является "контекстом" для последующего раздела, который определяет, какие расширения вы хотите использовать. С req_extэтим значением остальная часть конфигурации будет выглядеть примерно так:

[ req_ext ]
subjectAltName = @alt_names 

[alt_names]
IP.1    = 192.168.1.10
  • Чтобы подтвердить, что сгенерированный запрос на подпись сертификата (CSR) содержит записи, вы можете использовать:
openssl req -noout -text -in switch.csr

Проверьте наличиеX509v3 Альтернативное имя субъектараздел. Внутри должны быть записи, IP:содержащие все, что вы определили при openssl.cnfсоздании CSR. Если IP-адрес, который, как вы ожидаете, должен защищать сертификат, не указан в записях SAN CSR, что-то пошло не так, любой сгенерированный сертификат из CSR, в котором отсутствуют поля, будет отображать указанную вами ошибку, поскольку он не защищает IP должным образом.

Если вы видите ожидаемые записи IP, передайте CSR в свой центр сертификации для подписания и создания сертификата.

  • Чтобы убедиться, что подписанный CA сертификат содержит записи с последней версией OpenSSL, вы можете использовать:
openssl x509 -noout -ext subjectAltName -in switch.pem
  • Чтобы подтвердить, что подписанный CA сертификат содержит записи со старой версией openssl (без флага расширений -ext), вы можете использовать:
openssl x509 -noout -text -in switch.pem

Используя любой из методов выше, вы можете проверить подписанный сертификат перед установкой. ПроверьтеАльтернативное имя субъектазначения разделов. Если это выглядит правильно, то продолжайте и установите новый сертификат на вашем коммутаторе.


В качестве альтернативы вы также можете исследовать поля SAN через браузер для уже установленных сертификатов. В зависимости от программного обеспечения браузера и его версии, расположение информации может отличаться.

Например, вот Chrome, который требует нажать на HTTPS/Lock в браузере (просмотр информации о сайте), нажатьсоединение безопаснозатем нажавСертификат действителен, ваш переключатель, конечно, не скажет «действительно», поэтому нажмитеСертификат недействителен.

Chrome: сведения о сертификате

В Firefox при просмотре сертификата также нажмите HTTPS/Lock в браузере,Безопасное соединение(конечно, если это правда), тоБольше информации

Firefox: Просмотреть сертификат

Связанный контент