400 Requête incorrecte - Erreur de certificat SSL

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X.
en savoir plus

Problème constaté

L'application cliente reçoit une réponse HTTP 400 - Bad request avec le message The SSL certificate error. Cette erreur est généralement envoyée par le routeur Edge via une configuration TLS bidirectionnelle activée pour la connexion entrante à Apigee Edge.

Message d'erreur

L'application cliente obtient le code de réponse suivant:

HTTP/1.1 400 Bad Request

Suivi de la page d'erreur HTML ci-dessous:

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

Causes possibles :

Voici les causes possibles de ce problème:

Cause Description Instructions de dépannage applicables à
Certificat client expiré Le certificat envoyé par le client a expiré. Utilisateurs de cloud privé et public Edge
Certificat incorrect envoyé par le client Cette erreur est générée si le certificat envoyé par l'application cliente ne correspond pas au certificat stocké dans le magasin de confiance du routeur Edge. Utilisateurs de cloud privé et public Edge
Certificat racine du client manquant dans le Truststore Cette erreur est générée si le certificat racine du client signé par une autorité de certification est manquant dans le magasin de confiance du routeur Edge. Utilisateurs de cloud privé et public Edge
Certificats clients non chargés dans Edge Router Cette erreur se produit si les certificats client importés dans le Truststore ne sont pas chargés sur le routeur. Utilisateurs de cloud privé périphérique

Cause: certificat client expiré

Ce problème se produit généralement pour un TLS à deux voies, lorsque le certificat envoyé par le client a expiré. Dans un protocole TLS bidirectionnel, le client et le serveur échangent leurs certificats publics pour établir le handshake. Le client valide le certificat du serveur, tandis que le serveur le valide.

Dans Edge, le protocole TLS bidirectionnel est mis en œuvre au niveau d'un hôte virtuel, où le certificat de serveur est ajouté au keystore et le certificat client aux Truststores.

Lors du handshake TLS, s'il s'avère que le certificat client a expiré, le serveur envoie 400 - Bad request avec le message The SSL certificate error.

Diagnostic

  1. Connectez-vous à l'interface utilisateur Edge et affichez la configuration d'hôte virtuel spécifique (Admin > Hôtes virtuels) pour laquelle la requête API est effectuée, ou utilisez l'API de gestion Obtenir l'API d'hôte virtuel pour obtenir la définition de l'hôte virtuel spécifique.

    En général, un hôte virtuel pour la communication TLS bidirectionnelle se présente comme suit:

    <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. Déterminez la référence Truststore utilisée dans l'hôte virtuel. Dans l'exemple ci-dessus, le nom de la référence du Truststore est myTruststoreRef.

  3. Déterminez le Truststore indiqué par la référence Truststore.
    1. Dans l'interface utilisateur Edge, accédez à Admin > Environnements > Références et recherchez le nom de référence du Truststore.
    2. Notez le nom dans la colonne Reference (Référence) pour la référence Truststore spécifique. Ce sera votre nom Truststore.

      Interface utilisateur Edge affichant une liste de références
      Figure 1

      Dans l'exemple ci-dessus, notez que myTruststoreRef contient la référence à myTruststore. Par conséquent, le nom du Truststore est myTruststore.

  4. Dans Admin > Environnements > Keystores TLS dans l'interface utilisateur Edge, accédez aux keystores TLS et recherchez le Truststore trouvé à l'étape 3.
  5. Sélectionnez le certificat dans le Truststore spécifique (déterminé à l'étape 3 ci-dessus), comme indiqué ci-dessous:

    Figure 2

    Dans l'exemple ci-dessus, le certificat avec l'alias client-cert-markw indique qu'il a expiré.

  6. Vérifiez si le certificat de l'alias de certificat de votre magasin de confiance a expiré.
  7. S'il n'a pas expiré, passez à la procédure de diagnostic commune pour les autres causes.

Résolution

Procurez-vous un nouveau certificat et importez-le:

  1. Créez un nouveau magasin de confiance, par exemple myNewTruststore.
  2. Importez le nouveau certificat dans le Truststore que vous venez de créer.
  3. Modifiez la référence du trustore utilisée dans l'hôte virtuel spécifique pour qu'elle pointe vers le nouveau truststore en suivant les étapes décrites dans la section Modifier une référence.

    Dans l'exemple décrit ci-dessus, pointez la référence myTruststoreRef vers myNewTruststore.

Étapes de diagnostic courantes pour les autres causes

  1. Pour étudier ce problème, vous devez capturer des paquets TCP/IP à l'aide de l'outil tcpdump.
    1. Si vous êtes un utilisateur de cloud privé, vous pouvez capturer les paquets TCP/IP sur l'application cliente ou le routeur.
    2. Si vous êtes un utilisateur du Cloud public, capturez les paquets TCP/IP sur l'application cliente.
    3. Une fois que vous avez choisi l'emplacement de capture des paquets TCP/IP, exécutez la commande tcpdump suivante:

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

      Remarque:Si vous utilisez les paquets TCP/IP sur le routeur, utilisez l'adresse IP publique de l'application cliente dans la commande tcpdump.

      Si vous prenez les paquets TCP/IP sur l'application cliente, utilisez l'adresse IP publique du nom d'hôte utilisé dans l'hôte virtuel dans la commande tcpdump.

      Pour plus d'informations sur cet outil et pour découvrir d'autres variantes de cette commande, reportez-vous à la section tcpdump.

  2. Analysez les paquets TCP/IP collectés à l'aide de l'outil Wireshark ou d'un outil similaire que vous connaissez.

Voici l'analyse d'exemples de données de paquets TCP/IP à l'aide de l'outil Wireshark:

  1. Le paquet n° 30 de tcpdump (image ci-dessous) montre que l'application cliente (source) a envoyé un message "Client Hello" au routeur (destination).
  2. Le paquet 34 montre que le routeur accuse réception du message Hello du client de l'application cliente.
  3. Le routeur envoie "Server Hello" dans le paquet 35, puis envoie son certificat et demande également à l'application cliente d'envoyer son certificat dans le paquet 38.
  4. Dans le paquet n° 38, où le routeur envoie le paquet "Certificate Request" (Demande de certificat), consultez la section "Noms distincts" qui fournit des détails sur le certificat client, sa chaîne et les autorités de certification acceptées par le routeur (serveur).
  5. Figure 3
  6. L'application cliente envoie son certificat au paquet 41. Consultez la section Certificate Check (Vérification de certificat) dans le paquet 41 et déterminez le certificat envoyé par l'application cliente.

    Figure 4
  7. Vérifiez si l'objet et l'émetteur du certificat et de sa chaîne envoyées par l'application cliente (paquet 41) correspondent au certificat accepté et à sa chaîne du routeur (paquet 38). Si vous constatez une non-concordance, c'est la cause de l'erreur. Par conséquent, le routeur (serveur) envoie l'alerte chiffrée (paquet n° 57) suivie de FIN, ACK (paquet 58) à l'application cliente et finalement la connexion est interrompue.
  8. L'incohérence du certificat et de sa chaîne peut être due aux scénarios décrits dans les sections suivantes.

Cause: certificat incorrect envoyé par le client

Cela se produit généralement si l'objet ou l'émetteur du certificat et/ou de sa chaîne envoyés par l'application cliente ne correspondent pas au certificat et/ou à la chaîne stockés dans le magasin de confiance du routeur (serveur).

Diagnostic

  1. Connectez-vous à l'interface utilisateur Edge et affichez la configuration d'hôte virtuel spécifique (Admin > Hôtes virtuels) pour laquelle la requête API est effectuée, ou utilisez l'API de gestion Obtenir l'API d'hôte virtuel pour obtenir la définition de l'hôte virtuel spécifique.

    En général, un hôte virtuel pour la communication TLS bidirectionnelle se présente comme suit:

        <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. Déterminez la référence Truststore utilisée dans l'hôte virtuel.

    Dans l'exemple ci-dessus, le nom de la référence Truststore est myCompanyTruststoreRef.

  3. Déterminez le Truststore indiqué par la référence Truststore.
    1. Dans l'interface utilisateur Edge, accédez à Admin > Références d'environnement et recherchez le nom de référence du Truststore.
    2. Notez le nom dans la colonne Reference (Référence) pour la référence Truststore spécifique. Ce sera votre nom Truststore.

      Interface utilisateur Edge affichant la référence du Trustedstore.
      Figure 5

      Dans l'exemple ci-dessus, notez que myCompanyTruststoreRef contient la référence à myCompanyTruststore. Par conséquent, le nom du Truststore est myCompanyTruststore.

  4. Récupérez les certificats stockés dans le Truststore (déterminé à l'étape précédente) à l'aide des API suivantes :
    1. Répertoriez les certificats d'une API keystore ou de magasin de clés de confiance.

      Cette API liste tous les certificats du Truststore spécifique.

    2. Obtenez les détails d'un certificat à partir d'un keystore ou d'une API Truststore.

      Cette API renvoie des informations sur un certificat spécifique du Truststore spécifique.

  5. Vérifiez si l'émetteur et l'objet de chacun des certificats et de sa chaîne stockés dans myCompanyTruststore correspondent à ceux du certificat et de sa chaîne, tels qu'ils apparaissent dans les paquets TCP/IP (voir le paquet 38) ci-dessus. En cas de non-concordance, cela signifie que les certificats importés dans le Truststore ne sont pas chargés dans le routeur Edge. Accédez à Cause: les certificats clients ne sont pas chargés dans Edge Router.
  6. Si aucune incohérence n'est détectée à l'étape 5, cela signifie que l'application cliente n'a pas envoyé le bon certificat et sa chaîne.

Résolution

Assurez-vous que l'application cliente envoie le bon certificat et sa chaîne à Edge.

Cause: certificat racine du client manquant dans le magasin de confiance

Cette erreur est générée si le certificat racine du client signé par une autorité de certification est manquant dans le magasin de confiance du routeur Edge.

Diagnostic

  1. Connectez-vous à l'interface utilisateur Edge et affichez la configuration spécifique d'hôte virtuel pour laquelle la demande API est effectuée (Admin > Hôtes virtuels > virtual_host), ou utilisez l' API d'obtention d'hôte virtuel pour obtenir la définition de l'hôte virtuel spécifique.

    En général, un hôte virtuel pour la communication TLS bidirectionnelle se présente comme suit:

        <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. Déterminez la référence du Trustedstore utilisée dans l'hôte virtuel. Dans l'exemple précédent, le nom de référence du truststore est myCompanyTruststoreRef.
  3. Déterminez le magasin de confiance réel utilisé par sa référence.
  4. Dans l'interface utilisateur Edge, accédez à Admin > Environnements > Références et recherchez le nom de référence du magasin de confiance.
  5. Le nom du magasin de confiance pour la référence du magasin de confiance spécifique se trouve dans la colonne Reference (Référence).

    Figure 6

    Dans cet exemple, notez que myCompanyTruststoreRef contient myCompanyTruststore dans la colonne "Reference". Par conséquent, le nom du Trustedstore est myCompanyTruststore.

  6. Récupérez les certificats stockés dans le Truststore (déterminé à l'étape précédente) à l'aide des API suivantes :
    1. Répertoriez les certificats d'une API keystore ou de magasin de clés de confiance. Cette API liste tous les certificats du Truststore.
    2. Obtenez les détails d'un certificat à partir d'un keystore ou d'une API Truststore. Cette API renvoie des informations sur un certificat spécifique dans le Truststore.
  7. Vérifiez si le certificat inclut une chaîne complète, y compris le certificat racine envoyé par le client spécifique, comme illustré dans les paquets TCP/IP (voir la figure 4). Le Truststore doit inclure le certificat racine, ainsi que le certificat d'entité finale, ou le certificat feuille et intermédiaire du client. Si le certificat racine valide du client est manquant dans le magasin de confiance, c'est la cause de l'erreur.

    Toutefois, si la chaîne de certificats complète du client, y compris le certificat racine, existe dans le magasin de confiance, cela signifie que les certificats importés dans le magasin de confiance ne sont peut-être pas chargés dans le routeur périphérique. Dans ce cas, consultez la section Cause: les certificats client ne sont pas chargés dans le routeur périphérique.

Résolution

Assurez-vous que le certificat client approprié, y compris le certificat racine, est disponible dans le magasin de confiance du routeur Apigee Edge.

Cause: les certificats clients ne sont pas chargés dans le routeur périphérique

  1. Si vous êtes un utilisateur du cloud public, contactez l'assistance Apigee Edge.
  2. Si vous êtes un utilisateur de cloud privé, suivez les instructions ci-dessous pour chaque routeur :
    1. Vérifiez si le fichier /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem existe pour l'hôte virtuel spécifique. Si le fichier n'existe pas, passez à la section Resolution (Résolution) ci-dessous.
    2. Si le fichier existe, utilisez la commande openssl ci-dessous pour obtenir les détails des certificats disponibles sur le routeur Edge :
      openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
    3. Vérifiez l'émetteur, l'objet et la date d'expiration du certificat. Si l'un d'entre eux ne correspond pas à ce qui a été observé dans le Truststore de l'interface utilisateur Edge ou à l'aide des API de gestion, c'est la cause de l'erreur.
    4. Il est possible que le routeur n'ait pas actualisé les certificats importés.

Résolution

Redémarrez le routeur pour vous assurer que les derniers certificats sont chargés en procédant comme suit:

apigee-service edge-router restart

Exécutez à nouveau les API et vérifiez les résultats. Si le problème persiste, consultez la section Collecter des informations de diagnostic.

Collecte d'informations de diagnostic

Si le problème persiste même après avoir suivi les instructions ci-dessus, veuillez rassembler les informations de diagnostic suivantes. Contactez et partagez les informations que vous collectez avec l'assistance Apigee Edge:

  1. Si vous êtes un utilisateur de cloud public, fournissez les informations suivantes :
    1. Nom de l'organisation
    2. Nom de l'environnement
    3. Nom du proxy d'API
    4. Nom d'hôte virtuel
    5. Nom de l'alias de l'hôte
    6. Exécuter la commande curl pour reproduire l'erreur
    7. Paquets TCP/IP capturés sur l'application cliente
  2. Si vous êtes un utilisateur de cloud privé, fournissez les informations suivantes :
    1. Nom d'hôte virtuel et sa définition à l'aide de l'API Obtenir un hôte virtuel
    2. Nom de l'alias de l'hôte
    3. Message d'erreur complet observé
    4. Paquets TCP/IP capturés sur l'application cliente ou le routeur.
    5. Résultat de l'API Lister les certificats de l'API keystore et les détails de chaque certificat obtenu à l'aide de l'API Get cert details
  3. Informations sur les sections de ce playbook que vous avez essayées et sur d'autres informations qui nous aideront à accélérer la résolution de ce problème.