Falhas no handshake de TLS/SSL

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

Sintoma

Uma falha de handshake de TLS/SSL ocorre quando um cliente e um servidor não conseguem estabelecer a comunicação usando o protocolo TLS/SSL. Quando esse erro ocorre no Apigee Edge, o cliente receberá um status HTTP 503 com a mensagem Service Unavailable. Você verá esse erro 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

Também é possível ver essa mensagem de erro quando ocorre uma falha de handshake de TLS/SSL:

Received fatal alert: handshake_failure

Causas possíveis

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

1. Combine a versão do protocolo a ser usada.
2. Selecione o algoritmo criptográfico a ser usado.
3. Autenticar uns aos outros trocando e validando certificados digitais.

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

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

Protocolo Incompatibilidade

Uma falha de handshake de TLS/SSL ocorre se o protocolo usado pelo cliente não for suportado pelo na conexão de entrada (sentido norte) ou de saída (sentido sul). Consulte também Entender as conexões dos sentidos norte e sul.

Diagnóstico

1. Determine se o erro ocorreu no sentido norte ou southbound. Para mais orientações sobre como determinação, consulte Determinar a origem do problema.
2. Execute o tcpdump para coletar mais informações:
   • Se você for usuário da nuvem privada, poderá coletar o tcpdump os dados no cliente ou servidor relevante. Um cliente pode ser o aplicativo cliente (para entrada, ou conexões ao norte) ou a mensagem Processador (para conexões de saída ou no sentido sul). Um servidor pode ser o Edge Router (por conexões de entrada ou ao norte) ou o servidor de back-end (para conexões de saída ou no sentido sul) com base na sua determinação da Etapa 1.
   • Se você for usuário da nuvem pública, poderá coletar o tcpdump dados somente no app cliente (para conexões de entrada ou no sentido norte) ou no servidor de back-end (para conexões de saída ou no sentido sul), porque você precisa sem acesso ao Edge Router ou ao Processador de mensagens.

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

   Consulte tcpdump para mais informações sobre como usar o tcpdump kubectl.
3. analisar os dados do tcpdump usando a ferramenta Wireshark; ou uma ferramenta semelhante.
4. Aqui está um exemplo de análise tcpdump usando o Wireshark:
   • Nesse 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 sentido sul).
   • A mensagem 4 na saída de tcpdump abaixo mostra que o processador de mensagens (origem) enviou uma "Olá, cliente" para o servidor de back-end (destino).
     

     

   • Se você selecionar a mensagem Client Hello, ela 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 confirma a "Client Hello" mensagem de o processador de mensagens.
   • O servidor de back-end envia imediatamente Alerta fatal : Fechar notificação para o Processador de mensagens (mensagem no 6). Isso significa que o handshake de TLS/SSL falhou e a conexão ser fechado.

   • Analisar mais detalhadamente a mensagem 6 mostra que a causa da falha de handshake de TLS/SSL é o servidor de back-end só é compatível com o protocolo TLSv1.0, conforme mostrado abaixo:

     

   • Como não há correspondência entre o protocolo usado pelo processador de mensagens e o servidor de back-end, ele enviou a mensagem: Fatal Alert Message: Close Notificar.

Resolução

O processador de mensagens é executado em Java 8 e usa o protocolo TLSv1.2 por padrão. Se o back-end não oferecer suporte ao protocolo TLSv1.2, siga uma das etapas abaixo para resolver esse problema:

1. Faça upgrade do servidor de back-end para que ele seja compatível com o protocolo TLSv1.2. Essa é uma solução recomendada, o protocolo TLSv1.2 é mais seguro.
2. Se você não conseguir fazer upgrade do servidor de back-end imediatamente por algum motivo, será possível forçar 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 tiver especificado um servidor de destino na definição de TargetEndpoint do proxy, defina o elemento Protocol ao 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 o proxy e, em seguida, use dessa API de gerenciamento para definir o protocolo como TLSv1.0 no na configuração do servidor de destino.

Incompatibilidade de criptografia

Uma falha de handshake de TLS/SSL pode ocorrer se o algoritmo do pacote de criptografia usado pelo cliente não estiver suportado pelo servidor na conexão de entrada (sentido norte) ou de saída (sentido sul) no Apigee Edge. Consulte também Entender as conexões dos sentidos norte e sul.

Diagnóstico

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

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

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

   • A mensagem 4 na saída de tcpdump abaixo mostra que o aplicativo cliente (origem) enviou uma "Olá, cliente" para o roteador de borda (destino).

     

   • Selecionar a mensagem Client Hello mostra que o aplicativo cliente está usando o protocolo TLSv1.2.

     

   • A mensagem no 5 mostra que o roteador de borda reconhece a chamada "Client Hello" mensagem de aplicativo cliente.
   • O roteador de borda envia imediatamente um Alerta fatal : falha de handshake para aplicativo cliente (mensagem 6). Isso significa que o handshake de TLS/SSL falhou e a conexão será fechado.
   • Analisar mais detalhadamente a mensagem no 6 mostra as seguintes informações:
     • O roteador de borda oferece suporte ao protocolo TLSv1.2. Isso significa que o protocolo corresponde entre o aplicativo cliente e o roteador de borda.

     • No entanto, o roteador de borda ainda envia o alerta fatal: handshake Falha no aplicativo cliente, conforme mostrado na captura de tela abaixo:

       

   • O erro pode ser causado por um dos seguintes problemas:
     • O aplicativo cliente não está usando os algoritmos do pacote de criptografia aceitos pelo Roteador de borda.
     • O Edge Router está ativado para SNI, mas o aplicativo cliente não está enviando a do servidor de anúncios.
   • A mensagem 4 na saída de tcpdump lista os algoritmos do pacote de criptografia aceitos pelo cliente. do aplicativo, conforme mostrado abaixo:

     

   • Os algoritmos do pacote de criptografia aceitos pelo Edge Router estão listados no /opt/nginx/conf.d/0-default.conf. Neste exemplo, o roteador de borda oferece suporte apenas aos algoritmos do pacote de criptografia de alta criptografia.
   • O aplicativo cliente não usa nenhum dos algoritmos do pacote de criptografia de alta criptografia. Essa incompatibilidade é a causa da Falha de handshake de TLS/SSL.
   • Como o Edge Router está ativado para SNI, role para baixo até a mensagem no 4 na saída tcpdump e confirme se o aplicativo cliente está enviando o nome do servidor corretamente, como mostrado Figura abaixo:
     
     e
     
   • Se esse nome for válido, você poderá inferir que a falha de handshake de TLS/SSL ocorreu porque os algoritmos do pacote de criptografia usados pelo aplicativo cliente não têm suporte da o roteador de borda.

Resolução

Você precisa garantir que o cliente use os algoritmos do pacote de criptografia que estão suportado pelo servidor. Para solucionar o problema descrito na seção na seção "Diagnóstico", faça o download e instale pacote Java Cryptoography Extension (JCE) e incluí-lo no para dar suporte a algoritmos do pacote de criptografia de alta criptografia.

Certificado incorreto

Uma falha de handshake de TLS/SSL ocorre quando há certificados incorretos no keystore/truststore, na conexão de entrada (sentido norte) ou de saída (sentido sul) no Apigee Edge. Consulte também Entender as conexões dos sentidos norte e sul.

Se o problema for sentido norte, talvez você veja mensagens de erro diferentes dependendo da causa subjacente.

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

Mensagens de erro

Talvez você veja mensagens de erro diferentes, dependendo da causa da falha de handshake de TLS/SSL. Este é um exemplo de mensagem de erro que pode aparecer quando você chama 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

Estas são as causas mais comuns desse problema:

Nome do host Incompatibilidade

Diagnóstico

1. Observe o nome do host usado no URL retornado pela seguinte chamada da API Edge Management:

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

   Por exemplo:

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

2. Encontre o CN usado no certificado armazenado no keystore específico. Você pode usar o seguintes APIs de gerenciamento de borda para acessar os detalhes do certificado:
   1. Encontre o nome do certificado no keystore:
      
      Se você for um usuário da nuvem privada, 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. Acesse os detalhes do certificado no keystore usando a API Edge Management.
      
      Se você for 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 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 da API (consulte a etapa 1 acima) e o assunto nome no certificado não forem correspondentes, ocorrerá a falha de handshake de TLS/SSL.

Resolução

Esse problema pode ser resolvido de duas maneiras:

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

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

• Consiga um certificado (se ainda não tiver) com um CN do assunto existente, mas use your-org:your-domain como nome alternativo do assunto e faça o upload do cadeia de certificados ao keystore.

Referências

Keystores e Truststores

Cadeia de certificados incompleta ou incorreta

Diagnóstico

1. Encontre o CN usado no certificado armazenado no keystore específico. Você pode usar o seguintes APIs de gerenciamento de borda para acessar os detalhes do certificado:
   1. Encontre o nome do certificado no keystore:
      
      Se você for 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 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. Acesse os detalhes do certificado no keystore:
      
      Se você for 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 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. validar o certificado e a cadeia dele e verificar se estão em conformidade às diretrizes do artigo como as cadeias de certificados funcionam para garantir que o certificado seja um certificado cadeia de certificados. Se a cadeia de certificados armazenada no keystore estiver incompleto ou inválido, será exibido o handshake de TLS/SSL falha.
   4. O gráfico a seguir mostra um exemplo de certificado com uma cadeia de certificados 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 corresponde

   
   

Resolução

1. Obtenha um certificado (se ainda não tiver) que inclua um certificado completo e válido cadeia de certificados.
2. Execute o comando openssl a seguir para verificar se a cadeia de certificados está correta e completar:

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

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

Expirado ou desconhecido certificado enviado pelo servidor ou cliente

Se um certificado incorreto/expirado for enviado pelo servidor/cliente na direção norte ou na conexão sul, a outra extremidade (servidor/cliente) rejeita o certificado levando a uma falha de handshake de TLS/SSL.

Diagnóstico

1. Determine se o erro ocorreu no sentido norte ou southbound. Para mais orientações sobre como determinação, consulte Determinar a origem do problema.
2. Execute o tcpdump para coletar mais informações:
   • Se você for usuário da nuvem privada, poderá coletar o tcpdump os dados no cliente ou servidor relevante. Um cliente pode ser o aplicativo cliente (para entrada, ou conexões ao norte) ou a mensagem Processador (para conexões de saída ou no sentido sul). Um servidor pode ser o Edge Router (por conexões de entrada ou ao norte) ou o servidor de back-end (para conexões de saída ou no sentido sul) com base na sua determinação da Etapa 1.
   • Se você for usuário da nuvem pública, poderá coletar o tcpdump dados somente no app cliente (para conexões de entrada ou no sentido norte) ou no servidor de back-end (para conexões de saída ou no sentido sul), porque você precisa sem acesso ao Edge Router ou ao Processador de mensagens.

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

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

   Exemplo tcpdump mostrando um erro de certificado desconhecido

   
   

   1. O processador de mensagens (cliente) envia "Client Hello" para o servidor de back-end (servidor) na mensagem 59.
   2. O servidor de back-end envia "Server Hello" para o processador de mensagens na mensagem No 61.
   3. Eles validam mutuamente o protocolo e os algoritmos do pacote de criptografia usados.
   4. O servidor de back-end envia a mensagem "Certificate e Server Hello Done" para Processador de mensagens na mensagem 68.
   5. O processador de mensagens envia o alerta fatal "Description: Certificate "Desconhecido" na mensagem 70.
   6. Analisando mais a mensagem no 70, não há detalhes adicionais a mais do que a mensagem de alerta, conforme mostrado abaixo:

      
      

   7. Revise a mensagem no 68 para conferir os detalhes sobre o certificado enviado pelo back-end de contêiner, como mostrado no gráfico a seguir:

      

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

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

      2. Acesse 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 (sentido norte) ou O processador de mensagens (sentido sul) corresponde ao certificado armazenado no o keystore do aplicativo cliente (sentido norte) ou servidor de destino (sentido sul), ou um que é obtido da saída tcpdump. Se houver uma incompatibilidade, essa é a causa da falha de handshake de TLS/SSL.
8. Se o certificado for desconhecido pelo aplicativo cliente (direcionado ao norte) ou no servidor de destino (sentido sul) e, em seguida, siga estas etapas:
   1. Consulte a cadeia completa de certificados usada no certificado armazenado no um repositório de chaves de acesso. (Consulte a configuração do host virtual para o roteador e o endpoint de destino do processador de mensagens.) Você pode usar as seguintes APIs para obter o do certificado:
      1. Encontre 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. Acesse 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 (no sentido norte) ou O processador de mensagens (sentido sul) corresponde ao certificado armazenado no truststore do aplicativo cliente (direcionado ao norte), servidor de destino (direcionado ao sul) ou ao aplicativo da saída tcpdump. Se houver incompatibilidade, essa será a causa do problema de SSL falha de handshake.
9. Se o certificado enviado por um servidor/cliente estiver vencido, o destinatário o cliente/servidor rejeitará o certificado e você verá a seguinte mensagem de alerta 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 o upload do arquivo certificado para o Trustore no Processador de mensagens.

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

SNI ativado Servidor

A falha de handshake de TLS/SSL pode ocorrer quando o cliente está se comunicando com um servidor Indicação de nome (SNI) ativada Server, mas o cliente não está ativado para SNI. Isso pode acontecer no sentido norte conexão sul no Edge.

Primeiro você precisa identificar o nome do host e o número da porta do servidor que está sendo usado e verificar se se o SNI está ativado ou não.

Identificação do servidor com SNI ativada

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

   openssl s_client -connect hostname:port
   

   É possível que você receba os certificados e, às vezes, pode observar a falha de handshake o 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 etapa 2, ele indicará que o servidor especificado está com o SNI ativado.

Depois de identificar se o servidor está com o SNI ativado, siga as etapas abaixo para Verifique se a falha de handshake de TLS/SSL foi causada porque o cliente não consegue se comunicar com servidor SNI.

Diagnóstico

1. Determine se o erro ocorreu no sentido norte ou southbound. Para mais orientações sobre como determinação, consulte Determinar a origem do problema.
2. Execute o tcpdump para coletar mais informações:
   • Se você for usuário da nuvem privada, poderá coletar o tcpdump os dados no cliente ou servidor relevante. Um cliente pode ser o aplicativo cliente (para entrada, ou conexões ao norte) ou a mensagem Processador (para conexões de saída ou no sentido sul). Um servidor pode ser o Edge Router (por conexões de entrada ou ao norte) ou o servidor de back-end (para conexões de saída ou no sentido sul) com base na sua determinação da Etapa 1.
   • Se você for usuário da nuvem pública, poderá coletar o tcpdump dados somente no app cliente (para conexões de entrada ou no sentido norte) ou no servidor de back-end (para conexões de saída ou no sentido sul), porque você precisa sem acesso ao Edge Router ou ao Processador de mensagens.

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

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

      

   3. Selecionar "Client Hello" mostra que a mensagem O processador está usando o protocolo TLSv1.2.

      

   4. A mensagem no 4 mostra que o servidor de back-end confirma o "Client Hello" mensagem do processador de mensagens.
   5. O servidor de back-end envia imediatamente um Alerta fatal : handshake Falha no processador de mensagens (mensagem no 5). Isso significa que o handshake TLS/SSL falhou e a conexão será encerrada.
   6. Revise a mensagem 6 para descobrir as seguintes informações
      • O servidor de back-end é compatível com o protocolo TLSv1.2. Isso significa que o protocolo correspondentes entre o processador de mensagens e o servidor de back-end.
      • No entanto, o servidor de back-end ainda envia o alerta fatal: handshake Falha no 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 do pacote de criptografia com suporte do 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 3 (Hello Client) na saída tcpdump com mais detalhes. Observe que o 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 ativado para SNI;
   10. Essa é a causa da falha de handshake de TLS/SSL e o motivo pelo qual o back-end servidor envia o Alerta fatal: falha no handshake para a mensagem Processador
5. Verifique se jsse.enableSNIExtension property na system.properties é definido como falso no processador de mensagens para confirmar que o O processador de mensagens não está ativado para se comunicar com o servidor habilitado para SNI.

Resolução

Permita que os processadores de mensagens se comuniquem com servidores habilitados para SNI realizando o etapas a seguir:

1. Crie o /opt/apigee/customer/application/message-processor.properties (se ainda não existir).
2. Adicione a seguinte linha ao 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 Processadores de mensagens

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