Falhas no handshake de TLS/SSL

Você está vendo a documentação do Apigee Edge.
Acesse a 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 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 é exibido 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

Você também poderá ver essa mensagem de erro quando ocorrer uma falha de handshake de TLS/SSL:

Received fatal alert: handshake_failure

Causas possíveis

TLS (Transport Layer Security, cujo antecessor é 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 que 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 de TLS/SSL for bem-sucedido, o cliente TLS/SSL e o servidor transferirão os 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 para falhas de handshake de TLS/SSL são:

Causa Descrição Quem pode realizar as etapas de solução de problemas
Incompatibilidade de protocolo O protocolo usado pelo cliente não é compatível com o servidor. Usuários de nuvem privada e pública
Incompatibilidade do pacote de criptografia O pacote de criptografia usado pelo cliente não é compatível com o servidor. Usuários de nuvem privada e pública
Certificado incorreto O nome do host no URL usado pelo cliente não corresponde ao nome do host no certificado armazenado no servidor. Usuários de nuvem privada e pública
Uma cadeia de certificados incompleta ou inválida está armazenada no lado do cliente ou do servidor. Usuários de nuvem privada e pública
Um certificado incorreto ou expirado é enviado pelo cliente ao servidor ou do servidor ao cliente. Usuários de nuvem privada e pública
Servidor com SNI ativado A indicação de nome do servidor (SNI, na sigla em inglês) está ativada no servidor de back-end. No entanto, o cliente não pode se comunicar com os servidores SNI. Apenas usuários da nuvem privada

Incompatibilidade de protocolo

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

Diagnóstico

  1. Determine se o erro ocorreu na conexão northbound ou southbound. 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ê é um usuário da nuvem privada, pode coletar os dados de tcpdump no cliente ou servidor relevante. Um cliente pode ser o app cliente (para conexões de entrada ou ao norte) ou o processador de mensagens (para conexões de saída ou sentido sul). Um servidor pode ser o roteador de borda, para conexões de entrada ou para o norte, ou o servidor de back-end, para conexões de saída ou sentido sul, com base na determinação da etapa 1.
    • Se você for um usuário da nuvem pública, poderá coletar os dados de tcpdump somente no app cliente (para conexões de entrada ou para o norte) ou no servidor de back-end (para conexões de saída ou sentido sul), porque você não tem acesso ao roteador de borda ou 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 ferramenta semelhante.
  4. Confira um exemplo de análise do tcpdump usando o Wireshark:
    • Neste exemplo, ocorreu uma falha de handshake de TLS/SSL 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 mensagem "Client Hello" 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 reconhece a mensagem "Client Hello" do processador de mensagens.
    • O servidor de back-end envia imediatamente Fatal Alert : Close notify para o processador de mensagens (mensagem no 6). Isso significa que o handshake de TLS/SSL falhou, e a conexão será encerrada.

    • Analisar mais detalhes na mensagem 6 mostra que a causa da falha de handshake de 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: Fatal Alert Message: Close notify.

Resolução

O processador de mensagens é executado em 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 das etapas a seguir para resolver esse problema:

  1. Faça upgrade do servidor de back-end para que seja compatível com o protocolo TLSv1.2. Essa é uma solução recomendada porque o protocolo TLSv1.2 é mais seguro.
  2. Se não for possível 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 o 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

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

Diagnóstico

  1. Determine se o erro ocorreu na 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 utilitário tcpdump para coletar mais informações:
    • Se você é um usuário da nuvem privada, pode coletar os dados de tcpdump no cliente ou servidor relevante. Um cliente pode ser o app cliente (para conexões de entrada ou ao norte) ou o processador de mensagens (para conexões de saída ou sentido sul). Um servidor pode ser o roteador de borda, para conexões de entrada ou para o norte, ou o servidor de back-end, para conexões de saída ou sentido sul, com base na determinação da etapa 1.
    • Se você for um usuário da nuvem pública, poderá coletar os dados de tcpdump somente no app cliente (para conexões de entrada ou para o norte) ou no servidor de back-end (para conexões de saída ou sentido sul), porque você não tem acesso ao roteador de borda ou 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. Veja a seguir o exemplo de análise da saída tcpdump usando o Wireshark:
    • Neste exemplo, ocorreu uma falha de handshake de TLS/SSL entre o aplicativo cliente e o roteador de borda (conexão no sentido norte). A saída tcpdump foi coletada no roteador de borda.

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

    • Selecionar a mensagem Client Hello mostra 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 de handshake para o aplicativo cliente (mensagem 6). Isso significa que o handshake de TLS/SSL falhou, e a conexão será encerrada.
    • Analisar mais a mensagem 6 mostra as seguintes informações:
      • O roteador de borda é compatível com o protocolo TLSv1.2. Isso significa que o protocolo faz a correspondência entre o aplicativo cliente e o roteador de borda.

      • No entanto, o roteador de borda ainda envia o Alerta fatal: falha de handshake para o 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 roteador de borda está ativado para SNI, mas o aplicativo cliente não está enviando o nome do servidor.
    • A mensagem 4 na saída de tcpdump lista os algoritmos do pacote de criptografia com suporte do aplicativo cliente, conforme mostrado abaixo:

    • A lista de algoritmos do pacote de criptografia compatíveis com o roteador de borda está listada no arquivo /opt/nginx/conf.d/0-default.conf. Neste exemplo, o roteador de borda é compatível apenas com os 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 roteador de borda é ativado para SNI, role para baixo até a mensagem 4 na saída tcpdump e confirme se o aplicativo cliente está enviando o nome do servidor corretamente, como mostrado na figura abaixo:


    • Se esse nome for válido, será possível inferir que a falha de handshake de TLS/SSL ocorreu porque os algoritmos do pacote 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 com suporte do servidor. Para resolver o problema descrito na seção "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 aos algoritmos do pacote de criptografia 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 (sentido norte) ou de saída (sentido sul) na Apigee Edge. Consulte também Noções básicas sobre as conexões de norte e sul.

Se o problema estiver no 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.

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

As causas mais comuns desse problema são:

Causa Descrição Quem pode realizar as etapas de solução de problemas
Incompatibilidade de nome do host O nome do host usado no URL não corresponde ao certificado no keystore do roteador. Por exemplo, uma incompatibilidade ocorrerá se o nome do host usado no URL for myorg.domain.com, enquanto o certificado tiver o nome do host no CN como CN=something.domain.com.

 Usuários de nuvem privada e pública do Edge
Cadeia de certificados incompleta ou incorreta A cadeia de certificados não está completa ou não está correta. Somente usuários de nuvem privada e pública de borda
Certificado expirado ou desconhecido enviado pelo servidor ou cliente Um certificado expirado ou desconhecido é enviado pelo servidor ou cliente no sentido norte ou na conexão sul. Usuários da nuvem privada do Edge e da nuvem pública do Edge

Incompatibilidade de nome do host

Diagnóstico

  1. Anote o nome do host usado no URL retornado pela seguinte chamada da API Edge Management: 
    curl -v https://myorg.domain.com/v1/getinfo
    Exemplo: 
    curl -v https://api.enterprise.apigee.com/v1/getinfo
  2. Acessa o CN usado no certificado armazenado no keystore específico. É possível usar as 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. Consiga os detalhes do certificado no keystore usando a API Edge Management.

      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 da API (consulte a etapa 1 acima) e o nome do assunto no certificado não correspondem, você recebe a falha de handshake de TLS/SSL.

Resolução

Esse problema pode ser resolvido de uma das seguintes maneiras:

  • Consiga um certificado (se ainda não tiver um) em que o assunto CN tenha um certificado curinga e faça upload da nova cadeia completa de certificados para o keystore. Por exemplo: 
    "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",
  • Consiga um certificado (se ainda não tiver um) com um CN de assunto, mas use your-org.your-domain como um nome alternativo do assunto e, em seguida, faça upload de toda a cadeia de certificados para o keystore.

Referências

Keystores e Truststores

Cadeia de certificados incompleta ou incorreta

Diagnóstico

  1. Acessa o CN usado no certificado armazenado no keystore específico. É possível usar as seguintes APIs de gerenciamento de borda para acessar os detalhes do certificado:
    1. Consiga 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. Confira 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 ele está em conformidade com as diretrizes fornecidas no artigo Como funcionam as cadeias de certificados 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ê verá a falha de handshake de TLS/SSL.
    4. O gráfico a seguir mostra um exemplo de certificado com uma cadeia de certificados inválida, em que os certificados intermediários e raiz não correspondem:

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


Resolução

  1. Consiga um certificado (se 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 validados no keystore.

Certificado expirado ou desconhecido enviado pelo servidor ou cliente

Se um certificado incorreto/expirado for enviado pelo servidor/cliente no sentido norte ou na conexão sul, a outra extremidade rejeitará o certificado, levando a uma falha de handshake de TLS/SSL.

Diagnóstico

  1. Determine se o erro ocorreu na conexão northbound ou southbound. 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ê é um usuário da nuvem privada, pode coletar os dados de tcpdump no cliente ou servidor relevante. Um cliente pode ser o app cliente (para conexões de entrada ou ao norte) ou o processador de mensagens (para conexões de saída ou sentido sul). Um servidor pode ser o roteador de borda, para conexões de entrada ou para o norte, ou o servidor de back-end, para conexões de saída ou sentido sul, com base na determinação da etapa 1.
    • Se você for um usuário da nuvem pública, poderá coletar os dados de tcpdump somente no app cliente (para conexões de entrada ou para o norte) ou no servidor de back-end (para conexões de saída ou sentido sul), porque você não tem acesso ao roteador de borda ou 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. É possível recuperar o certificado enviado pela outra extremidade da saída tcpdump, desde que os dados não estejam criptografados. Isso será útil para comparar se esse certificado corresponde ao disponível no truststore.
  6. Revise a amostra tcpdump para comunicação SSL entre o processador de mensagens e o servidor de back-end.

    Exemplo de tcpdump mostrando o erro de certificado desconhecido


    1. O processador de mensagens (cliente) envia a mensagem "Client Hello" ao servidor de back-end (servidor) na mensagem 59.
    2. O servidor de back-end envia "Server Hello" ao processador de mensagens na mensagem 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 and Server Hello Done" para o processador de mensagens na mensagem 68.
    5. O processador de mensagens envia o alerta fatal "Description: Certificate Unknown" da mensagem 70.
    6. Analisando a mensagem no 70, não há detalhes além da mensagem de alerta, conforme mostrado abaixo:


    7. Revise a mensagem 68 para ver 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 dele estão disponíveis abaixo da seção "Certificados", conforme mostrado na figura acima.
  7. Se o certificado for desconhecido pelo roteador (sentido norte) ou pelo processador de mensagens (sentido sul), como no exemplo ilustrado acima, siga estas etapas:
    1. Acessa o certificado e a cadeia dele armazenadas no truststore específico. (Consulte a configuração do host virtual para o roteador e para a configuração do endpoint de destino para o processador de mensagens). É possível usar as seguintes APIs para ver os detalhes do certificado:
      1. Consiga 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. Consiga 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 processador de mensagens (sentido sul) corresponde ao certificado armazenado no keystore do aplicativo cliente (sentido norte), do servidor de destino (sentido sul) ou daquele recebido da saída tcpdump. Se houver incompatibilidade, essa será a causa da falha de handshake de TLS/SSL.
  8. Se o certificado for desconhecido pelo aplicativo cliente (sentido norte) ou pelo servidor de destino (sentido sul), siga estas etapas:
    1. Acesse 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.) É possível usar as seguintes APIs para ver os detalhes do certificado:
      1. Consiga 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. Consiga 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 (sentido norte) ou processador de mensagens (sentido sul) corresponde ao certificado armazenado no truststore do aplicativo cliente (sentido norte), do servidor de destino (sentido sul) ou daquele que é recebido da saída tcpdump. Se houver incompatibilidade, essa será a causa da falha de handshake de SSL.
  9. Se o certificado enviado por um servidor/cliente for considerado expirado, o cliente/servidor de recebimento o rejeitará e você 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 do servidor de back-end válido para o trustore no processador de mensagens.

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

Causa Descrição Resolução
Certificado expirado NorthBound
  • O certificado armazenado no keystore do roteador expirou.
  • O certificado armazenado no keystore do aplicativo cliente expirou (SSL bidirecional).
 Faça upload de um novo certificado e da cadeia completa dele para o keystore no host apropriado.
SouthBound
  • O certificado armazenado no keystore do Servidor de destino expirou.
  • O certificado armazenado no keystore do processador de mensagens expirou (SSL bidirecional).
 Faça upload de um novo certificado e da cadeia completa dele para o keystore no host apropriado.
Certificado desconhecido NorthBound
  • O certificado armazenado no truststore do aplicativo cliente não corresponde ao certificado do roteador.
  • O certificado armazenado no truststore do roteador não corresponde ao certificado do aplicativo cliente (SSL bidirecional).
 Faça upload do certificado válido para o truststore no host apropriado.
SouthBound
  • O certificado armazenado no truststore do servidor de destino não corresponde ao certificado do processador de mensagens.
  • O certificado armazenado no truststore do processador de mensagens não corresponde ao certificado do servidor de destino (SSL bidirecional).
 Faça upload do certificado válido para o truststore no host apropriado.

Servidor com SNI ativado

A falha de handshake de TLS/SSL pode ocorrer quando o cliente está se comunicando com um servidor ativado por indicação de nome de servidor (SNI, na sigla em inglês), mas o cliente não está com esse recurso ativado. Isso pode acontecer no sentido norte ou na 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 o SNI está ativado ou não.

Identificação do servidor com SNI ativado

  1. Execute o comando openssl e tente se conectar ao nome do host do servidor relevante (roteador de borda ou servidor de back-end) sem transmitir o nome do servidor, conforme mostrado abaixo: 
    openssl s_client -connect hostname:port
    Talvez você receba os certificados e, às vezes, vai notar a falha de handshake no comando openssl, como 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 como mostrado abaixo: 
    openssl s_client -connect hostname:port -servername hostname
  3. Se você receber uma falha de handshake na etapa 1 ou receber certificados diferentes nas etapas 1 e 2, isso indica que o servidor especificado tem a SNI ativada.

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

Diagnóstico

  1. Determine se o erro ocorreu na conexão northbound ou southbound. 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ê é um usuário da nuvem privada, pode coletar os dados de tcpdump no cliente ou servidor relevante. Um cliente pode ser o app cliente (para conexões de entrada ou ao norte) ou o processador de mensagens (para conexões de saída ou sentido sul). Um servidor pode ser o roteador de borda, para conexões de entrada ou para o norte, ou o servidor de back-end, para conexões de saída ou sentido sul, com base na determinação da etapa 1.
    • Se você for um usuário da nuvem pública, poderá coletar os dados de tcpdump somente no app cliente (para conexões de entrada ou para o norte) ou no servidor de back-end (para conexões de saída ou sentido sul), porque você não tem acesso ao roteador de borda ou 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 um exemplo de análise 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 no sentido sul).
    2. A mensagem 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. A seleção da mensagem "Client Hello" mostra que o processador de mensagens está usando o protocolo TLSv1.2.

    4. A mensagem no 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 de handshake para o processador de mensagens (mensagem no 5). Isso significa que o handshake de TLS/SSL falhou, e a conexão será encerrada.
    6. Leia a mensagem 6 para conferir as informações a seguir
      • O servidor de back-end é compatível com o protocolo TLSv1.2. Isso significa que o protocolo é correspondido entre o processador de mensagens e o servidor de back-end.
      • No entanto, o servidor de back-end ainda envia o Alerta fatal: falha de handshake para o 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 compatíveis com o servidor de back-end.
      • O servidor de back-end está ativado por SNI, mas o aplicativo cliente não está enviando o nome do servidor.
    8. Analise a mensagem no 3 (Client Hello) na saída tcpdump com mais detalhes. Observe que o Extension: server_name está ausente, conforme mostrado abaixo:

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

Resolução

Para permitir que o(s) processador(es) de mensagens se comunique com os servidores ativados por 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. Transferir 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 os processadores de mensagens.

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