502 Bad Gateway – selbst signiertes Zertifikat in der Kette

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zuApigee X wechseln. info

Symptom

Die Clientanwendung erhält für API-Aufrufe in Edge Microgateway einen HTTP-Antwortcode 502 mit der Meldung Bad Gateway.

Alternativ erhält der Administrator beim Ausführen des edgemicro configure Befehls den self signed certificate in certificate chain Fehler.

Fehlermeldung

Der Client sieht die folgende Antwortmeldung:

HTTP/1.1 502 Bad Gateway

Zwei häufige 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: Zielserver präsentiert ein selbst signiertes Zertifikat

Wenn der Zielserver bei der Southbound Verbindung ein selbst signiertes Zertifikat präsentiert, löst Edge Microgateway standardmäßig diesen Fehler aus, da selbst signierte Zertifikate nicht vertrauenswürdig sind.

Diagnose

In den Logs (/var/tmp/edgemicro-`hostname`- *.log) kann der folgende Fehler auftreten:

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 Edge Microgateway sehr wahrscheinlich ein selbst signiertes Zertifikat vom Zielserver erhalten hat. So bestätigen Sie dies: So bestätigen Sie dies:

1. Führen Sie den folgenden openssl Befehl aus, um die Zertifikatskette des Zielservers zu überprüfen:

   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 des Problems.

   Im folgenden Beispiel präsentiert der Zielserver ein selbst signiertes Zertifikat:

   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. Bitten Sie das Team, das für den Zielserver zuständig ist, ein gültiges TLS-Zertifikat zu besorgen, das von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) signiert wurde.

2. Wenn das nicht möglich ist, können Sie eine der folgenden Optionen verwenden, um selbst signierte Zertifikate in Edge Microgateway zuzulassen.

   Option 1: Legen Sie eine Systemeigenschaft fest, damit Edge Microgateway alle Zertifikate als vertrauenswürdig einstuft

   1. Wenn Sie Docker verwenden, lesen Sie den Abschnitt Eine Zertifizierungsstelle verwenden, die von Node.js nicht als vertrauenswürdig eingestuft wird.

   2. Andernfalls exportieren Sie eine Umgebungsvariable namens NODE_EXTRA_CA_CERTS, die auf die Stammzertifizierungsstellendatei verweist.

      Dies ist auf der offiziellen Node.js Website dokumentiert.

   Option 2: Konfigurieren Sie die YAML-Konfigurationsdatei von Edge Microgateway so, dass das spezifische Zertifikat für diesen Zielserver als vertrauenswürdig eingestuft wird

   1. Das Zertifikat (oder die Kette) des Zielservers muss im PEM-Format vorliegen. Informationen zum Konvertieren anderer Zertifikatsformate in PEM finden Sie unter Zertifikate in ein unterstütztes Format konvertieren.

   2. Wenn eine Zertifikatskette vorhanden ist, müssen die Zertifikate in der richtigen Reihenfolge angegeben sein. Das Blattzertifikat muss immer zuerst angegeben werden, gefolgt vom Zwischenzertifikat und dann vom Stammzertifikat. Weitere Informationen finden Sie unter Zertifikatskette validieren.

      Im folgenden Beispiel haben wir die vertrauenswürdige Zertifizierungsstellendatei für untrusted-root.badssl.com konfiguriert.

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

   Die Anleitung zum Konfigurieren finden Sie auch im Video Edge Microgateway Module – Configure 1-way and 2-way Southbound TLS. Weitere Informationen finden Sie unter SSL auf dem Edge Microgateway-Server konfigurieren.

Wenn das Problem weiterhin besteht, gehen Sie zu Erfassen von Diagnoseinformationen erforderlich.

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

Wenn Sie Edge Microgateway zum ersten Mal einrichten, müssen Sie unter anderem den Befehl ausführen: edgemicro configure oder edgemicro private configure. Mit diesem Befehl wird der Cluster gebootstrappt und Apigee Edge kontaktiert, um die erforderlichen Informationen herunterzuladen.

Bei Edge Private Cloud wird die Management Server-URL durch das Argument -m bestimmt. Wenn Sie TLS für den Management Server aktiviert haben, versucht Edge Microgateway, das vom Management Server präsentierte Zertifikat zu überprüfen.

Ein Beispiel für einen edgemicro configure-Befehl für Edge Private Cloud sieht so aus:

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 Management Server mit einem selbst signierten Zertifikat konfiguriert ist, wird in der Konsolenausgabe der folgende Fehler 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 gibt der Management Server (management.apigee-dev.net) möglicherweise ein selbst signiertes TLS-Zertifikat zurück.
2. Wahrscheinlich hat Ihr Apigee Edge-Systemadministrator das Zertifikat und verfügt über eine Kopie davon.
3. Andernfalls führen Sie den folgenden Befehl aus, um Informationen zum Zertifikat zu erhalten:

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

4. Wenn der Management Server ein selbst signiertes Zertifikat hat, ist das die Ursache dieses Problems.

Auflösung

1. Bitten Sie das Team, das für den Zielserver zuständig ist, ein gültiges TLS-Zertifikat zu besorgen, das von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) signiert wurde.

2. Wenn das nicht möglich ist, gehen Sie so vor, um selbst signierte Zertifikate in Edge Microgateway zuzulassen.

3. Legen Sie eine Systemeigenschaft fest, damit Edge Microgateway alle Zertifikate als vertrauenswürdig einstuft.
4. Wenn Sie Docker verwenden, lesen Sie den Abschnitt Eine Zertifizierungsstelle verwenden, die von Node.js nicht als vertrauenswürdig eingestuft wird.
5. Andernfalls exportieren Sie eine Umgebungsvariable namens NODE_EXTRA_CA_CERTS, die auf die Stammzertifizierungsstellendatei verweist.Dies ist auf der offiziellen Node.js Website dokumentiert.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an den Apigee Edge-Support:

• Logdateien: Der Standardordner ist /var/tmp, kann aber in der Hauptdatei config.yaml (logging > dir parameter) überschrieben werden. Es wird empfohlen, log > level in info zu ändern, bevor Sie die Logdateien an den Apigee Edge-Support senden.
• Konfigurationsdatei: Die Hauptkonfiguration von Edge Microgateway befindet sich in der YAML Datei im Standardordner von Edge Microgateway, $HOME/.edgemicro. Es gibt eine Standardkonfigurationsdatei namens default.yaml und dann eine für jede Umgebung ORG-ENV-config.yaml. Laden Sie diese Datei vollständig für die betroffene Organisation und Umgebung hoch.

  Referenzdokumente

  Edge UI für den Zugriff auf die Edge API mit TLS konfigurieren