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:
- Combine a versão do protocolo a ser usada.
- Selecione o algoritmo criptográfico a ser usado.
- 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:
Causa | Descrição | Quem pode executar as etapas de solução de problemas |
---|---|---|
Incompatibilidade de protocolo | O protocolo usado pelo cliente não é suportado pelo servidor. | Usuários de nuvem privada e pública |
Incompatibilidade no pacote de criptografia | O pacote de criptografia usado pelo cliente não tem suporte do 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 armazenadas no servidor. | Usuários de nuvem privada e pública |
Uma cadeia de certificados incompleta ou inválida é armazenada na extremidade do cliente ou 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 | O servidor de back-end está com a indicação de nome do servidor (SNI, na sigla em inglês) ativada. No entanto, o cliente não pode se comunicar com o servidores SNI. | Somente usuários da nuvem privada |
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
- Determine se o erro ocorreu no sentido norte ou southbound. Para mais orientações sobre como determinação, consulte Determinar a origem do problema.
- 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.
Consulte tcpdump para mais informações sobre como usar otcpdump -i any -s 0 host IP address -w File name
tcpdump
kubectl. - Se você for usuário da nuvem privada, poderá coletar o
- analisar os dados do
tcpdump
usando a ferramenta Wireshark; ou uma ferramenta semelhante. - 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:
- 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.
- 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:
- Se você não tiver especificado um servidor de destino na definição de TargetEndpoint do proxy, defina
o elemento
Protocol
aoTLSv1.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 e, em seguida, use dessa API de gerenciamento para definir o protocolo como TLSv1.0 no na configuração do servidor de destino.
- Se você não tiver especificado um servidor de destino na definição de TargetEndpoint do proxy, defina
o elemento
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
- 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.
- 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.
Consulte tcpdump para mais informações sobre como usar o comandotcpdump -i any -s 0 host IP address -w File name
tcpdump
. - Se você for usuário da nuvem privada, poderá coletar o
- Analisar os dados do
tcpdump
usando a ferramenta Wireshark ou qualquer outra ferramenta que você conheça. - 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.
- 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
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:
Causa | Descrição | Quem pode executar as etapas de solução de problemas |
Incompatibilidade do nome do host |
O nome do host usado no URL e o certificado no keystore do roteador não
são correspondentes. Por exemplo, vai ocorrer uma incompatibilidade se o nome do host usado no URL for myorg.domain.com , enquanto
o certificado tem o nome do host em seu CN como CN=something.domain.com.
|
Usuários de nuvem pública e privada de borda |
Certificado incompleto ou incorreto corrente | A cadeia de certificados não está completa ou não está correta. | Apenas usuários de borda privada e de nuvem pública |
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 com sentido sul. | Usuários da nuvem privada de borda e da nuvem pública de borda |
Nome do host Incompatibilidade
Diagnóstico
- Observe o nome do host usado no URL retornado pela seguinte chamada da API Edge Management:
Por exemplo:curl -v https://myorg.domain.com/v1/getinfo
curl -v https://api.enterprise.apigee.com/v1/getinfo
- 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:
-
Encontre o nome do certificado no keystore:
Se você for um usuário da nuvem privada, use a API Management da seguinte maneira:
Se você for um usuário da nuvem pública, 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
curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
-
Acesse os detalhes do certificado no keystore usando a API Edge Management.
Se você for usuário da nuvem privada:
Se você for usuário da nuvem pública:curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
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.
-
Encontre o nome do certificado no keystore:
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
Cadeia de certificados incompleta ou incorreta
Diagnóstico
- 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:
-
Encontre o nome do certificado no keystore:
Se você for usuário da nuvem privada:
Se você for usuário da nuvem pública:curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
-
Acesse os detalhes do certificado no keystore:
Se você for usuário da nuvem privada:
Se você for usuário da nuvem pública:curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
- 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.
- 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
-
Encontre o nome do certificado no keystore:
Resolução
- Obtenha um certificado (se ainda não tiver) que inclua um certificado completo e válido cadeia de certificados.
- 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
- 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
- Determine se o erro ocorreu no sentido norte ou southbound. Para mais orientações sobre como determinação, consulte Determinar a origem do problema.
- 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.
Consulte tcpdump para mais informações sobre como usar o comandotcpdump -i any -s 0 host IP address -w File name
tcpdump
. - Se você for usuário da nuvem privada, poderá coletar o
- Analise os dados de
tcpdump
usando o Wireshark ou semelhante. - Na saída
tcpdump
, determine o host (cliente ou servidor) que está rejeitando a certificado durante a etapa de verificação. - É 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. - 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
- O processador de mensagens (cliente) envia "Client Hello" para o servidor de back-end (servidor) na mensagem 59.
- O servidor de back-end envia "Server Hello" para o processador de mensagens na mensagem No 61.
- Eles validam mutuamente o protocolo e os algoritmos do pacote de criptografia usados.
- O servidor de back-end envia a mensagem "Certificate e Server Hello Done" para Processador de mensagens na mensagem 68.
- O processador de mensagens envia o alerta fatal "Description: Certificate "Desconhecido" na mensagem 70.
- Analisando mais a mensagem no 70, não há detalhes adicionais a mais
do que a mensagem de alerta, conforme mostrado abaixo:
- 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:
- O certificado do servidor de back-end e a cadeia completa dele estão disponíveis abaixo de "Certificados" conforme mostrado na figura acima.
- Se o certificado for desconhecido pelo roteador (sentido norte) ou
Message Processador (sentido sul), como no exemplo ilustrado acima, e siga estas
etapas:
- 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:
-
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
-
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
-
Encontre o nome do certificado no truststore:
- 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.
- 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:
- Se o certificado for desconhecido pelo aplicativo cliente (direcionado ao norte)
ou no servidor de destino (sentido sul) e, em seguida, siga estas etapas:
- 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:
-
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
-
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
-
Encontre o nome do certificado no keystore:
- 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.
- 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:
- 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)
- 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.
Causa | Descrição | Resolução |
Certificado expirado |
NorthBound
|
Faça upload de um novo certificado e de sua cadeia completa no keystore no host. |
SouthBound
|
Faça upload de um novo certificado e de sua cadeia completa no keystore no host. | |
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. |
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
- 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: É possível que você receba os certificados e, às vezes, pode observar a falha de handshake o comando openssl, conforme mostrado abaixo:openssl s_client -connect hostname:port
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, conforme mostrado abaixo:openssl s_client -connect hostname:port -servername hostname
- 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
- Determine se o erro ocorreu no sentido norte ou southbound. Para mais orientações sobre como determinação, consulte Determinar a origem do problema.
- 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.
Consulte tcpdump para mais informações sobre como usar o comandotcpdump -i any -s 0 host IP address -w File name
tcpdump
. - Se você for usuário da nuvem privada, poderá coletar o
- Analise a saída do
tcpdump
usando o Wireshark ou um semelhante. - Confira um exemplo de análise de
tcpdump
usando o Wireshark:- Neste exemplo, a falha de handshake de TLS/SSL ocorreu entre a mensagem de borda Processador e servidor de back-end (conexão sul).
- 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). - Selecionar "Client Hello" mostra que a mensagem
O processador está usando o protocolo TLSv1.2.
- A mensagem no 4 mostra que o servidor de back-end confirma o "Client Hello" mensagem do processador de mensagens.
- 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.
- 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:
- 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.
- 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: - Isso confirma que o processador de mensagens não enviou o server_name para o servidor de back-end ativado para SNI;
- 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
- Verifique se
jsse.enableSNIExtension property
nasystem.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:
- Crie o
/opt/apigee/customer/application/message-processor.properties
(se ainda não existir). - Adicione a seguinte linha ao arquivo:
conf_system_jsse.enableSNIExtension=true
- Mude 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 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
.