Falhas no handshake de TLS/SSL

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Sintoma

Uma falha no handshake TLS/SSL ocorre quando um cliente e um servidor não conseguem estabelecer comunicação usando o protocolo TLS/SSL. Quando esse erro ocorre no Apigee Edge, o aplicativo cliente recebe um status HTTP 503 com a mensagem Serviço indisponível. Esse erro aparece após qualquer chamada de API em que ocorre uma falha de handshake de TLS/SSL.

Mensagens de erro

HTTP/1.1 503 Service Unavailable

Essa mensagem de erro também aparece quando ocorre uma falha no handshake de TLS/SSL:

Received fatal alert: handshake_failure

Causas possíveis

O TLS (Transport Layer Security, cujo predecessor é o SSL) é a tecnologia de segurança padrão para estabelecer um link criptografado entre um servidor da Web e um cliente da Web, como um navegador ou um app. Um handshake é um processo que permite que o cliente e o servidor TLS/SSL estabeleçam um conjunto de chaves secretas com as quais podem se comunicar. Durante esse processo, o cliente e o servidor:

1. Concorde com a versão do protocolo a ser usada.
2. Selecione o algoritmo criptográfico a ser usado.
3. Autentiquem-se trocando e validando certificados digitais.

Se o handshake TLS/SSL for bem-sucedido, o cliente e o servidor TLS/SSL vão transferir dados entre si com segurança. Caso contrário, se ocorrer uma falha de handshake de TLS/SSL, a conexão será encerrada e o cliente receberá um erro 503 Service Unavailable.

As possíveis causas de falhas no handshake TLS/SSL são:

Divergência de protocolo

Uma falha de handshake TLS/SSL ocorre se o protocolo usado pelo cliente não for compatível com o servidor na conexão de entrada (norte) ou saída (sul). Consulte também Noções básicas sobre conexões no sentido norte e sul.

Diagnóstico

1. Determine se o erro ocorreu na conexão de entrada ou de saída. Para mais orientações sobre como fazer essa determinação, consulte Como determinar a origem do problema.
2. Execute o utilitário tcpdump para coletar mais informações:
   • Se você for um usuário da nuvem privada, poderá coletar os dados tcpdump no cliente ou servidor relevante. Um cliente pode ser o app cliente (para conexões de entrada ou de norte a sul) ou o processador de mensagens (para conexões de saída ou de sul a norte). Um servidor pode ser o roteador de borda (para conexões de entrada ou northbound) ou o servidor de back-end (para conexões de saída ou southbound), com base na sua determinação da etapa 1.
   • Se você for um usuário da nuvem pública, poderá coletar os dados tcpdump apenas no app cliente (para conexões de entrada ou de norte a sul) ou no servidor de back-end (para conexões de saída ou de sul a norte), porque não tem acesso ao roteador de borda ou ao processador de mensagens.

   tcpdump -i any -s 0 host IP address -w File name
   

   Consulte os dados do tcpdump para mais informações sobre como usar o comando tcpdump.
3. Analise os dados de tcpdump usando a ferramenta Wireshark ou uma semelhante.
4. Confira um exemplo de análise do tcpdump usando o Wireshark:
   • Neste exemplo, a falha de handshake de TLS/SSL ocorreu entre o processador de mensagens e o servidor de back-end (a conexão de saída ou southbound).
   • A mensagem nº 4 na saída tcpdump abaixo mostra que o processador de mensagens (origem) enviou uma mensagem "Client Hello" para o servidor de back-end (destino).
     

     

   • Se você selecionar a mensagem Client Hello, isso vai mostrar que o processador de mensagens está usando o protocolo TLSv1.2, conforme mostrado abaixo:

     

   • A mensagem 5 mostra que o servidor de back-end reconhece a mensagem "Client Hello" do Processador de mensagens.
   • O servidor de back-end envia imediatamente Alerta fatal : Close Notify ao processador de mensagens (mensagem nº 6). Isso significa que o handshake TLS/SSL falhou e a conexão será encerrada.

   • Analisando mais a fundo a mensagem nº 6, vemos que a causa da falha no handshake TLS/SSL é que o servidor de back-end é compatível apenas com o protocolo TLSv1.0, conforme mostrado abaixo:

     

   • Como há uma incompatibilidade entre o protocolo usado pelo processador de mensagens e o servidor de back-end, o servidor de back-end enviou a mensagem: Mensagem de alerta fatal: fechar Notificar.

Resolução

O processador de mensagens é executado no Java 8 e usa o protocolo TLSv1.2 por padrão. Se o servidor de back-end não for compatível com o protocolo TLSv1.2, siga uma destas etapas para resolver o problema:

1. Faça upgrade do servidor de back-end para oferecer suporte ao protocolo TLSv1.2. Essa é uma solução recomendada porque o protocolo TLSv1.2 é mais seguro.
2. Se você não puder fazer upgrade do servidor de back-end imediatamente por algum motivo, force o processador de mensagens a usar o protocolo TLSv1.0 para se comunicar com o servidor de back-end seguindo estas etapas:
   1. Se você não especificou um servidor de destino na definição de TargetEndpoint do proxy, defina o elemento Protocol como TLSv1.0, conforme mostrado abaixo:

      <TargetEndpoint name="default">
       …
       <HTTPTargetConnection>
         <SSLInfo>
             <Enabled>true</Enabled>
             <Protocols>
                 <Protocol>TLSv1.0</Protocol>
             </Protocols>
         </SSLInfo>
         <URL>https://myservice.com</URL>
       </HTTPTargetConnection>
       …
      </TargetEndpoint>

   2. Se você configurou um servidor de destino para seu proxy, use esta API de gerenciamento para definir o protocolo como TLSv1.0 na configuração específica do servidor de destino.

Incompatibilidade de criptografia

Você pode ver uma falha de handshake de TLS/SSL se o algoritmo do pacote de criptografia usado pelo cliente não for compatível com o servidor na conexão de entrada (norte) ou saída (sul) no Apigee Edge. Consulte também Noções básicas sobre conexões no sentido norte e sul.

Diagnóstico

1. Determine se o erro ocorreu na conexão de entrada ou de saída. Para mais orientações sobre como fazer essa determinação, consulte Determinar a origem do problema.
2. Execute o utilitário tcpdump para coletar mais informações:
   • Se você for um usuário da nuvem privada, poderá coletar os dados tcpdump no cliente ou servidor relevante. Um cliente pode ser o app cliente (para conexões de entrada ou de norte a sul) ou o processador de mensagens (para conexões de saída ou de sul a norte). Um servidor pode ser o roteador de borda (para conexões de entrada ou northbound) ou o servidor de back-end (para conexões de saída ou southbound), com base na sua determinação da etapa 1.
   • Se você for um usuário da nuvem pública, poderá coletar os dados tcpdump apenas no app cliente (para conexões de entrada ou de norte a sul) ou no servidor de back-end (para conexões de saída ou de sul a norte), porque não tem acesso ao roteador de borda ou ao processador de mensagens.

   tcpdump -i any -s 0 host IP address -w File name
   

   Consulte os dados do tcpdump para mais informações sobre como usar o comando tcpdump.
3. Analise os dados de tcpdump usando a ferramenta Wireshark ou qualquer outra que você conheça.
4. Confira o exemplo de análise da saída tcpdump usando o Wireshark:
   • Neste exemplo, a falha no handshake TLS/SSL ocorreu entre o aplicativo cliente e o roteador de borda (conexão de saída). A saída tcpdump foi coletada no roteador de borda.

   • A mensagem nº 4 na saída tcpdump abaixo mostra que o aplicativo cliente (origem) enviou uma mensagem "Client Hello" para o roteador de borda (destino).

     

   • Ao selecionar a mensagem "Client Hello", você vê que o aplicativo cliente está usando o protocolo TLSv1.2.

     

   • A mensagem 5 mostra que o roteador de borda reconhece a mensagem "Client Hello" do aplicativo cliente.
   • O roteador de borda envia imediatamente um Alerta fatal : falha no handshake para o aplicativo cliente (mensagem nº 6). Isso significa que o handshake TLS/SSL falhou e a conexão será fechada.
   • Ao analisar a mensagem nº 6, as seguintes informações são exibidas:
     • O roteador de borda é compatível com o protocolo TLSv1.2. Isso significa que o protocolo corresponde entre o aplicativo cliente e o roteador de borda.

     • No entanto, o roteador do Edge ainda envia o Alerta fatal: falha no handshake para o aplicativo cliente, conforme mostrado na captura de tela abaixo:

       

   • O erro pode ser resultado de um dos seguintes problemas:
     • O aplicativo cliente não está usando os algoritmos de conjunto de criptografia compatíveis com o roteador do Edge.
     • O roteador do Edge está ativado para SNI, mas o aplicativo cliente não está enviando o nome do servidor.
   • A mensagem 4 na saída tcpdump lista os algoritmos de conjunto de criptografia compatíveis com o aplicativo cliente, conforme mostrado abaixo:

     

   • A lista de algoritmos de pacote de criptografia compatíveis com o roteador de borda está no arquivo /opt/nginx/conf.d/0-default.conf. Neste exemplo, o roteador de borda só é compatível com os algoritmos do pacote de criptografia de alta criptografia.
   • O aplicativo cliente não usa nenhum dos algoritmos do conjunto de criptografia de alta criptografia. Essa incompatibilidade é a causa da falha no handshake TLS/SSL.
   • Como o roteador de borda está ativado para SNI, role para baixo até a mensagem nº 4 na saída tcpdump e confirme se o aplicativo cliente está enviando o nome do servidor corretamente, conforme mostrado na figura abaixo:
     
     
     
   • Se esse nome for válido, é possível inferir que a falha no handshake TLS/SSL ocorreu porque os algoritmos de conjunto de criptografia usados pelo aplicativo cliente não são compatíveis com o roteador de borda.

Resolução

Verifique se o cliente usa os algoritmos do pacote de criptografia compatíveis com o servidor. Para resolver o problema descrito na seção de diagnóstico anterior, faça o download e instale o pacote Java Cryptography Extension (JCE) e inclua-o na instalação do Java para oferecer suporte a algoritmos de conjunto de criptografias de alta criptografia.

Certificado incorreto

Uma falha de handshake de TLS/SSL ocorre se você tiver certificados incorretos no keystore/truststore, na conexão de entrada (norte) ou de saída (sul) no Apigee Edge. Consulte também Noções básicas sobre conexões no sentido norte e sul.

Se o problema for norte, você poderá ver mensagens de erro diferentes dependendo da causa.

As seções a seguir listam exemplos de mensagens de erro e as etapas para diagnosticar e resolver esse problema.

Mensagens de erro

Você pode receber mensagens de erro diferentes dependendo da causa da falha no handshake TLS/SSL. Confira um exemplo de mensagem de erro que pode aparecer ao chamar um proxy de API:

* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

Causas possíveis

As causas típicas desse problema são:

Divergência de nome do host

Diagnóstico

1. Anote o nome do host usado no URL retornado pela seguinte chamada da API de gerenciamento do Edge:

   curl -v https://myorg.domain.com/v1/getinfo

   Por exemplo:

   curl -v https://api.enterprise.apigee.com/v1/getinfo

2. Receba o CN usado no certificado armazenado no keystore específico. Você pode usar as seguintes APIs de gerenciamento do Edge para receber os detalhes do certificado:
   1. Extraia o nome do certificado no keystore:
      
      Se você for um usuário do Private Cloud, use a API Management da seguinte maneira:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      Se você for um usuário da nuvem pública, use a API Management da seguinte maneira:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Receba os detalhes do certificado no armazenamento de chaves usando a API de gerenciamento do Edge.
      
      Se você for um usuário da nuvem privada:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Se você for um usuário da nuvem pública:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Exemplo de certificado::

      "certInfo": [
          {
            "basicConstraints": "CA:FALSE",
            "expiryDate": 1456258950000,
            "isValid": "No",
            "issuer": "SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=\"GoDaddy.com, Inc.\", L=Scottsdale, ST=Arizona, C=US",
            "publicKey": "RSA Public Key, 2048 bits",
            "serialNumber": "07:bc:a7:39:03:f1:56",
            "sigAlgName": "SHA1withRSA",
            "subject": "CN=something.domain.com, OU=Domain Control Validated, O=something.domain.com",
            "validFrom": 1358287055000,
            "version": 3
          },

      O nome do assunto no certificado principal tem o CN como something.domain.com.

      Como o nome do host usado no URL da solicitação de API (consulte a etapa 1 acima) e o nome do assunto no certificado não correspondem, você recebe a falha no handshake TLS/SSL.

Resolução

Esse problema pode ser resolvido de uma das duas maneiras a seguir:

• Obtenha um certificado (se você ainda não tiver um) em que o CN do assunto tenha um certificado curinga e faça upload da nova cadeia de certificados completa para o keystore. Exemplo:

  "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",

• Obtenha um certificado (se você ainda não tiver um) com um CN de assunto atual, mas use your-org.your-domain como um nome alternativo do assunto e faça upload da cadeia de certificados completa para o keystore.

Referências

Keystores e truststores

Cadeia de certificados incompleta ou incorreta

Diagnóstico

1. Receba o CN usado no certificado armazenado no keystore específico. Você pode usar as seguintes APIs de gerenciamento do Edge para receber os detalhes do certificado:
   1. Receba o nome do certificado no keystore:
      
      Se você for um usuário da nuvem privada:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

      Se você for um usuário da nuvem pública:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Receba os detalhes do certificado no keystore:
      
      Se você for um usuário da nuvem privada:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Se você for um usuário da nuvem pública:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

   3. Valide o certificado e a cadeia dele e verifique se eles seguem as diretrizes fornecidas no artigo Como as cadeias de certificados funcionam para garantir que seja uma cadeia de certificados válida e completa. Se a cadeia de certificados armazenada no keystore estiver incompleta ou inválida, você vai ver a falha no handshake TLS/SSL.
   4. O gráfico a seguir mostra um exemplo de certificado com uma cadeia inválida, em que os certificados intermediário e raiz não correspondem:

   Exemplo de certificado intermediário e raiz em que o emissor e o assunto não correspondem

   
   

Resolução

1. Obtenha um certificado (se você ainda não tiver um) que inclua uma cadeia de certificados completa e válida.
2. Execute o seguinte comando openssl para verificar se a cadeia de certificados está correta e completa:

   openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert

3. Faça upload da cadeia de certificados validada para o keystore.

Certificado expirado ou desconhecido enviado pelo servidor ou cliente

Se um certificado incorreto/expirado for enviado pelo servidor/cliente na conexão de entrada ou de saída, a outra extremidade (servidor/cliente) vai rejeitar o certificado, resultando em uma falha de handshake de TLS/SSL.

Diagnóstico

1. Determine se o erro ocorreu na conexão de entrada ou de saída. Para mais orientações sobre como fazer essa determinação, consulte Determinar a origem do problema.
2. Execute o utilitário tcpdump para coletar mais informações:
   • Se você for um usuário da nuvem privada, poderá coletar os dados tcpdump no cliente ou servidor relevante. Um cliente pode ser o app cliente (para conexões de entrada ou de norte a sul) ou o processador de mensagens (para conexões de saída ou de sul a norte). Um servidor pode ser o roteador de borda (para conexões de entrada ou northbound) ou o servidor de back-end (para conexões de saída ou southbound), com base na sua determinação da etapa 1.
   • Se você for um usuário da nuvem pública, poderá coletar os dados tcpdump apenas no app cliente (para conexões de entrada ou de norte a sul) ou no servidor de back-end (para conexões de saída ou de sul a norte), porque não tem acesso ao roteador de borda ou ao processador de mensagens.

   tcpdump -i any -s 0 host IP address -w File name
   

   Consulte os dados do tcpdump para mais informações sobre como usar o comando tcpdump.
3. Analise os dados de tcpdump usando o Wireshark ou uma ferramenta semelhante.
4. Na saída tcpdump, determine o host (cliente ou servidor) que está rejeitando o certificado durante a etapa de verificação.
5. Você pode recuperar o certificado enviado da outra extremidade na saída tcpdump, desde que os dados não estejam criptografados. Isso será útil para comparar se o certificado corresponde ao certificado disponível no truststore.
6. Analise o exemplo tcpdump para a comunicação SSL entre o processador de mensagens e o servidor de back-end.

   Exemplo de tcpdump mostrando o erro "Certificado desconhecido"

   
   

   1. O processador de mensagens (cliente) envia "Client Hello" para o servidor de back-end (servidor) na mensagem nº 59.
   2. O servidor de back-end envia "Server Hello" ao processador de mensagens na mensagem #61.
   3. Eles validam mutuamente os algoritmos de protocolo e pacote de criptografia usados.
   4. O servidor de back-end envia a mensagem "Certificate" e "Server Hello Done" ao processador de mensagens na mensagem nº 68.
   5. O processador de mensagens envia o alerta fatal "Description: Certificate Unknown" na mensagem nº 70.
   6. Analisando melhor a mensagem nº 70, não há outros detalhes além da mensagem de alerta, conforme mostrado abaixo:

      
      

   7. Revise a mensagem nº 68 para conferir os detalhes sobre o certificado enviado pelo servidor de back-end, conforme mostrado no gráfico a seguir:

      

   8. O certificado do servidor de back-end e a cadeia completa estão disponíveis na seção "Certificados", conforme mostrado na figura acima.
7. Se o certificado for desconhecido pelo roteador (norte) ou pelo processador de mensagens (sul), como no exemplo ilustrado acima, siga estas etapas:
   1. Receba o certificado e a cadeia dele armazenados no repositório de confiança específico. Consulte a configuração do host virtual para o roteador e a configuração do endpoint de destino para o processador de mensagens. Você pode usar as seguintes APIs para receber os detalhes do certificado:
      1. Extraia o nome do certificado do truststore:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs

      2. Receba os detalhes do certificado no truststore:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name

   2. Verifique se o certificado armazenado no truststore do roteador (norte) ou do processador de mensagens (sul) corresponde ao certificado armazenado no keystore do aplicativo cliente (norte) ou do servidor de destino (sul), ou ao obtido na saída tcpdump. Se houver uma incompatibilidade, essa será a causa da falha no handshake TLS/SSL.
8. Se o certificado for considerado desconhecido pelo aplicativo cliente (norte) ou pelo servidor de destino (sul), siga estas etapas:
   1. Receba a cadeia de certificados completa usada no certificado armazenado no keystore específico. Consulte a configuração do host virtual para o roteador e a configuração do endpoint de destino para o processador de mensagens. Você pode usar as seguintes APIs para receber os detalhes do certificado:
      1. Acesse o nome do certificado no keystore:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      2. Receba os detalhes do certificado no keystore:
         

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
         

   2. Verifique se o certificado armazenado no keystore do roteador (norte) ou do processador de mensagens (sul) corresponde ao certificado armazenado no repositório de confiança do aplicativo cliente (norte) ou do servidor de destino (sul), ou ao certificado obtido da saída tcpdump. Se houver uma incompatibilidade, essa será a causa da falha no handshake SSL.
9. Se o certificado enviado por um servidor/cliente estiver expirado, o cliente/servidor recebedor vai rejeitar o certificado, e você vai ver a seguinte mensagem de alerta no tcpdump:

   Alerta (nível: fatal, descrição: certificado expirado)

10. Verifique se o certificado no keystore do host apropriado expirou.

Resolução

Para resolver o problema identificado no exemplo acima, faça upload do certificado válido do servidor de back-end para o trustore no processador de mensagens.

A tabela a seguir resume as etapas para resolver o problema, dependendo da causa.

Servidor com SNI ativado

A falha no handshake de TLS/SSL pode ocorrer quando o cliente está se comunicando com um servidor habilitado para indicação de nome do servidor (SNI), mas o cliente não está habilitado para SNI. Isso pode acontecer na conexão de entrada ou de saída no Edge.

Primeiro, identifique o nome do host e o número da porta do servidor em uso e verifique se ele está ativado para SNI ou não.

Identificação do servidor ativado para SNI

1. Execute o comando openssl e tente se conectar ao nome do host do servidor relevante (roteador do Edge ou servidor de back-end) sem transmitir o nome do servidor, conforme mostrado abaixo:

   openssl s_client -connect hostname:port

   É possível receber os certificados e, às vezes, observar a falha de handshake no comando openssl, conforme mostrado abaixo:
   

   CONNECTED(00000003)
   9362:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_clnt.c:593

2. Execute o comando openssl e tente se conectar ao nome do host do servidor relevante (roteador de borda ou servidor de back-end) transmitindo o nome do servidor, conforme mostrado abaixo:

   openssl s_client -connect hostname:port -servername hostname

3. Se você receber uma falha de handshake na etapa 1 ou certificados diferentes nas etapas 1 e 2, isso indica que o servidor especificado está com o SNI ativado.

Depois de identificar que o servidor está com o SNI ativado, siga as etapas abaixo para verificar se a falha no handshake de TLS/SSL é causada pela incapacidade do cliente de se comunicar com o servidor SNI.

Diagnóstico

1. Determine se o erro ocorreu na conexão de entrada ou de saída. Para mais orientações sobre como fazer essa determinação, consulte Determinar a origem do problema.
2. Execute o utilitário tcpdump para coletar mais informações:
   • Se você for um usuário da nuvem privada, poderá coletar os dados tcpdump no cliente ou servidor relevante. Um cliente pode ser o app cliente (para conexões de entrada ou de norte a sul) ou o processador de mensagens (para conexões de saída ou de sul a norte). Um servidor pode ser o roteador de borda (para conexões de entrada ou northbound) ou o servidor de back-end (para conexões de saída ou southbound), com base na sua determinação da etapa 1.
   • Se você for um usuário da nuvem pública, poderá coletar os dados tcpdump apenas no app cliente (para conexões de entrada ou de norte a sul) ou no servidor de back-end (para conexões de saída ou de sul a norte), porque não tem acesso ao roteador de borda ou ao processador de mensagens.

   tcpdump -i any -s 0 host IP address -w File name
   

   Consulte os dados de tcpdump para mais informações sobre como usar o comando tcpdump.
3. Analise a saída tcpdump usando o Wireshark ou uma ferramenta semelhante.
4. Confira a análise de amostra de tcpdump usando o Wireshark:
   1. Neste exemplo, a falha de handshake de TLS/SSL ocorreu entre o processador de mensagens do Edge e o servidor de back-end (conexão de saída).
   2. A mensagem nº 4 na saída tcpdump abaixo mostra que o processador de mensagens (origem) enviou uma mensagem "Client Hello" para o servidor de back-end (destino).

      

   3. Ao selecionar a mensagem "Client Hello", você vê que o processador de mensagens está usando o protocolo TLSv1.2.

      

   4. A mensagem 4 mostra que o servidor de back-end reconhece a mensagem "Client Hello" do Processador de mensagens.
   5. O servidor de back-end envia imediatamente um Alerta fatal : falha no handshake ao processador de mensagens (mensagem nº 5). Isso significa que o handshake TLS/SSL falhou e a conexão será fechada.
   6. Leia a mensagem nº 6 para descobrir as seguintes informações:
      • O servidor de back-end é compatível com o protocolo TLSv1.2. Isso significa que o protocolo correspondeu entre o processador de mensagens e o servidor de back-end.
      • No entanto, o servidor de back-end ainda envia o Alerta fatal: falha no handshake ao Processador de mensagens, conforme mostrado na figura abaixo:

        

   7. Esse erro pode ocorrer por um dos seguintes motivos:
      • O processador de mensagens não está usando os algoritmos de pacote de criptografia compatíveis com o servidor de back-end.
      • O servidor de back-end está ativado para SNI, mas o aplicativo cliente não está enviando o nome do servidor.
   8. Analise a mensagem nº 3 (Client Hello) na saída tcpdump com mais detalhes. Observe que a Extensão: server_name está ausente, conforme mostrado abaixo:

      

   9. Isso confirma que o processador de mensagens não enviou o server_name para o servidor de back-end habilitado para SNI.
   10. Essa é a causa da falha no handshake TLS/SSL e o motivo pelo qual o servidor de back-end envia o Alerta fatal: falha no handshake ao processador de mensagens.
5. Verifique se o jsse.enableSNIExtension property em system.properties está definido como "false" no processador de mensagens para confirmar que ele não está ativado para se comunicar com o servidor habilitado para SNI.

Resolução

Para permitir que os processadores de mensagens se comuniquem com servidores habilitados para SNI, siga estas etapas:

1. Crie o arquivo/opt/apigee/customer/application/message-processor.properties, se ele ainda não existir.
2. Adicione a seguinte linha a esse arquivo: conf_system_jsse.enableSNIExtension=true
3. Mude o proprietário deste arquivo para apigee:apigee:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Reinicie o processador de mensagens.

   /opt/apigee/apigee-service/bin/apigee-service message-processor restart

5. Se você tiver mais de um processador de mensagens, repita as etapas de 1 a 4 em todos eles.

Se não for possível determinar a causa da falha de handshake TLS/SSL e corrigir o problema ou se você precisar de mais ajuda, entre em contato com o suporte do Apigee Edge. Compartilhe os detalhes completos do problema com a saída do tcpdump.