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

API-Monitoring

Prozedur 1: API-Monitoring verwenden

So diagnostizieren Sie den Fehler mithilfe von API-Monitoring:

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

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

   
3. Rufen Sie die Seite Analysieren > API-Überwachung > Untersuchen auf.
4. Wählen Sie den Zeitraum aus, in dem Sie die Fehler beobachtet haben.

5. Stellen Sie den Fehlercode der Zeit gegenüber.

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

Verfahren 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, oder
   • Wenn Sie das Problem reproduzieren können, führen Sie den API-Aufruf aus, um das Problem zu reproduzieren. 503 Service Unavailable

2. Achten Sie darauf, dass Show all FlowInfos aktiviert ist:

   
3. Wählen Sie eine der fehlgeschlagenen Anfragen aus und prüfen Sie den Trace.
4. Gehen Sie die verschiedenen Phasen des Trace durch und ermitteln Sie, wo der Fehler aufgetreten ist.

5. Der Fehler tritt in der Regel nach der Phase Zielanfragefluss gestartet auf, wie unten dargestellt:

   ( größeres Bild ansehen)

   
6. Notieren Sie sich die folgenden Werte 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 zeigt an, dass der SSL-Handshake fehlgeschlagen ist, da der Message Processor von Apigee Edge das Zertifikat des Back-End-Servers nicht validieren konnte.
7. Gehen Sie im Trace zur Phase AX (Analytics Data Recorded) und klicken Sie darauf.

8. Scrollen Sie nach unten zum Abschnitt Phase Details Error Headers und bestimmen Sie die Werte für X-Apigee-Fehler-Code, X-Apigee-Fehler-Quelle und X-Apigee-Message-ID wie unten dargestellt:

   ( größeres Bild ansehen)

   
9. Beachten Sie die Werte von X-Apigee-fault-code, X-Apigee-fault-code und X-Apigee-fault-code:

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 ein Private Cloud-Nutzer sind, können Sie mithilfe von NGINX-Zugriffslogs die wichtigsten Informationen zu HTTP-503 Service Unavailable ermitteln.

2. Prüfen Sie die NGINX-Zugriffslogs:

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

3. Prüfen Sie, ob während eines bestimmten Zeitraums (wenn das Problem in der Vergangenheit aufgetreten ist) 503-Fehler mit dem Fehlercode messaging.adaptors.http.flow.SslHandshakeFailed aufgetreten sind oder ob es immer noch Anfragen mit 503 gibt, die fehlschlagen.

4. Wenn Sie 503-Fehler mit dem X-Apigee-fault-code finden, der dem Wert von X-Apigee-fault-code entspricht, bestimmen Sie den Wert von X-Apigee-fault-code.

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

   ( größeres Bild ansehen)

   

   Der obige Beispieleintrag aus dem NGINX-Zugriffslog enthält die folgenden Werte für X-Apigee-fault-code und X-Apigee-fault-code :

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

Message Processor-Protokolle

Verfahren Nr. 4: Nachrichtenprozessorprotokolle verwenden

1. Bestimmen Sie die Nachrichten-ID einer der fehlgeschlagenen Anfragen mithilfe von API-Monitoring, Trace-Tool oder NGINX-Zugriffslogs, wie unter Allgemeine Diagnoseschritte erläutert.

2. Suchen Sie im Message Processor-Log (/opt/apigee/var/log/edge-message-processor/logs/system.log) nach der spezifischen Anfragenachrichten-ID. 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 zeigt an, dass der SSL-Handshake zwischen dem Nachrichtenprozessor und dem Back-End-Server fehlgeschlagen ist.

   Darauf folgt eine Ausnahme mit einem detaillierten 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>
     

   Beachten Sie, dass der Handshake aus folgenden Gründen fehlschlägt:

   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 Back-End-Servers nicht validieren konnte.

Phase 1

Phase 1: Zertifikatskette des Back-End-Servers ermitteln

Verwenden Sie eine der folgenden Methoden, um die Zertifikatskette des Back-End-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: Vergleichen Sie das Zertifikat des Back-End-Servers und die Zertifikate, die im Truststore des Message Processor gespeichert sind

1. Bestimmen Sie die Zertifikatskette des Back-End-Servers.
2. Führen Sie die folgenden Schritte aus, um das im Truststore des Message Processor gespeicherte Zertifikat zu ermitteln:

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

      Sehen wir uns ein Beispiel für einen SSLInfo-Abschnitt 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 Environments > References (Umgebungen > Referenzen) aus. Notieren Sie sich den Namen in der Spalte Referenz für die spezifische Truststore-Referenz. Dies ist der Name Ihres Truststores.

      ( größeres Bild ansehen)

      

   4. Im obigen Beispiel lautet der Truststore-Name:

      myCompanyTruststoreRef myCompanyTruststore

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

   1. Alle Zertifikate für einen Schlüsselspeicher oder Truststore abrufen Diese API listet alle Zertifikate im jeweiligen Truststore auf.

      Public Cloud-Nutzer:

      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"
      

      Wo:

      • 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 lauten:

      [
        "serverCert"
      ]
      

   2. Zertifikatdetails für ein bestimmtes Zertifikat aus einem Schlüsselspeicher oder Truststore abrufen Diese API gibt die Informationen zu einem bestimmten Zertifikat im jeweiligen Truststore zurück.

      Public Cloud-Nutzer:

      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"
      

      Wo:

      • 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

      In den Details von serverCert sind Subjekt und Aussteller so zu sehen:

      Blatt-/Entitätszertifikat:

      "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 erhaltene Serverzertifikat und das im Truststore aus Schritt 3 gespeicherte Zertifikat übereinstimmen. Wenn sie nicht übereinstimmen, ist das der Grund für das Problem.

   Betrachten wir im obigen Beispiel jeweils nur ein Zertifikat:

   1. Blatt-Zertifikat:

      Über den Back-End-Server:

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

      Aus dem Truststore von Message Processor (Client):

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

      Das im Truststore gespeicherte untergeordnete Zertifikat stimmt mit dem des Back-End-Servers überein.

   2. Zwischenzertifikat:

      Über den Back-End-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 von Message Processor (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 entspricht dem des Back-End-Servers.

   3. Root-Zertifikat:

      Über den Back-End-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 im Truststore des Message Processor vollständig.

   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

Aktualisieren Sie den Schlüsselspeicher des Back-End-Servers mit dem richtigen FQDN sowie einer gültigen und vollständigen Zertifikatskette:

1. Wenn Sie kein Zertifikat eines Back-End-Servers mit dem richtigen FQDN haben, besorgen Sie das richtige Zertifikat von einer entsprechenden Zertifizierungsstelle (Zertifizierungsstelle).

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

3. Sobald Sie die gültige und vollständige Zertifikatskette mit dem richtigen FQDN des Back-End-Servers im untergeordneten oder Entitätszertifikat haben, das mit dem im Zielendpunkt angegebenen Hostnamen identisch ist, aktualisieren Sie den Schlüsselspeicher des Back-Ends mit der vollständigen Zertifikatskette.

Richtiger Back-End-Server

Aktualisieren Sie den Zielendpunkt mit dem korrekten Hostnamen des Back-End-Servers:

1. Wenn der Hostname im Zielendpunkt falsch angegeben wurde, aktualisieren Sie den Zielendpunkt so, dass er den richtigen Hostnamen enthält, der mit dem FQDN im Zertifikat des Back-End-Servers übereinstimmt.

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

   Wenn im oben beschriebenen Beispiel der Hostname des Back-End-Servers falsch angegeben wurde, können Sie das Problem beheben, indem Sie den FQDN aus dem Zertifikat des Back-End-Servers (backend.apigee.net) verwenden:

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