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

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

Sintoma

O aplicativo cliente recebe uma resposta HTTP 400 - Solicitação inválida com o erro mensagem "O erro de certificado SSL". Este erro geralmente é enviado pelo roteador de borda com uma configuração de TLS bidirecional ativada para a conexão de entrada com o Apigee Edge.

Mensagem de erro

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

HTTP/1.1 400 Bad Request

Depois, esta é a 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

Estas são as possíveis causas desse problema:

Causa Descrição Instruções para solução de problemas aplicáveis
Certificado do cliente expirado O certificado enviado pelo cliente expirou. Usuários de nuvem pública e privada de borda
Certificado incorreto enviado pelo cliente Esse erro será gerado se o certificado enviado pelo aplicativo cliente não corresponder. pelo certificado armazenado no truststore do roteador do Edge. Usuários de nuvem pública e privada de borda
Certificado raiz do cliente ausente no Truststore Esse erro será gerado se o certificado raiz assinado pela CA do cliente estiver ausente no o truststore do roteador do Edge. Usuários de nuvem pública e privada de borda
Certificados do cliente não carregados no roteador de borda Esse erro será gerado se os certificados do cliente enviados para o truststore não forem carregados. no roteador. Usuários da nuvem privada de borda

Causa: certificado do cliente expirado

Esse problema normalmente acontece para um TLS bidirecional, quando o certificado enviado pelo cliente expirar. Em um TLS bidirecional, tanto o cliente quanto 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 constatado que o certificado do cliente expirou, o servidor enviará 400 - Solicitação inválida com a mensagem "Erro de certificado SSL".

Diagnóstico

  1. Fazer login na interface do usuário do Edge e visualizar a configuração específica do Virtual Host (Administrador > Hosts virtuais) para os quais a solicitação de API está sendo ou use o Get virtual Host API Management para obter a definição do host virtual específico.

    Geralmente, um host virtual para comunicação 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. Determine a referência do Truststore usada no host virtual. No exemplo acima, O nome de referência do Truststore é myTruststoreRef.

  3. Determine o Truststore indicado pela referência do Truststore.
    1. Na interface do Edge, acesse Administrador > Ambientes > Referências e procure o nome de referência do Truststore.

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

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

      No exemplo acima, myTruststoreRef tem a referência para myTruststore. Portanto, o nome do Truststore é myTruststore.

  4. Em Administrador > Ambientes > Keystores TLS na interface do Edge, navegue até 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 é expirou.

  6. Verifique se o certificado do alias de certificado do truststore expirou.
  7. Se o certificado não tiver expirado, acesse as 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. Modificar a referência da infraestrutura 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 de diagnóstico comuns para outras causas

  1. Para investigar o problema, capture pacotes TCP/IP usando o tcpdump.
    1. Se você é usuário de nuvem privada, pode capturar os pacotes TCP/IP na aplicativo cliente ou roteador.
    2. Se você for um usuário de 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 para capturar pacotes TCP/IP:

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

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

      Se você estiver recebendo os pacotes TCP/IP no aplicativo cliente, use o IP público endereço 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 o ferramenta Wireshark ou outra ferramenta semelhante com a qual esteja familiarizado.

Esta é a análise de amostras 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 no 34 mostra que o roteador reconhece a mensagem Client Hello do aplicativo cliente.
  3. O roteador envia a mensagem de erro no pacote 35, depois envia o certificado e também solicita que o aplicativo cliente envie o certificado no pacote 38.
  4. No pacote 38, em que o roteador envia o pacote "Certificate Request", verifique o "Nomes distintos" , que fornece detalhes sobre o certificado do cliente, sua cadeia e autoridades certificadoras aceitas pelo roteador (servidor).
    5. Figura 3

  5. O aplicativo cliente envia o certificado no pacote 41. Marque a caixa Certificado Verificar no pacote 41 e determinar o certificado enviado pelo aplicativo cliente.

    Figura 4
  6. Verificar se o assunto, o emissor e a cadeia do certificado foram enviados pelo cliente aplicativo (pacote 41) corresponde ao certificado aceito e sua cadeia do Roteador (pacote no 38). Se houver incompatibilidade, essa será a causa do erro. Daí o roteador (Servidor) envia o Alerta Criptografado (pacote 57) seguido de FIN, ACK (pacote 58) para o aplicativo cliente e, por fim, a conexão será encerrada.
  7. A incompatibilidade entre o certificado e a cadeia pode ser causada pelos cenários descritos em nas seções a seguir.

Causa: certificado incorreto enviado pelo cliente

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

Diagnóstico

  1. Fazer login na interface do usuário do Edge e visualizar a configuração específica do Virtual Host (Administrador > Hosts virtuais) para os quais a solicitação de API está sendo ou use a API Get virtual Host Management para obter a definição do host virtual específico.

    Geralmente, um host virtual para comunicação 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. Determine a referência do Truststore usada no host virtual.

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

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

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

      Interface do Edge mostrando uma referência do truststore.
      Figura 5

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

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

    1. Listar certificados para uma API keystore ou truststore

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

    2. Receba detalhes do certificado de uma API keystore ou 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 estão armazenados em myCompanyTruststore corresponde ao código do certificado e sua cadeia como vistos nos pacotes TCP/IP (consulte o pacote no 38) acima. Se houver incompatibilidade, se os certificados enviados para o truststore não estão sendo carregados no roteador de borda. Acesse Causa: certificados do cliente não carregados no roteador de borda.
  6. Se não foi encontrada uma incompatibilidade na Etapa 5, isso indica que o aplicativo cliente não enviar o certificado correto e a cadeia dele.

Resolução

Confira 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 será gerado se o certificado raiz assinado pela CA do cliente estiver ausente no o truststore do roteador do Edge.

Diagnóstico

  1. Fazer login na interface do usuário do Edge e visualizar a configuração específica do host virtual para a qual a API está sendo feita (Administrador > Hosts virtuais > virtual_host), ou use o Acessar a API de host virtual para obter a definição do host virtual específico.

    Geralmente, um host virtual para comunicação 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. Determine a referência do truststore usada no host virtual. No exemplo anterior, O nome de referência do truststore é myCompanyTruststoreRef.
  3. Determine o truststore real que está sendo usado pela referência truststore.
  4. Na interface do Edge, acesse Administrador > Ambientes > Referências e pesquisa para o nome de referência do truststore.

  5. O nome do truststore da referência específica do truststore está no Coluna Referência.

    Figura 6

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

  6. Obtenha os certificados armazenados no truststore (determinado na etapa anterior) usando as seguintes APIs:
    1. Listar certificados de uma API Keystore ou truststore Essa API lista todas as certificados do truststore.
    2. Consiga detalhes de um certificado de uma API keystore ou 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, bem como o certificado de folha ou a folha do cliente, e certificado intermediário. Se o certificado raiz válido do cliente estiver ausente no truststore, essa é a causa do erro.

    No entanto, se a cadeia completa de certificados do cliente, incluindo o certificado raiz, existir no truststore, isso indica que os certificados enviados para o o truststore pode não estar carregado no roteador de borda. Se esse for o caso, consulte Causa: os certificados do cliente não foram carregados no Edge Router.

Resolução

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

Causa: os certificados do cliente não foram carregados no Edge Router

  1. Se você for um usuário de nuvem pública, entre em contato com o suporte do Apigee Edge.
  2. Se você for usuário de 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 um 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 acessar os detalhes do que estão 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 com o que foi observado no Truststore na interface de usuário do Edge ou usando as APIs de gerenciamento, então isso a causa do erro.
    4. É possível que o roteador não tenha recarregado os certificados enviados.

Resolução

Siga esta etapa para reiniciar o roteador para garantir que os certificados mais recentes sejam carregados:

apigee-service edge-router restart

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

  1. Se você é 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. Complete o comando curl para reproduzir o erro
    7. Pacotes TCP/IP capturados no aplicativo cliente
  2. Se você é usuário da nuvem privada, forneça as seguintes informações:
    1. Nome do host virtual e a 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 de Listar os certificados da API Keystore e também os detalhes de cada certificado conseguido com a API Get Cert Details.
  3. Detalhes sobre quais seções deste manual você usou e outros insights que nos ajude a acelerar a resolução desse problema.