Después de habilitar HTTPS para un contenedor Nexus, las cargas y descargas de CURL fallan con el siguiente error: curl: 51 SSL: sin certificado alternativo.
Me encuentro con un problema al habilitar HTTPS para un contenedor Nexus (v3:3.30.0); ya no puedo cargar/descargar artefactos a través de Curl, aunque la interfaz web sí se muestra mediante HTTPS. Obtengo el siguiente error al intentar hacer curl: curl: (51) SSL: no se ajusta ningún tema de certificado alternativo al nombre de host de destino.
Estoy usando keytool para generar archivos .jks y .pem. Luego, el archivo .pem se importa a Active Directory Certificate Services interno. Una vez que se genera la cadena de certificados, los importo nuevamente al keystore en el contenedor, junto con las mejores prácticas de Sonatype en otras configuraciones.
https://help.sonatype.com/repomanager3/system-configuration/configuring-ssl
Reinicio el contenedor y puedo acceder a la interfaz de usuario a través de HTTPS, pero curl ahora muestra el siguiente error:
[usera@hosta]$ curl -l -v https://10.88.0.255:8081
Reconstruyendo URL para: https://10.88.0.255:8081/
Tratando 10.88.0.255 …
Se estableció TCP_NODELAY
Conectado a 10.88.0.255 (10.88.0.255) puerto 8081 (#0)
ALPN, ofreciendo h2
ALPN, ofreciendo http/1.1
ubicaciones de verificación de certificado establecidas correctamente:
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: ninguno
TLSv1.3 (OUT), handshake TLS, saludo del cliente (1):
TLSv1.3 (IN), handshake TLS, saludo del servidor (2):
TLSv1.2 (IN), handshake TLS, certificado (11):
TLSv1.2 (IN), handshake TLS, key exchange del servidor (12):
TLSv1.2 (IN), handshake TLS, finalizado del servidor (14):
TLSv1.2 (OUT), handshake TLS, key exchange del cliente (16):
TLSv1.2 (OUT), cambio de cifrado TLS, cambio de especificación de cifrado (1):
TLSv1.2 (OUT), handshake TLS, finalizado (20):
TLSv1.2 (IN), handshake TLS, finalizado (20):
Conexión SSL utilizando TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
ALPN, el servidor no aceptó ningún protocolo
Certificado del servidor:
subjeto: C=XX; ST=XX; L=XXXXXXXX; O=XX-XX; OU=XXX; CN=xxxx-xxxxxxx.xxxxxxxx.com
fecha de inicio: 28 nov 2021 19:49:21 GMT
fecha de término: 28 nov 2023 19:49:21 GMT
subjectAltName no coincide con 10.88.0.255
SSL: no hay ningún tema de certificado alternativo que coincida con el nombre de host de destino ‘10.88.0.255’
Cerrando conexión 0
TLSv1.2 (OUT), alerta TLS, notificación de cierre (256):
curl: (51) SSL: no hay ningún tema de certificado alternativo que coincida con el nombre de host de destino ‘10.88.0.255’
Cualquiera de los comandos openssl que uso contra el contenedor
openssl s_client –connect 10.88.1.9:8081
openssl s_client -connect 10.88.1.9:8081 –showcerts
openssl s_client -connect 10.88.1.9:8081 -tlsextdebug
openssl s_client -connect 10.88.1.9:8081 -tls1_2
Vuelve con:
Estrechón de manos SSL ha leído 4590 bytes y escrito 328 bytes
Verificación: OK
Código de retorno de verificación: 0 (OK)
davy.ai
Parece que hay un error de coincidencia de certificado al intentar usar Curl para cargar/descargar artefactos después de habilitar HTTPS para un contenedor Nexus. La interfaz web se carga a través de HTTPS, pero Curl devuelve un error “SSL: no alternative certificate subject matches target host name”.
El usuario ha utilizado keytool para generar archivos .jks y .pem, y luego ha importado el .pem en un servicio interno de certificados de Active Directory. Una vez que se genera la cadena de certificados, el usuario los importa de vuelta en el almacén de claves del contenedor, siguiendo las mejores prácticas de Sonatype en otras configuraciones.
Parece que el problema puede estar relacionado con el Nombre de Alternativa de Asunto (SAN) en el certificado que no coincide con el nombre del host objetivo utilizado en Curl. El mensaje de error muestra “subjectAltName no coincide con 10.88.0.255”. Es posible que el usuario necesite incluir el SAN correcto en el certificado o utilizar el nombre de host correcto al utilizar Curl.
Los comandos OpenSSL contra el contenedor devuelven una verificación que es correcta, por lo que parece probable que el certificado se haya instalado correctamente.
Para solucionar el problema, es posible que sea necesario verificar la configuración del certificado y asegurarse de que el SAN coincida con el nombre del host objetivo, junto con revisar cualquier otra configuración adicional que pueda afectar a la conectividad HTTPS y Curl.