502 Bad Gateway – Certificat autosigné dans la chaîne

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

Problème constaté

L'application cliente reçoit un code de réponse HTTP 502 avec le message Bad Gateway en réponse aux appels d'API dans Edge Microgateway.

L'administrateur peut également recevoir une erreur self signed certificate in certificate chain lorsqu'il exécute la edgemicro configure commande.

Message d'erreur

Le client voit le message de réponse suivant :

HTTP/1.1 502 Bad Gateway

Voici deux exemples courants de réponses d'erreur :

{"message":"self signed certificate in certificate chain","code":"SELF_SIGNED_CERT_IN_CHAIN"}

{"message":"self signed certificate","code":"DEPTH_ZERO_SELF_SIGNED_CERT"}

Cette erreur peut également se produire lors de l'exécution de edgemicro configure :

{ Error: self signed certificate in certificate chain
at TLSSocket.onConnectSecure (_tls_wrap.js:1051:34)
at TLSSocket.emit (events.js:189:13)
at TLSSocket._finishInit (_tls_wrap.js:633:8) code: 'SELF_SIGNED_CERT_IN_CHAIN' }

Causes possibles

Cause : Le serveur cible présente un certificat autosigné

Si un certificat autosigné est présenté par le serveur cible lors de la connexion sortante, Edge Microgateway génère cette erreur par défaut, car il n'approuve pas les certificats autosignés.

Diagnostic

L'erreur suivante peut s'afficher dans les journaux (/var/tmp/edgemicro-`hostname`- *.log) :

2021-05-18T10:52:46.425Z [error][0:8000][1][gsc][test][edgemicro_badtargethost][][][2db53f80-
b7c7-11eb-9abe-05b6297863f1][microgateway-core][][GET][502][self signed certificate in certificate
chain][SELF_SIGNED_CERT_IN_CHAIN][]

Le code d'erreur SELF_SIGNED_CERT_IN_CHAIN indique qu'Edge Microgateway a très probablement reçu un certificat autosigné du serveur cible. Pour le confirmer, procédez comme suit :

1. Exécutez la commande openssl suivante pour vérifier la chaîne de certificats du serveur cible :

   echo | openssl s_client -connect TARGET_SERVER_HOSTNAME:PORT -servername TARGET_SERVER_HOSTNAME | openssl x509 -noout
   

2. Si la chaîne de certificats du serveur cible est autosignée, c'est la cause de le problème.

   Dans l'exemple suivant, notez que le serveur cible présente un certificat autosigné :

   echo | openssl s_client -connect untrusted-root.badssl.com:443 -servername untrusted-root.badssl.com | openssl x509 -noout
   

   depth=1 C = US, ST = California, L = San Francisco, O = BadSSL, CN = BadSSL Untrusted Root Certificate Authority
   verify error:num=19:self signed certificate in certificate chain
   verify return:0
   DONE

Solution

1. Collaborez avec l'équipe propriétaire du serveur cible pour obtenir un certificat TLS approprié signé par une autorité de certification approuvée.

2. Si cela n'est pas possible, envisagez l'une des options suivantes pour autoriser les certificats autosignés dans Edge Microgateway.

   Option 1 : Définissez une propriété système pour autoriser Edge Microgateway à approuver tous les certificats

   1. Si vous utilisez Docker, consultez Utiliser une autorité de certification non approuvée par Node.js

   2. Sinon, exportez une variable d'environnement appelée NODE_EXTRA_CA_CERTS, qui pointe vers le fichier d'autorité de certification racine.

      Cette procédure est décrite sur le site Web officiel de Node.js.

   Option 2 : Configurez le fichier de configuration YAML d'Edge Microgateway pour approuver ce certificat spécifique pour ce serveur cible

   1. Assurez-vous que le certificat (ou la chaîne) du serveur cible est au format PEM. Pour convertir d'autres formats de certificat au format PEM, suivez les instructions de la section Convertir des certificats au format compatible.

   2. S'il existe une chaîne de certificats, assurez-vous que les certificats sont dans le bon ordre. Le certificat de feuille doit toujours être en premier, suivi du certificat intermédiaire, puis du certificat racine. Pour en savoir plus, consultez la section Valider la chaîne de certificats.

      Dans l'exemple suivant, nous avons configuré le fichier d'autorité de certification approuvée pour untrusted-root.badssl.com.

      edgemicro:
      ...
      targets:
        - host: 'untrusted-root.badssl.com'
          ssl:
            client
              ca: /opt/apigee/certs/untrusted-root.pem

   Les instructions de configuration sont également présentées dans la vidéo Module Edge Microgateway – Configure 1-way and 2-way Southbound TLS. Pour en savoir plus, consultez la section Configurer SSL sur le serveur Edge Microgateway.

Si le problème persiste, consultez la page Vous devez collecter des informations de diagnostic.

Cause : Le serveur de gestion Apigee Edge utilise un certificat autosigné

Lors de la première configuration d'Edge Microgateway, vous devez exécuter l'une des commandes suivantes : edgemicro configure ou edgemicro private configure. Cette commande amorce le cluster et contacte Apigee Edge pour télécharger les informations requises.

Pour Edge pour le cloud privé, l'URL du serveur de gestion est déterminée par l'argument -m. Si vous avez activé TLS pour le serveur de gestion, Edge Microgateway tente de vérifier le certificat présenté par le serveur de gestion.

Voici un exemple de commande edgemicro configure pour Edge pour le cloud privé :

edgemicro private configure -u <username> -p <password> -o apigee -e dev -v secure -r https://apigee-dev.net -m https://management.apigee-dev.net:8443

Si le serveur de gestion est configuré avec un certificat autosigné, l'erreur suivante s'affiche dans la sortie de la console.

{ Error: self signed certificate in certificate chain
at TLSSocket.onConnectSecure (_tls_wrap.js:1051:34)
at TLSSocket.emit (events.js:189:13)
at TLSSocket._finishInit (_tls_wrap.js:633:8) code: 'SELF_SIGNED_CERT_IN_CHAIN' }

Diagnostic

1. Dans ce cas, le serveur de gestion (management.apigee-dev.net) peut renvoyer un certificat TLS autosigné.
2. Il est probable que votre administrateur système Apigee Edge ait fourni le certificat et en possède une copie.
3. Sinon, exécutez la commande suivante pour obtenir des informations sur le certificat :

   echo | openssl s_client -connect management.apigee-dev.net:8443 -servername management.apigee-dev.net | openssl x509 -noout
   

4. Si le serveur de gestion possède un certificat autosigné, c'est la cause de ce problème.

Solution

1. Collaborez avec l'équipe propriétaire du serveur cible pour obtenir un certificat TLS approprié signé par une autorité de certification approuvée.

2. Si cela n'est pas possible, procédez comme suit pour autoriser les certificats autosignés dans Edge Microgateway.

3. Définissez une propriété système pour autoriser Edge Microgateway à approuver tous les certificats.
4. Si vous utilisez Docker, consultez Utiliser une autorité de certification non approuvée par Node.js.
5. Sinon, exportez une variable d'environnement appelée NODE_EXTRA_CA_CERTS, qui pointe vers le fichier d'autorité de certification racine.Cette procédure est décrite sur le site Web officiel Node.js.

Vous devez collecter des informations de diagnostic

Si le problème persiste, même après avoir suivi les instructions ci-dessus, rassemblez les informations de diagnostic suivantes, puis contactez l'assistance Apigee Edge :

• Fichiers journaux : le dossier par défaut est /var/tmp, mais il peut être remplacé dans le fichier config.yaml principal (logging > dir parameter). Nous vous recommandons de remplacer log > level par info avant de fournir les fichiers journaux à l'assistance Apigee Edge.
• Fichier de configuration : la configuration principale d'Edge Microgateway réside dans le fichier YAML du dossier Edge Microgateway par défaut, $HOME/.edgemicro. Il existe un fichier de configuration par défaut appelé default.yaml, puis un pour chaque environnement ORG-ENV-config.yaml. Importez ce fichier dans son intégralité pour l'organisation et l'environnement concernés.

  Documents de référence

  Configurer l'UI Edge pour utiliser TLS afin d'accéder à l'API Edge