Importé un certificado de servidor web de un CSR procedente de mi Cisco C9300. El certificado provino de la autoridad certificadora y muestra la CA correcta al final de la cadena. CLI muestra que el certificado se instaló correctamente sin problemas. El problema es cuando voy al sitio web seguro (https://) para buscar el conmutador pero dice que la conexión no es segura. Verifico el certificado en el navegador y muestra el certificado que obtuve de la CA. ¿Por qué se muestra inseguro aunque el certificado sea válido?
Al entrar a la pagina diceNET::ERR_CERT_COMMON_NAME_INVALID
ACTUALIZACIÓN 1: Gracias a @Zac67 estoy comprobando la información de Trustpoint. Cuando accedemos al switch de la página web utilizamos https://ipaddress. Puedo crear lo siguiente:
subject-name C=US, ST=Pennsylvania, L=My-Town, O=My-Org, OU=My-Department, CN=SWITCHNAME.DOMAIN.NET
Pero cuando lo hago subject-alt-name 192.168.1.10me da el siguiente error:
CRYPTO_PKI: Label cannot be made only of digits. Also, ip addresses are not permitted
Intenté poner la dirección en el CN pero tampoco funcionó. Todavía dice que el certificado no es válido.
ACTUALIZACIÓN 2:Estoy usando el How-To ubicadoaquí:para crear una clave RSA. Con esa clave estoy usando mi CA como punto de confianza. Obtengo la huella digital para entregársela a mi CA de Microsoft para obtener un certificado de servidor web. Obtengo el certificado de servidor web de mi CA y lo importo con las mismas instrucciones prácticas al conmutador. Luego voy a la página web y dice que la página web no es válida. El certificado proviene de la CA de mi dominio. No veo cómo piensa que no es válido.
ACTUALIZACIÓN 3:Así que estoy mirando las sugerencias de RICK sobre SAN. Voy a exponer que no utilizamos OpenSSL porque no se nos permite hacerlo. Tenemos que utilizar nuestra CA en la red. Para el CN, configuré el CN en la dirección IP del certificado. Para SAN, Cisco tiene comandos separados que dicen ip-addresscuál agrega la dirección y allí tengo un comando diferente llamado subject-name-alternativedel cual no puedo agregar una dirección IP a ese comando porque no está permitido. Entonces, lo que encuentro puedo hacer lo siguiente:
CN puede ser el siguiente:
- dirección IP
- Nombre de host
- FQDN
SAN (Nombre-Asunto-Alternativa puede ser el siguiente:
- Nombre de host
- FQDN
La dirección IP se puede agregar o no
Probé una combinación de todas esas cosas y todavía me dice que el certificado no es válido en EDGE con el error: NET::ERR_CERT_COMMON_NAME_INVALID. Si miras el certificado de Edge, muestra el mismo certificado si lo abro solo con las mismas huellas digitales.
Entonces, ¿cuál debería ser el CN al acceder desde la dirección IP usando Edge?
ACTUALIZACIÓN 4Además, al hacer lo siguiente para realizar la CSR, agrego la línea de dirección IP. Pero cuando miro el certificado, no parece que la dirección IP esté agregada a la SAN.De hecho, ¡el certificado no tiene SAN EN ABSOLUTO!Parece que algo se está perdiendo en la traducción.
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
¿Alguna idea de por qué no incluye la dirección IP en la SAN?
Respuesta1
Para profundizar en el comentario de Ricky: el nombre de host utilizado enhttps:// debecoincidir con el nombre del sujeto del certificado (SN) o uno de los nombres alternativos del sujeto (SAN). Si utiliza la dirección IP básica, debe estar presente como SAN. Incluso la más mínima discrepancia provoca un error de certificado.
También asegúrese de que el certificado de CA raíz esté presente en el almacén de confianza del cliente si utiliza su propia CA.
Respuesta2
Si la versión de Cisco IOS que está utilizando no permite definir un nombre alternativo de sujeto (SAN) basado en IP, entonces debe crear el CSR a través de una herramienta diferente como openssl para incluir el IP y luego firmar el CSR con su CA.
Con openssl usará un openssl.cnfarchivo de configuración y agregará una sección para incluir la SAN (también se puede hacer a través de CLI, pero se vuelve un poco más complicado).
Para utilizar el archivo de configuración, la [req]sección debe incluir un req_extensionsparámetro, algo como:
req_extensions = req_ext
El valor que proporciona es el "contexto" para la sección posterior que define qué extensiones desea utilizar. Con req_extel valor el resto de la configuración se vería así:
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
IP.1 = 192.168.1.10
- Para confirmar que la Solicitud de firma de certificado (CSR) generada contiene las entradas que puede utilizar:
openssl req -noout -text -in switch.csr
Verifique elNombre alternativo del sujeto X509v3sección. En el interior debe haber entradas IP:que contengan lo que usted definió cuando openssl.cnfgeneró la CSR. Si la dirección IP que espera que proteja el certificado no aparece dentro de las entradas SAN del CSR, algo salió mal, cualquier certificado generado por un CSR al que le falten los campos observará el error que mencionó, ya que no protege la IP correctamente.
Si ve las entradas de IP esperadas, pase la CSR a su CA para firmar y crear el certificado.
- Para confirmar que el certificado firmado por CA contiene las entradas con un openssl reciente, puede utilizar:
openssl x509 -noout -ext subjectAltName -in switch.pem
- Para confirmar que el certificado firmado por CA contiene las entradas con una versión anterior de openssl (falta el indicador de extensiones
-ext), puede usar:
openssl x509 -noout -text -in switch.pem
Utilizando cualquiera de los métodos anteriores, puede investigar el certificado firmado antes de la instalación. Comprobar elNombre alternativo del sujetovalores de las secciones. Si esto parece correcto, continúe e instale el nuevo certificado en su conmutador.
Alternativamente, también puede investigar los campos SAN a través del navegador en busca de certificados ya instalados. Dependiendo del software del navegador y de la versión, el diseño de la información puede variar.
Por ejemplo, aquí está Chrome, que requiere hacer clic en HTTPS/Bloquear en el navegador (ver información del sitio), hacer clic enla conexión es seguraluego haciendo clicEl certificado es válido, su interruptor no dirá válido, por supuesto, así que haga clic enEl certificado no es válido.
Chrome: Detalles del certificado
En Firefox, al revisar el certificado, también haga clic en HTTPS/Bloquear en el navegador.Conexión segura(cuando es cierto, por supuesto), entoncesMás información
