
Я импортировал сертификат веб-сервера из 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 в браузере,Безопасное соединение(конечно, если это правда), тоБольше информации