502 Bad Gateway – selbst signiertes Zertifikat in der Kette

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation
weitere Informationen

Symptom

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

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

Fehlermeldung

Der Client sieht die folgende Antwortnachricht:

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
Der Zielserver stellt ein selbst signiertes Zertifikat bereit Edge Microgateway prüft das Zertifikat des Zielservers. Wenn es nicht vertrauenswürdig ist, wird ein Laufzeitfehler ausgelöst. Nutzer von Edge Public und Private Cloud
Apigee Edge Management Server verwendet ein selbst signiertes Zertifikat Wenn Sie Edge Microgateway zum ersten Mal konfigurieren, wird über TLS eine Verbindung zu Apigee Edge zum Bootstrapping hergestellt. Wenn Edge ein selbst signiertes Zertifikat anzeigt, schlägt dieser Vorgang fehl. Edge Private Cloud-Nutzer

Ursache: Zielserver stellt ein selbst signiertes Zertifikat bereit

Wenn der Zielserver bei der Verbindung southbound ein selbst signiertes Zertifikat bereitstellt, löst Edge Microgateway standardmäßig diesen Fehler aus, da es selbst signierten Zertifikaten nicht vertraut.

Diagnose

In den Logs kann der folgende Fehler auftreten (/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][]

Der Fehlercode SELF_SIGNED_CERT_IN_CHAIN gibt an, dass das Edge Microgateway höchstwahrscheinlich ein selbst signiertes Zertifikat vom Zielserver erhalten hat. Führen Sie die folgenden Schritte aus, um dies zu bestätigen:

  1. Führen Sie den folgenden openssl-Befehl aus, um die Zertifikatskette des Zielservers zu prü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.

    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. Arbeiten Sie mit dem Team, das Inhaber des Zielservers ist, zusammen, um ein ordnungsgemäßes TLS-Zertifikat zu erhalten, das von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde.
  2. Wenn dies nicht möglich ist, sollten Sie eine der folgenden Optionen in Betracht ziehen, um selbst signierte Zertifikate in Edge Microgateway zuzulassen.

    Option 1: Systemattribut festlegen, damit Edge Microgateway allen Zertifikaten vertraut wird

    1. Wenn Sie Docker verwenden, lesen Sie den Abschnitt Eine von Node.js nicht vertrauenswürdige Zertifizierungsstelle verwenden.
    2. Exportieren Sie andernfalls eine Umgebungsvariable namens NODE_EXTRA_CA_CERTS, die auf die Stamm-CA-Datei verweist.

      Dies ist auf der offiziellen Node.js dokumentiert.

    Option 2: YAML-Konfigurationsdatei für Edge Microgateway so konfigurieren, dass dieses bestimmte Zertifikat für diesen Zielserver als vertrauenswürdig eingestuft wird

    1. Prüfen Sie, ob Sie das Zertifikat oder die Kette des Zielservers im PEM-Format haben. Eine Anleitung zum Konvertieren anderer Zertifikatsformate in das PEM-Format finden Sie unter Zertifikate in ein unterstütztes Format konvertieren.
    2. Wenn eine Zertifikatskette vorhanden ist, achten Sie darauf, dass die Zertifikate in der richtigen Reihenfolge sind. Das untergeordnete Zertifikat sollte immer zuerst gefolgt vom Zwischenzertifikat und schließlich dem Stammzertifikat sein. Weitere Informationen dazu finden Sie unter Zertifikatskette validieren.

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

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

    Eine Anleitung zum Konfigurieren finden Sie auch im Video Edge Microgateway Module – 1-Wege- und 2-Wege-Richtungs-TLS für Süden konfigurieren. Weitere Informationen finden Sie unter SSL auf dem Edge Microgateway-Server konfigurieren.

Wenn das Problem weiterhin besteht, lesen Sie die Informationen unter Diagnoseinformationen müssen erfasst werden.

Ursache: Apigee Edge Management Server verwendet ein selbst signiertes Zertifikat

Wenn Edge Microgateway zum ersten Mal eingerichtet wird, müssen Sie unter anderem edgemicro configure oder edgemicro private configure ausführen. Mit diesem Befehl wird das Bootstrapping des Clusters gestartet und Apigee Edge kontaktiert, um die erforderlichen Informationen herunterzuladen.

Für die Edge Private Cloud wird die Management Server-URL durch das Argument -m bestimmt. Wenn Sie TLS für den Verwaltungsserver aktiviert haben, würde Edge Microgateway versuchen, das vom Verwaltungsserver bereitgestellte Zertifikat zu prü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 Verwaltungsserver mit einem selbst signierten Zertifikat konfiguriert ist, wird der folgende 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 gibt der Verwaltungsserver (management.apigee-dev.net) möglicherweise ein selbst signiertes TLS-Zertifikat zurück.
  2. Es ist wahrscheinlich, dass Ihr Apigee Edge-Systemadministrator das Zertifikat bereitgestellt hat und eine Kopie davon hat.
  3. Andernfalls können Sie den folgenden Befehl ausführen, 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 des Problems.

Auflösung

  1. Arbeiten Sie mit dem Team, das Inhaber des Zielservers ist, zusammen, um ein ordnungsgemäßes TLS-Zertifikat zu erhalten, das von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde.
  2. Wenn dies nicht möglich ist, führen Sie die folgenden Schritte aus, um selbst signierte Zertifikate in Edge Microgateway zuzulassen.

  3. Legen Sie ein Systemattribut fest, damit Edge Microgateway allen Zertifikaten vertraut wird.
  4. Wenn Sie Docker verwenden, lesen Sie den Abschnitt Eine Zertifizierungsstelle verwenden, die von Node.js nicht als vertrauenswürdig eingestuft wird.
  5. Exportieren Sie andernfalls eine Umgebungsvariable namens NODE_EXTRA_CA_CERTS, die auf die Stamm-CA-Datei verweist.Dies ist auf der offiziellen Node.js dokumentiert.

Erfassen von Diagnoseinformationen erforderlich

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

  • Protokolldateien: Der Standardordner ist /var/tmp, kann aber in der config.yaml-Hauptdatei (logging > dir parameter) überschrieben werden. Es wird empfohlen, log > level in info zu ändern, bevor Sie die Protokolldateien an den Apigee Edge-Support senden.
  • Konfigurationsdatei: Die Hauptkonfiguration von Edge Microgateway befindet sich in der YAML-Datei im Edge Microgateway-Standardordner $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-Benutzeroberfläche für die Verwendung von TLS für den Zugriff auf die Edge API konfigurieren