O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Falhas no handshake de SSL: certificado de cliente inválido

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

Sintoma

O aplicativo cliente recebe um código de status HTTP 503 com a mensagem "Serviço indisponível" como resposta a uma solicitação de API. No trace da interface, você vai observar que o error.cause é Received fatal alert: bad_certificate no fluxo de solicitação de destino para a solicitação de API com falha.

Se você tiver acesso aos registros do processador de mensagens, vai notar a mensagem de erro Received fatal alert: bad_certificate para a solicitação de API com falha. Esse erro é observado durante o processo de handshake SSL entre o processador de mensagens e o servidor de back-end em uma configuração TLS bidirecional.

Mensagem de erro

O aplicativo cliente recebe o seguinte código de resposta:

HTTP/1.1 503 Service Unavailable

Além disso, você pode observar a seguinte mensagem de erro:

{
 "fault": {
    "faultstring":"The Service is temporarily unavailable",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.ServiceUnavailable"
    }
 }
}

Os usuários da nuvem privada vão encontrar o seguinte erro para a solicitação de API específica nos registros do processador de mensagens /opt/apigee/var/log/edge-message-processor/system.log:

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1 bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate

Causas possíveis

As possíveis causas desse problema são as seguintes:

Causa	Descrição	Instruções de solução de problemas aplicáveis a
Nenhum certificado de cliente	O keystore usado no endpoint de destino do servidor de destino não tem nenhum certificado de cliente.	Usuários da nuvem pública e privada do Edge
Incompatibilidade da autoridade certificadora	A autoridade certificadora do certificado folha (o primeiro certificado na cadeia de certificados) no keystore do processador de mensagens não corresponde a nenhuma das autoridades certificadoras aceitas pelo servidor de back-end.	Usuários da nuvem pública e privada do Edge

Etapas comuns do diagnóstico

Ative o trace na interface do Edge, faça a chamada de API e reproduza o problema.
Nos resultados do trace da interface, navegue por cada fase e determine onde o erro ocorreu. O erro ocorreu no fluxo de solicitação de destino.
Examine o fluxo que mostra o erro. Você vai observar o erro conforme mostrado no exemplo de trace abaixo:
Como você pode ver na captura de tela acima, o error.cause é "Received fatal alert: bad_certificate".

Se você for um usuário da nuvem privada, siga as instruções abaixo:

Você pode receber o ID da mensagem para a solicitação de API com falha determinando o valor do cabeçalho de erro "X-Apigee.Message-ID" na fase indicada por AX no trace.

Pesquise esse ID de mensagem no registro do processador de mensagens /opt/apigee/var/log/edge-message-processor/system.log e determine se você pode encontrar mais informações sobre o erro:

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1
bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate
2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLInfo:
KeyStore:java.security.KeyStore@52de60d9 KeyAlias:KeyAlias TrustStore:java.security.KeyStore@6ec45759
2017-10-23 05:28:57,814 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
RequestWriteListener.onException(HTTPRequest@6071a73d)
javax.net.ssl.SSLException: Received fatal alert: bad_certificate
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800) ~[na:1.8.0_101]
at com.apigee.nio.NIOSelector$SelectedIterator.findNext(NIOSelector.java:496) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:312) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:302) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:59) [nio-1.0.0.jar:na]

O registro do processador de mensagens tinha um stack trace para o erro Received fatal alert: bad_certificate, mas não tem mais informações que indiquem a causa desse problema.

Para investigar esse problema, você precisará capturar pacotes TCP/IP usando tcpdump ferramenta.
1. Se você for um usuário da nuvem privada, poderá capturar os pacotes TCP/IP no servidor de back-end ou no processador de mensagens. De preferência, capture-os no servidor de back-end, já que os pacotes são descriptografados nele no servidor de back-end.
2. Se você for um usuário da nuvem pública, capture os pacotes TCP/IP no servidor de back-end.
3. Depois de decidir onde você quer capturar pacotes TCP/IP, use o comando tcpdump abaixo para capturar pacotes TCP/IP.
Analise os pacotes TCP/IP usando a ferramenta Wireshark ou uma ferramenta semelhante com que você esteja familiarizado.

Confira a análise dos dados de pacotes TCP/IP de amostra usando a ferramenta Wireshark:

alt_text

A mensagem nº 4 no tcpdump acima mostra que o processador de mensagens (origem) enviou uma mensagem "Client Hello" para o servidor de back-end (destino).
A mensagem nº 5 mostra que o servidor de back-end reconhece a mensagem Client Hello do processador de mensagens.
O servidor de back-end envia a mensagem "Server Hello" com o certificado, e solicita que o cliente envie o certificado na mensagem nº 7.
O processador de mensagens conclui a verificação do certificado e reconhece a mensagem ServerHello do servidor de back-end na mensagem nº 8.
O processador de mensagens envia o certificado para o servidor de back-end na mensagem nº 9.
O servidor de back-end reconhece o recebimento do certificado do processador de mensagens na mensagem nº 11.
No entanto, ele envia imediatamente um alerta fatal: certificado inválido para o processador de mensagens (mensagem nº 12). Isso indica que o certificado enviado por o processador de mensagens era inválido e, portanto, a verificação do certificado falhou no servidor de back-end. Como resultado, o handshake SSL falhou e a conexão será fechada.
Agora vamos analisar a mensagem nº 9 para verificar o conteúdo do certificado enviado pelo processador de mensagens:
Como você pode notar, o servidor de back-end não recebeu nenhum certificado do cliente (Certificate Length: 0). Portanto, o servidor de back-end envia o alerta fatal: certificado inválido.
Normalmente, isso acontece quando o cliente, ou seja, o processador de mensagens (um processo baseado em Java):
1. Não tem nenhum certificado de cliente no keystore ou
2. Não é possível enviar um certificado de cliente. Isso pode acontecer se não for possível encontrar um certificado emitido por uma das autoridades certificadoras aceitáveis do servidor de back-end. Isso significa que, se a autoridade certificadora do certificado folha do cliente (ou seja, o primeiro certificado na cadeia) não corresponder a nenhuma das autoridades certificadoras aceitáveis do servidor de back-end, o processador de mensagens não enviará o certificado.

Vamos analisar cada uma dessas causas separadamente, conforme abaixo.

Causa: nenhum certificado de cliente

Diagnóstico

Se não houver um certificado no keystore especificado na seção "Informações SSL" do endpoint de destino ou do servidor de destino usado no endpoint de destino, essa será a causa desse erro.

Siga as etapas abaixo para determinar se essa é a causa:

Determine o keystore que está sendo usado no endpoint de destino ou no servidor de destino para o proxy de API específico seguindo as etapas abaixo:
1. Receba o nome de referência do keystore do elemento Keystore na seção SSLInfo no endpoint de destino ou no servidor de destino.
  Vamos analisar uma seção SSLInfo de amostra em uma configuração de endpoint de destino:
```
<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>true</ClientAuthEnabled>
  <KeyStore>ref://myKeystoreRef</KeyStore>
  <KeyAlias>myKey</KeyAlias>
  <TrustStore>ref://myTrustStoreRef</TrustStore>
</SSLInfo>
```
2. No exemplo acima, o nome de referência do keystore é "myKeystoreRef".
3. Acesse a interface do Edge e selecione Proxies de API -> Configurações de ambiente.
  Selecione a guia Referências e pesquise o nome de referência do keystore. Anote o nome na coluna Referência para a referência do keystore específico. Esse será o nome do keystore.
4. No exemplo acima, você pode notar que myKeystoreRef tem a referência a "myKeystore". Portanto, o nome do keystore é myKeystore.
Verifique se esse keystore contém o certificado usando a interface do Edge ou a API List certs for keystore.
Se o keystore contiver certificados, avance para Causa: incompatibilidade da autoridade certificadora.
Se o keystore não contiver nenhum certificado, esse será o motivo pelo qual o certificado de cliente não será enviado pelo processador de mensagens.

Resolução

Verifique se a cadeia de certificados de cliente adequada e completa foi enviada para o keystore específico no processador de mensagens.

Causa: incompatibilidade da autoridade certificadora

Geralmente, quando o servidor solicita que o cliente envie o certificado, ele indica o conjunto de emissores ou autoridades certificadoras aceitos. Se o emissor/autoridade certificadora do certificado folha (ou seja, o primeiro certificado na cadeia de certificados) no keystore do processador de mensagens não corresponder a nenhuma das autoridades certificadoras aceitas pelo servidor de back-end, o processador de mensagens (que é um processo baseado em Java) não enviará o certificado para o servidor de back-end.

Siga as etapas abaixo para confirmar se esse é o caso:

API List certs for keystore.
Receba os detalhes de cada certificado obtido na etapa 1 acima usando a API Get cert for keystore.

Anote o emissor do certificado folha (ou seja, o primeiro certificado na cadeia de certificados) armazenado no keystore.

Exemplo de certificado folha

{
  "certInfo" : [ {
    "basicConstraints" : "CA:FALSE",
    "expiryDate" : 1578889324000,
    "isValid" : "Yes",
    "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com",
    "publicKey" : "RSA Public Key, 2048 bits",
    "serialNumber" : "65:00:00:00:d2:3e:12:d8:56:fa:e2:a9:69:00:06:00:00:00:d2",
    "sigAlgName" : "SHA256withRSA",
    "subject" : "CN=nonprod-api.mycompany.com, OU=ITS, O=MyCompany, L=MELBOURNE, ST=VIC, C=AU",
    "subjectAlternativeNames" : [ ],
    "validFrom" : 1484281324000,
    "version" : 3
  } ],
  "certName" : "nonprod-api.mycompany.com.key.pem-cert"
}

No exemplo acima, o emissor/autoridade certificadora é "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com"

Determine a lista aceita de emissores ou autoridades certificadoras do servidor de back-end usando uma das seguintes técnicas:
Técnica 1: use o comando openssl abaixo:
```
openssl s_client -host <backend server host name> -port <Backend port#> -cert <Client Certificate> -key <Client Private Key>
```
Consulte a seção intitulada "Acceptable Client Certificate CA names" na saída desse comando, conforme mostrado abaixo:
```
Acceptable client certificate CA names
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
```
Técnica 2: verifique o pacote Certificate Request em pacotes TCP/IP, em que o servidor de back-end solicita que o cliente envie o certificado:

Nos pacotes TCP/IP de amostra mostrados acima, Certificate Request pacote é a mensagem nº 7. Consulte a seção "Nomes distintos", que contém as autoridades certificadoras aceitáveis do servidor de back-end.

**Observação**: a lista de "autoridades certificadoras aceitáveis" do servidor de back-end é preenchida adicionando os emissores de todos os certificados armazenados no truststore do servidor de back-end.
Verifique se a autoridade certificadora obtida na etapa 3 corresponde à lista de emissores ou autoridades certificadoras aceitas do servidor de back-end obtida na etapa 4. Se houver uma incompatibilidade, o processador de mensagens não enviará o certificado de cliente para o servidor de back-end.

No exemplo acima, você pode notar que o emissor do certificado folha do cliente no keystore do processador de mensagens não corresponde a nenhuma das autoridades certificadoras aceitas do servidor de back-end. Portanto, o processador de mensagens não envia o certificado de cliente para o servidor de back-end. Isso faz com que o handshake SSL falhe e o servidor de back-end envie a mensagem "Fatal alert: bad_certificate".

Resolução

Verifique se o certificado com o emissor/autoridade certificadora que corresponde o emissor/autoridade certificadora do certificado folha do cliente (primeiro certificado na cadeia) está armazenado no truststore do servidor de back-end.
No exemplo descrito neste manual, o certificado com o emissor "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com" foi adicionado ao truststore do servidor de back-end para resolver o problema.

Se o problema persistir, acesse Precisa de informações de diagnóstico.

É necessário coletar informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, colete as seguintes informações de diagnóstico. Entre em contato com o suporte do Apigee Edge e compartilhe-as:

Se você for um usuário da nuvem pública, forneça as seguintes informações:
1. Nome da organização
2. Nome do ambiente
3. Nome do proxy de API
4. Comando curl completo para reproduzir o erro
5. Arquivo de trace mostrando o erro
6. Pacotes TCP/IP capturados no servidor de back-end
Se você for um usuário da nuvem privada, forneça as seguintes informações:
1. Mensagem de erro completa observada
2. Pacote de proxy de API
3. Arquivo de trace mostrando o erro
4. Registros do processador de mensagens /opt/apigee/var/log/edge-message-processor/logs/system.log
5. Pacotes TCP/IP capturados no servidor de back-end ou no processador de mensagens.
6. Saída da API Get cert for keystore.
Detalhes sobre quais seções deste manual você tentou e outras informações que nos ajudarão a acelerar a resolução desse problema.