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:
- Concorde com a versão do protocolo a ser usada.
- Selecione o algoritmo criptográfico a ser usado.
- 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
- 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.
- 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 comandotcpdump
. - Se você é um usuário da nuvem privada, pode coletar os dados de
- Analise os dados de
tcpdump
usando a ferramenta Wireshark ou uma ferramenta semelhante. - 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:
- 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.
- 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:
- Se você não especificou um servidor de destino na definição de TargetEndpoint do proxy, defina
o elemento
Protocol
comoTLSv1.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>
- 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.
- Se você não especificou um servidor de destino na definição de TargetEndpoint do proxy, defina
o elemento
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
- 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.
- 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 comandotcpdump
. - Se você é um usuário da nuvem privada, pode coletar os dados de
- Analise os dados de
tcpdump
usando a ferramenta Wireshark ou qualquer outra que você conheça. - 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.
- 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
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
- 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
- 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:
-
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
-
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.
-
Encontre o nome do certificado no keystore:
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
Cadeia de certificados incompleta ou incorreta
Diagnóstico
- 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:
-
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
-
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
- 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.
- 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:
Exemplo de certificado intermediário e raiz em que o emissor e o assunto não correspondem
-
Consiga o nome do certificado no keystore:
Resolução
- Consiga um certificado (se ainda não tiver um) que inclua uma cadeia de certificados completa e válida.
- 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
- 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
- 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.
- 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 comandotcpdump
. - Se você é um usuário da nuvem privada, pode coletar os dados de
- Analise os dados de
tcpdump
usando o Wireshark ou uma ferramenta semelhante. - Na saída
tcpdump
, determine o host (cliente ou servidor) que está rejeitando o certificado durante a etapa de verificação. - É 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. - 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
- O processador de mensagens (cliente) envia a mensagem "Client Hello" ao servidor de back-end (servidor) na mensagem 59.
- O servidor de back-end envia "Server Hello" ao processador de mensagens na mensagem 61.
- Eles validam mutuamente o protocolo e os algoritmos do pacote de criptografia usados.
- O servidor de back-end envia a mensagem "Certificate and Server Hello Done" para o processador de mensagens na mensagem 68.
- O processador de mensagens envia o alerta fatal "Description: Certificate Unknown" da mensagem 70.
- Analisando a mensagem no 70, não há detalhes além da mensagem de alerta, conforme mostrado abaixo:
- Revise a mensagem 68 para ver os detalhes sobre o certificado enviado pelo servidor de back-end, conforme mostrado no gráfico a seguir:
- 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.
- Se o certificado for desconhecido pelo roteador (sentido norte) ou pelo processador de mensagens (sentido sul), como no exemplo ilustrado acima, siga estas etapas:
- 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:
-
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
-
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
-
Consiga o nome do certificado no truststore:
- 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.
- 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:
- Se o certificado for desconhecido pelo aplicativo cliente (sentido norte)
ou pelo servidor de destino (sentido sul), siga estas etapas:
- 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:
-
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
-
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
-
Consiga o nome do certificado no keystore:
- 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.
- 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:
- 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)
- 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
|
Faça upload de um novo certificado e da cadeia completa dele para o keystore no host apropriado. |
SouthBound
|
Faça upload de um novo certificado e da cadeia completa dele para o keystore no host apropriado. | |
Certificado desconhecido |
NorthBound
|
Faça upload do certificado válido para o truststore no host apropriado. |
SouthBound
|
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
- 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
- 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
- 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
- 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.
- 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 comandotcpdump
. - Se você é um usuário da nuvem privada, pode coletar os dados de
- Analise a saída
tcpdump
usando o Wireshark ou uma ferramenta semelhante. - Confira um exemplo de análise de
tcpdump
usando o Wireshark:- 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).
- 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). - A seleção da mensagem "Client Hello" mostra que o processador de mensagens está usando o protocolo TLSv1.2.
- A mensagem no 4 mostra que o servidor de back-end reconhece a mensagem "Client Hello" do processador de mensagens.
- 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.
- 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:
- 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.
- 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: - Isso confirma que o processador de mensagens não enviou o server_name ao servidor de back-end com SNI.
- 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.
- Verifique se o
jsse.enableSNIExtension property
emsystem.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:
- Crie o arquivo
/opt/apigee/customer/application/message-processor.properties
(se ele ainda não existir). - Adicione a seguinte linha a esse arquivo:
conf_system_jsse.enableSNIExtension=true
- Transferir o proprietário deste arquivo para
apigee:apigee
:chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
- Reinicie o processador de mensagens.
/opt/apigee/apigee-service/bin/apigee-service message-processor restart
- 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
.