solucion - Java: ¿Por qué el protocolo de enlace SSL da la excepción ''No se pudo generar el par de llaves DH''?
introduzca la contraseña del almacen de claves keytool (20)
Cuando hago una conexión SSL con algunos servidores IRC (pero no a otros, presumiblemente debido al método de cifrado preferido del servidor) obtengo la siguiente excepción:
Caused by: java.lang.RuntimeException: Could not generate DH keypair
at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:106)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:556)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:183)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:893)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
... 3 more
Causa final:
Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)
at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:100)
... 10 more
Un ejemplo de un servidor que demuestra este problema es aperture.esper.net:6697 (este es un servidor IRC). Un ejemplo de un servidor que no demuestra el problema es kornbluth.freenode.net:6697. [No es sorprendente que todos los servidores en cada red compartan el mismo comportamiento respectivo.]
Mi código (que como se indica funciona cuando se conecta a algunos servidores SSL) es:
SSLContext sslContext = SSLContext.getInstance("SSL");
sslContext.init(null, trustAllCerts, new SecureRandom());
s = (SSLSocket)sslContext.getSocketFactory().createSocket();
s.connect(new InetSocketAddress(host, port), timeout);
s.setSoTimeout(0);
((SSLSocket)s).startHandshake();
Es el último inicio de Handshake que arroja la excepción. Y sí, hay algo de magia con ''trustAllCerts''; ese código obliga al sistema SSL a no validar certs. (Entonces ... no es un problema de certificación)
Obviamente, una posibilidad es que el servidor de ESP esté mal configurado, pero busqué y no encontré ninguna otra referencia a las personas que tienen problemas con los puertos SSL de ESPer, y se conecta a él (ver a continuación). Así que me pregunto si esto es una limitación del soporte SSL predeterminado de Java, o algo así. ¿Alguna sugerencia?
Esto es lo que sucede cuando me conecto a aperture.esper.net 6697 usando ''openssl'' desde la línea de comandos:
~ $ openssl s_client -connect aperture.esper.net:6697
CONNECTED(00000003)
depth=0 /C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
verify return:1
---
Certificate chain
0 s:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
i:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
---
Server certificate
-----BEGIN CERTIFICATE-----
[There was a certificate here, but I deleted it to save space]
-----END CERTIFICATE-----
subject=/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
issuer=/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/[email protected]
---
No client certificate CA names sent
---
SSL handshake has read 2178 bytes and written 468 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 51F1D40A1B044700365D3BD1C61ABC745FB0C347A334E1410946DCB5EFE37AFD
Session-ID-ctx:
Master-Key: DF8194F6A60B073E049C87284856B5561476315145B55E35811028C4D97F77696F676DB019BB6E271E9965F289A99083
Key-Arg : None
Start Time: 1311801833
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
Como se señaló, después de todo eso, se conecta con éxito, que es más de lo que puede decir para mi aplicación Java.
Si es relevante, estoy usando OS X 10.6.8, Java versión 1.6.0_26.
Aquí está mi solución (java 1.6), también estaría interesado por qué tenía que hacer esto:
Me di cuenta de javax.security.debug = ssl, que a veces el paquete de cifrado utilizado es TLS_DHE _... y en algún momento es TLS_ECDHE _.... Lo último ocurriría si añadiera BouncyCastle. Si se seleccionó TLS_ECDHE_, LA MAYORÍA DE las veces funcionó, pero no SIEMPRE, por lo que agregar incluso el proveedor BouncyCastle no era confiable (falló con el mismo error, en otro momento más o menos). Supongo que en algún lugar de la implementación de Sun SSL a veces elige DHE , a veces elige ECDHE .
Entonces la solución publicada aquí se basa en eliminar TLS_DHE_ cifras por completo. NOTA: BouncyCastle NO es necesario para la solución.
Así que crea el archivo de certificación del servidor de la siguiente manera:
echo |openssl s_client -connect example.org:443 2>&1 |sed -ne ''/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p''
Guárdelo como se hará referencia más adelante, que aquí está la solución para un HTTP http obtener, excluyendo las suites de cifrado TLS_DHE_.
package org.example.security;
import java.io.BufferedInputStream;
import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.InetAddress;
import java.net.Socket;
import java.net.URL;
import java.net.UnknownHostException;
import java.security.KeyStore;
import java.security.cert.Certificate;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
import java.util.ArrayList;
import java.util.List;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLParameters;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSocketFactory;
import javax.net.ssl.TrustManagerFactory;
import org.apache.log4j.Logger;
public class SSLExcludeCipherConnectionHelper {
private Logger logger = Logger.getLogger(SSLExcludeCipherConnectionHelper.class);
private String[] exludedCipherSuites = {"_DHE_","_DH_"};
private String trustCert = null;
private TrustManagerFactory tmf;
public void setExludedCipherSuites(String[] exludedCipherSuites) {
this.exludedCipherSuites = exludedCipherSuites;
}
public SSLExcludeCipherConnectionHelper(String trustCert) {
super();
this.trustCert = trustCert;
//Security.addProvider(new BouncyCastleProvider());
try {
this.initTrustManager();
} catch (Exception ex) {
ex.printStackTrace();
}
}
private void initTrustManager() throws Exception {
CertificateFactory cf = CertificateFactory.getInstance("X.509");
InputStream caInput = new BufferedInputStream(new FileInputStream(trustCert));
Certificate ca = null;
try {
ca = cf.generateCertificate(caInput);
logger.debug("ca=" + ((X509Certificate) ca).getSubjectDN());
} finally {
caInput.close();
}
// Create a KeyStore containing our trusted CAs
KeyStore keyStore = KeyStore.getInstance("jks");
keyStore.load(null, null);
keyStore.setCertificateEntry("ca", ca);
// Create a TrustManager that trusts the CAs in our KeyStore
String tmfAlgorithm = TrustManagerFactory.getDefaultAlgorithm();
tmf = TrustManagerFactory.getInstance(tmfAlgorithm);
tmf.init(keyStore);
}
public String get(URL url) throws Exception {
// Create an SSLContext that uses our TrustManager
SSLContext context = SSLContext.getInstance("TLS");
context.init(null, tmf.getTrustManagers(), null);
SSLParameters params = context.getSupportedSSLParameters();
List<String> enabledCiphers = new ArrayList<String>();
for (String cipher : params.getCipherSuites()) {
boolean exclude = false;
if (exludedCipherSuites != null) {
for (int i=0; i<exludedCipherSuites.length && !exclude; i++) {
exclude = cipher.indexOf(exludedCipherSuites[i]) >= 0;
}
}
if (!exclude) {
enabledCiphers.add(cipher);
}
}
String[] cArray = new String[enabledCiphers.size()];
enabledCiphers.toArray(cArray);
// Tell the URLConnection to use a SocketFactory from our SSLContext
HttpsURLConnection urlConnection =
(HttpsURLConnection)url.openConnection();
SSLSocketFactory sf = context.getSocketFactory();
sf = new DOSSLSocketFactory(sf, cArray);
urlConnection.setSSLSocketFactory(sf);
BufferedReader in = new BufferedReader(new InputStreamReader(urlConnection.getInputStream()));
String inputLine;
StringBuffer buffer = new StringBuffer();
while ((inputLine = in.readLine()) != null)
buffer.append(inputLine);
in.close();
return buffer.toString();
}
private class DOSSLSocketFactory extends javax.net.ssl.SSLSocketFactory {
private SSLSocketFactory sf = null;
private String[] enabledCiphers = null;
private DOSSLSocketFactory(SSLSocketFactory sf, String[] enabledCiphers) {
super();
this.sf = sf;
this.enabledCiphers = enabledCiphers;
}
private Socket getSocketWithEnabledCiphers(Socket socket) {
if (enabledCiphers != null && socket != null && socket instanceof SSLSocket)
((SSLSocket)socket).setEnabledCipherSuites(enabledCiphers);
return socket;
}
@Override
public Socket createSocket(Socket s, String host, int port,
boolean autoClose) throws IOException {
return getSocketWithEnabledCiphers(sf.createSocket(s, host, port, autoClose));
}
@Override
public String[] getDefaultCipherSuites() {
return sf.getDefaultCipherSuites();
}
@Override
public String[] getSupportedCipherSuites() {
if (enabledCiphers == null)
return sf.getSupportedCipherSuites();
else
return enabledCiphers;
}
@Override
public Socket createSocket(String host, int port) throws IOException,
UnknownHostException {
return getSocketWithEnabledCiphers(sf.createSocket(host, port));
}
@Override
public Socket createSocket(InetAddress address, int port)
throws IOException {
return getSocketWithEnabledCiphers(sf.createSocket(address, port));
}
@Override
public Socket createSocket(String host, int port, InetAddress localAddress,
int localPort) throws IOException, UnknownHostException {
return getSocketWithEnabledCiphers(sf.createSocket(host, port, localAddress, localPort));
}
@Override
public Socket createSocket(InetAddress address, int port,
InetAddress localaddress, int localport) throws IOException {
return getSocketWithEnabledCiphers(sf.createSocket(address, port, localaddress, localport));
}
}
}
Finalmente, aquí está cómo se usa (certFilePath si la ruta del certificado se guardó de openssl):
try {
URL url = new URL("https://www.example.org?q=somedata");
SSLExcludeCipherConnectionHelper sslExclHelper = new SSLExcludeCipherConnectionHelper(certFilePath);
logger.debug(
sslExclHelper.get(url)
);
} catch (Exception ex) {
ex.printStackTrace();
}
El problema es el tamaño principal. El tamaño máximo aceptable que acepta Java es de 1024 bits. Este es un problema conocido (ver JDK-6521495 ).
El informe de errores al que me he vinculado menciona una workaround mediante la implementación de JCE de BouncyCastle. Espero que eso funcione para ti.
ACTUALIZAR
Esto se informó como error JDK-7044060 y se ha solucionado recientemente.
Tenga en cuenta, sin embargo, que el límite solo se elevó a 2048 bits. Para tamaños> 2048 bit, existe JDK-8072452 - Elimine el tamaño máximo de las claves DH ; la solución parece ser para 9.
Encontré el error de SSL en un servidor de CentOS con JDK 6.
Mi plan era instalar una versión JDK más alta (JDK 7) para que coexistiera con JDK 6, pero resultó que simplemente instalar el JDK más nuevo con rpm -i no era suficiente.
La instalación del JDK 7 solo tendrá éxito con la opción de actualización rpm -U como se ilustra a continuación.
1. Descargar JDK 7
wget -O /root/jdk-7u79-linux-x64.rpm --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F; o raclelicense=accept-securebackup-cookie" "http://download.oracle.com/otn-pub/java/jdk/7u79-b15/jdk-7u79-linux-x64.rpm"
2. La instalación de RPM falla
rpm -ivh jdk-7u79-linux-x64.rpm
Preparing... ########################################### [100%]
file /etc/init.d/jexec from install of jdk-2000:1.7.0_79-fcs.x86_64 conflicts with file from package jdk-2000:1.6.0_43-fcs.x86_64
3. La actualización de RPM tiene éxito
rpm -Uvh jdk-7u79-linux-x64.rpm
Preparing... ########################################### [100%]
1:jdk ########################################### [100%]
Unpacking JAR files...
rt.jar...
jsse.jar...
charsets.jar...
tools.jar...
localedata.jar...
jfxrt.jar...
4. Confirma la nueva versión
java -version
java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
Es posible que tenga dependencias Maven incorrectas. Debe encontrar estas bibliotecas en la jerarquía de dependencias de Maven:
bcprov-jdk14, bcpkix-jdk14, bcmail-jdk14
Si tiene estas dependencias, ese es el error, y debe hacer esto:
Agrega la dependencia:
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcmail-jdk15on</artifactId>
<version>1.59</version>
</dependency>
Excluya estas dependencias del artefacto que incluía las dependencias incorrectas, en mi caso es:
<dependency>
<groupId>com.lowagie</groupId>
<artifactId>itext</artifactId>
<version>2.1.7</version>
<exclusions>
<exclusion>
<groupId>org.bouncycastle</groupId>
<artifactId>bctsp-jdk14</artifactId>
</exclusion>
<exclusion>
<groupId>bouncycastle</groupId>
<artifactId>bcprov-jdk14</artifactId>
</exclusion>
<exclusion>
<groupId>bouncycastle</groupId>
<artifactId>bcmail-jdk14</artifactId>
</exclusion>
</exclusions>
</dependency>
Esta es una publicación bastante antigua, pero si usa Apache HTTPD, puede limitar el tamaño de DH. Ver http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh
Intente descargar "Archivos de políticas de jurisdicción de fuerza ilimitada de Java Cryptography Extension (JCE)" del sitio de descarga de Java y reemplace los archivos en su JRE.
Esto funcionó para mí y ni siquiera tuve que usar BouncyCastle: el Sun JCE estándar podía conectarse al servidor.
PD. Obtuve el mismo error (ArrayIndexOutOfBoundsException: 64) cuando intenté usar BouncyCastle antes de cambiar los archivos de política, por lo que parece que nuestra situación es muy similar.
La respuesta "Expediente de criptografía de Java (JCE) Archivos de política de jurisdicción de fuerza ilimitada" no funcionó, pero la sugerencia del proveedor de JCE de BouncyCastle sí.
Aquí están los pasos que tomé usando Java 1.6.0_65-b14-462 en Mac OSC 10.7.5
1) Descarga estos frascos:
2) mover estos archivos jar a $ JAVA_HOME / lib / ext
3) edite $ JAVA_HOME / lib / security / java.security de la siguiente manera: security.provider.1 = org.bouncycastle.jce.provider.BouncyCastleProvider
reinicia la aplicación usando JRE y pruébalo
La respuesta anterior es correcta, pero en términos de la solución alternativa, tuve problemas con la implementación de BouncyCastle cuando la configuré como proveedor preferido:
java.lang.ArrayIndexOutOfBoundsException: 64
at com.sun.crypto.provider.TlsPrfGenerator.expand(DashoA13*..)
Esto también se discute en un hilo del foro que encontré, que no menciona una solución. http://www.javakb.com/Uwe/Forum.aspx/java-programmer/47512/TLS-problems
Encontré una solución alternativa que funciona para mi caso, aunque no estoy nada contento con ella. La solución es configurarlo de modo que el algoritmo Diffie-Hellman no esté disponible en absoluto. Entonces, suponiendo que el servidor admite un algoritmo alternativo, se seleccionará durante la negociación normal. Obviamente, la desventaja de esto es que si alguien de alguna manera logra encontrar un servidor que solo admita Diffie-Hellman a 1024 bits o menos, entonces esto realmente significa que no funcionará donde antes funcionaba.
Aquí está el código que funciona dado un SSLSocket (antes de conectarlo):
List<String> limited = new LinkedList<String>();
for(String suite : ((SSLSocket)s).getEnabledCipherSuites())
{
if(!suite.contains("_DHE_"))
{
limited.add(suite);
}
}
((SSLSocket)s).setEnabledCipherSuites(limited.toArray(
new String[limited.size()]));
Asqueroso.
Para mí, la siguiente línea de comando solucionó el problema:
java -jar -Dhttps.protocols=TLSv1.2 -Ddeployment.security.TLSv1.2=true -Djavax.net.debug=ssl:handshake XXXXX.jar
Estoy usando JDK 1.7.0_79
Puede desactivar DHE por completo en su jdk, editar jre / lib / security / java.security y asegurarse de que DHE esté desactivado, por ej. me gusta
jdk.tls.disabledAlgorithms=SSLv3, DHE .
Puede instalar el proveedor de forma dinámica:
1) Descarga estos frascos:
-
bcprov-jdk15on-152.jar -
bcprov-ext-jdk15on-152.jar
2) Copie jar a WEB-INF/lib (o su classpath)
3) Agregar proveedor de forma dinámica:
import org.bouncycastle.jce.provider.BouncyCastleProvider;
...
Security.addProvider(new BouncyCastleProvider());
Recibimos el mismo error de excepción exacto devuelto, para solucionarlo fue fácil después de horas navegando por Internet.
Descargamos la versión más alta de jdk que pudimos encontrar en oracle.com, la instalamos y apuntábamos al servidor de aplicaciones Jboss al directorio de la nueva jdk instalada.
Reiniciado Jboss, reprocesado, solucionado el problema !!!
Resolvió el problema actualizando a JDK 8.
Si el servidor admite un cifrado que no incluye DH, puede forzar al cliente a seleccionar ese cifrado y evitar el error DH. Como:
String pickedCipher[] ={"TLS_RSA_WITH_AES_256_CBC_SHA"};
sslsocket.setEnabledCipherSuites(pickedCipher);
Tenga en cuenta que especificar un cifrado exacto es propenso a la rotura a largo plazo.
Si está utilizando jdk1.7.0_04, actualice a jdk1.7.0_21. El problema ha sido arreglado en esa actualización.
Si todavía está mordido por este problema Y está utilizando Apache httpd v> 2.4.7, intente esto: http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh
copiado de la url :
A partir de la versión 2.4.7, mod_ssl usará parámetros DH que incluyen números primos con longitudes de más de 1024 bits. Sin embargo, Java 7 y versiones anteriores limitan su compatibilidad con tamaños de primers DH a un máximo de 1024 bits.
Si su cliente basado en Java aborta con excepciones tales como java.lang.RuntimeException: No se pudo generar el par de llaves DH y java.security.InvalidAlgorithmParameterException: el tamaño principal debe ser múltiplo de 64, y solo puede variar de 512 a 1024 (inclusive), y httpd registra error interno de alerta tlsv1 (número de alerta SSL 80) (en LogLevel info o superior), puede reorganizar la lista de cifrado de mod_ssl con SSLCipherSuite (posiblemente en conjunción con SSLHonorCipherOrder), o puede usar parámetros DH personalizados con un primo de 1024 bits , que siempre tendrá prioridad sobre cualquiera de los parámetros DH incorporados.
Para generar parámetros DH personalizados, use la
openssl dhparam 1024
mando. Alternativamente, puede usar los siguientes parámetros DH estándar de 1024 bits de RFC 2409, sección 6.2:
-----BEGIN DH PARAMETERS-----
MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL
/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC
-----END DH PARAMETERS-----
Agregue los parámetros personalizados, incluidas las líneas "BEGIN DH DH PARAMETERS" y "END DH PARAMETERS", al final del primer archivo de certificado que haya configurado con la directiva SSLCertificateFile.
Estoy usando Java 1.6 en el lado del cliente, y resolvió mi problema. No bajé las suites de cifrado ni me gustó, pero agregué un param DH personalizado generado al archivo cert.
Solía obtener un error similar al acceder a svn.apache.org con clientes java SVN utilizando un IBM JDK. Actualmente, los usuarios de svn.apache.org las preferencias de cifrado de los clientes.
Después de ejecutar solo una vez con un paquete de captura / javax.net.debug = TODO, pude poner en lista negra solo un solo cifrado DHE y las cosas funcionan para mí (ECDHE se negocia en su lugar).
.../java/jre/lib/security/java.security:
jdk.tls.disabledAlgorithms=SSL_DHE_RSA_WITH_AES_256_CBC_SHA
Una buena solución rápida cuando no es fácil cambiar el cliente.
Tengo el mismo problema con el servidor Yandex Maps, JDK 1.6 y Apache HttpClient 4.2.1. El error fue
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
con depuración activada por -Djavax.net.debug=all había un mensaje en un registro
Could not generate DH keypair
Solucioné este problema añadiendo la biblioteca bcprov-jdk16-1.46.jar y registrando un proveedor en una clase de servicio de mapas
public class MapService {
static {
Security.addProvider(new BouncyCastleProvider());
}
public GeocodeResult geocode() {
}
}
Un proveedor se registra en el primer uso de MapService .
Tengo este error con Bamboo 5.7 + Proyecto Gradle + Apache. Gradle intentó obtener algunas dependencias de uno de nuestros servidores a través de SSL.
Solución:
- Generar DH Param:
con OpenSSL:
openssl dhparam 1024
ejemplo de salida:
-----BEGIN DH PARAMETERS-----
MIGHfoGBALxpfMrDpImEuPlhopxYX4L2CFqQov+FomjKyHJrzj/EkTP0T3oAkjnS
oCGh6p07kwSLS8WCtYJn1GzItiZ05LoAzPs7T3ST2dWrEYFg/dldt+arifj6oWo+
vctDyDqIjlevUE+vyR9MF6B+Rfm4Zs8VGkxmsgXuz0gp/9lmftY7AgEC
-----END DH PARAMETERS-----
Adjuntar salida al archivo de certificado (para Apache -
SSLCertificateFileparam)Reiniciar Apache
Reiniciar Bamboo
Intenta construir un proyecto de nuevo
Utilizo ColdFusion 8 en JDK 1.6.45 y tuve problemas para dar solo cruces rojas en lugar de imágenes, y también con cfhttp no poder conectarme al servidor web local con ssl.
mi script de prueba para reproducir con coldfusion 8 fue
<CFHTTP URL="https://www.onlineumfragen.com" METHOD="get" ></CFHTTP>
<CFDUMP VAR="#CFHTTP#">
esto me dio el error bastante genérico de "I / O Exception: peer not authenticated". Luego traté de agregar certificados del servidor, incluidos certificados raíz e intermedios, al almacén de claves de java y también al almacén de claves de coldfusion, pero no sirvió de nada. entonces depuré el problema con
java SSLPoke www.onlineumfragen.com 443
y consiguió
javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
y
Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be
multiple of 64, and can only range from 512 to 1024 (inclusive)
at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:107)
... 10 more
Luego tuve la idea de que el servidor web (apache en mi caso) tenía cifras muy modernas para ssl y es bastante restrictivo (calificación de qualys a +) y usa fuertes teclas diffman hellmann con más de 1024 bits. obviamente, coldfusion y java jdk 1.6.45 no pueden gestionar esto. El siguiente paso en el odysee fue pensar en instalar un proveedor de seguridad alternativo para Java, y decidí construir un castillo hinchable. ver también http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for-java-jse-projects/
Luego descargué el
bcprov-ext-jdk15on-156.jar
de http://www.bouncycastle.org/latest_releases.html y lo instaló en C: / jdk6_45 / jre / lib / ext o donde esté su jdk, en la instalación original de coldfusion 8 estaría bajo C: / JRun4 / jre / lib / ext pero utilizo un jdk más nuevo (1.6.45) ubicado fuera del directorio de coldfusion. es muy importante poner el bcprov-ext-jdk15on-156.jar en el directorio / ext (esto me costó unas dos horas y algo de pelo ;-) luego edité el archivo C: / jdk6_45 / jre / lib / security / java.security (con wordpad no con editor.exe!) y poner en una línea para el nuevo proveedor. luego la lista parecía
#
# List of providers and their preference orders (see above):
#
security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.mscapi.SunMSCAPI
(ver el nuevo en la posición 1)
luego reinicie el servicio ColdFusion por completo. puedes entonces
java SSLPoke www.onlineumfragen.com 443 (or of course your url!)
y disfruta de la sensación ... y por supuesto
qué noche y qué día. Espero que esto ayude (parcial o totalmente) a alguien allá afuera. si tiene alguna pregunta, solo envíeme un correo electrónico a la información ... (dominio de arriba).