502 Bad Gateway – selbst signiertes Zertifikat in der Kette

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

<ph type="x-smartling-placeholder">

Symptom

Die Clientanwendung empfängt den HTTP-Antwortcode 502 mit der Nachricht Bad Gateway als Antwort für API-Aufrufe in Edge Microgateway.

Alternativ erhält der Administrator einen self signed certificate in certificate chain-Fehler beim Ausführen der <ph type="x-smartling-placeholder"></ph> edgemicro configure-Befehl.

Fehlermeldung

Der Client sieht die folgende Antwort: 

HTTP/1.1 502 Bad Gateway

Zwei gängige Beispiele für Fehlerantworten sind: 

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

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

Alternativ kann dieser Fehler beim Ausführen von edgemicro configure auftreten: 

{ 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' }

Mögliche Ursachen

Ursache Beschreibung Anleitungen zur Fehlerbehebung gelten für
<ph type="x-smartling-placeholder"></ph> Zielserver zeigt selbst signiertes Zertifikat an Edge Microgateway überprüft das Zertifikat des Zielservers und wenn es nicht vertrauenswürdig ist löst einen Laufzeitfehler aus. Edge-Nutzer von öffentlichen und privaten Clouds
Apigee Edge Management Server verwendet ein selbst signiertes Zertifikat Wenn Sie Edge Microgateway zum ersten Mal konfigurieren, wird über TLS für Bootstrap. Wenn Edge ein selbst signiertes Zertifikat anzeigt, schlägt dies fehl. Edge Private Cloud-Nutzer

Ursache: Zielserver zeigt selbst signiertes Zertifikat an

<ph type="x-smartling-placeholder">

Wenn ein selbst signiertes Zertifikat vom Zielserver am <ph type="x-smartling-placeholder"></ph> Verbindung in Richtung Süden, würde Edge Microgateway standardmäßig diesen Fehler ausgeben, selbst signierten Zertifikaten nicht vertraut.

Diagnose

In den Logs (/var/tmp/edgemicro-`hostname`- *.log) wird möglicherweise der folgende Fehler angezeigt: 

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

Der Fehlercode SELF_SIGNED_CERT_IN_CHAIN gibt an, dass das Edge Microgateway Sie haben höchstwahrscheinlich ein selbst signiertes Zertifikat vom Zielserver erhalten. Führen Sie zur Bestätigung führen Sie die folgenden Schritte aus:

  1. Führen Sie den folgenden openssl-Befehl aus, um zu prüfen, Zertifikatskette: 
    echo | openssl s_client -connect TARGET_SERVER_HOSTNAME:PORT -servername TARGET_SERVER_HOSTNAME | openssl x509 -noout

  2. Wenn die Zertifikatskette des Zielservers tatsächlich selbst signiert ist, ist dies die Ursache das Problem zu lösen.

    Beachten Sie im folgenden Beispiel, dass der Zielserver ein selbst signiertes Zertifikat bereitstellt: 

    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

Auflösung

  1. Erstellen Sie zusammen mit dem Team, das Inhaber des Zielservers ist, ein korrektes TLS-Zertifikat, das von einem vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA). <ph type="x-smartling-placeholder">

  2. Wenn dies nicht möglich ist, sollten Sie eine der folgenden Optionen in Betracht ziehen. Zertifikate in Edge Microgateway.

    <ph type="x-smartling-placeholder">

    Option 1: Systemeigenschaft festlegen, damit Edge Microgateway allen vertrauen Zertifikate

    1. Wenn Sie Docker verwenden, lesen Sie den Abschnitt <ph type="x-smartling-placeholder"></ph> Zertifizierungsstelle verwenden, die von Node.js nicht als vertrauenswürdig eingestuft wird

    2. Andernfalls exportieren Sie die Umgebungsvariable NODE_EXTRA_CA_CERTS. auf die Stamm-CA-Datei verweist.

      Dies wird auf der offiziellen Node.js Website.

    <ph type="x-smartling-placeholder">

    Option 2: YAML-Konfigurationsdatei für Edge Microgateway so konfigurieren, dass dieser bestimmten für diesen Zielserver

    1. Achten Sie darauf, dass das Zertifikat (oder die Kette) des Zielservers im PEM-Format vorliegt. Bis andere Zertifikatsformate in das PEM-Format konvertieren, <ph type="x-smartling-placeholder"></ph> Zertifikate in ein unterstütztes Format konvertieren

    2. Wenn eine Zertifikatskette vorhanden ist, achten Sie darauf, dass die Zertifikate in den richtigen Reihenfolge. Das untergeordnete Zertifikat sollte immer an erster Stelle stehen, gefolgt vom Zwischenzertifikat. und dann auf das Root-Zertifikat. Weitere Erklärungen dazu finden Sie <ph type="x-smartling-placeholder"></ph> Zertifikatskette wird validiert.

      Im folgenden Beispiel haben wir die Datei der vertrauenswürdigen Zertifizierungsstelle für untrusted-root.badssl.com 

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

    Die Konfigurationsanleitung finden Sie auch im <ph type="x-smartling-placeholder"></ph> Edge Microgateway-Modul: Video zur 1- und 2-Wege-Verbindung mit TLS in Richtung Süden konfigurieren Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> SSL auf dem Edge Microgateway-Server konfigurieren.

Wenn das Problem weiterhin besteht, gehe zu Diagnoseinformationen müssen erfasst werden.

Ursache: Apigee Edge Management Server verwendet ein selbst signiertes Zertifikat.

<ph type="x-smartling-placeholder">

Wenn Edge Microgateway zum ersten Mal eingerichtet wird, müssen Sie einen der Befehle ausführen, ist edgemicro configure oder edgemicro private configure. Mit diesem Befehl Führen Sie ein Bootstrapping des Clusters aus und kontaktieren Sie Apigee Edge, um die erforderlichen Informationen herunterzuladen.

Für Edge Private Cloud wird die Verwaltungsserver-URL durch das Argument -m bestimmt. Wenn Sie TLS für den Verwaltungsserver aktiviert haben, versucht Edge Microgateway, zu überprüfen, das vom Verwaltungsserver bereitgestellte Zertifikat.

Hier ein Beispiel für einen edgemicro configure-Befehl für Edge Private Cloud: 

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

Wenn der Verwaltungsserver mit einem selbst signierten Zertifikat konfiguriert ist, erhalten Sie das folgenden Fehler in der Konsolenausgabe angezeigt. 

{ 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' }

Diagnose

  1. In diesem Fall hat der Verwaltungsserver (management.apigee-dev.net) ein selbst signiertes TLS-Zertifikat zurückgeben.
  2. Es ist wahrscheinlich, dass Ihr Apigee Edge-Systemadministrator das Zertifikat zur Verfügung gestellt hat. und hat eine Kopie davon.
  3. Andernfalls führen Sie den folgenden Befehl aus, um Informationen zum Zertifikat abzurufen: 
    echo | openssl s_client -connect management.apigee-dev.net:8443 -servername management.apigee-dev.net | openssl x509 -noout
  4. Wenn der Verwaltungsserver ein selbst signiertes Zertifikat hat, ist das die Ursache Problem.

Auflösung

  1. Erstellen Sie zusammen mit dem Team, das Inhaber des Zielservers ist, ein korrektes TLS-Zertifikat, das von einem vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA). <ph type="x-smartling-placeholder">

  2. Wenn dies nicht möglich ist, gehen Sie so vor, um die Selbstsignierung zu aktivieren. Zertifikate in Edge Microgateway.

    3. <ph type="x-smartling-placeholder">
  3. Legen Sie eine Systemeigenschaft fest, damit Edge Microgateway allen Zertifikaten vertraut.
  4. Wenn Sie Docker verwenden, lesen Sie den Abschnitt <ph type="x-smartling-placeholder"></ph> Sie verwenden eine Zertifizierungsstelle, die von Node.js nicht als vertrauenswürdig eingestuft wird.
  5. Andernfalls exportieren Sie die Umgebungsvariable NODE_EXTRA_CA_CERTS. auf die Stammzertifizierungsstelle. dokumentiert auf der offiziellen Node.js-Website. <ph type="x-smartling-placeholder">

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem trotz Befolgung der obigen Anleitung weiterhin besteht, stellen Sie Folgendes zusammen: Diagnoseinformationen und wenden Sie sich dann an den Apigee Edge-Support:

  • Protokolldateien: Der Standardordner ist /var/tmp, kann jedoch in folgenden Ordner überschrieben werden: die config.yaml-Hauptdatei (logging > dir parameter) Es ist wird empfohlen, den log > level in info zu ändern, bevor Sie den Parameter Protokolldateien an den Apigee Edge-Support.
  • Konfigurationsdatei: Die Hauptkonfiguration von Edge Microgateway befindet sich in der YAML-Datei. im Edge Microgateway-Standardordner $HOME/.edgemicro. Es gibt eine Standardkonfigurationsdatei mit dem Namen default.yaml, gefolgt von einer Datei für jede Umgebung ORG - ENV - config.yaml Diese Datei hochladen für die betroffene Organisation und Umgebung.

    Referenzdokumente

    <ph type="x-smartling-placeholder"></ph> Konfigurieren Sie die Edge-Benutzeroberfläche für den Zugriff auf die Edge API mithilfe von TLS.