Alerta fatal recebido: handshake_failure por SSLHandshakeException

134

Estou com um problema de conexão SSL autorizada. Criei o Struts Action que se conecta ao servidor externo com o certificado SSL autorizado pelo cliente. Na minha ação, estou tentando enviar alguns dados para o servidor do banco, mas sem sorte, porque, como resultado do servidor, tenho o seguinte erro:

error: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Meu método da classe Action que envia dados para o servidor

//Getting external IP from host
    URL whatismyip = new URL("http://automation.whatismyip.com/n09230945.asp");
    BufferedReader inIP = new BufferedReader(new InputStreamReader(whatismyip.openStream()));

    String IPStr = inIP.readLine(); //IP as a String

    Merchant merchant;

    System.out.println("amount: " + amount + ", currency: " + currency + ", clientIp: " + IPStr + ", description: " + description);

    try {

        merchant = new Merchant(context.getRealPath("/") + "merchant.properties");

    } catch (ConfigurationException e) {

        Logger.getLogger(HomeAction.class.getName()).log(Level.INFO, "message", e);
        System.err.println("error: " + e.getMessage());
        return ERROR;
    }

    String result = merchant.sendTransData(amount, currency, IPStr, description);

    System.out.println("result: " + result);

    return SUCCESS;

Meu arquivo merchant.properties:

bank.server.url=https://-servernameandport-/
https.cipher=-cipher-

keystore.file=-key-.jks
keystore.type=JKS
keystore.password=-password-
ecomm.server.version=2.0

encoding.source=UTF-8
encoding.native=UTF-8

Pela primeira vez, pensei que fosse um problema de certificado, converti-o de .pfx para .jks, mas tenho o mesmo erro, sem alterações.

java ssl ssl-certificate sslhandshakeexception Denees
fonte
você adicionou o certificado SSL do servidor ao seu armazenamento confiável?
happymeal 15/06
desculpe, eu não entendo o que isso significa, eu sou novo no SSL
Denees
Assumirei que seu aplicativo está usando o armazenamento confiável padrão do java. O armazenamento confiável padrão é <java-home> / lib / security / cacerts. abra a URL do servidor com o seu navegador e baixe todos os certificados SSL; incluindo quaisquer cadeias / certificados intermediários. adicione todos esses certificados ao armazenamento confiável.
21711 happymeal
Não consigo abrir o URL no navegador, por causa do certificado de autenticação do cliente, posso enviar para este link apenas parâmetros específicos que recebo dos clientes.
Denees
basta abrir o URL. ignore todos os erros que você vê no seu navegador. ao acessar o URL, você verá um ícone de cadeado na barra de endereços do seu navegador. clique nele e faça o download do certificado SSL do servidor.
Happy Meal

Respostas:

251

A falha do aperto de mão pode ter ocorrido devido a vários motivos:

  • Conjuntos de cifras incompatíveis em uso pelo cliente e pelo servidor. Isso exigiria que o cliente usasse (ou habilitasse) um conjunto de criptografia suportado pelo servidor.
  • Versões incompatíveis de SSL em uso (o servidor pode aceitar apenas TLS v1, enquanto o cliente é capaz de usar apenas SSL v3). Novamente, o cliente pode precisar garantir uma versão compatível do protocolo SSL / TLS.
  • Caminho de confiança incompleto para o certificado do servidor; o certificado do servidor provavelmente não é confiável pelo cliente. Isso normalmente resultaria em um erro mais detalhado, mas é bem possível. Geralmente, a correção é importar o certificado CA do servidor no armazenamento confiável do cliente.
  • O certificado é emitido para um domínio diferente. Novamente, isso resultaria em uma mensagem mais detalhada, mas vou indicar a correção aqui, caso essa seja a causa. A resolução nesse caso seria obter o servidor (não parece ser seu) para usar o certificado correto.

Como a falha subjacente não pode ser identificada, é melhor ativar o -Djavax.net.debug=allsinalizador para ativar a depuração da conexão SSL estabelecida. Com a depuração ativada, você pode identificar qual atividade do handshake falhou.

Atualizar

Com base nos detalhes agora disponíveis, parece que o problema ocorre devido a um caminho incompleto de confiança do certificado entre o certificado emitido para o servidor e uma CA raiz. Na maioria dos casos, isso ocorre porque o certificado da CA raiz está ausente no armazenamento confiável, levando à situação em que um caminho de confiança do certificado não pode existir; o certificado é essencialmente não confiável pelo cliente. Os navegadores podem apresentar um aviso para que os usuários possam ignorar isso, mas o mesmo não acontece com clientes SSL (como a classe HttpsURLConnection ou qualquer biblioteca de clientes HTTP como Apache HttpComponents Client ).

A maioria dessas classes / bibliotecas cliente dependeria do armazenamento confiável usado pela JVM para validação de certificado. Na maioria dos casos, esse será o cacertsarquivo no diretório JRE_HOME / lib / security. Se o local do armazenamento confiável tiver sido especificado usando a propriedade do sistema JVM javax.net.ssl.trustStore, o armazenamento nesse caminho geralmente será o usado pela biblioteca do cliente. Em caso de dúvida, dê uma olhada na sua Merchantturma e descubra a turma / biblioteca que ela está usando para fazer a conexão.

Adicionar o certificado do servidor que emite a CA a esse armazenamento confiável deve resolver o problema. Você pode consultar minha resposta em uma pergunta relacionada sobre como obter ferramentas para essa finalidade, mas o utilitário Java keytool é suficiente para essa finalidade.

Aviso : O armazenamento confiável é essencialmente a lista de todas as CAs em que você confia. Se você inserir um certificado que não pertence a uma CA na qual não confia, as conexões SSL / TLS com sites com certificados emitidos por essa entidade poderão ser descriptografadas se a chave privada estiver disponível.

Atualização # 2: Compreendendo a saída do rastreamento JSSE

O keystore e os truststores usados ​​pela JVM são geralmente listados no início, algo como o seguinte:

keyStore is : 
keyStore type is : jks
keyStore provider is : 
init keystore
init keymanager of type SunX509
trustStore is: C:\Java\jdk1.6.0_21\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is :

Se o armazenamento confiável errado for usado, será necessário reimportar o certificado do servidor para o correto ou reconfigurar o servidor para usar o listado (não recomendado se você tiver várias JVMs e todas elas forem usadas para diferentes necessidades).

Se você deseja verificar se a lista de certificados confiáveis ​​contém os certificados necessários, existe uma seção para o mesmo, que começa como:

adding as trusted cert:
  Subject: CN=blah, O=blah, C=blah
  Issuer:  CN=biggerblah, O=biggerblah, C=biggerblah
  Algorithm: RSA; Serial number: yadda
  Valid from SomeDate until SomeDate

Você precisará procurar se a autoridade de certificação do servidor é um assunto.

O processo de handshake terá algumas entradas salientes (você precisará conhecer o SSL para entendê-las em detalhes, mas, para fins de depuração do problema atual, será suficiente saber que um handshake_failure geralmente é relatado no ServerHello.

1. ClientHello

Uma série de entradas será relatada quando a conexão estiver sendo inicializada. A primeira mensagem enviada pelo cliente em uma configuração de conexão SSL / TLS é a mensagem ClientHello, geralmente relatada nos logs como:

*** ClientHello, TLSv1
RandomCookie:  GMT: 1291302508 bytes = { some byte array }
Session ID:  {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods:  { 0 }
***

Observe os conjuntos de criptografia usados. Este pode ter que concordar com a entrada em seu arquivo merchant.properties, para a mesma convenção pode ser empregado por biblioteca do banco. Se a convenção usada for diferente, não haverá motivo de preocupação, pois o ServerHello indicará isso, se o conjunto de criptografia for incompatível.

2. ServerHello

O servidor responde com um ServerHello, que indicará se a configuração da conexão pode continuar. As entradas nos logs geralmente são do seguinte tipo:

*** ServerHello, TLSv1
RandomCookie:  GMT: 1291302499 bytes = { some byte array}
Cipher Suite: SSL_RSA_WITH_RC4_128_SHA
Compression Method: 0
***

Observe o conjunto de cifras que ele escolheu; esse é o melhor pacote disponível para o servidor e o cliente. Normalmente, o conjunto de criptografia não é especificado se houver um erro. O certificado do servidor (e opcionalmente toda a cadeia) é enviado pelo servidor e pode ser encontrado nas entradas como:

*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: CN=server, O=server's org, L=server's location, ST =Server's state, C=Server's country
  Signature Algorithm: SHA1withRSA, OID = some identifer

.... the rest of the certificate
***

Se a verificação do certificado for bem-sucedida, você encontrará uma entrada semelhante a:

Found trusted certificate:
[
[
  Version: V1
  Subject: OU=Server's CA, O="Server's CA's company name", C=CA's country
  Signature Algorithm: SHA1withRSA, OID = some identifier

Uma das etapas acima não teria êxito, resultando no handshake_failure, pois o handshake normalmente está completo nesse estágio (na verdade não, mas os estágios subsequentes do handshake normalmente não causam falha no handshake). Você precisará descobrir qual etapa falhou e postar a mensagem apropriada como uma atualização para a pergunta (a menos que você já tenha entendido a mensagem e saiba o que fazer para resolvê-la).

Vineet Reynolds
fonte
Por favor, poste o que tiver, se puder, para que eu possa atualizar a resposta com uma resposta mais específica.
Vineet Reynolds
1
Ok Vineet, não consigo descobrir como lidar com isso, já estou exausto. Eu encontrei uma maneira de verificar a URL do servidor com o openssl "openssl s_client -connect servername: 4402" e veja o que eu consegui: img225.imageshack.us/img225/8999/screenshoturr.png
Denees
@hoss, parece que o certificado do servidor foi emitido por uma entidade que não está presente no armazenamento confiável usado pelo OpenSSL e também possivelmente não está presente no armazenamento confiável usado pelo seu servidor (o cliente), quando ele se conecta ao o servidor. Nesse caso, você precisará importar o certificado da CA que emitiu o certificado ( e não o servidor ) para o armazenamento confiável do seu cliente (OpenSSL / seu servidor).
Vineet Reynolds
1
Bem, pode ser que isso dependa de cacerts. Mas você pode determinar isso apenas se entender a saída da depuração da rede. Se você quiser verificar isso, precisará usar o keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacertscomando para imprimir o conteúdo. Em seguida, verifique se os certificados em cacerts correspondem à CA do certificado do banco.
Vineet Reynolds
5
O padrão é geralmente changeit. A menos que tenha sido alterado.
Vineet Reynolds
20

A instalação da força ilimitada do Java Cryptography Extension (JCE) ( para JDK7 | for JDK8 ) pode corrigir esse erro. Descompacte o arquivo e siga o leia-me para instalá-lo.

Simon Yu
fonte
16

A falha do handshake pode ser uma implementação de protocolo TLSv1 com erros.

No nosso caso, isso ajudou no java 7: 

java -Dhttps.protocols=TLSv1.2,TLSv1.1,TLSv1

A jvm negociará nesta ordem. Os servidores com a atualização mais recente farão o 1.2, os de buggy descerão para a v1 e isso funciona com a v1 semelhante no java 7.

Bela Vizy
fonte
1
Isso me ajudou. Havia o meu ClientHello, mas nenhum servidor, o final foi bastante abrupto. Isso corrigiu para mim no Java 7. Muito obrigado.
Virgo47
15

Isso também pode acontecer quando o cliente precisa apresentar um certificado. Depois que o servidor lista a cadeia de certificados, pode acontecer o seguinte:

3. Solicitação de certificado O servidor emitirá uma solicitação de certificado do cliente. A solicitação listará todos os certificados que o servidor aceita.

*** CertificateRequest
Cert Types: RSA
Cert Authorities:
<CN=blah, OU=blah, O=blah, L=blah, ST=blah, C=blah>
<CN=yadda, DC=yadda, DC=yadda>
<CN=moreblah, OU=moreblah, O=moreblah, C=moreblah>
<CN=moreyada, OU=moreyada, O=moreyada, C=moreyada>
... the rest of the request
*** ServerHelloDone

4. Cadeia de Certificados de Clientes Este é o certificado que o cliente está enviando para o servidor.

*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: EMAILADDRESS=client's email, CN=client, OU=client's ou, O=client's Org, L=client's location, ST=client's state, C=client's Country
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
  ... the rest of the certificate
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1    
... key exchange info

Se não houver um certificado na cadeia e o servidor exigir um, você receberá o erro de handshake aqui. Uma causa provável é que o caminho para o seu certificado não foi encontrado.

5. Verificação de certificado O cliente solicita ao servidor que verifique o certificado 

*** CertificateVerify
... payload of verify check

Esta etapa acontecerá apenas se você estiver enviando um certificado.

6. Concluído O servidor responderá com uma resposta de verificação

*** Finished
verify_data:  { 345, ... }
Brigue
fonte
no meu caso, parece que todas as etapas estão bem, mas ainda assim recebemos o erro do aperto de mão.
Tib 11/02
resposta muito boa ... mas tudo isso está bem na minha falha de aperto de mão, mas ainda assim eu tenho a falha. você poderia dar uma olhada na minha pergunta semelhante?
Tib 11/02
Falha na apresentação de um certificado de cliente não representa nenhum tipo de erro no TLS. Se o servidor exigir um certificado de cliente e um não for apresentado, ele fechará a conexão.
Marquês de Lorne
@EJP isso é verdade, não é um erro no TLS, no entanto, a falha na conexão aparece como um erro no código Java.
Brig
1
@ Brig Mas não como um alerta, que é o que esta resposta diz e o que é a pergunta.
Marquês de Lorne
15

Não acho que isso resolva o problema para o primeiro interlocutor, mas para os googlers que vêm aqui em busca de respostas:

Na atualização 51, o java 1.8 proíbe cifras [1] RC4 por padrão, como podemos ver na página Notas da versão:

Correção de bug: Proibir conjuntos de cifras RC4

O RC4 agora é considerado como uma cifra comprometida.

Os conjuntos de cifras RC4 foram removidos da lista de conjuntos de cifras ativada por padrão do cliente e do servidor na implementação do Oracle JSSE. Esses conjuntos de criptografia ainda podem ser ativados por SSLEngine.setEnabledCipherSuites()e SSLSocket.setEnabledCipherSuites()métodos. Consulte JDK-8077109 (não público).

Se o seu servidor tiver uma forte preferência por essa cifra (ou usar apenas essa cifra), isso poderá ativar um handshake_failurejava.

Você pode testar a conexão com o servidor ativando as cifras RC4 (primeiro, tente sem enabledargumento para ver se dispara a e handshake_failure, em seguida, defina enabled:

import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSocketFactory;
import java.io.*;

import java.util.Arrays;

/** Establish a SSL connection to a host and port, writes a byte and
 * prints the response. See
 * http://confluence.atlassian.com/display/JIRA/Connecting+to+SSL+services
 */
public class SSLRC4Poke {
    public static void main(String[] args) {
        String[] cyphers;
        if (args.length < 2) {
            System.out.println("Usage: "+SSLRC4Poke.class.getName()+" <host> <port> enable");
            System.exit(1);
        }
        try {
            SSLSocketFactory sslsocketfactory = (SSLSocketFactory) SSLSocketFactory.getDefault();
            SSLSocket sslsocket = (SSLSocket) sslsocketfactory.createSocket(args[0], Integer.parseInt(args[1]));
        
            cyphers = sslsocketfactory.getSupportedCipherSuites();
            if (args.length ==3){
                sslsocket.setEnabledCipherSuites(new String[]{
                    "SSL_DH_anon_EXPORT_WITH_RC4_40_MD5",
                    "SSL_DH_anon_WITH_RC4_128_MD5",
                    "SSL_RSA_EXPORT_WITH_RC4_40_MD5",
                    "SSL_RSA_WITH_RC4_128_MD5",
                    "SSL_RSA_WITH_RC4_128_SHA",
                    "TLS_ECDHE_ECDSA_WITH_RC4_128_SHA",
                    "TLS_ECDHE_RSA_WITH_RC4_128_SHA",
                    "TLS_ECDH_ECDSA_WITH_RC4_128_SHA",
                    "TLS_ECDH_RSA_WITH_RC4_128_SHA",
                    "TLS_ECDH_anon_WITH_RC4_128_SHA",
                    "TLS_KRB5_EXPORT_WITH_RC4_40_MD5",
                    "TLS_KRB5_EXPORT_WITH_RC4_40_SHA",
                    "TLS_KRB5_WITH_RC4_128_MD5",
                    "TLS_KRB5_WITH_RC4_128_SHA"
                });     
            }

            InputStream in = sslsocket.getInputStream();
            OutputStream out = sslsocket.getOutputStream();

            // Write a test byte to get a reaction :)
            out.write(1);

            while (in.available() > 0) {
                System.out.print(in.read());
            }
            System.out.println("Successfully connected");

        } catch (Exception exception) {
            exception.printStackTrace();
        }
    }
}

1 - https://www.java.com/en/download/faq/release_changes.xml

motobói
fonte
10

Eu tenho esse erro enquanto tentava usar o JDK 1.7. Quando atualizei meu JDK para jdk1.8.0_66, tudo começou a funcionar bem.

Portanto, a solução mais simples para esse problema pode ser: atualize seu JDK e ele poderá começar a funcionar bem.

Maxim Votyakov
fonte
4
Agradável. A solução mais simples é atualizar o JDK? : D Você sabe o quão complicado isso pode ser, dependendo do ambiente em que isso está sendo feito? Suponha que a Amazon execute o JDK 7 e agora precise atualizar para o JDK 8 de repente ... Bom!
Arturas M
1
Uma atualização de versão secundária simples resolveu esse problema para mim .. de JDK 11.0.1 para 11.0.6
Clint
4

No meu caso, cert é importado, o erro permanece, resolvido isso adicionando System.setProperty("https.protocols", "TLSv1.2,TLSv1.1,SSLv3");antes de conectar

Molly Gu
fonte
Trabalhou para mim em java 1.8. Obrigado :)
Supun Amarasinghe
3

Supondo que você esteja usando os protocolos SSL / TLS adequados, configurando seu keyStoree corretamente trustStoree confirmando que não existem problemas com os próprios certificados, pode ser necessário reforçar seus algoritmos de segurança .

Conforme mencionado na resposta do Vineet , um possível motivo para você receber esse erro é o uso de conjuntos de códigos incompatíveis. Atualizando my local_policye US_export_policyjars na securitypasta do meu JDK com os fornecidos na Java Cryptography Extension (JCE) , consegui concluir o handshake com êxito.

heez
fonte
2

Hoje, encontro o mesmo problema com o cliente OkHttp para obter um URL baseado em https. Foi causado pela incompatibilidade da versão do protocolo Https e do método Cipher entre o servidor e o cliente .

1) verifique o site https versão do protocolo e método de cifra.

openssl>s_client -connect your_website.com:443 -showcerts

Você obterá muitas informações detalhadas, as principais informações estão listadas a seguir:

SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
2) configure seu cliente http, por exemplo, no caso do cliente OkHttp : 
@Test()
public void testHttpsByOkHttp() {
    ConnectionSpec spec = new ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
            .tlsVersions(TlsVersion.TLS_1_0) //protocol version
            .cipherSuites(
                    CipherSuite.TLS_RSA_WITH_RC4_128_SHA, //cipher method
                    CipherSuite.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
                    CipherSuite.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
                    CipherSuite.TLS_DHE_RSA_WITH_AES_128_GCM_SHA256)
            .build();

    OkHttpClient client = new OkHttpClient();
    client.setConnectionSpecs(Collections.singletonList(spec));
    Request request = new Request.Builder().url("https://your_website.com/").build();
    try {
        Response response = client.newCall(request).execute();
        if(response.isSuccessful()){
            logger.debug("result= {}", response.body().string());
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
}

Isso vai conseguir o que queremos.

Armstrongya
fonte
2

Encontrei um servidor HTTPS que falhou dessa maneira se meu processo do cliente Java foi configurado com

-Djsse.enableSNIExtension=false

A conexão falhou handshake_failureapós a ServerHelloconclusão com êxito, mas antes do início do fluxo de dados.

Não havia uma mensagem de erro clara que identificasse o problema, o erro parecia

main, READ: TLSv1.2 Alert, length = 2
main, RECV TLSv1.2 ALERT:  fatal, handshake_failure
%% Invalidated:  [Session-3, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384]
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Eu isolei o problema tentando com e sem a -Djsse.enableSNIExtension=falseopção " "

Rico
fonte
Estou recebendo o mesmo erro ao conectar-me ao sandbox GDAX, alguma solução para isso?
Nitin Vavdiya
1

O meu foi um TLSerro de versão incompatível.

Anteriormente, TLSv1eu mudei TLSV1.2isso resolveu o meu problema.

Ali786
fonte
1

Estou usando o cliente http com.google.api. Quando me comunico com um site interno da empresa, recebi esse problema ao usar por engano https, em vez de http. 

main, READ: TLSv1.2 Alert, length = 2
main, RECV TLSv1.2 ALERT:  fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
main, IOException in getSession():  javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
main, called close()
main, called closeInternal(true)
262 [main] DEBUG org.apache.http.impl.conn.DefaultClientConnection  - Connection shut down
main, called close()
main, called closeInternal(true)
263 [main] DEBUG org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager  - Released connection is not reusable.
263 [main] DEBUG org.apache.http.impl.conn.tsccm.ConnPoolByRoute  - Releasing connection [HttpRoute[{s}->https://<I-replaced>]][null]
263 [main] DEBUG org.apache.http.impl.conn.tsccm.ConnPoolByRoute  - Notifying no-one, there are no waiting threads
Exception in thread "main" javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
    at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:431)
    at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
    at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:339)
    at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123)
    at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147)
    at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:108)
    at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
    at com.google.api.client.http.apache.ApacheHttpRequest.execute(ApacheHttpRequest.java:67)
    at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:960)
thebiggestlebowski
fonte
Não, você não pode. O servidor não pode enviar um alerta TLS se não estiver falando TLS.
Marquês de Lorne
Eu atualizei meu comentário para mostrar a saída do meu programa. Isso é real. Agradeceria se você removesse o voto negativo.
thebiggestlebowski
É real, mas não é causado pela conversação do TLS com um servidor de texto sem formatação. Um servidor de texto sem formatação não está falando de TLS, por definição, e, portanto, você não pode receber um alerta de TLS por definição. Você não tem nenhuma informação sobre quem rebaixou sua resposta.
Marquês de Lorne
Presumi que você votou mal - minhas desculpas, se não for esse o caso. Minha mensagem de erro corresponde exatamente ao título desta pergunta. É um caminho válido / caso de teste para receber essa mensagem de erro e eu tenho uma solução que pode ajudar outras pessoas. Respeitosamente, acho que não importa se foi causado por uma resposta de erro do servidor TLS ou não. Alguém chegará aqui do google e minha resposta pode ajudar se cometerem o mesmo erro.
thebiggestlebowski
Eu não disse nada sobre sua mensagem de erro. Estou comentando sua alegação incorreta de que ela se deve ao "uso incorreto de HTTPS em vez de HTTP". Não é, e não pode ser, por razões que afirmei e que você não abordou de forma alguma. O uso do HTTP certamente fará com que ele desapareça, obviamente, pois não há alertas TLS em texto sem formatação, mas não soluciona o problema subjacente.
Marquês de Lorne
1

Eu tive uma questão semelhante; a atualização para o Apache HTTPClient 4.5.3 o corrigiu.

Hazel Troost
fonte
1

Ugg! Acabou sendo simplesmente um problema de versão do Java para mim. Eu recebi o erro de aperto de mão usando o JRE 1.6 e tudo funcionou perfeitamente usando o JRE 1.8.0_144.

John
fonte
0

Isenção de responsabilidade: não sei se a resposta será útil para muitas pessoas, apenas compartilhando porque pode.

Eu estava recebendo esse erro ao usar o Parasoft SOATest para enviar solicitação XML (SOAP).

O problema foi que eu selecionei o alias errado no menu suspenso depois de adicionar o certificado e autenticá-lo.

user3251882
fonte
0

No meu caso, o site apenas pode usar o TLSv1.2. e eu uso o apache httpclient 4.5.6, eu uso esse código e instalo o jce para resolver isso (JDK1.7):

jce

jdk7 http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

jdk 8 http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html

código:

SSLContext sslContext = SSLContext.getDefault();

  SSLConnectionSocketFactory sslConnectionFactory = new SSLConnectionSocketFactory(
      sslContext,
      new String[]{"TLSv1.2"}, // important
      null,
      NoopHostnameVerifier.INSTANCE);

  Registry<ConnectionSocketFactory> registry = RegistryBuilder.<ConnectionSocketFactory>create()
      .register("https", sslConnectionFactory)
      .register("http", PlainConnectionSocketFactory.INSTANCE)
      .build();

  HttpClientConnectionManager ccm = new BasicHttpClientConnectionManager(registry);
  httpclient = HttpClientBuilder.create().
      .setSSLSocketFactory(sslConnectionFactory)
      .setConnectionManager(ccm)
      .build();
Tianmu
fonte
0

Para solucionar problemas da perspectiva do desenvolvedor (item 1) e do administrador do sistema (itens 2 e 3):

  1. Ative a depuração do handshake SSL no Java via -Djavax.net.debug=ssl:handshake:verbose.
  2. Instale o ssldump no servidor via sudo apt install ssldumpou compile a partir da fonte seguindo este link se você observar Unknown valuena cifra quando executar a etapa abaixo.
  3. No servidor, sudo ssldump -k <your-private-key> -i <your-network-interface>
  4. Verifique o log sobre o real motivo da falha.

Exemplo de aperto de mão do log ssldump:

New TCP connection #1: 10.1.68.86(45308) <-> 10.1.68.83(5671)
1 1  0.0111 (0.0111)  C>S  Handshake
      ClientHello
        Version 3.3
        cipher suites
        TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        TLS_RSA_WITH_AES_256_GCM_SHA384
        TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
        TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
        TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
        TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        TLS_RSA_WITH_AES_128_GCM_SHA256
        TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
        TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
        TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
        TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
        TLS_RSA_WITH_AES_256_CBC_SHA256
        TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
        TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
        TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
        TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_DSS_WITH_AES_256_CBC_SHA
        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
        TLS_RSA_WITH_AES_128_CBC_SHA256
        TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
        TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
        TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA
        TLS_EMPTY_RENEGOTIATION_INFO_SCSV
        compression methods
                  NULL
1 2  0.0122 (0.0011)  S>C  Alert
    level           fatal
    value           insufficient_security
1    0.0126 (0.0004)  S>C  TCP RST

Exemplo de handshake bem-sucedido do log ssldump

New TCP connection #1: 10.1.68.86(56558) <-> 10.1.68.83(8443)
1 1  0.0009 (0.0009)  C>S  Handshake
      ClientHello
        Version 3.3
        cipher suites
        TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
        Unknown value 0xcca9
        Unknown value 0xcca8
        Unknown value 0xccaa
        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA
        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_AES_256_GCM_SHA384
        TLS_RSA_WITH_AES_128_GCM_SHA256
        TLS_RSA_WITH_AES_256_CBC_SHA256
        TLS_RSA_WITH_AES_128_CBC_SHA256
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLS_EMPTY_RENEGOTIATION_INFO_SCSV
        compression methods
                  NULL
1 2  0.0115 (0.0106)  S>C  Handshake
      ServerHello
        Version 3.3
        session_id[0]=

        cipherSuite         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        compressionMethod                   NULL
1 3  0.0115 (0.0000)  S>C  Handshake
      Certificate
1 4  0.0115 (0.0000)  S>C  Handshake
      ServerKeyExchange
Not enough data. Found 294 bytes (expecting 32767)
1 5    0.0115   (0.0000)    S>C    Handshake
        ServerHelloDone
1 6    0.0141   (0.0025)    C>S    Handshake
        ClientKeyExchange
Not enough data. Found 31 bytes (expecting 16384)
1 7    0.0141   (0.0000)    C>S    ChangeCipherSpec
1 8    0.0141   (0.0000)    C>S      Handshake
1 9    0.0149   (0.0008)    S>C    Handshake
1 10   0.0149   (0.0000)    S>C    ChangeCipherSpec
1 11   0.0149   (0.0000)    S>C      Handshake

Exemplo de log Java não funcionando

javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.778 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.779 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.779 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.780 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.780 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.780 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.781 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.781 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.781 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.782 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.782 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.782 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.782 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.783 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.783 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.783 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.783 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.783 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.784 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.784 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: T LS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.784 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS11
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.784 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.784 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.784 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.784 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.785 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.786 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS10
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.787 MYT|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS10
javax.net.ssl|WARNING|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.818 MYT|SignatureScheme.java:282|Signature algorithm, ed25519, is not supported by the underlying providers
javax.net.ssl|WARNING|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.818 MYT|SignatureScheme.java:282|Signature algorithm, ed448, is not supported by the underlying providers
javax.net.ssl|ALL|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.822 MYT|SignatureScheme.java:358|Ignore disabled signature sheme: rsa_md5
javax.net.ssl|INFO|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.822 MYT|AlpnExtension.java:161|No available application protocols
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.823 MYT|SSLExtensions.java:256|Ignore, context unavailable extension: application_layer_protocol_negotiation
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.823 MYT|SSLExtensions.java:256|Ignore, context unavailable extension: renegotiation_info
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.825 MYT|ClientHello.java:651|Produced ClientHello handshake message (
"ClientHello": {
  "client version"      : "TLSv1.2",
  "random"              : "FB BC CD 7C 17 65 86 49 3E 1C 15 37 24 94 7D E7 60 44 1B B8 F4 18 21 D0 E1 B1 31 0D E1 80 D6 A7",
  "session id"          : "",
  "cipher suites"       : "[TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]",
  "compression methods" : "00",  "extensions"          : [
    "server_name (0)": {
      type=host_name (0), value=mq.tpc-ohcis.moh.gov.my
    },
    "status_request (5)": {
      "certificate status type": ocsp
      "OCSP status request": {
        "responder_id": <empty>
        "request extensions": {
          <empty>
        }
      }
    },
    "supported_groups (10)": {
      "versions": [secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]
    },
    "ec_point_formats (11)": {
      "formats": [uncompressed]
    },
    "signature_algorithms (13)": {
      "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
    },
    "signature_algorithms_cert (50)": {
      "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
    },
    "status_request_v2 (17)": {
      "cert status request": {
        "certificate status type": ocsp_multi
        "OCSP status request": {
          "responder_id": <empty>
          "request extensions": {
            <empty>
          }
        }      }
    },
    "extended_master_secret (23)": {
      <empty>
    },
    "supported_versions (43)": {
      "versions": [TLSv1.2, TLSv1.1, TLSv1]
    }
  ]
}
)
javax.net.ssl|DEBUG|43|SimpleAsyncTaskExecutor-1|2019-07-03 17:35:01.829 MYT|Alert.java:238|Received alert message (
"Alert": {
  "level"      : "fatal",
  "description": "insufficient_security"
}
)
Lee Chee Kiam
fonte
0

No meu caso, tive um problema com a versão 1.1. Eu estava reproduzindo o problema facilmente com curl. O servidor não suporta versões inferiores ao TLS1.2.

Este problema de handshake recebido:

curl --insecure --tlsv1.1 -i https://youhost --noproxy "*"

Com a versão 1.2, estava funcionando bem:

curl --insecure --tlsv1.2 -i https://youhost --noproxy "*"

O servidor estava executando um Weblogic e a inclusão desse argumento no setEnvDomain.sh fez com que ele funcionasse com o TLSv1.1:

-Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.1
Ravenskater
fonte
0

Este problema está ocorrendo devido à versão java. Eu estava usando o JDK 1.8.0.231 e recebendo esse erro. Eu degradei minha versão java de 1.8.0.231 para 1.8.0.171, agora está funcionando bem.

hariom gupta
fonte