503 Dienst nicht verfügbar – SSL-Handshake-Fehler

API-Monitoring

Methode 1: API-Monitoring verwenden

So diagnostizieren Sie den Fehler mit API Monitoring:

1. Melden Sie sich in der Apigee Edge-UI als Nutzer mit einer geeigneten Rolle an.

2. Wechseln Sie zu der Organisation, in der Sie das Problem untersuchen möchten.

   
3. Rufen Sie die Seite Analysieren > API-Monitoring > Untersuchen auf.
4. Wählen Sie den Zeitraum aus, in dem die Fehler aufgetreten sind.

5. Stellen Sie den Fehlercode im Vergleich zur Zeit dar.

6. Wählen Sie eine Zelle mit dem Fehlercode messaging.adaptors.http.flow.SslHandshakeFailed aus, wie unten dargestellt:

   ( größeres Bild ansehen)

   

7. Informationen zum Fehlercode messaging.adaptors.http.flow.SslHandshakeFailed werden wie unten dargestellt angezeigt:

   ( größeres Bild ansehen)

   

8. Klicken Sie auf Logs ansehen und maximieren Sie die Zeile für die fehlgeschlagene Anfrage.

   ( größeres Bild ansehen)

   
9. Notieren Sie sich im Fenster Logs die folgenden Details:
   • Nachrichten-ID der Anfrage
   • Statuscode:503
   • Fehlerquelle: target
   • Fehlercode:messaging.adaptors.http.flow.SslHandshakeFailed

Trace

Vorgehensweise 2: Trace-Tool verwenden

So diagnostizieren Sie den Fehler mit dem Trace-Tool:

1. Aktivieren Sie die Trace-Sitzung und entweder
   • Warten Sie, bis der Fehler 503 Service Unavailable mit dem Fehlercode messaging.adaptors.http.flow.SslHandshakeFailed auftritt.
   • Wenn Sie das Problem reproduzieren können, führen Sie den API-Aufruf aus, um das Problem zu reproduzieren: 503 Service Unavailable

2. Prüfen Sie, ob Alle FlowInfos anzeigen aktiviert ist:

   
3. Wählen Sie eine der fehlgeschlagenen Anfragen aus und sehen Sie sich den Trace an.
4. Navigieren Sie durch die verschiedenen Phasen des Traces und suchen Sie nach der Stelle, an der der Fehler aufgetreten ist.

5. Der Fehler wird in der Regel nach der Phase Target Request Flow Started angezeigt, wie unten dargestellt:

   ( größeres Bild ansehen)

   
6. Notieren Sie sich die Werte der folgenden Elemente aus dem Trace:
   • Fehler: SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.cause: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.class::com.apigee.errors.http.server.ServiceUnavailableException
   • Der Wert des Fehlers SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target gibt an, dass der SSL-Handshake fehlgeschlagen ist, da der Message Processor von Apigee Edge das Zertifikat des Backend-Servers nicht validieren konnte.
7. Suchen Sie im Trace nach der Phase AX (Analytics Data Recorded) und klicken Sie darauf.

8. Scrollen Sie nach unten zum Abschnitt Phase Details Error Headers (Fehlerheader für Phasendetails) und ermitteln Sie die Werte von X-Apigee-fault-code, X-Apigee-fault-source und X-Apigee-Message-ID, wie unten dargestellt:

   ( größeres Bild ansehen)

   
9. Notieren Sie sich die Werte von X-Apigee-fault-code, X-Apigee-fault-source und X-Apigee-Message-ID:

Fehlerheader	Wert
X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
X-Apigee-fault-source	target
X-Apigee-Message-ID	MESSAGE_ID

NGINX

Verfahren 3: NGINX-Zugriffslogs verwenden

So diagnostizieren Sie den Fehler mithilfe von NGINX-Zugriffslogs:

1. Wenn Sie Private Cloud-Nutzer sind, können Sie die NGINX-Zugriffsprotokolle verwenden, um die wichtigsten Informationen zu HTTP 503 Service Unavailable zu ermitteln.

2. NGINX-Zugriffslogs prüfen:

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

3. Suchen Sie nach 503-Fehlern mit dem Fehlercode messaging.adaptors.http.flow.SslHandshakeFailed in einem bestimmten Zeitraum (wenn das Problem in der Vergangenheit aufgetreten ist) oder nach Anfragen, bei denen weiterhin 503-Fehler auftreten.

4. Wenn Sie 503-Fehler finden, bei denen der X-Apigee-fault-code mit dem Wert von messaging.adaptors.http.flow.SslHandshakeFailed übereinstimmt, ermitteln Sie den Wert von X-Apigee-fault-source.

   Beispiel für einen 503-Fehler aus dem NGINX-Zugriffslog:

   ( größeres Bild ansehen)

   

   Der obige Beispiel-Eintrag aus dem NGINX-Zugriffslog hat die folgenden Werte für X-Apigee-fault-code und X-Apigee-fault-source:

   Header	Wert
   X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-fault-source	target

Logs des Message Processors

Vorgehensweise 4: Message Processor-Logs verwenden

1. Ermitteln Sie die Nachrichten-ID einer der fehlgeschlagenen Anfragen mit API Monitoring, dem Trace-Tool oder NGINX-Zugriffsprotokollen, wie in Gängige Diagnoseschritte beschrieben.

2. Suchen Sie im Message Processor-Log (/opt/apigee/var/log/edge-message-processor/logs/system.log) nach der ID der spezifischen Anfragenachricht. Möglicherweise wird der folgende Fehler angezeigt:

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
   SSLClientChannel[Connected: Remote:X.X.X.X:443
   Local:192.168.194.140:55102]@64596 useCount=1
   bytesRead=0 bytesWritten=0 age=233ms  lastIO=233ms
   isOpen=true handshake failed, message: General SSLEngine problem
   

   Der obige Fehler weist darauf hin, dass der SSL-Handshake zwischen dem Message Processor und dem Backend-Server fehlgeschlagen ist.

   Danach folgt eine Ausnahme mit detailliertem Stacktrace, wie unten dargestellt:

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
   RequestWriteListener.onException(HTTPRequest@1522922c)
   javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478)
   	at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
   	... <snipped>
   Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Alerts.getSSLException(Alerts.java:203)
   	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
   	... <snipped>
   Caused by: sun.security.validator.ValidatorException: PKIX path building failed:
   sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
   certification path to requested target
   	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
   	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
   	... <snipped>
     

   Der Handshake-Fehler hat folgende Ursachen:

   Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

   Dies weist darauf hin, dass der SSL-Handshake fehlgeschlagen ist, da der Message Processor von Apigee Edge das Zertifikat des Backend-Servers nicht validieren konnte.

Phase 1

Phase 1: Zertifikatkette des Backend-Servers ermitteln

Verwenden Sie eine der folgenden Methoden, um die Zertifikatkette des Backend-Servers zu ermitteln:

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

Certificate chain
 0 s:/CN=mocktarget.apigee.net
   i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
 1 s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
 2 s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

Phase 2

Phase 2: Zertifikat des Backend-Servers mit den im Truststore des Message Processor gespeicherten Zertifikaten vergleichen

1. Zertifikatkette des Backend-Servers ermitteln
2. So ermitteln Sie das im Truststore des Message Processor gespeicherte Zertifikat:

   1. Rufen Sie den Truststore-Referenznamen aus dem Element TrustStore im Abschnitt SSLInfo in der TargetEndpoint ab.

      Sehen wir uns einen Beispielabschnitt SSLInfo in einer TargetEndpoint-Konfiguration an:

      <TargetEndpoint name="default">
      ...
         <HTTPTargetConnection>
            <Properties />
            <SSLInfo>
               <Enabled>true</Enabled>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <KeyStore>ref://myKeystoreRef</KeyStore>
               <KeyAlias>myKey</KeyAlias>
               <TrustStore>
                  ref://myCompanyTrustStoreRef
               </TrustStore>
            </SSLInfo>
         </HTTPTargetConnection>
         ...
      </TargetEndpoint>

   2. Im obigen Beispiel lautet der Referenzname TrustStore myCompanyTruststoreRef.

   3. Wählen Sie in der Edge-Benutzeroberfläche Umgebungen > Verweise aus. Notieren Sie sich den Namen in der Spalte Reference (Referenz) für die jeweilige Truststore-Referenz. Das ist der Name Ihres Truststores.

      ( größeres Bild ansehen)

      

   4. Im obigen Beispiel lautet der Truststore-Name:

      myCompanyTruststoreRef: myCompanyTruststore

3. Rufen Sie die im Truststore gespeicherten Zertifikate (im vorherigen Schritt ermittelt) mit den folgenden APIs ab:

   1. Alle Zertifikate für einen Keystore oder Truststore abrufen: Diese API listet alle Zertifikate im angegebenen Truststore auf.

      Nutzer der öffentlichen Cloud:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      Private Cloud-Nutzer:

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      Dabei gilt:

      • ORGANIZATION_NAME ist der Name der Organisation.
      • ENVIRONMENT_NAME ist der Name der Umgebung.
      • KEYSTORE_NAME ist der Name des Schlüsselspeichers.
      • $TOKEN ist auf Ihr OAuth 2.0-Zugriffstoken festgelegt, wie unter OAuth 2.0-Zugriffstoken abrufen beschrieben.
      • Die in diesem Beispiel verwendeten curl-Optionen werden unter curl verwenden beschrieben.

      Beispielausgabe:

      Die Zertifikate aus dem Beispiel-Truststore myCompanyTruststore sind:

      [
        "serverCert"
      ]

   2. Zertifikatsdetails für das jeweilige Zertifikat aus einem Keystore oder Truststore abrufen Diese API gibt Informationen zu einem bestimmten Zertifikat im angegebenen Truststore zurück.

      Nutzer der öffentlichen Cloud:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      Private Cloud-Nutzer

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#>/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      Dabei gilt:

      • ORGANIZATION_NAME ist der Name der Organisation.
      • ENVIRONMENT_NAME ist der Name der Umgebung.
      • KEYSTORE_NAME ist der Name des Schlüsselspeichers.
      • CERT_NAME ist der Name des Zertifikats.
      • $TOKEN ist auf Ihr OAuth 2.0-Zugriffstoken festgelegt, wie unter OAuth 2.0-Zugriffstoken abrufen beschrieben.
      • Die in diesem Beispiel verwendeten curl-Optionen werden unter curl verwenden beschrieben.

      Beispielausgabe

      Die Details von serverCert zeigen Betreff und Aussteller wie folgt:

      Leaf-/Entity-Zertifikat:

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",

      Zwischenzertifikat:

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",

4. Prüfen Sie, ob das in Schritt 1 abgerufene tatsächliche Serverzertifikat mit dem in Schritt 3 abgerufenen Zertifikat übereinstimmt, das im Truststore gespeichert ist. Wenn sie nicht übereinstimmen, ist das die Ursache des Problems.

   Sehen wir uns die Zertifikate im obigen Beispiel einzeln an:

   1. Untergeordnetes Zertifikat:

      Vom Backend-Server:

      s:/CN=mocktarget.apigee.net
      i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4

      Aus dem Truststore des Message Processors (Client):

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",

      Das im Truststore gespeicherte Blattzertifikat stimmt mit dem des Backend-Servers überein.

   2. Zwischenzertifikat:

      Vom Backend-Server:

      s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

      Aus dem Truststore des Message Processors (Client):

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",

      Das im Truststore gespeicherte Zwischenzertifikat stimmt mit dem des Backend-Servers überein.

   3. Root-Zertifikat:

      Vom Backend-Server:

      s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

      Das Root-Zertifikat fehlt vollständig im Truststore des Message Processors.

   4. Da das Root-Zertifikat im Truststore fehlt, löst der Message Processor die folgende Ausnahme aus:

      sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

      und gibt 503 Service Unavailable mit dem Fehlercode messaging.adaptors.http.flow.SslHandshakeFailed an die Clientanwendungen zurück.

Richtiger FQDN

Keystore des Backend-Servers mit dem richtigen FQDN und einer gültigen und vollständigen Zertifikatskette aktualisieren:

1. Wenn Sie kein Zertifikat für den Back-End-Server mit dem richtigen FQDN haben, besorgen Sie sich das entsprechende Zertifikat von einer geeigneten Zertifizierungsstelle.

2. Prüfen Sie, ob Sie eine gültige und vollständige Zertifikatskette des Backend-Servers haben.

3. Sobald Sie die gültige und vollständige Zertifikatskette mit dem richtigen FQDN des Backend-Servers im Blatt- oder Entitätszertifikat haben, der mit dem im Zielendpunkt angegebenen Hostnamen identisch ist, aktualisieren Sie den Keystore des Backends mit der vollständigen Zertifikatskette.

Backend-Server korrigieren

Zielendpunkt mit dem Hostnamen des richtigen Backend-Servers aktualisieren:

1. Wenn der Hostname im Zielendpunkt falsch angegeben wurde, aktualisieren Sie den Zielendpunkt mit dem richtigen Hostnamen, der mit dem FQDN im Zertifikat des Backend-Servers übereinstimmt.

2. Speichern Sie die Änderungen am API-Proxy.

   Wenn im oben besprochenen Beispiel der Hostname des Backend-Servers falsch angegeben wurde, können Sie ihn mit dem FQDN aus dem Zertifikat des Backend-Servers korrigieren, also backend.apigee.net:

   <TargetEndpoint name="default">
      …
      <HTTPTargetConnection>
         <Properties />
         <SSLInfo>
            <Enabled>true</Enabled>
            <TrustStore>ref://myTrustStoreRef</TrustStore>
         </SSLInfo>
         <URL>https://backend.apigee.net/resource</URL>
      </HTTPTargetConnection>
   </TargetEndpoint>