Solución:
Solución 1:
No puedes hacer eso con keytool. Primero, keytool no es compatible con DH en absoluto. Segundo, keytool no genera parámetros por sí mismos para ningún algoritmo, solo una clave privada / par de claves. Tercero, cuando keytool genera un par de claves también genera un certificado autofirmado (que algunas veces posteriormente se reemplaza por un certificado “real” emitido por una CA) y es imposible generar un certificado autofirmado para DH porque DH no firma. usted podría escriba un programa Java muy simple (alrededor de 10 líneas) para generar parámetros DH. Pero probablemente no te sirva de nada porque:
Java no acepta los parámetros DHE aquí de todos modos. JbossWS (el servidor web Jboss, más tarde Wildfly) es una bifurcación de Tomcat, y normalmente usa la implementación Java de SSL / TLS, JSSE. Hasta Java 7, JSSE usa sus propios parámetros DHE que son de 768 bits, lo que es inaceptablemente débil. (Excepto para las suites EXPORT donde JSSE obedece el requisito de RFC para DH-512, que está totalmente roto, pero luego las suites EXPORT están por diseño totalmente descompuestas de todos modos y deshabilitadas de forma predeterminada en Java 7 en adelante). Java 8 JSSE le permite controlar el Talla de los parámetros DHE, pero no el valor real.
Sus opciones (algunas superpuestas) son:
Utilice Java 8. JSSE en Java 8, pero no antes, por defecto DHE a 1024 bits, que la mayoría de las autoridades consideran lo suficientemente fuerte a pesar de que débildh.org no lo hace, y le permite especificar más, consulte https://docs.oracle.com/javase/8 /docs/technotes/guides/security/jsse/JSSERefGuide.html#customizing_dh_keys y para el fondo https://stackoverflow.com/questions/30352105/how-to-set-custom-dh-group-in-java-sslengine-to -prevenir-logjam-attack. Tenga en cuenta que si tiene Java clientela antes de Java 8, fallar si el servidor usa DHE sobre 1024 bits. No conozco a ningún otro cliente que tenga este problema, pero pruebe el suyo antes de comprometerse con este cambio.
Habilite ECDHE. JSSE en Java 7 y posteriores implementa ECDHE, que no está sujeto a precomputación como DHE, (normalmente) usando P-256, que es más que suficientemente fuerte. (Aunque algunas personas no confían alguna de las curvas NIST ECC porque NIST en general está influenciado por NSA, aunque ningún código abierto que conozca ha mostrado un problema en las curvas ECC específicamente.) Java 6 en realidad tiene la parte JSSE para ECDHE, pero solo está habilitado si la JVM tiene un “proveedor” de cifrado para primitivas ECC, que Java 6 no lo hace. bcprov – * – jdk15on de http://www.bouncycastle.org/ es un proveedor de JCE para una variedad de primitivas criptográficas de Java, incluido ECC, por lo que si agrega el jar a su JRE/lib/ext y añadir org.bouncycastle.jce.provider.BouncyCastleProvider a la lista en JRE/lib/security/java.security (o hacer una adecuada Security.add/insertProvider() en algún lugar temprano en su código) Java 6 puede hacer ECDHE. Por supuesto, si debería tener Java 6 todavía en uso es una cuestión en sí misma.
Hace unos años, el soporte para ECDHE en navegadores y otros clientes era dudoso, pero hoy AFAIK todos los navegadores actualizados lo admiten y preferir a DHE, es decir, el hola del navegador enumera las suites ECDHE antes que las suites DHE, de modo que si el servidor implementa ambas, debería elegir ECDHE. Los clientes que no son navegadores tal vez no; prueba para estar seguro.
Desactive DHE. Puede configurar la lista de cifrados en el atributo Connector para excluir los cifrados DHE; mientras lo hace, también excluya staticDH y staticECDH que son inútiles, y (solo) DES y (todos) “EXPORTAR” si están presentes (Java 6). Esto significa que los navegadores y clientes que no utilicen ECHDE estarán bloqueados con RSA simple y sin confidencialidad directa, pero al menos tienen el secreto “actual”. No lo recuerdo con seguridad, pero creo que la configuración del conector 5.1 todavía estaba en algún lugar como $server/deploy/jbossweb/server.xml .
Prueba nativo. Tomcat, que, como dije, comenzó desde JbossWS, tiene una opción para implementar HTTPS (SSL / TLS) usando “native” también conocido como “APR”, que en realidad es OpenSSL en el interior en lugar de JSSE. He tenido un éxito desigual al hacer que esta opción funcione en JbossWS, y no recuerdo nada de 5.1. Si su JbossWS tiene una opción nativa de TC viable, y si puede manejar la configuración de parámetros DH, luego usa openssl para generar los parámetros DH y las instrucciones nativas de JbossWS para configurarlos.
Solucion 2:
En realidad, puede especificar parámetros DHE personalizados con versiones recientes de Java 8. Eso es independiente de la aplicación (siempre que utilice la implementación JSSE TLS).
Primero debe especificar el tamaño de la clave DHE para usar (-Djdk.tls.ephemeralDHKeySize=1024 o -Djdk.tls.ephemeralDHKeySize=2048). En el servidor, esto usará una combinación predefinida de generador / principal para DHE. Con Java 8 solo se puede usar 1024 o 2048, JDK 9 admitirá tamaños más grandes.
Si desea proporcionar una combinación diferente, puede especificarlos en jre / lib / security / Java.security con el jdk.tls.server.defaultDHEParameters propiedad de seguridad (desde 8u51). Toma una lista de parámetros (uno para cada tamaño de clave utilizado) y debe contener el principal y el generador (normalmente 2 o 5) como hexadecimal.
Si usaste openssl dhparam -out dhparam2048.pem 2048 para generar un nuevo par que puedes usar openssl dhparam -noout -text -check -in dhparam2048.pem para leer e imprimir ese archivo en modo texto. Tendrá que copiar y pegar el texto en las propiedades de seguridad de Java (usando tr -d ':' para quitar el : entre la representación hexadecimal de openssl)
Aquí hay una muestra (solo 1024 bis):
>openssl dhparam -in p -check -text -noout | tr -d ':'
PKCS#3 DH Parameters: (1024 bit)
prime:
00f7a63b59edcc43a43df12077f0e9
14129c20a73cef95f919896e608ebc
8722776c948765bbbf61542e118329
6c6ea74ecbded3a93aff77a062aba4
fcf04fc01030e65077f5a802605058
65b836368dd5ea389d77691fac0f2c
f7a161c51c8e97ddecb3cf7f872b0c
cfaf54373d5203edcabc575e871bb1
107ec2f30c78ebf403
generator: 2 (0x2)
DH parameters appear to be ok.
Y esto resulta en
jdk.tls.server.defaultDHEParameters=
{
00f7a63b59edcc43a43df12077f0e9
14129c20a73cef95f919896e608ebc
8722776c948765bbbf61542e118329
6c6ea74ecbded3a93aff77a062aba4
fcf04fc01030e65077f5a802605058
65b836368dd5ea389d77691fac0f2c
f7a161c51c8e97ddecb3cf7f872b0c
cfaf54373d5203edcabc575e871bb1
107ec2f30c78ebf403, 2 }
Debe reiniciar el servidor y verificar que realmente use este principal (y no los predeterminados) ya que el proceso no es directo, por lo que muchas cosas pueden salir mal. El valor predeterminado se define en la fuente, para 2048 bits, el valor principal es del borrador TLS FFDHE.
Por ejemplo, cuando ejecuto openssl s_client, puedo ver el 1024bit prime (ffffff ffffffffffc90f … 5381ffffffffffffffff) al conectarse a un servidor JSSE de Java 8:
>openssl s_client -msg -cipher DHE-RSA-AES128-SHA256 -connect localhost:1234
...
<<< TLS 1.2 Handshake [length 018f], ServerKeyExchange
0c 00 01 8b 00 80 ff ff ff ff ff ff ff ff c9 0f
da a2 21 68 c2 34 c4 c6 62 8b 80 dc 1c d1 29 02
4e 08 8a 67 cc 74 02 0b be a6 3b 13 9b 22 51 4a
08 79 8e 34 04 dd ef 95 19 b3 cd 3a 43 1b 30 2b
0a 6d f2 5f 14 37 4f e1 35 6d 6d 51 c2 45 e4 85
b5 76 62 5e 7e c6 f4 4c 42 e9 a6 37 ed 6b 0b ff
5c b6 f4 06 b7 ed ee 38 6b fb 5a 89 9f a5 ae 9f
24 11 7c 4b 1f e6 49 28 66 51 ec e6 53 81 ff ff
ff ff ff ff ff ff 00 01 02 ...
En lugar de esto, debe ver sus parámetros personalizados cuando se instalan.
Los parámetros predeterminados para Java 7 (768bit) serían “e9e642 … 7a3daf” con un generador largo “30470ad..529252” como se define en ParameterCache.
Solución 3:
He estado pasando por el mismo problema, pero de Glassfish.
En primer lugar, recomendaría (si puede) poner algún tipo de proxy inverso frente a su servidor JBoss, ya que eliminará el enlace entre la seguridad de cifrado / certificado y la versión de Java que está ejecutando.
Para obtener una longitud de clave DH efímera mayor que 768 bits, debe ejecutar Java 8. 1024 es el nuevo valor predeterminado, y puede ir hasta 2048 utilizando el jdk.tls.ephemeralDHKeySize (detalles: personalización de claves DH). Por lo que pude encontrar, no existe el concepto de regenerar los parámetros clave por separado en Java.