Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

400 Requête incorrecte - Erreur de certificat SSL

Vous consultez la documentation Apigee Edge.
Accédez à la documentation**Apigee X**. info

Problème constaté

L'application cliente reçoit une réponse HTTP 400 - Requête incorrecte avec le message "The SSL certificate error" (Erreur de certificat SSL). Cette erreur est généralement envoyée par le routeur Edge dans 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

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 :

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

Cause	Description	Instructions de dépannage applicables
Expiration du certificat client	Le certificat envoyé par le client a expiré.	Utilisateurs du 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 à celui stocké dans le truststore du routeur Edge.	Utilisateurs du cloud privé et public Edge
Certificat racine client manquant dans le truststore	Cette erreur est générée si le certificat racine signé par l'autorité de certification du client est manquant dans le truststore du routeur Edge.	Utilisateurs du cloud privé et public Edge
Certificats clients non chargés dans le routeur Edge	Cette erreur est générée si les certificats clients importés dans le truststore ne sont pas chargés sur le routeur.	Utilisateurs du cloud privé Edge

Cause : Expiration du certificat client

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 échangent leurs certificats publics pour effectuer le handshake. Le client valide le certificat du serveur et le serveur valide le certificat du client.

Dans Edge, le protocole TLS bidirectionnel est implémenté au niveau de l'hôte virtuel, où le certificat du serveur est ajouté au keystore et le certificat du client est ajouté aux truststores.

Lors du handshake TLS, si le certificat du client a expiré, le serveur envoie 400 - Requête incorrecte avec le message "The SSL certificate error" (Erreur de certificat SSL).

Diagnostic

Connectez-vous à l'UI Edge et affichez la configuration de l'hôte virtuel spécifique (Admin > Virtual Hosts) pour lequel la requête API est effectuée, ou utilisez l'API de gestion Get virtual host API 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 du 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 du truststore.
1. Dans l'UI Edge, accédez à Admin > Environments > References 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 du truststore spécifique. Il s'agit du nom de votre truststore.
  
  Figure 1
  
  Dans l'exemple ci-dessus, notez que myTruststoreRef fait référence à myTruststore. Par conséquent, le nom du truststore est myTruststore.
Dans l'UI Edge, accédez à Admin > Environments > TLS Keystores (Administration > Environnements > Keystores TLS), puis recherchez le truststore trouvé à l'étape 3.
Sélectionnez le certificat sous 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é.
Vérifiez si le certificat a expiré pour l'alias de certificat de votre truststore.
Si le certificat n'a pas expiré, passez aux étapes de diagnostic courantes pour les autres causes.

Solution

Procurez-vous un nouveau certificat et importez-le :

Créez un truststore, par exemple myNewTruststore.
Importez le nouveau certificat dans le truststore que vous venez de créer.
Modifiez la référence du truststore 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, faites pointer la référence myTruststoreRef vers myNewTruststore.

Étapes de diagnostic courantes pour les autres causes

Pour examiner ce problème, vous devez capturer les paquets TCP/IP à l'aide de l' tcpdump.
1. Si vous êtes un utilisateur du 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 décidé où vous souhaitez capturer les paquets TCP/IP, utilisez la commande tcpdump suivante pour capturer les paquets TCP/IP :
```
tcpdump -i any -s 0 host <IP address> -w <File name>
```
  Remarque : Si vous récupérez les paquets TCP/IP sur le routeur, utilisez l' adresse IP publique de l'application cliente dans la commande tcpdump.
  
  Si vous récupérez 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 tcpdump commande.
  
  Pour en savoir plus sur cet outil et sur d'autres variantes de cette commande, consultez la page tcpdump.
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'un exemple de données de paquets TCP/IP à l'aide de l'outil Wireshark :

Le paquet n° 30 du 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 et demande également à l'application cliente d'envoyer son certificat dans le paquet n° 38.
Dans le paquet n° 38, où le routeur envoie le paquet "Certificate Request", consultez la section "Distinguished Names" qui fournit des informations sur le certificat client, sa chaîne et les autorités de certification acceptées par le routeur (serveur).

L'application cliente envoie son certificat dans le paquet n° 41. Consultez la section Certificate Verify (Vérification du certificat) du paquet n° 41 et déterminez le certificat envoyé par l'application cliente.

Figure 4
Vérifiez si le sujet et l'émetteur du certificat et de sa chaîne envoyés par l'application cliente (paquet n° 41) correspondent au certificat accepté et à sa chaîne du routeur (paquet n° 38). Si ce n'est pas le cas, c'est la cause de cette erreur. Par conséquent, le routeur (serveur) envoie l'alerte chiffrée (paquet n° 57), suivie de FIN, ACK (paquet n° 58) à l' application cliente, et la connexion est finalement interrompue.
La non-concordance 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 le sujet/l'émetteur du certificat et/ou de sa chaîne envoyés par l' application cliente ne correspondent pas au certificat et/ou à sa chaîne stockés dans le truststore du routeur (serveur).

Diagnostic

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 ci-dessus, le nom de référence du truststore est myCompanyTruststoreRef.
Déterminez le truststore vers lequel pointe la référence du truststore.
1. Dans l'UI Edge, accédez à Admin > Environments > References 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 du truststore spécifique. Il s'agit du nom de votre truststore.
  
  Figure 5
  
  Dans l'exemple ci-dessus, notez que myCompanyTruststoreRef fait référence à myCompanyTruststore. Par conséquent, le nom du truststore est myCompanyTruststore.
Obtenez les certificats stockés dans le truststore (déterminé à l'étape précédente) à l'aide des API suivantes :
1. API List certificates for a keystore or truststore
  
  Cette API liste tous les certificats du truststore spécifique.
2. API Get cert details from a keystore or truststore.
  
  Cette API renvoie des informations sur un certificat spécifique dans le truststore spécifique.
Vérifiez si l'émetteur et le sujet de chaque certificat 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 n° 38 ci-dessus). Si ce n'est pas le cas, cela indique que les certificats importés dans le truststore ne sont pas chargés dans le routeur Edge. Passez à la section Cause : Certificats clients non chargés dans le routeur Edge.
Si aucune non-concordance n'a été trouvée à l'étape 5, cela indique que l'application cliente n'a pas envoyé le bon certificat ni sa chaîne.

Solution

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

Cause : Certificat racine client manquant dans le truststore

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

Diagnostic

Connectez-vous à l'UI Edge et affichez la configuration de l'hôte virtuel spécifique pour lequel la requête API est effectuée (Admin > Virtual Hosts > virtual_host), ou utilisez l' API Get virtual host 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 du truststore.
Dans l'UI Edge, accédez à Admin > Environments > References (Administration > Environnements > Références), puis recherchez le nom de référence du truststore.
Le nom du truststore pour la référence du truststore spécifique se trouve dans la Reference colonne.

Figure 6

Dans cet exemple, notez que myCompanyTruststoreRef contient myCompanyTruststore dans la colonne "Reference" (Référence). Par conséquent, le nom du truststore est myCompanyTruststore.
Obtenez les certificats stockés dans le truststore (déterminé à l'étape précédente) à l'aide des API suivantes :
1. API List certificates for a keystore or truststore. Cette API liste tous les certificats du truststore.
2. API Get cert details from a keystore or truststore. Cette API renvoie des informations sur un certificat spécifique dans le truststore.
Vérifiez si le certificat inclut une chaîne complète, y compris le certificat racine envoyé 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 final du client ou le certificat final et le certificat intermédiaire. Si le certificat racine valide du client est manquant dans le truststore, 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 truststore, cela indique que les certificats importés dans le truststore ne sont peut-être pas chargés dans le routeur Edge. Si c'est le cas, consultez la section Cause : Certificats clients non chargés dans le routeur Edge.

Solution

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

Cause : Certificats clients non chargés dans le routeur Edge

Si vous êtes un utilisateur du cloud public, contactez l'assistance Apigee Edge.
Si vous êtes un utilisateur du cloud privé, suivez les instructions ci-dessous sur 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 "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, le sujet et la date d'expiration du certificat. Si l'un de ces éléments ne correspond pas à ce qui a été observé dans le truststore de l'UI 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 rechargé les certificats importés.

Solution

Redémarrez le routeur pour vous assurer que les derniers certificats sont chargés en suivant l'étape ci-dessous :

apigee-service edge-router restart

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

Recueillir des informations de diagnostic

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

Si vous êtes un utilisateur du cloud public, fournissez les informations suivantes :
1. Nom de l'organisation
2. Nom de l'environnement
3. Nom du proxy d'API
4. Nom de l'hôte virtuel
5. Nom de l'alias d'hôte
6. Commande curl complète pour reproduire l'erreur
7. Paquets TCP/IP capturés sur l'application cliente
Si vous êtes un utilisateur du cloud privé, fournissez les informations suivantes :
1. Nom de l'hôte virtuel et sa définition à l'aide de l'API Get virtual host
2. Nom de l'alias d'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 List the certificates from the keystore et détails de chaque certificat obtenu à l'aide de l'API Get cert details.
Informations sur les sections de ce guide que vous avez essayées et toute autre information qui nous aidera à accélérer la résolution de ce problème.