plugin - java.security.invalidalgorithmparameterexception: the trustanchors parameter must be non-empty
Certificados autofirmados, Java, Hudson y JIRA. (3)
Estoy intentando configurar el complemento JIRA de Hudson. Nuestro servidor JIRA está protegido con un certificado SSL autofirmado. He insertado el certificado que mi navegador web ha guardado con el comando keytool y he conseguido que Hudson lo encuentre. Pero ahora se queja:
java.security.cert.CertificateException: No subject alternative names present
El nombre común del certificado es "Desconocido", y no veo ningún nombre alternativo de sujeto en el certificado
$ openssl x509 -in Unknown -text -noout
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 1214507595 (0x4863ea4b)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=US, ST=NJ, L=[Our town], O=[Our company], OU=[Our project], CN=Unknown
Validity
Not Before: Jun 26 19:13:15 2008 GMT
Not After : May 5 19:13:15 2018 GMT
Subject: C=US, ST=NJ, L=[Our town], O=[Our company], OU=[Our project], CN=Unknown
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
[omitted]
Signature Algorithm: md5WithRSAEncryption
[omitted]
(Identificando la información redactada y anotada entre paréntesis.)
¿Hay alguna manera de adjuntar un nombre alternativo del sujeto a este certificado? ¿O hay alguna otra manera? ¿O me veo obligado a hackear el complemento Hudson Jira?
El nombre de host utilizado para acceder a su servidor Jira (por ejemplo, jira.acme.com en https://jira.acme.com/ ) debe coincidir con uno de los campos CN del nombre del sujeto o, cuando no lo hace, uno de los Subject Alternative Name del cert.
Esto se detalla en el RFC 2818 :
En algunos casos, el URI se especifica como una dirección IP en lugar de un nombre de host. En este caso, iPAddress subjectAltName debe estar presente en el certificado y debe coincidir exactamente con la IP en el URI.
En su caso, Java se está quejando porque ni el CN ("Desconocido") ni el Subject Alternative Name (ya que no tiene) coincidieron con el nombre de host de su servidor Jira.
Entonces, genere un certificado con el CN apropiado, por ejemplo, utilizando keytool :
Para crear un par de llaves y un certificado autofirmado.
$ keytool -genkey -alias jira_acme_com -keyalg RSA -keysize 2048 -validity 365 -keystore jira_acme_com.jks Enter keystore password: Re-enter new password: What is your first and last name? [Unknown]: jira.acme.com What is the name of your organizational unit? [Unknown]: Our project What is the name of your organization? [Unknown]: Our company What is the name of your City or Locality? [Unknown]: Our town What is the name of your State or Province? [Unknown]: NJ What is the two-letter country code for this unit? [Unknown]: US Is CN=jira.acme.com, OU=Our project, O=Our company, L=Our town, ST=NJ, C=US correct? [no]: y Enter key password for (RETURN if same as keystore password):
Para ver la información personal.
$ keytool -list -v -keystore jira_acme_com.jks Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 1 entry Alias name: jira_acme_com Creation date: Sep 4, 2010 Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=jira.acme.com, OU=Our project, O=Our company, L=Our town, ST=NJ, C=US Issuer: CN=jira.acme.com, OU=Our project, O=Our company, L=Our town, ST=NJ, C=US Serial number: 4c81e9a9 Valid from: Sat Sep 04 10:39:37 CEST 2010 until: Sun Sep 04 10:39:37 CEST 2011 Certificate fingerprints: MD5: 15:6A:E3:14:E2:78:F4:95:41:E6:33:C9:F8:8B:64:23 SHA1: CD:A6:9A:84:18:E8:62:50:2C:DC:2F:89:22:F6:BA:E9:1A:63:F6:C6 Signature algorithm name: SHA1withRSA Version: 3
Y configura Tomcat para usar el almacén de claves.
De, si desea crear un certificado multitarjeta, tendrá que usar OpenSSL (keytool no puede agregar extensiones X509 como el nombre alternativo del sujeto). Estos enlaces son excelentes recursos:
- Creación de un certificado SSL con varios nombres de host
- OpenSSL - Documentación de la comunidad de Ubuntu
Actualización: Dado que no puede cambiar el certificado (realmente debería haberlo mencionado), una solución temporal podría ser cambiar el /etc/hosts local de las máquinas necesarias para resolver Unknown a la IP real de la máquina.
123.123.123.123 Unknown
Para que pueda acceder a https: // Desconocido / desde estas máquinas. Pero obviamente, esto es más un truco sucio que una solución real y no se puede escalar.
Ponerse en contacto con los administradores para obtener un verdadero "buen" certificado sigue siendo la buena solución.
Recursos
- Algunos comandos SSL de uso frecuente (mediante openssl o keytool)
- Creación de un certificado SSL con varios nombres de host
- OpenSSL - Documentación de la comunidad de Ubuntu
Referencias
Hay varias soluciones posibles, cada una con su propio conjunto de dolores.
Genere un nuevo certificado para JIRA, esta vez especificando un CN al generar el par de claves secretas para el certficate.
No puedo ver por qué no se puede generar un nuevo certificado; Estoy bastante seguro de que otro cliente del servidor JIRA también tiene algunos problemas, especialmente las advertencias de los navegadores, para el certificado descrito. Por lo tanto, todos los clientes (y las aplicaciones de los clientes) deben volver a probarse, pero esto no es una molestia, si el certificado autofirmado ha sido emitido por una CA local en la que confían todos los clientes.
- Edite las entradas de DNS para asegurarse de que la búsqueda a ''Desconocido'' desde el servidor de Hudson apunte al servidor donde está instalado JIRA [Le recordé a alguien que hay problemas asociados con algunas de las soluciones :-)]. Esto garantiza que el valor del CN almacenado en el certificado coincida con el nombre de host; deberá configurar Hudson para usar una URL como
http://Unknown/....Y oh, usa esto solo si estás en un lugar muy estrecho; No quieres explicar por qué hiciste esto.
Si no me equivoco, SSL requiere que el nombre común del certificado contenga el nombre de host al que intenta conectarse, de esa manera el lado del cliente puede validar que el certificado no solo es de confianza en general, sino también de confianza para la ubicación .
Supongo que está generando el certificado con OpenSSL. ¿Hay alguna razón por la que no esté configurando cn=[yourserver] ?
Puede suceder que cuando no se puede encontrar el nombre de host correcto en el nombre común, que el complemento intente buscarlo en un nombre alternativo del sujeto, y cuando eso falla porque no hay un SubjectAltName, aparece un mensaje de error erróneo. .
De todos modos, si está usando esto para múltiples sitios, necesita tener los nombres de host en el sujetoAltName. He encontrado un sitio que documenta cómo crear su certificado autofirmado correctamente.
http://library.linode.com/ssl-guides/subject-alt-name-ssl
Espero que esto ayude.