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

API-Monitoring

Verfahren 1: API-Monitoring verwenden

So diagnostizieren Sie den Fehler mithilfe von API-Monitoring:

1. <ph type="x-smartling-placeholder"></ph> Melden Sie sich in der Apigee Edge-Benutzeroberfläche als Nutzer mit einem Rolle.

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

   
3. Wechseln Sie zum Bereich Analysieren > API-Monitoring > Untersuchen.
4. Wählen Sie den Zeitraum aus, in dem Sie die Fehler beobachtet haben.

5. Stellen Sie den Fehlercode in den Vergleich mit der Zeit ein.

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

6. Wähle eine Zelle mit dem Fehlercode aus messaging.adaptors.http.flow.SslHandshakeFailed wie gezeigt unten:

   ( Größeres Bild ansehen)

   

7. Informationen über den Fehlercode messaging.adaptors.http.flow.SslHandshakeFailed wird angezeigt als (siehe unten):

   ( 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. Im Fenster Logs werden die folgenden Details angezeigt: <ph type="x-smartling-placeholder">
   </ph>
   • 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 <ph type="x-smartling-placeholder">
   </ph>
   • Auf den Fehler 503 Service Unavailable mit Fehlercode warten messaging.adaptors.http.flow.SslHandshakeFailed oder
   • Wenn Sie das Problem reproduzieren können, führen Sie den API-Aufruf aus, um es zu reproduzieren. 503 Service Unavailable

2. Achten Sie darauf, dass Show all FlowInfos (Alle FlowInfos anzeigen) 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 wird in der Regel nach der Phase Zielanfragefluss gestartet angezeigt. wie unten dargestellt:

   ( Größeres Bild ansehen)

   
6. Notieren Sie sich die folgenden Werte aus dem Trace: <ph type="x-smartling-placeholder">
   </ph>
   • 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 die Zertifikat.
7. Navigieren 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 Werte von X-Apigee-fault-code und X-Apigee-fault-code und X-Apigee-Message-ID wie unten gezeigt:

   ( Größeres Bild ansehen)

   
9. Notieren Sie sich die Werte von X-Apigee-fault-code und X-Apigee-fault-code. 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 ein Private Cloud-Nutzer sind, können Sie mithilfe von NGINX-Zugriffslogs ermitteln, die wichtigsten Informationen zu HTTP 503 Service Unavailable.

2. Prüfen Sie die NGINX-Zugriffslogs:

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

   <ph type="x-smartling-placeholder">
3. Nach 503-Fehlern mit Fehlercode suchen messaging.adaptors.http.flow.SslHandshakeFailed während eines bestimmten Zeitraums (wenn das Problem im oder Anfragen mit 503 fehlschlagen.

4. Wenn Sie 503-Fehler mit dem X-Apigee-fault-code finden Wert von messaging.adaptors.http.flow.SslHandshakeFailed, dann Bestimmen Sie den Wert von X-Apigee-fault-source..

   Beispielfehler 503 aus dem NGINX-Zugriffsprotokoll:

   ( Größeres Bild ansehen)

   

   Der obige Beispieleintrag aus dem NGINX-Zugriffsprotokoll 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-Logs

Verfahren 4: Nachrichtenprozessorlogs verwenden

1. Ermitteln Sie die Nachrichten-ID einer der fehlgeschlagenen Anfragen mithilfe des API-Monitorings, des Trace-Tools, oder NGINX-Zugriffs-Logs, wie unter Allgemeine Diagnoseschritte erläutert.

2. Suchen Sie im Message Processor-Protokoll nach der spezifischen ID der Anfragenachricht. (/opt/apigee/var/log/edge-message-processor/logs/system.log) Möglicherweise stellen Sie fest, folgenden Fehler:

   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 Message Processor fehlgeschlagen ist. und den Back-End-Server.

   Darauf folgt eine Ausnahme mit einem detaillierten Stacktrace:

   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-Fehler folgende Ursachen hat:

   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 kann nicht validiert werden.

Phase 1

Phase 1: Bestimmen der Zertifikatskette des Back-End-Servers

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 Backend-Servers und die Zertifikate, die im Truststore des Nachrichtenverarbeiters

1. Bestimmen Sie die Zertifikatskette des Back-End-Servers.
2. Ermitteln Sie das im Truststore des Message Processor gespeicherte Zertifikat mithilfe von führen Sie die folgenden Schritte aus: <ph type="x-smartling-placeholder">
   </ph>

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

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

      <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 Name der TrustStore-Referenz myCompanyTruststoreRef.

   3. Wählen Sie in der Edge-Benutzeroberfläche Environments > Referenzen. Notieren Sie sich den Namen in der Reference (Referenz) für die spezifische Truststore-Referenz. Dies ist Ihr Truststore-Name.

      ( Größeres Bild ansehen)

      

   4. Im obigen Beispiel lautet der Truststore-Name:

      myCompanyTruststoreRef: myCompanyTruststore

3. Die im Truststore gespeicherten Zertifikate abrufen (im vorherigen Schritt ermittelt) mithilfe der folgenden APIs:

   1. <ph type="x-smartling-placeholder"></ph> Alle Zertifikate für einen Schlüsselspeicher oder Truststore abrufen Diese API listet alle Zertifikate im jeweiligen Truststore.

      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 wie beschrieben auf Ihr OAuth 2.0-Zugriffstoken festgelegt: OAuth 2.0-Zugriffstoken abrufen
      • Die in diesem Beispiel verwendeten curl-Optionen werden unter Curl verwenden

      Beispielausgabe:

      Die Zertifikate aus dem Beispiel-Truststore myCompanyTruststore sind:

      [
        "serverCert"
      ]
      

   2. <ph type="x-smartling-placeholder"></ph> Zertifikatsdetails für das jeweilige Zertifikat aus einem Schlüsselspeicher oder Truststore abrufen Diese API gibt die Informationen zu einem bestimmten Zertifikat in der spezifischen Truststore.

      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 wie beschrieben auf Ihr OAuth 2.0-Zugriffstoken festgelegt: OAuth 2.0-Zugriffstoken abrufen
      • Die in diesem Beispiel verwendeten curl-Optionen werden unter Curl verwenden

      Beispielausgabe

      Details zu serverCert zeigen Thema und Aussteller so an:

      Blatt-/Rechtssubjektzertifikat:

      "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 Zertifikat die im Truststore gespeichert sind, den Sie in Schritt 3 abgerufen haben. Stimmen sie nicht überein, die Ursache des Problems ist.

   Sehen wir uns ausgehend vom obigen Beispiel jeweils nur ein Zertifikat an:

   1. Lehrbescheinigung:

      Vom Back-End-Server:

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

      Aus dem Truststore des Message Processor (Client):

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

      Das untergeordnete Zertifikat, das im Truststore gespeichert ist, stimmt mit dem Zertifikat des Back-Ends überein Server.

   2. Zwischenzertifikat:

      Vom 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 des 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 stimmt mit dem Zertifikat des Back-End-Server.

   3. Root-Zertifikat:

      Vom 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 Message Processor vollständig. Truststore.

   4. Da das Root-Zertifikat im Truststore fehlt, Message Processor löst 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 zurück. messaging.adaptors.http.flow.SslHandshakeFailed an den Kunden Anwendungen.

Richtiger FQDN

Schlüsselspeicher des Backend-Servers mit korrektem FQDN, gültigem und vollständigem Zertifikat aktualisieren Kette:

1. Wenn Sie kein Zertifikat eines Backend-Servers mit dem richtigen FQDN haben, Fordern Sie dann das entsprechende Zertifikat von einer entsprechenden Zertifizierungsstelle an.

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

   <ph type="x-smartling-placeholder">
3. Sobald Sie die gültige und vollständige Zertifikatskette mit dem richtigen FQDN der Backend-Server im Blatt- oder Entitätszertifikat, das mit dem Hostnamen identisch ist im Zielendpunkt angegeben ist, aktualisieren Sie den Keystore des Back-Ends mit der vollständige Zertifikatskette.

Richtiger Backend-Server

Aktualisieren Sie den Zielendpunkt mit dem richtigen Hostnamen des Backend-Servers:

1. Wenn der Hostname im Zielendpunkt falsch angegeben wurde, aktualisieren Sie den Zielendpunkt, damit dieser den richtigen Hostnamen hat, der mit dem FQDN im Back-End übereinstimmt des Serverzertifikats.

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

   Wenn im oben beschriebenen Beispiel der Hostname des Back-End-Servers falsch war, können Sie das Problem mit dem FQDN aus dem Zertifikat des Back-End-Servers beheben. mit dem Wert 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>