Por que o handshake SSL fornece exceção ‘Não foi possível gerar keypair DH’?

Quando faço uma conexão SSL com alguns servidores de IRC (mas não outros – presumivelmente devido ao método de criptografia preferencial do servidor), recebo a seguinte exceção:

Caused by: java.lang.RuntimeException: Could not generate DH keypair at com.sun.net.ssl.internal.ssl.DHCrypt.(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.(DHCrypt.java:100) ... 10 more 

Um exemplo de um servidor que demonstra este problema é o aperture.esper.net:6697 (este é um servidor de IRC). Um exemplo de um servidor que não demonstra o problema é kornbluth.freenode.net:6697. [Não é de surpreender que todos os servidores em cada rede compartilhem o mesmo comportamento.]

Meu código (que, como observado, funciona ao se conectar a alguns servidores SSL) é:

  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(); 

É o último startHandshake que lança a exceção. E sim, há alguma mágica acontecendo com os ‘trustAllCerts’; esse código força o sistema SSL a não validar certificados. (Então … não é um problema de certificação)

Obviamente, uma possibilidade é que o servidor de esper esteja configurado incorretamente, mas eu procurei e não encontrei nenhuma outra referência a pessoas com problemas com as portas SSL do esper, e o ‘openssl’ se conecta a ele (veja abaixo). Então eu estou querendo saber se isso é uma limitação do suporte SSL padrão Java, ou algo assim. Alguma sugestão?

Aqui está o que acontece quando eu me conecto ao aperture.esper.net 6697 usando ‘openssl’ da linha de comando:

 ~ $ 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/emailAddress=support@esper.net 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/emailAddress=support@esper.net verify return:1 --- Certificate chain 0 s:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net i:/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net --- 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/emailAddress=support@esper.net issuer=/C=GB/ST=England/L=London/O=EsperNet/OU=aperture.esper.net/CN=*.esper.net/emailAddress=support@esper.net --- 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 observado, depois de tudo isso, ele se conecta com sucesso, o que é mais do que você pode dizer para o meu aplicativo Java.

Caso seja relevante, estou usando o OS X 10.6.8, Java versão 1.6.0_26.

O problema é o tamanho principal. O tamanho máximo aceitável que o Java aceita é de 1024 bits. Este é um problema conhecido (consulte JDK-6521495 ).

O relatório de bug que eu vinculei menciona uma solução alternativa usando a implementação JCE do BouncyCastle. Espero que isso funcione para você.

ATUALIZAR

Isto foi relatado como bug JDK-7044060 e corrigido recentemente.

Note, no entanto, que o limite só foi aumentado para 2048 bits. Para tamanhos> 2048 bits, há JDK-8072452 – Remova o tamanho máximo das chaves DH ; a correção parece ser para 9.

A resposta “Ficheiros de Política de Jurisdição de Força Ilimitada da Extensão de Criptografia Java (JCE)” não funcionou para mim, mas a sugestão do provedor JCE do BouncyCastle o fez.

Aqui estão os passos que tomei usando o Java 1.6.0_65-b14-462 no Mac OSC 10.7.5

1) Faça o download desses flasks:

  • bcprov-jdk15on-154.jar

  • bcprov-ext-jdk15on-154.jar

2) mova esses jars para $ JAVA_HOME / lib / ext

3) edite $ JAVA_HOME / lib / security / java.security da seguinte forma: security.provider.1 = org.bouncycastle.jce.provider.BouncyCastleProvider

reinicie o aplicativo usando o JRE e experimente

Aqui está a minha solução (java 1.6), também estaria interessada porque eu tive que fazer isso:

Eu notei a partir do javax.security.debug = ssl, que às vezes o conjunto de cifras usado é TLS_DHE _… e às vezes é TLS_ECDHE _…. O mais tardar aconteceria se eu adicionasse BouncyCastle. Se TLS_ECDHE_ foi selecionado, a maior parte do tempo que funcionou, mas não SEMPRE, então adicionar mesmo provedor BouncyCastle não era confiável (falha com o mesmo erro, todas as outras vezes). Eu acho que em algum lugar na implementação SSL da Sun às vezes ele escolhe DHE , às vezes ele escolhe ECDHE .

Portanto, a solução postada aqui depende da remoção completa de cifras TLS_DHE_. NOTA: BouncyCastle não é necessário para a solução.

Portanto, crie o arquivo de certificação do servidor por:

 echo |openssl s_client -connect example.org:443 2>&1 |sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' 

Salve isso, pois ele será mencionado mais tarde, do que aqui está a solução para um SSL http, excluindo os conjuntos de cifras 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 enabledCiphers = new ArrayList(); for (String cipher : params.getCipherSuites()) { boolean exclude = false; if (exludedCipherSuites != null) { for (int i=0; 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, aqui está como ele é usado (certFilePath se o caminho do certificado salvo do 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(); } 

A resposta acima está correta, mas em termos da solução alternativa, tive problemas com a implementação do BouncyCastle quando a configurei como o provedor preferencial:

 java.lang.ArrayIndexOutOfBoundsException: 64 at com.sun.crypto.provider.TlsPrfGenerator.expand(DashoA13*..) 

Isso também é discutido em um tópico do fórum que encontrei, que não menciona uma solução. http://www.javakb.com/Uwe/Forum.aspx/java-programmer/47512/TLS-problems

Eu encontrei uma solução alternativa que funciona para o meu caso, embora eu não esteja nada feliz com isso. A solução é configurá-lo para que o algoritmo Diffie-Hellman não esteja disponível. Então, supondo que o servidor suporte um algoritmo alternativo, ele estará selecionando durante a negociação normal. Obviamente, o lado negativo disso é que, se alguém de alguma forma consegue encontrar um servidor que suporte apenas o Diffie-Hellman a 1024 bits ou menos, isso significa que ele não funcionará onde costumava funcionar antes.

Aqui está o código que funciona dado um SSLSocket (antes de conectá-lo):

 List limited = new LinkedList(); for(String suite : ((SSLSocket)s).getEnabledCipherSuites()) { if(!suite.contains("_DHE_")) { limited.add(suite); } } ((SSLSocket)s).setEnabledCipherSuites(limited.toArray( new String[limited.size()])); 

Desagradável.

Você pode desabilitar completamente o DHE no seu jdk, editar jre / lib / security / java.security e certificar-se de que o DHE esteja desabilitado, por exemplo. gostar

jdk.tls.disabledAlgorithms=SSLv3, DHE .

Você pode instalar o provedor dinamicamente:

1) Faça o download desses flasks:

  • bcprov-jdk15on-152.jar
  • bcprov-ext-jdk15on-152.jar

2) Copie os flasks para WEB-INF/lib (ou seu classpath)

3) Adicionar provedor dinamicamente:

import org.bouncycastle.jce.provider.BouncyCastleProvider;

Security.addProvider(new BouncyCastleProvider());

Este é um post bem antigo, mas se você usar o Apache HTTPD, poderá limitar o tamanho do DH. Veja http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

Se você estiver usando jdk1.7.0_04, atualize para jdk1.7.0_21. O problema foi corrigido nessa atualização.

Se você ainda for mordido por esse problema E estiver usando o Apache httpd v> 2.4.7, tente isto: http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

copiado do URL :

A partir da versão 2.4.7, o mod_ssl utilizará os parâmetros DH, que incluem primos com comprimentos de mais de 1024 bits. Java 7 e anteriores limitam seu suporte para tamanhos de primários DH a um máximo de 1024 bits, no entanto.

Se seu cliente baseado em Java abortar com exceções, como java.lang.RuntimeException: Não foi possível gerar o par de chaves DH e java.security.InvalidAlgorithmParameterException: O tamanho principal deve ser múltiplo de 64 e só pode variar de 512 a 1024 (inclusive) e httpd logs tlsv1 alert erro interno (SSL alert number 80) (em LogLevel info ou superior), você pode rearranjar a lista de cifras do mod_ssl com SSLCipherSuite (possivelmente em conjunit com SSLHonorCipherOrder), ou você pode usar parâmetros DH customizados com um primo de 1024 bits , que sempre terá precedência sobre qualquer um dos parâmetros DH internos.

Para gerar parâmetros DH personalizados, use o

openssl dhparam 1024

comando. Como alternativa, você pode usar os seguintes parâmetros padrão de 1024 bits DH do RFC 2409, seção 6.2:

 -----BEGIN DH PARAMETERS----- MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL /1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC -----END DH PARAMETERS----- 

Adicione os parâmetros personalizados, incluindo as linhas “BEGINDINH PARAMETERS” e “END DH PARAMETERS” ao final do primeiro arquivo de certificado que você configurou usando a diretiva SSLCertificateFile.


Estou usando o java 1.6 no lado do cliente e resolvi meu problema. Eu não baixei os conjuntos de cifras ou algo assim, mas adicionei um parâmetro DH gerado personalizado ao arquivo cert.

Tente baixar “Arquivos de Política de Jurisdição de Força Ilimitada da Extensão de Criptografia (JCE)” do site de download do Java e substitua os arquivos no seu JRE.

Isso funcionou para mim e eu nem precisei usar o BouncyCastle – o Sun JCE padrão era capaz de se conectar ao servidor.

PS. Eu tenho o mesmo erro (ArrayIndexOutOfBoundsException: 64) quando eu tentei usar BouncyCastle antes de alterar os arquivos de política, por isso parece que nossa situação é muito semelhante.

Eu tenho o mesmo problema com o servidor Yandex Maps, o JDK 1.6 e o ​​Apache HttpClient 4.2.1. O erro foi

 javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated 

com o debug habilitado por -Djavax.net.debug=all que havia uma mensagem em um log

 Could not generate DH keypair 

Eu bcprov-jdk16-1.46.jar esse problema adicionando a biblioteca BouncyCastle bcprov-jdk16-1.46.jar e registrando um provedor em uma class de serviço de mapa

 public class MapService { static { Security.addProvider(new BouncyCastleProvider()); } public GeocodeResult geocode() { } } 

Um provedor é registrado no primeiro uso do MapService .

Resolveu o problema atualizando para o JDK 8.

Eu uso o coldfusion 8 no JDK 1.6.45 e tive problemas em fornecer apenas cruzes vermelhas em vez de imagens, e também com o cfhttp incapaz de se conectar ao servidor local com o ssl.

meu script de teste para reproduzir com coldfusion 8 foi

   

isso me deu o erro bastante genérico de “Exceção de E / S: par não autenticado”. Eu então tentei adicionar certificados do servidor, incluindo certificados raiz e intermediário ao keystore java e também o keystore coldfusion, mas nada ajudou. então depurei o problema com

 java SSLPoke www.onlineumfragen.com 443 

e pegou

 javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair 

e

 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.(DHCrypt.java:107) ... 10 more 

Eu então tive a idéia de que o servidor web (apache no meu caso) tinha cifras muito modernas para ssl e é bastante restritivo (qualys score a +) e usa chaves diffiel hellmann fortes com mais de 1024 bits. obviamente, coldfusion e java jdk 1.6.45 não podem gerenciar isso. O próximo passo no odysee foi pensar em instalar um provedor de segurança alternativo para o java, e decidi por um castelo inflável. veja também http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for-java-jse-projects/

Eu então baixei o

 bcprov-ext-jdk15on-156.jar 

de http://www.bouncycastle.org/latest_releases.html e instale-o em C: \ jdk6_45 \ jre \ lib \ ext ou onde quer que seu jdk esteja, na instalação original do coldfusion 8 ele estaria em C: \ JRun4 \ jre \ lib \ ext mas eu uso um novo jdk (1.6.45) localizado fora do diretório coldfusion. É muito importante colocar o bcprov-ext-jdk15on-156.jar no diretório \ ext (isso me custou cerca de duas horas e um pouco de cabelo 😉 então eu editei o arquivo C: \ jdk6_45 \ jre \ lib \ security \ java.security (com o wordpad não com editor.exe!) e coloque em uma linha para o novo provedor. depois a lista parecia

 # # 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 

(veja o novo na posição 1)

em seguida, reinicie o serviço coldfusion completamente. você pode então

 java SSLPoke www.onlineumfragen.com 443 (or of course your url!) 

e aproveite o sentimento … e claro

Que noite e que dia. Espero que isso ajude (parcial ou totalmente) para alguém lá fora. Se você tiver dúvidas, apenas envie-me em info … (domínio acima).

Se o servidor suportar uma cifra que não inclua DH, você poderá forçar o cliente a selecionar essa cifra e evitar o erro DH. Tal como:

 String pickedCipher[] ={"TLS_RSA_WITH_AES_256_CBC_SHA"}; sslsocket.setEnabledCipherSuites(pickedCipher); 

Tenha em mente que especificar uma cifra exata é propenso a quebras no longo prazo.

Recebemos o mesmo erro de exceção exato, para consertá-lo foi fácil depois de horas navegando na internet.

Nós baixamos a versão mais alta do jdk que pudemos encontrar no oracle.com, instalamos e apontamos o servidor de aplicativos Jboss para o diretório do novo jdk instalado.

Jboss reiniciado, reprocessado, problema corrigido !!!

Eu tenho esse erro com o projeto Bamboo 5.7 + Gradle + Apache. Gradle tentou obter algumas dependencies de um dos nossos servidores via SSL.

Solução:

  1. Gere o DH Param:

com OpenSSL:

 openssl dhparam 1024 

exemplo de saída:

 -----BEGIN DH PARAMETERS----- MIGHfoGBALxpfMrDpImEuPlhopxYX4L2CFqQov+FomjKyHJrzj/EkTP0T3oAkjnS oCGh6p07kwSLS8WCtYJn1GzItiZ05LoAzPs7T3ST2dWrEYFg/dldt+arifj6oWo+ vctDyDqIjlevUE+vyR9MF6B+Rfm4Zs8VGkxmsgXuz0gp/9lmftY7AgEC -----END DH PARAMETERS----- 
  1. Anexar saída ao arquivo de certificado (para o parâmetro Apache – SSLCertificateFile )

  2. Reinicie o apache

  3. Reinicie o Bambu

  4. Tente construir o projeto novamente

Eu costumava obter um erro semelhante ao acessar svn.apache.org com clientes java SVN usando um IBM JDK. Atualmente, os usuários svn.apache.org as preferências de criptografia de clientes.

Depois de executar apenas uma vez com um pacote de captura / javax.net.debug = ALL eu era capaz de fazer uma lista negra apenas uma única cifra DHE e as coisas funcionam para mim (ECDHE é negociado em vez disso).

 .../java/jre/lib/security/java.security: jdk.tls.disabledAlgorithms=SSL_DHE_RSA_WITH_AES_256_CBC_SHA 

Uma solução rápida e agradável quando não é fácil alterar o cliente.

Eu encontrei o erro SSL em um servidor CentOS executando o JDK 6.

Meu plano era instalar uma versão mais alta do JDK (JDK 7) para coexistir com o JDK 6, mas acontece que simplesmente instalar o JDK mais novo com rpm -i não foi suficiente.

A instalação do JDK 7 só seria bem-sucedida com a opção de atualização rpm -U conforme ilustrado abaixo.

1. Baixe o 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. A instalação do RPM falha

 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. A atualização do RPM é bem-sucedida

 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. Confirme a nova versão

 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) 

É possível que você tenha dependencies incorretas do Maven. Você deve encontrar essas bibliotecas na hierarquia de dependencies do Maven:

 bcprov-jdk14, bcpkix-jdk14, bcmail-jdk14 

Se você tem essas dependencies, esse é o erro e você deve fazer isso:

Adicione a dependência:

  org.bouncycastle bcmail-jdk15on 1.59  

Exclua estas dependencies do artefato que incluiu as dependencies erradas, no meu caso é:

  com.lowagie itext 2.1.7   org.bouncycastle bctsp-jdk14   bouncycastle bcprov-jdk14   bouncycastle bcmail-jdk14    

Recentemente eu tenho o mesmo problema e depois de atualizar a versão do jdk de 1.6.0_45 para jdk1.7.0_191 que resolveu o problema.

Para mim, a seguinte linha de comando corrigiu o problema:

java -jar -Dhttps.protocols=TLSv1.2 -Ddeployment.security.TLSv1.2=true -Djavax.net.debug=ssl:handshake XXXXX.jar

Eu estou usando o JDK 1.7.0_79