Pourquoi la négociation SSL donne-t-elle une exception 'Impossible de générer la paire de clés DH'?
Lorsque je crée une connexion SSL avec certains serveurs IRC (mais pas d'autres - probablement à cause de la méthode de cryptage préférée du serveur), j'obtiens l'exception suivante:
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
Cause finale:
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 exemple de serveur illustrant ce problème est aperture.esper.net:6697 (il s’agit d’un serveur IRC). Kornbluth.freenode.net:6697 est un exemple de serveur qui ne démontre pas le problème. [Sans surprise, tous les serveurs de chaque réseau partagent le même comportement respectif.]
Mon code (qui, comme indiqué, fonctionne lors de la connexion à certains serveurs SSL) est le suivant:
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();
C'est ce dernier startHandshake qui lève l'exception. Et oui, il y a de la magie avec les 'trustAllCerts'; ce code oblige le système SSL à ne pas valider les certificats. (Alors ... pas un problème de cert.)
Une possibilité est évidemment que le serveur esper soit mal configuré, mais j'ai cherché et n'ai trouvé aucune autre référence à des personnes ayant des problèmes avec les ports SSL d'esper, et 'openssl' s'y connecte (voir ci-dessous). Je me demande donc s’il s’agit d’une limitation de Java prise en charge par défaut de SSL, ou de quelque chose du genre. Aucune suggestion?
Voici ce qui se passe lorsque je me connecte à aperture.esper.net 6697 en utilisant 'openssl' à partir de la ligne de commande:
~ $ 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)
---
Comme indiqué, après tout cela, il se connecte avec succès, ce qui est plus que ce que vous pouvez dire pour mon application Java.
Si cela est pertinent, j'utilise OS X 10.6.8, Java version 1.6.0_26.
Le problème est la taille principale. La taille maximale acceptable acceptée par Java est de 1024 bits. Il s'agit d'un problème connu (voir JDK-6521495 ).
Le rapport de bogue que j'ai lié à mentionne un solution de contournement en utilisant l'implémentation JCE de BouncyCastle. Espérons que cela devrait fonctionner pour vous.
UPDATE
Cela a été rapporté comme un bug JDK-704406 et corrigé récemment.
Notez cependant que la limite n'a été élevée qu'à 2048 bits. Pour les tailles> 2048 bits, il existe JDK-8072452 - Supprimer la taille initiale maximale des touches DH ; le correctif semble être pour 9.
La réponse "Fichiers de stratégie juridictionnelle à portée illimitée JCE (Java Cryptography Extension)" ne fonctionnait pas pour moi, contrairement à la suggestion du fournisseur JCE de BouncyCastle.
Voici les étapes que j'ai suivies avec Java 1.6.0_65-b14-462 sur Mac OS 10.7.5
1) Téléchargez ces pots:
2) déplacez ces fichiers jar dans $ Java_HOME/lib/ext
3) éditez $ Java_HOME/lib/security/Java.security comme suit: security.provider.1 = org.bouncycastle.jce.provider.BouncyCastleProvider
redémarrer l'application en utilisant JRE et l'essayer
Voici ma solution (Java 1.6), je serais également intéressé par la raison pour laquelle je devais le faire:
Javax.security.debug = ssl, j’ai remarqué que parfois la suite de chiffrement utilisée est TLS_DHE _... et parfois TLS_ECDHE _.... La dernière se produirait si j’ ajoutais BouncyCastle. Si TLS_ECDHE_ était sélectionné, la plupart du temps, mais pas TOUJOURS, l'ajout même du fournisseur BouncyCastle n'était pas fiable (échec avec la même erreur, environ une fois sur deux). Je suppose que quelque part dans l’implémentation Sun SSL, parfois il choisit DHE, parfois il choisit ECDHE.
La solution publiée ici repose donc sur la suppression complète des chiffrements TLS_DHE_. REMARQUE: BouncyCastle n'est PAS requis pour la solution.
Créez donc le fichier de certification du serveur en:
echo |openssl s_client -connect example.org:443 2>&1 |sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
Enregistrez ceci car il sera référencé plus tard, voici la solution pour un get http SSL, à l’exclusion des suites de chiffrement 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));
}
}
}
Enfin, voici comment il est utilisé (certFilePath si le chemin du certificat enregistré depuis 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();
}
La réponse ci-dessus est correcte, mais en ce qui concerne la solution de contournement, j'ai rencontré des problèmes avec l'implémentation de BouncyCastle lorsque je l'ai configurée comme fournisseur préféré:
Java.lang.ArrayIndexOutOfBoundsException: 64
at com.Sun.crypto.provider.TlsPrfGenerator.expand(DashoA13*..)
Ceci est également discuté dans un fil de discussion que j'ai trouvé, qui ne mentionne pas de solution. http://www.javakb.com/Uwe/Forum.aspx/Java-programmer/47512/TLS-problems
J'ai trouvé une solution alternative qui fonctionne pour mon cas, bien que cela ne me plaise pas du tout. La solution consiste à le configurer de sorte que l'algorithme Diffie-Hellman ne soit pas disponible du tout. Ensuite, en supposant que le serveur prenne en charge un algorithme alternatif, il effectuera la sélection lors de la négociation normale. Évidemment, l'inconvénient est que, si quelqu'un parvient à trouver un serveur ne prenant en charge que Diffie-Hellman en 1024 bits ou moins, cela signifie en réalité que cela ne fonctionnera pas comme avant.
Voici le code qui fonctionne avec un SSLSocket (avant de le connecter):
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()]));
Méchant.
Vous pouvez désactiver complètement DHE dans votre jdk, éditer jre/lib/security/Java.security et vous assurer que DHE est désactivé, par exemple. comme
jdk.tls.disabledAlgorithms=SSLv3, DHE.
Vous pouvez installer le fournisseur de manière dynamique:
1) Téléchargez ces pots:
bcprov-jdk15on-152.jarbcprov-ext-jdk15on-152.jar
2) Copier les fichiers jar dans WEB-INF/lib (ou votre chemin de classe)
3) Ajouter le fournisseur de manière dynamique:
import org.bouncycastle.jce.provider.BouncyCastleProvider;
...
Security.addProvider(new BouncyCastleProvider());
Ceci est un article assez ancien, mais si vous utilisez HTTPD Apache, vous pouvez limiter la taille DH. Voir http://httpd.Apache.org/docs/current/ssl/ssl_faq.html#javadh
Si vous utilisez jdk1.7.0_04, effectuez une mise à niveau vers jdk1.7.0_21. Le problème a été corrigé dans cette mise à jour.
Essayez de télécharger "Fichiers de règles juridictionnelles de compétence illimitée de JCE (Java Cryptography Extension)" à partir du site de téléchargement Java et de remplacer les fichiers de votre JRE.
Cela a fonctionné pour moi et je n'ai même pas eu besoin d'utiliser BouncyCastle - le standard Sun JCE était capable de se connecter au serveur.
PS J'ai eu la même erreur (ArrayIndexOutOfBoundsException: 64) lorsque j'ai essayé d'utiliser BouncyCastle avant de modifier les fichiers de stratégie. Il semble donc que notre situation est très similaire.
Si vous êtes toujours piqué par ce problème ET, vous utilisez Apache httpd v> 2.4.7, essayez ceci: http://httpd.Apache.org/docs/current/ssl/ssl_faq.html#javadh
copié à partir de l'URL :
À partir de la version 2.4.7, mod_ssl utilisera des paramètres DH qui incluent des nombres premiers d'une longueur supérieure à 1024 bits. Java 7 et versions antérieures limitent toutefois leur prise en charge des tailles principales DH à un maximum de 1024 bits.
Si votre client Java abandonne avec des exceptions telles que Java.lang.RuntimeException: impossible de générer la paire de clés DH et Java.security.InvalidAlgorithmParameterException: la taille principale doit être multiple de 64 et ne peut se situer que entre 512 et 1024 (inclus), et httpd enregistre une erreur interne de l'alerte tlsv1 (numéro d'alerte SSL 80) (au niveau des informations de LogLevel ou plus), vous pouvez réorganiser la liste de chiffrement de mod_ssl avec SSLCipherSuite (éventuellement en association avec SSLHonorCipherOrder), ou vous pouvez utiliser des paramètres DH personnalisés , qui aura toujours priorité sur les paramètres DH intégrés.
Pour générer des paramètres DH personnalisés, utilisez le
openssl dhparam 1024
commander. Sinon, vous pouvez utiliser les paramètres DH standard à 1024 bits suivants de la RFC 2409, section 6.2:
-----BEGIN DH PARAMETERS-----
MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL
/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC
-----END DH PARAMETERS-----
Ajoutez les paramètres personnalisés, y compris les lignes "BEGIN DH PARAMETERS" et "END DH PARAMETERS" à la fin du premier fichier de certificat que vous avez configuré à l'aide de la directive SSLCertificateFile.
J'utilise Java 1.6 sur le côté client et le problème a été résolu. Je n'ai pas abaissé les suites de chiffrement, mais ajouté un paramètre DH généré personnalisé au fichier cert.
Il est possible que vous ayez des dépendances Maven incorrectes. Vous devez trouver ces bibliothèques dans la hiérarchie de dépendances Maven:
bcprov-jdk14, bcpkix-jdk14, bcmail-jdk14
Si vous avez ces dépendances c'est l'erreur, et vous devriez faire ceci:
Ajoutez la dépendance:
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcmail-jdk15on</artifactId>
<version>1.59</version>
</dependency>
Excluez ces dépendances de l'artefact contenant les mauvaises dépendances. Dans mon cas, il s'agit de:
<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>
J'ai le même problème avec le serveur Yandex Maps, JDK 1.6 et Apache HttpClient 4.2.1. L'erreur était
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
avec le débogage activé par -Djavax.net.debug=all il y avait un message dans un journal
Could not generate DH keypair
J'ai résolu ce problème en ajoutant la bibliothèque BouncyCastle bcprov-jdk16-1.46.jar et en enregistrant un fournisseur dans une classe de service de carte.
public class MapService {
static {
Security.addProvider(new BouncyCastleProvider());
}
public GeocodeResult geocode() {
}
}
Un fournisseur est enregistré lors de la première utilisation de MapService.
J'utilise coldfusion 8 sur JDK 1.6.45 et je ne pouvais pas me connecter avec des croix rouges, mais aussi avec cfhttp, incapable de se connecter au serveur Web local avec ssl.
mon script de test pour reproduire avec coldfusion 8 était
<CFHTTP URL="https://www.onlineumfragen.com" METHOD="get" ></CFHTTP>
<CFDUMP VAR="#CFHTTP#">
cela m'a donné l'erreur assez générique de "Exception E/S: homologue non authentifié." J'ai ensuite essayé d'ajouter des certificats du serveur, y compris des certificats racine et intermédiaires, au fichier de clés Java ainsi qu'au fichier de clés coldfusion, mais rien n'y fait. alors j'ai débogué le problème avec
Java SSLPoke www.onlineumfragen.com 443
et j'ai
javax.net.ssl.SSLException: Java.lang.RuntimeException: Could not generate DH keypair
et
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
J'ai alors eu l’idée que le serveur Web (Apache dans mon cas) avait des chiffrements très modernes pour ssl et qu’il était assez restrictif (qualys score a +) et utilisait de fortes clés diffie hellmann de plus de 1024 bits. évidemment, coldfusion et Java jdk 1.6.45 ne peuvent pas gérer cela. La prochaine étape dans l'odysee était de penser à installer un fournisseur de sécurité alternatif pour Java, et j'ai opté pour un château gonflable. voir aussi http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-Eclipse-for-Java-jse- projets /
J'ai ensuite téléchargé le
bcprov-ext-jdk15on-156.jar
à partir de http://www.bouncycastle.org/latest_releases.html et l’a installé sous C:\jdk6_45\jre\lib\ext ou n’importe où se trouve votre jdk, lors de l’installation initiale de coldfusion 8 être sous C:\JRun4\jre\lib\ext mais j'utilise un jdk plus récent (1.6.45) situé en dehors du répertoire coldfusion. il est très important de placer le fichier bcprov-ext-jdk15on-156.jar dans le répertoire\ext (cela m’a coûté environ deux heures et quelques cheveux ;-) puis j’ai édité le fichier C:\jdk6_45\jre\lib\security\Java.security (avec wordpad pas avec editor.exe!) Et mettez une ligne pour le nouveau fournisseur. ensuite, la liste ressemblait à
#
# 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
(voir le nouveau en position 1)
puis redémarrez complètement le service coldfusion. vous pouvez alors
Java SSLPoke www.onlineumfragen.com 443 (or of course your url!)
et profiter de la sensation ... et bien sûr
quelle nuit et quelle journée. Espérons que cela aidera (partiellement ou totalement) quelqu'un. si vous avez des questions, écrivez-moi à info ... (domaine ci-dessus).
J'ai rencontré l'erreur SSL sur un serveur CentOS exécutant JDK 6.
Mon plan était d'installer une version plus récente du JDK (JDK 7) afin de coexister avec le JDK 6, mais il s'avère que la simple installation du nouveau JDK avec rpm -i ne suffisait pas.
L'installation de JDK 7 ne réussirait qu'avec l'option de mise à niveau rpm -U, comme illustré ci-dessous.
1. Télécharger 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. L'installation de RPM échoue
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 mise à jour de RPM réussit
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. Confirmez la nouvelle version
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)
Résolu le problème en mettant à niveau JDK 8.
Nous avons eu exactement la même erreur d’exception, mais il était facile de régler le problème après des heures passées à surfer sur Internet.
Nous avons téléchargé la version la plus récente de jdk que nous avons pu trouver sur Oracle.com, l'avons installée et fait pointer le serveur d'applications Jboss vers le répertoire du nouveau jdk installé.
Jboss redémarré, retraité, problème résolu !!!
J'avais l'habitude d'obtenir une erreur similaire lors de l'accès à svn.Apache.org avec Java clients SVN à l'aide d'un JDK IBM. Actuellement, svn.Apache.org utilise les préférences de chiffrement des clients.
Après avoir exécuté une seule fois avec une capture de paquet/javax.net.debug = ALL, j'ai été en mesure de répertorier un seul chiffre DHE et les choses fonctionnent pour moi (ECDHE est négocié à la place).
.../Java/jre/lib/security/Java.security:
jdk.tls.disabledAlgorithms=SSL_DHE_RSA_WITH_AES_256_CBC_SHA
Une solution rapide quand il n'est pas facile de changer de client.
Récemment, j'ai le même problème et après la mise à niveau de la version jdk de 1.6.0_45 à jdk1.7.0_191 qui a résolu le problème.
J'ai cette erreur avec Bamboo 5.7 + projet Gradle + Apache. Gradle a essayé d’obtenir des dépendances de l’un de nos serveurs via SSL.
Solution:
- Générer DH Param:
avec OpenSSL:
openssl dhparam 1024
exemple de sortie:
-----BEGIN DH PARAMETERS-----
MIGHfoGBALxpfMrDpImEuPlhopxYX4L2CFqQov+FomjKyHJrzj/EkTP0T3oAkjnS
oCGh6p07kwSLS8WCtYJn1GzItiZ05LoAzPs7T3ST2dWrEYFg/dldt+arifj6oWo+
vctDyDqIjlevUE+vyR9MF6B+Rfm4Zs8VGkxmsgXuz0gp/9lmftY7AgEC
-----END DH PARAMETERS-----
Ajouter la sortie au fichier de certificat (pour Apache -
SSLCertificateFileparam)Redémarrer Apache
Redémarrer Bamboo
Essayer de reconstruire le projet
Si le serveur prend en charge un chiffrement n'incluant pas DH, vous pouvez forcer le client à sélectionner ce chiffrement et éviter l'erreur DH. Tel que:
String pickedCipher[] ={"TLS_RSA_WITH_AES_256_CBC_SHA"};
sslsocket.setEnabledCipherSuites(pickedCipher);
Gardez à l'esprit que la spécification d'un chiffre exact est susceptible de se briser à long terme.