Cette page a été traduite par l'API Cloud Translation.

400 Requête incorrecte - Erreur de certificat SSL

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

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

Message d'erreur

L'application cliente reçoit le code de réponse suivant:

HTTP/1.1 400 Bad Request

Cette page est suivie 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 :

Les causes possibles de ce problème sont les suivantes:

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 par le certificat stocké dans le Truststore du routeur Edge.	Utilisateurs de cloud privé et public Edge
Certificat client manquant dans le Truststore	Cette erreur est générée si le certificat racine signé par une autorité de certification du client est manquant dans le magasin de confiance du routeur Edge.	Utilisateurs de cloud privé et public Edge
Certificats clients non chargés dans le routeur Edge	Cette erreur est générée si les certificats client importés dans le truststore ne sont pas chargés. sur le routeur.	Utilisateurs de cloud privé Edge

Cause: certificat client expiré

Ce problème se produit généralement pour un protocole TLS bidirectionnel, Lorsque le certificat envoyé par le client a expiré. Dans un protocole TLS bidirectionnel, le client et le serveur s'échangent leurs certificats publics pour effectuer le handshake. Le client valide le certificat du serveur et le serveur valide le certificat client.

Dans Edge, TLS bidirectionnel est mis en œuvre au niveau de l’hôte virtuel, où le certificat du serveur est ajouté au keystore et le certificat client est ajouté aux truststores.

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

Diagnostic

Connectez-vous à l'interface utilisateur Edge et affichez la configuration spécifique de l'hôte virtuel (Admin > Hôtes virtuels) pour lesquels la requête API est en cours ou utilisez l'API d'obtention d'un hôte virtuel de gestion pour obtenir la définition de l'hôte virtuel spécifique.

En règle générale, un hôte virtuel pour une 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>

Déterminez la référence Truststore utilisée dans l'hôte virtuel. Dans l'exemple ci-dessus, le nom de référence du Truststore est myTruststoreRef.
Déterminez le Truststore vers lequel pointe 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 Référence pour la référence Truststore spécifique. Il s'agira du nom de votre Truststore.
  <ph type="x-smartling-placeholder">
  </ph>
  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.
Dans Administration > Environnements > Keystores TLS dans l'interface utilisateur Edge, accédez à TLS Keystores et recherchez le Truststore à l'étape 3.
Sélectionnez le certificat sous le Truststore spécifique (déterminé à l'étape 3 ci-dessus), comme indiqué ci-dessous:
<ph type="x-smartling-placeholder">
</ph>
Figure 2

Dans l'exemple ci-dessus, le certificat avec l'alias client-cert-markw indique qu'il s'agit est arrivé à expiration.
Vérifiez si le certificat associé à l'alias de certificat de votre magasin de confiance a expiré.
Si le certificat n'a pas expiré, passez à la section Étapes courantes du diagnostic pour les autres causes.

Solution

Procurez-vous un nouveau certificat et importez-le:

Créez un nouveau truststore, par exemple myNewTruststore.
Importez le nouveau certificat dans le Truststore nouvellement créé.
Modifiez la référence Trustore utilisée dans l'hôte virtuel spécifique pour qu'elle pointe vers le nouveau confiance en suivant les étapes décrites dans Modifier une référence

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

Autres causes : étapes courantes du diagnostic

Pour étudier ce problème, vous devez capturer des paquets TCP/IP à l'aide de la méthode tcpdump.
1. Si vous êtes un utilisateur de cloud privé, vous pouvez capturer les paquets TCP/IP sur le l'application cliente ou le routeur.
2. Si vous êtes un utilisateur de cloud public, capturez les paquets TCP/IP sur l'application cliente.
3. Une fois que vous avez décidé où vous souhaitez capturer des paquets TCP/IP, utilisez le code suivant : tcpdump pour capturer des paquets TCP/IP:
```
tcpdump -i any -s 0 host <IP address> -w <File name>
```
  Remarque:Si vous acceptez les paquets TCP/IP sur le routeur, utilisez le paramètre adresse IP publique de l'application cliente dans la commande tcpdump.
  
  Si vous utilisez les paquets TCP/IP sur l'application cliente, utilisez l'adresse IP publique adresse du nom d'hôte utilisé dans l'hôte virtuel dans la commande tcpdump.
  
  Consultez tcpdump. pour en savoir plus sur cet outil et sur les autres variantes de cette commande.
Analyser les paquets TCP/IP collectés à l'aide du Outil Wireshark ou un outil similaire que vous connaissez bien.

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

Le paquet n° 30 dans tcpdump (image ci-dessous) montre que l'application cliente (source) a envoyé un message "Client Hello" au routeur (destination).
Le paquet n° 34 indique que le routeur accuse réception du message "Client Hello" de l'application cliente.
Le routeur envoie le message « Server Hello » dans le paquet n° 35, puis envoie son certificat ainsi que demande à l'application cliente d'envoyer son certificat dans le paquet n° 38.
Dans le paquet n° 38, où le routeur envoie le paquet "Demande de certificat", vérifiez « Noms distinctifs » qui fournit des détails sur le certificat client, sa chaîne et les autorités de certification qui sont acceptées par le routeur (serveur).

L'application cliente envoie son certificat dans le paquet n° 41. Vérifiez le Certificat Vérifiez la section n° 41 du paquet et déterminez le certificat envoyé par l'application cliente.
<ph type="x-smartling-placeholder">
</ph>
Figure 4
Vérifiez si l'objet et l'émetteur du certificat et de sa chaîne envoyés par le client (paquet n° 41) correspond au certificat accepté et à sa chaîne depuis le routeur (paquet n° 38). Une non-concordance est à l'origine de l'erreur. D'où le routeur (Serveur) envoie l'alerte chiffrée (paquet n° 57) suivie de FIN, ACK (paquet 58) au l'application cliente, puis la connexion finit par être interrompue.
La non-concordance du certificat et de sa chaîne peut être due aux scénarios décrits dans dans les sections suivantes.

Cause: envoi d'un certificat incorrect par le client

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

Diagnostic

Connectez-vous à l'interface utilisateur Edge et affichez la configuration spécifique de l'hôte virtuel (Admin > Hôtes virtuels) pour lesquels la requête API est en cours ou utilisez l'API Get virtual host de gestion pour obtenir la définition de l'hôte virtuel spécifique.

En règle générale, un hôte virtuel pour une 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>

Déterminez la référence Truststore utilisée dans l'hôte virtuel.
Dans l'exemple ci-dessus, le nom de référence du Truststore est myCompanyTruststoreRef.
Déterminez le Truststore indiqué par la référence Truststore.
1. Dans l'interface utilisateur Edge, accédez à Admin > Documentation de référence sur les environnements et recherchez le nom de référence du Truststore.
2. Notez le nom dans la colonne Référence pour la référence Truststore spécifique. Il s'agira du nom de votre Truststore.
  <ph type="x-smartling-placeholder">
  </ph>
  Figure 5
  
  Dans l'exemple ci-dessus, notez que myCompanyTruststoreRef a la valeur référence à myCompanyTruststore. Par conséquent, le nom du Truststore est myCompanyTruststore.
Récupérez les certificats stockés dans le Truststore (déterminé à l'étape précédente) à l'aide des API suivantes: <ph type="x-smartling-placeholder">
1. Répertoriez les certificats d'un keystore ou d'une API truststore.
  
  Cette API liste tous les certificats du Truststore spécifique.
2. Obtenez les détails du certificat à partir d'un keystore ou d'une API truststore.
  
  Cette API renvoie des informations sur un certificat spécifique du Truststore concerné.
Vérifiez si l'émetteur et l'objet de chaque certificat et sa chaîne sont stockés dans myCompanyTruststore correspond à celui du certificat et de sa chaîne en tant que vu dans les paquets TCP/IP (voir le paquet n° 38) ci-dessus. En cas de non-concordance, que les certificats importés dans le truststore ne sont pas chargés dans le routeur Edge. Passez à Cause: les certificats clients ne sont pas chargés dans le routeur Edge.
Si aucune incohérence n'est détectée à l'étape 5, cela signifie que l'application cliente a ne pas envoyer le bon certificat et sa chaîne.

Solution

Assurez-vous que le bon certificat et sa chaîne sont envoyés par l'application cliente à Edge.

Cause: certificat racine du client manquant dans le Truststore

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

Diagnostic

Connectez-vous à l'interface utilisateur Edge et affichez la configuration d'hôte virtuel spécifique pour laquelle l'API est en cours d'envoi (Admin > Hôtes virtuels > virtual_host), ou utilisez les <ph type="x-smartling-placeholder"></ph> Obtenir l'API hôte virtuel pour obtenir la définition de l'hôte virtuel spécifique

En règle générale, un hôte virtuel pour une 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>

Déterminez la référence du truststore utilisée dans l'hôte virtuel. Dans l'exemple précédent, le nom de référence du truststore est myCompanyTruststoreRef.
Déterminez le truststore réel utilisé par la référence truststore.
Dans l'interface utilisateur Edge, accédez à Admin > Environnements > Références et recherche pour le nom de référence du truststore.
Le nom du truststore correspondant à la référence du truststore spécifique se trouve dans la Colonne de référence.
<ph type="x-smartling-placeholder">
</ph>
Figure 6

Dans cet exemple, notez que myCompanyTruststoreRef a myCompanyTruststore dans la colonne "Référence". Par conséquent, le truststore est myCompanyTruststore.
Récupérez les certificats stockés dans le truststore (déterminé à l'étape précédente) à l'aide de les API suivantes: <ph type="x-smartling-placeholder">
1. <ph type="x-smartling-placeholder"></ph> Répertorier les certificats d'un keystore ou d'une API truststore Cette API répertorie l'ensemble des dans le truststore.
2. <ph type="x-smartling-placeholder"></ph> Obtenir les détails du certificat à partir d'un keystore ou d'une API truststore Cette API renvoie des informations un certificat spécifique dans le truststore.
Vérifier si le certificat inclut une chaîne complète, y compris le certificat racine envoyées par le client spécifique, comme indiqué dans les paquets TCP/IP (voir la Figure 4). Le Truststore doit inclure le certificat racine ainsi que le certificat d'entité finale du client et d'obtenir un certificat intermédiaire. Si le certificat racine valide du client est manquant dans le truststore, qui est à l'origine de l'erreur.

Toutefois, si la chaîne de certificats complète du client, y compris le certificat racine, existe dans le truststore, cela indique que les certificats importés dans le Truststore ne sont peut-être pas chargés dans le routeur Edge. Dans ce cas, consultez Cause: les certificats clients ne sont pas chargés dans le routeur Edge.

Solution

Assurez-vous que le certificat du bon client, y compris le certificat racine, est disponible dans le Truststore du routeur Apigee Edge.

Cause: les certificats clients ne sont pas chargés dans le routeur Edge

Si vous utilisez le cloud public, contactez l'assistance Apigee Edge.
Si vous êtes un utilisateur Private Cloud, suivez les instructions ci-dessous pour chaque routeur: <ph type="x-smartling-placeholder">
1. Vérifier 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, déplacez-le Résolution ci-dessous.
2. Si le fichier existe, utilisez la commande openssl ci-dessous pour obtenir les détails 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 de ces éléments ne correspond pas avec ce qui a été observé dans le Truststore de l'interface utilisateur Edge ou à l'aide des API de gestion, alors c'est la cause de l'erreur.
4. Il est possible que le routeur n'ait pas actualisé les certificats importés.

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, accédez à Recueillez des informations de diagnostic.

Recueillir des informations de diagnostic

Si le problème persiste alors que vous avez suivi les instructions ci-dessus, veuillez rassembler les informations de diagnostic suivantes. Contactez et partagez les informations que vous recueillez avec l'assistance Apigee Edge:

Si vous êtes un utilisateur de cloud public, fournissez les informations suivantes: <ph type="x-smartling-placeholder">
1. Nom de l'organisation
2. Nom de l'environnement
3. Nom du proxy d'API
4. Nom d'hôte virtuel
5. Nom d'alias de l'hôte
6. Exécutez la commande curl pour reproduire l'erreur
7. Paquets TCP/IP capturés sur l'application cliente
Si vous êtes un utilisateur de Private Cloud, fournissez les informations suivantes: <ph type="x-smartling-placeholder">
1. Nom d'hôte virtuel et sa définition à l'aide de l'API Get virtual host
2. Nom d'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 la commande Lister les certificats de l'API keystore et les détails de chaque certificat obtenus à l'aide de l'API Get cert details.
Des informations sur les sections de ce playbook que vous avez essayées et toute autre information susceptible aidez-nous à résoudre ce problème via Fastrack.