400 Solicitação inválida - Erro de certificado SSL

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

Sintoma

O aplicativo cliente recebe uma resposta HTTP 400 - Bad request com a mensagem "The SSL certificate error". Esse erro normalmente é enviado pelo roteador do Edge em uma configuração de TLS bidirecional ativada para a conexão recebida com o Apigee Edge.

Mensagem de erro

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

HTTP/1.1 400 Bad Request

Seguido pela página de erro HTML abaixo:

<html>
  <head>
    <title>400 The SSL certificate error</title>
  </head>
  <body bgcolor="white">
    <center> <h1>400 Bad Request</h1>
    </center>
    <center>The SSL certificate error</center>
    <hr>
    <center>nginx</center>
  </body>
</html>

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
Certificado do cliente expirado O certificado enviado pelo cliente expirou. Usuários da nuvem pública e privada do Edge
Certificado incorreto enviado pelo cliente Esse erro é gerado se o certificado enviado pelo aplicativo cliente não corresponder ao certificado armazenado no truststore do roteador do Edge. Usuários da nuvem pública e privada do Edge
Certificado raiz do cliente ausente no truststore Esse erro é gerado se o certificado raiz assinado pela CA do cliente estiver ausente no truststore do roteador do Edge. Usuários da nuvem pública e privada do Edge
Certificados do cliente não carregados no roteador do Edge Esse erro é gerado se os certificados do cliente enviados para o truststore não forem carregados no roteador. Usuários da nuvem privada do Edge

Causa: certificado do cliente expirado

Esse problema normalmente ocorre para um TLS bidirecional, quando o certificado enviado pelo cliente expira. Em um TLS bidirecional, o cliente e o servidor trocam certificados públicos para realizar o handshake. O cliente valida o certificado do servidor e o servidor valida o certificado do cliente.

No Edge, o TLS bidirecional é implementado no host virtual, em que o certificado do servidor é adicionado ao keystore e o certificado do cliente é adicionado aos truststores.

Durante o handshake de TLS, se for constatado que o certificado do cliente expirou, o servidor enviará 400 - Bad request com a mensagem "The SSL certificate error".

Diagnóstico

  1. Faça login na interface do Edge e confira a configuração específica do host virtual (Admin > Virtual Hosts) para o qual a solicitação de API está sendo feita ou use a API Get virtual host management para receber a definição do host virtual específico.

    Normalmente, um host virtual para comunicação TLS bidirecional tem esta aparência:

    <VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>api.myCompany.com</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <TrustStore>ref://myTruststoreRef</TrustStore>
    </SSLInfo>
</VirtualHost>

  2. Determine a referência do truststore usada no host virtual. No exemplo acima, o nome da referência do truststore é myTruststoreRef.

  3. Determine o truststore apontado pela referência do truststore.
    1. Na interface do Edge, acesse Admin > Environments > References e pesquise o nome da referência do truststore.

    2. Anote o nome na coluna Reference para a referência do truststore específica. Esse será o nome do truststore.

      A interface do Edge mostrando uma lista de referências
      Figura 1

      No exemplo acima, observe que myTruststoreRef tem a referência a myTruststore. Portanto, o nome do truststore é myTruststore.

  4. Em Admin > Environments > TLS Keystores na interface do Edge, acesse TLS Keystores e procure o truststore encontrado na etapa 3.

  5. Selecione o certificado no truststore específico (determinado na etapa 3 acima), conforme mostrado abaixo:

    Figura 2

    O certificado com o alias client-cert-markw no exemplo acima mostra que ele expirou.

  6. Verifique se o certificado expirou para o alias do certificado do truststore.
  7. Se o certificado não tiver expirado, avance para Etapas comuns de diagnóstico para as outras causas.

Resolução

Adquira um novo certificado e faça o upload dele:

  1. Crie um novo truststore, por exemplo, myNewTruststore.
  2. Faça upload do novo certificado para o truststore recém-criado.

  3. Modifique a referência do truststore usada no host virtual específico para apontar para o novo truststore usando as etapas fornecidas em Como modificar uma referência.

    No exemplo descrito acima, aponte a referência myTruststoreRef para myNewTruststore.

Etapas comuns de diagnóstico para as outras causas

  1. Para investigar esse problema, será necessário capturar pacotes TCP/IP usando a tcpdump.
    1. Se você for um usuário da nuvem privada, poderá capturar os pacotes TCP/IP no aplicativo cliente ou no roteador.
    2. Se você for um usuário da nuvem pública, capture os pacotes TCP/IP no aplicativo cliente.

    3. Depois de decidir onde você quer capturar pacotes TCP/IP, use o seguinte tcpdump comando para capturar pacotes TCP/IP:

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

      Observação: se você estiver usando os pacotes TCP/IP no roteador, use o endereço IP público do aplicativo cliente no comando tcpdump.

      Se você estiver usando os pacotes TCP/IP no aplicativo cliente, use o endereço IP público do nome do host usado no host virtual no comando tcpdump.

      Consulte tcpdump para mais informações sobre essa ferramenta e outras variantes desse comando.

  2. Analise os pacotes TCP/IP coletados usando a ferramenta Wireshark ou uma ferramenta semelhante que você conheça.

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

  1. O pacote nº 30 no tcpdump (imagem abaixo) mostra que o aplicativo cliente (origem) enviou uma "Client Hello" mensagem para o roteador (destino).
  2. O pacote nº 34 mostra que o roteador reconhece a mensagem "Client Hello" do aplicativo cliente.
  3. O roteador envia o "Server Hello" no pacote nº 35 e, em seguida, envia o certificado e também solicita que o aplicativo cliente envie o certificado no pacote nº 38.
  4. No pacote nº 38, em que o roteador envia o pacote "Certificate Request", confira a seção "Distinguished Names", que fornece detalhes sobre o certificado do cliente, a cadeia e as autoridades de certificação aceitas pelo roteador (servidor).
    5. Figura 3

  5. O aplicativo cliente envia o certificado no pacote nº 41. Confira a seção Certificate Verify no pacote nº 41 e determine o certificado enviado pelo aplicativo cliente.

    Figura 4
  6. Verifique se o assunto e o emissor do certificado e da cadeia enviados pelo aplicativo cliente (pacote nº 41) correspondem ao certificado aceito e à cadeia do roteador (pacote nº 38). Se houver uma incompatibilidade, essa será a causa do erro. Portanto, o roteador (servidor) envia o alerta criptografado (pacote nº 57) seguido por FIN, ACK (pacote 58) para o aplicativo cliente e, por fim, a conexão é encerrada.
  7. A incompatibilidade do certificado e da cadeia pode ser causada pelos cenários descritos em as seções a seguir.

Causa: certificado incorreto enviado pelo cliente

Isso normalmente acontece se o assunto/emissor do certificado e/ou da cadeia enviados pelo aplicativo cliente não corresponder ao certificado e/ou à cadeia armazenados no truststore do roteador (servidor).

Diagnóstico

  1. Faça login na interface do Edge e confira a configuração específica do host virtual (Admin > Virtual Hosts) para o qual a solicitação de API está sendo feita ou use a API Get virtual host management para receber a definição do host virtual específico.

    Normalmente, um host virtual para comunicação TLS bidirecional tem esta aparência:

        <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
                <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>
  2. Determine a referência do truststore usada no host virtual.

    No exemplo acima, o nome da referência do truststore é myCompanyTruststoreRef.

  3. Determine o truststore apontado pela referência do truststore.
    1. Na interface do Edge, acesse Admin > Environments References e pesquise o nome da referência do truststore.

    2. Anote o nome na coluna Reference para a referência do truststore específica. Esse será o nome do truststore.

      IU do Edge mostrando referência do truststore.
      Figura 5

      No exemplo acima, observe que myCompanyTruststoreRef tem a referência a myCompanyTruststore. Portanto, o nome do truststore é myCompanyTruststore.

  4. Receba os certificados armazenados no truststore (determinado na etapa anterior) usando as seguintes APIs:

    1. API List certificates for a keystore or truststore.

      Essa API lista todos os certificados no truststore específico.

    2. API Get cert details from a keystore or truststore.

      Essa API retorna informações sobre um certificado específico no truststore específico.

  5. Verifique se o emissor e o assunto de cada certificado e da cadeia armazenados em myCompanyTruststore correspondem ao certificado e à cadeia, conforme mostrado nos pacotes TCP/IP (consulte o pacote nº 38) acima. Se houver uma incompatibilidade, isso indica que os certificados enviados para o truststore não estão sendo carregados no roteador do Edge. Acesse Causa: certificados do cliente não carregados no roteador do Edge.
  6. Se nenhuma incompatibilidade foi encontrada na etapa 5, isso indica que o aplicativo cliente não enviou o certificado correto e a cadeia dele.

Resolução

Verifique se o certificado correto e a cadeia dele foram enviados pelo aplicativo cliente para o Edge.

Causa: certificado raiz do cliente ausente no truststore

Esse erro é gerado se o certificado raiz assinado pela CA do cliente estiver ausente no truststore do roteador do Edge.

Diagnóstico

  1. Faça login na interface do Edge e confira a configuração específica do host virtual para a qual a solicitação de API está sendo feita (Admin > Virtual Hosts > virtual_host), ou use a API Get virtual host para receber a definição do host virtual específico.

    Normalmente, um host virtual para comunicação TLS bidirecional tem esta aparência:

        <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
            <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>
  2. Determine a referência do truststore usada no host virtual. No exemplo anterior, o nome da referência do truststore é myCompanyTruststoreRef.
  3. Determine o truststore real que está sendo usado pela referência do truststore.
  4. Na interface do Edge, acesse Admin > Environments > References e pesquise o nome da referência do truststore.

  5. O nome do truststore para a referência do truststore específica está na Reference coluna.

    Figura 6

    Neste exemplo, observe que myCompanyTruststoreRef tem myCompanyTruststore na coluna "Reference". Portanto, o nome do truststore é myCompanyTruststore.

  6. Receba os certificados armazenados no truststore (determinado na etapa anterior) usando as seguintes APIs:
    1. API List certificates for a keystore or truststore. Essa API lista todos os certificados no truststore.
    2. API Get cert details from a keystore or truststore. Essa API retorna informações sobre um certificado específico no truststore.

  7. Verifique se o certificado inclui uma cadeia completa, incluindo o certificado raiz enviado pelo cliente específico, conforme mostrado nos pacotes TCP/IP (consulte a Figura 4). O truststore precisa incluir o certificado raiz e o certificado de folha do cliente ou o certificado de folha e certificado intermediário. Se o certificado raiz válido do cliente estiver ausente no truststore, essa será a causa do erro.

    No entanto, se a cadeia de certificados completa do cliente, incluindo o certificado raiz, existir no truststore, isso indica que os certificados enviados para o truststore possivelmente não estão carregados no roteador do Edge. Nesse caso, consulte Causa: certificados do cliente não carregados no roteador do Edge.

Resolução

Verifique se o certificado correto do cliente, incluindo o certificado raiz, está disponível no truststore do roteador do Apigee Edge.

Causa: certificados do cliente não carregados no roteador do Edge

  1. Se você for um usuário da nuvem pública, entre em contato com o suporte do Apigee Edge.
  2. Se você for um usuário da nuvem privada, siga as instruções abaixo em cada roteador:
    1. Verifique se o arquivo /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem existe para o host virtual específico. Se o arquivo não existir, avance para a seção Resolução abaixo.
    2. Se o arquivo existir, use o comando openssl abaixo para receber os detalhes dos certificados disponíveis no roteador do Edge: 
      openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
    3. Verifique o emissor, o assunto e a data de validade do certificado. Se algum deles não corresponder ao que foi observado no truststore na interface do Edge ou usando as APIs de gerenciamento, essa será a causa do erro.
    4. É possível que o roteador não tenha recarregado os certificados enviados.

Resolução

Reinicie o roteador para garantir que os certificados mais recentes sejam carregados usando a etapa abaixo:

apigee-service edge-router restart

Execute as APIs novamente e confira os resultados. Se o problema persistir, acesse Coletar informações de diagnóstico.

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 e compartilhe as informações coletadas com o suporte do Apigee Edge:

  1. 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 da API
    4. Nome do host virtual
    5. Nome do alias do host
    6. Comando curl completo para reproduzir o erro
    7. Pacotes TCP/IP capturados no aplicativo cliente
  2. Se você for um usuário da nuvem privada, forneça as seguintes informações:
    1. Nome do host virtual e definição dele usando a API Get virtual host
    2. Nome do alias do host
    3. Mensagem de erro completa observada
    4. Pacotes TCP/IP capturados no aplicativo cliente ou no roteador.
    5. Saída da API List the certificates from the keystore e detalhes de cada certificado obtido usando a API Get cert details.
  3. Detalhes sobre quais seções deste manual você tentou e outras informações que nos ajudarão a acelerar a resolução desse problema.