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

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. informações

Sintoma

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

Mensagem de erro

O aplicativo cliente recebe este 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 de nuvem privada e pública do Edge
Certificado incorreto enviado pelo cliente Esse erro será gerado se o certificado enviado pelo aplicativo cliente não corresponder ao certificado armazenado no truststore do roteador do Edge. Usuários de nuvem privada e pública do Edge
Certificado de raiz do cliente ausente na Truststore Esse erro será gerado se o certificado raiz assinado pela CA do cliente estiver ausente no truststore do roteador do Edge. Usuários de nuvem privada e pública do Edge
Os certificados do cliente não foram carregados no roteador de borda Esse erro é gerado se os certificados do cliente enviados ao truststore não são carregados no roteador. Usuários da nuvem privada do Edge

Causa: certificado do cliente expirado

Esse problema normalmente acontece com uma TLS de duas vias, quando o certificado enviado pelo cliente expira. Em um TLS bidirecional, o cliente e o servidor trocam os 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 detectado que o certificado do cliente expirou, o servidor enviará 400 - Solicitação inválida com a mensagem "O erro do certificado SSL".

Diagnóstico

  1. Faça login na interface do Edge e veja a configuração específica do host virtual (Administrador > Hosts virtuais) referente à solicitação de API ou use a API de gerenciamento Receber API do host virtual para ver a definição do host virtual específico.

    Normalmente, um host virtual para comunicação de TLS bidirecional tem a seguinte 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. Determinar a referência do Truststore usada no host virtual. No exemplo acima, o nome de referência do Truststore é myTruststoreRef.

  3. Determine o Truststore apontado pela referência do Truststore.
    1. Na IU do Edge, acesse Administrador > Ambientes > Referências e pesquise o nome de referência do Truststore.

    2. Observe o nome na coluna Reference da referência específica do Truststore. Este será o nome do seu Truststore.

      IU 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 > Ambientes > TLS Keystores na IU do Edge, navegue até Keystores TLS 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 de certificado do seu truststore.
  7. Se o certificado não tiver expirado, siga para as Etapas comuns de diagnóstico para as outras causas.

Resolução

Procure um novo certificado e faça 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 trustore 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, direcione a referência myTruststoreRef para myNewTruststore.

Etapas de diagnóstico comuns para as outras causas

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

    3. Depois de decidir onde você quer capturar os pacotes TCP/IP, use o seguinte comando tcpdump 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 com que você esteja familiarizado.

Veja a seguir a análise de exemplos de dados de pacotes TCP/IP usando a ferramenta Wireshark:

  1. O pacote 30 no tcpdump (imagem abaixo) mostra que o aplicativo cliente (origem) enviou uma mensagem"Client Hello" para o roteador (destino).
  2. O pacote 34 mostra que o roteador reconhece a mensagem Client Hello do aplicativo cliente.
  3. O roteador envia a mensagem "Server Hello" no pacote no 35, envia o certificado e também solicita que o aplicativo cliente envie o certificado no pacote no 38.
  4. No pacote 38, em que o roteador envia o pacote Solicitação de certificado, consulte a seção "Nomes diferenciados", 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 no 41. Verifique a seção Certificate Verification no pacote 41 e determine o certificado enviado pelo aplicativo cliente.

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

Causa: certificado incorreto enviado pelo cliente

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

Diagnóstico

  1. Faça login na IU do Edge e veja a configuração específica do host virtual (Administrador > Hosts virtuais) referente à solicitação de API ou use a API de gerenciamento Receber API do host virtual para ver a definição do host virtual específico.

    Normalmente, um host virtual para comunicação de TLS bidirecional tem a seguinte 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. Determinar a referência do Truststore usada no host virtual.

    No exemplo acima, o nome de referência da Truststore é myCompanyTruststoreRef.

  3. Determine o Truststore apontado pela referência do Truststore.
    1. Na IU do Edge, acesse Administrador > Referências de ambientes e procure o nome de referência do Truststore.

    2. Observe o nome na coluna Reference da referência específica do Truststore. Este será o nome do seu Truststore.

      IU da Edge mostrando a referência do Truststore.
      Figura 5

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

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

    1. Listar certificados de um keystore ou de uma API truststore

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

    2. Consiga os detalhes do certificado de um keystore ou de uma API 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 a cadeia armazenada em myCompanyTruststore correspondem aos dados do certificado e à cadeia dele, conforme visto nos pacotes TCP/IP (consulte o pacote no 38) acima. Se houver incompatibilidade, isso indica que os certificados enviados ao truststore não estão sendo carregados no roteador de borda. Mude para Causa: certificados do cliente não carregados no roteador de borda.
  6. Se não houver incompatibilidade encontrada na etapa 5, isso indica que o aplicativo cliente não enviou o certificado correto e a cadeia correspondente.

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 na Truststore

Esse erro será 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 IU do Edge e confira a configuração do host virtual específico para que a solicitação de API está sendo feita (Administrador > Hosts virtuais > virtual_host) ou use Acessar API do host virtual para ver a definição do host virtual específico.

    Normalmente, um host virtual para comunicação de TLS bidirecional tem a seguinte 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. Determinar a referência do truststore usado no host virtual. No exemplo anterior, o nome de referência do truststore é myCompanyTruststoreRef.
  3. Determinar o truststore real que está sendo usado pela referência do truststore.
  4. Na IU do Edge, navegue até Admin > Environments > References e pesquise o nome de referência do truststore.

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

    Figura 6

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

  6. Consiga os certificados armazenados no truststore (determinado na etapa anterior) usando as seguintes APIs:
    1. Listar certificados para um keystore ou uma API de truststore. Essa API lista todos os certificados no truststore.
    2. Receba detalhes do certificado de um keystore ou de uma API truststore. Essa API retorna informações sobre um certificado específico no truststore.

  7. Verifique se o certificado inclui uma cadeia completa, inclusive o certificado raiz enviado pelo cliente específico, conforme visto nos pacotes TCP/IP (consulte a Figura 4). O truststore precisa incluir o certificado raiz, bem como o certificado folha ou secundário do cliente. 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 indicará que os certificados enviados ao truststore talvez não estejam carregados no roteador de borda. Se esse for o caso, consulte Causa: certificados do cliente não carregados no roteador de borda.

Resolução

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

Causa: os certificados do cliente não foram carregados no roteador de borda

  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 de nuvem privada, siga as instruções abaixo para 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, vá para a seção Resolução abaixo.
    2. Se o arquivo existir, use o comando openssl abaixo para ver os detalhes dos certificados disponíveis no roteador de borda: 
      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 IU do Edge ou no uso das 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 usuário de nuvem pública, forneça as seguintes informações:
    1. Nome da organização
    2. Nome do ambiente
    3. Nome de proxy da API
    4. Nome do host virtual
    5. Nome do alias do host
    6. Concluir o comando curl para reproduzir o erro
    7. Pacotes TCP/IP capturados no aplicativo cliente
  2. Se você é um usuário da nuvem privada, forneça as seguintes informações:
    1. Nome do host virtual e a definição dele usando Receber API do host virtual
    2. Nome do alias do host
    3. Mensagem de erro concluída observada
    4. Pacotes TCP/IP capturados no aplicativo cliente ou no roteador.
    5. Resultado de List the certificados from the keystore API e os detalhes de cada certificado recebido usando a API Get cert details.
  3. Detalhes sobre quais seções deste manual você experimentou e quaisquer outros insights que nos ajudarão a agilizar a resolução deste problema.