TLS/SSL-Handshakefehler

Sie lesen gerade die Dokumentation zu Apigee Edge.
Apigee X-Dokumentation aufrufen info

Symptom

Ein TLS/SSL-Handshake-Fehler tritt auf, wenn ein Client und ein Server keine Kommunikation über das TLS/SSL-Protokoll herstellen können. Wenn dieser Fehler in Apigee Edge auftritt, erhält die Clientanwendung den HTTP-Status 503 mit der Meldung Service Unavailable (Dienst nicht verfügbar). Dieser Fehler wird nach jedem API-Aufruf angezeigt, bei dem ein TLS-/SSL-Handshake-Fehler auftritt.

Fehlermeldungen

HTTP/1.1 503 Service Unavailable

Diese Fehlermeldung kann auch angezeigt werden, wenn ein TLS/SSL-Handshake-Fehler auftritt:

Received fatal alert: handshake_failure

Mögliche Ursachen

TLS (Transport Layer Security, dessen Vorgänger SSL ist) ist die Standard-Sicherheitstechnologie zum Einrichten einer verschlüsselten Verbindung zwischen einem Webserver und einem Webclient, z. B. einem Browser oder einer App. Ein Handshake ist ein Prozess, der es dem TLS-/SSL-Client und -Server ermöglicht, eine Reihe von geheimen Schlüsseln einzurichten, mit denen sie kommunizieren können. Während dieses Vorgangs:

1. Einigen Sie sich auf die zu verwendende Version des Protokolls.
2. Wählen Sie den zu verwendenden kryptografischen Algorithmus aus.
3. Authentifizieren Sie sich gegenseitig, indem Sie digitale Zertifikate austauschen und validieren.

Wenn der TLS/SSL-Handshake erfolgreich ist, übertragen der TLS/SSL-Client und ‑Server Daten sicher aneinander. Andernfalls wird die Verbindung bei einem TLS/SSL-Handshake-Fehler beendet und der Client erhält den Fehler 503 Service Unavailable.

Mögliche Ursachen für fehlgeschlagene TLS-/SSL-Handshakes:

Protokoll nicht kompatibel

Ein TLS/SSL-Handshake-Fehler tritt auf, wenn das vom Client verwendete Protokoll vom Server entweder bei der eingehenden (Northbound) oder ausgehenden (Southbound) Verbindung nicht unterstützt wird. Siehe auch Northbound- und Southbound-Verbindungen.

Diagnose

1. Stellen Sie fest, ob der Fehler bei der Northbound- oder Southbound-Verbindung aufgetreten ist. Weitere Informationen zur Ermittlung der Fehlerquelle finden Sie unter Fehlerquelle ermitteln.
2. Führen Sie das Dienstprogramm tcpdump aus, um weitere Informationen zu erfassen:
   • Wenn Sie ein Private Cloud-Nutzer sind, können Sie die tcpdump-Daten auf dem entsprechenden Client oder Server erfassen. Ein Client kann die Client-App (für eingehende oder Northbound-Verbindungen) oder der Message Processor (für ausgehende oder Southbound-Verbindungen) sein. Ein Server kann der Edge-Router (für eingehende oder Northbound-Verbindungen) oder der Backend-Server (für ausgehende oder Southbound-Verbindungen) sein, je nachdem, was Sie in Schritt 1 festgelegt haben.
   • Wenn Sie ein Public Cloud-Nutzer sind, können Sie die tcpdump-Daten nur in der Client-App (für eingehende oder Northbound-Verbindungen) oder auf dem Backend-Server (für ausgehende oder Southbound-Verbindungen) erfassen, da Sie keinen Zugriff auf den Edge-Router oder Message Processor haben.

   tcpdump -i any -s 0 host IP address -w File name
   

   Weitere Informationen zur Verwendung des Befehls tcpdump finden Sie unter tcpdump-Daten.
3. Analysieren Sie die tcpdump-Daten mit dem Wireshark-Tool oder einem ähnlichen Tool.
4. Hier ist eine Beispielanalyse des tcpdump mit Wireshark:
   • In diesem Beispiel ist der TLS/SSL-Handshake-Fehler zwischen dem Message Processor und dem Backend-Server (der ausgehenden oder Southbound-Verbindung) aufgetreten.
   • Nachricht 4 in der tcpdump-Ausgabe unten zeigt, dass der Message Processor (Source) eine „Client Hello“-Nachricht an den Backend-Server (Destination) gesendet hat.
     

     

   • Wenn Sie die Meldung Client Hello auswählen, wird angezeigt, dass der Message Processor das TLSv1.2-Protokoll verwendet, wie unten dargestellt:

     

   • Nachricht 5 zeigt, dass der Backend-Server die „Client Hello“-Nachricht vom Message Processor bestätigt.
   • Der Back-End-Server sendet sofort Fatal Alert : Close Notify an den Message Processor (Nachricht 6). Das bedeutet, dass der TLS/SSL-Handshake fehlgeschlagen ist und die Verbindung geschlossen wird.

   • Bei Nachricht 6 sehen wir, dass der TLS/SSL-Handshake fehlgeschlagen ist, weil der Backend-Server nur das TLSv1.0-Protokoll unterstützt, wie unten zu sehen ist:

     

   • Da es eine Abweichung zwischen dem vom Message Processor verwendeten Protokoll und dem Backend-Server gibt, hat der Backend-Server die Meldung Fatal Alert Message: Close Notify (Schwerwiegende Warnmeldung: Benachrichtigung schließen) gesendet.

Auflösung

Der Message Processor wird in Java 8 ausgeführt und verwendet standardmäßig das TLSv1.2-Protokoll. Wenn der Backend-Server das TLSv1.2-Protokoll nicht unterstützt, können Sie das Problem auf eine der folgenden Arten beheben:

1. Aktualisieren Sie Ihren Backend-Server, damit er das TLSv1.2-Protokoll unterstützt. Dies ist eine empfohlene Lösung, da das Protokoll TLSv1.2 sicherer ist.
2. Wenn Sie Ihren Backend-Server aus irgendeinem Grund nicht sofort aktualisieren können, können Sie den Message Processor mit den folgenden Schritten zwingen, das TLSv1.0-Protokoll für die Kommunikation mit dem Backend-Server zu verwenden:
   1. Wenn Sie in der TargetEndpoint-Definition des Proxys keinen Zielserver angegeben haben, legen Sie das Element Protocol auf TLSv1.0 fest, wie unten gezeigt:

      <TargetEndpoint name="default">
       …
       <HTTPTargetConnection>
         <SSLInfo>
             <Enabled>true</Enabled>
             <Protocols>
                 <Protocol>TLSv1.0</Protocol>
             </Protocols>
         </SSLInfo>
         <URL>https://myservice.com</URL>
       </HTTPTargetConnection>
       …
      </TargetEndpoint>

   2. Wenn Sie einen Zielserver für Ihren Proxy konfiguriert haben, verwenden Sie diese Management API, um das Protokoll in der entsprechenden Zielserverkonfiguration auf TLSv1.0 festzulegen.

Chiffre stimmt nicht überein

Ein TLS/SSL-Handshakefehler kann auftreten, wenn der vom Client verwendete Cipher Suite-Algorithmus vom Server entweder bei der eingehenden (Northbound) oder ausgehenden (Southbound) Verbindung in Apigee Edge nicht unterstützt wird. Siehe auch Northbound- und Southbound-Verbindungen.

Diagnose

1. Stellen Sie fest, ob der Fehler bei der Northbound- oder Southbound-Verbindung aufgetreten ist. Weitere Informationen zur Ermittlung der Fehlerquelle finden Sie unter Fehlerquelle ermitteln.
2. Führen Sie das Dienstprogramm tcpdump aus, um weitere Informationen zu erfassen:
   • Wenn Sie ein Private Cloud-Nutzer sind, können Sie die tcpdump-Daten auf dem entsprechenden Client oder Server erfassen. Ein Client kann die Client-App (für eingehende oder Northbound-Verbindungen) oder der Message Processor (für ausgehende oder Southbound-Verbindungen) sein. Ein Server kann der Edge-Router (für eingehende oder Northbound-Verbindungen) oder der Backend-Server (für ausgehende oder Southbound-Verbindungen) sein, je nachdem, was Sie in Schritt 1 festgelegt haben.
   • Wenn Sie ein Public Cloud-Nutzer sind, können Sie die tcpdump-Daten nur in der Client-App (für eingehende oder Northbound-Verbindungen) oder auf dem Backend-Server (für ausgehende oder Southbound-Verbindungen) erfassen, da Sie keinen Zugriff auf den Edge-Router oder Message Processor haben.

   tcpdump -i any -s 0 host IP address -w File name
   

   Weitere Informationen zur Verwendung des Befehls tcpdump finden Sie unter tcpdump-Daten.
3. Analysieren Sie die tcpdump-Daten mit dem Tool Wireshark oder einem anderen Tool, mit dem Sie vertraut sind.
4. Hier ist die Beispielanalyse der tcpdump-Ausgabe mit Wireshark:
   • In diesem Beispiel ist der TLS/SSL-Handshake-Fehler zwischen der Clientanwendung und dem Edge-Router (Northbound-Verbindung) aufgetreten. Die tcpdump-Ausgabe wurde auf dem Edge-Router erfasst.

   • In der Meldung 4 in der tcpdump-Ausgabe unten sehen Sie, dass die Clientanwendung (Quelle) eine „Client Hello“-Nachricht an den Edge-Router (Ziel) gesendet hat.

     

   • Wenn Sie die Client Hello-Nachricht auswählen, sehen Sie, dass die Clientanwendung das TLSv1.2-Protokoll verwendet.

     

   • Nachricht 5 zeigt, dass der Edge-Router die „Client Hello“-Nachricht von der Clientanwendung bestätigt.
   • Der Edge-Router sendet sofort eine Fatal Alert : Handshake Failure an die Clientanwendung (Nachricht 6). Das bedeutet, dass der TLS/SSL-Handshake fehlgeschlagen ist und die Verbindung geschlossen wird.
   • Bei der weiteren Untersuchung von Nachricht 6 werden die folgenden Informationen angezeigt:
     • Der Edge-Router unterstützt das TLSv1.2-Protokoll. Das bedeutet, dass das Protokoll zwischen der Clientanwendung und dem Edge-Router übereinstimmt.

     • Der Edge-Router sendet jedoch weiterhin die Fatal Alert: Handshake Failure an die Clientanwendung, wie im Screenshot unten zu sehen ist:

       

   • Der Fehler kann eine der folgenden Ursachen haben:
     • Die Clientanwendung verwendet nicht die vom Edge-Router unterstützten Cipher-Suite-Algorithmen.
     • Der Edge-Router ist SNI-fähig, aber die Clientanwendung sendet den Servernamen nicht.
   • Nachricht 4 in der tcpdump-Ausgabe listet die von der Clientanwendung unterstützten Cipher Suite-Algorithmen auf, wie unten dargestellt:

     

   • Die Liste der von Edge Router unterstützten Cipher-Suite-Algorithmen finden Sie in der Datei /opt/nginx/conf.d/0-default.conf. In diesem Beispiel unterstützt der Edge-Router nur die Cipher Suite-Algorithmen der High Encryption.
   • Die Clientanwendung verwendet keinen der Algorithmen der High Encryption Cipher Suite. Diese Diskrepanz ist die Ursache für den fehlgeschlagenen TLS/SSL-Handshake.
   • Da der Edge-Router SNI-fähig ist, scrollen Sie in der tcpdump-Ausgabe zu Nachricht 4 und prüfen Sie, ob die Clientanwendung den Servernamen korrekt sendet, wie in der Abbildung unten dargestellt:
     
     
     
   • Wenn dieser Name gültig ist, können Sie daraus schließen, dass der TLS/SSL-Handshake-Fehler aufgetreten ist, weil die von der Clientanwendung verwendeten Cipher Suite-Algorithmen vom Edge-Router nicht unterstützt werden.

Auflösung

Sie müssen dafür sorgen, dass der Client die Chiffrensammlungsalgorithmen verwendet, die vom Server unterstützt werden. Um das im vorherigen Abschnitt „Diagnose“ beschriebene Problem zu beheben, laden Sie das Java Cryptography Extension (JCE)-Paket herunter und installieren Sie es. Fügen Sie es der Java-Installation hinzu, um die Algorithmen der High Encryption-Chiffrierverfahren zu unterstützen.

Falsches Zertifikat

Ein TLS/SSL-Handshake-Fehler tritt auf, wenn Sie falsche Zertifikate im Keystore/Truststore haben, entweder bei der eingehenden (Northbound) oder ausgehenden (Southbound) Verbindung in Apigee Edge. Siehe auch Northbound- und Southbound-Verbindungen.

Wenn das Problem Northbound ist, werden je nach zugrunde liegendem Grund möglicherweise unterschiedliche Fehlermeldungen angezeigt.

In den folgenden Abschnitten finden Sie Beispiel-Fehlermeldungen und die Schritte zur Diagnose und Behebung dieses Problems.

Fehlermeldungen

Je nach Ursache des TLS/SSL-Handshake-Fehlers werden möglicherweise unterschiedliche Fehlermeldungen angezeigt. Hier ist ein Beispiel für eine Fehlermeldung, die beim Aufrufen eines API-Proxys angezeigt werden kann:

* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

Mögliche Ursachen

Die typischen Ursachen für dieses Problem sind:

Hostname-Konflikt

Diagnose

1. Notieren Sie sich den Hostnamen, der in der URL verwendet wird, die vom folgenden Edge Management API-Aufruf zurückgegeben wird:

   curl -v https://myorg.domain.com/v1/getinfo

   Beispiel:

   curl -v https://api.enterprise.apigee.com/v1/getinfo

2. Ruft den CN ab, der im Zertifikat verwendet wird, das im angegebenen Keystore gespeichert ist. Sie können die folgenden Edge-Verwaltungs-APIs verwenden, um die Details des Zertifikats abzurufen:
   1. Zertifikatsnamen im Keystore abrufen:
      
      Wenn Sie ein Private Cloud-Nutzer sind, verwenden Sie die Management API so:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      Wenn Sie ein Public Cloud-Nutzer sind, verwenden Sie die Management API so:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Details zum Zertifikat im Keystore mit der Edge Management API abrufen
      
      Private Cloud-Nutzer:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Wenn Sie ein Public Cloud-Nutzer sind
      :

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Beispiel für cert::

      "certInfo": [
          {
            "basicConstraints": "CA:FALSE",
            "expiryDate": 1456258950000,
            "isValid": "No",
            "issuer": "SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=\"GoDaddy.com, Inc.\", L=Scottsdale, ST=Arizona, C=US",
            "publicKey": "RSA Public Key, 2048 bits",
            "serialNumber": "07:bc:a7:39:03:f1:56",
            "sigAlgName": "SHA1withRSA",
            "subject": "CN=something.domain.com, OU=Domain Control Validated, O=something.domain.com",
            "validFrom": 1358287055000,
            "version": 3
          },

      Der Antragstellername im primären Zertifikat hat den CN als something.domain.com..

      Da der Hostname in der API-Anfrage-URL (siehe Schritt 1 oben) und der Betreffname im Zertifikat nicht übereinstimmen, erhalten Sie den TLS/SSL-Handshake-Fehler.

Auflösung

Dieses Problem kann auf eine der folgenden zwei Arten behoben werden:

• Besorgen Sie sich ein Zertifikat (falls Sie noch keines haben), bei dem der CN des Subjekts ein Platzhalterzertifikat ist, und laden Sie dann die neue vollständige Zertifikatskette in den Keystore hoch. Beispiel:

  "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",

• Besorgen Sie sich ein Zertifikat (falls Sie noch keines haben) mit einem vorhandenen CN-Betreff, verwenden Sie aber your-org.your-domain als alternativen Subjektnamen verwenden, laden Sie die vollständige Zertifikatkette in den Schlüsselspeicher hoch.

Verweise

Schlüsselspeicher und Truststores

Unvollständige oder falsche Zertifikatskette

Diagnose

1. Ruft den CN ab, der im Zertifikat verwendet wird, das im angegebenen Keystore gespeichert ist. Sie können die folgenden Edge-Verwaltungs-APIs verwenden, um die Details des Zertifikats abzurufen:
   1. Zertifikatsname im Keystore abrufen:
      
      Wenn Sie ein Private Cloud-Nutzer sind:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

      Wenn Sie ein Public Cloud-Nutzer sind
      :

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Details zum Zertifikat im Keystore abrufen:
      
      Wenn Sie ein Private Cloud-Nutzer sind:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Wenn Sie ein Public Cloud-Nutzer sind
      :

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

   3. Prüfen Sie das Zertifikat und die zugehörige Kette und vergewissern Sie sich, dass es den Richtlinien im Artikel So funktionieren Zertifikatsketten entspricht, damit es sich um eine gültige und vollständige Zertifikatskette handelt. Wenn die im Keystore gespeicherte Zertifikatskette unvollständig oder ungültig ist, schlägt der TLS/SSL-Handshake fehl.
   4. Die folgende Abbildung zeigt ein Beispielzertifikat mit einer ungültigen Zertifikatskette, bei der das Zwischen- und das Stammzertifikat nicht übereinstimmen:

   Beispiel für ein Zwischen- und ein Root-Zertifikat, bei dem Aussteller und Betreff nicht übereinstimmen

   
   

Auflösung

1. Besorgen Sie sich ein Zertifikat (falls Sie noch keines haben), das eine vollständige und gültige Zertifikatskette enthält.
2. Führen Sie den folgenden openssl-Befehl aus, um zu prüfen, ob die Zertifikatkette korrekt und vollständig ist:

   openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert

3. Laden Sie die validierte Zertifikatskette in den Schlüsselspeicher hoch.

Abgelaufenes oder unbekanntes Zertifikat, das vom Server oder Client gesendet wurde

Wenn vom Server/Client entweder bei der Northbound- oder bei der Southbound-Verbindung ein falsches/abgelaufenes Zertifikat gesendet wird, lehnt das andere Ende (Server/Client) das Zertifikat ab, was zu einem TLS/SSL-Handshake-Fehler führt.

Diagnose

1. Stellen Sie fest, ob der Fehler bei der Northbound- oder Southbound-Verbindung aufgetreten ist. Weitere Informationen zur Ermittlung der Fehlerquelle finden Sie unter Fehlerquelle ermitteln.
2. Führen Sie das Dienstprogramm tcpdump aus, um weitere Informationen zu erfassen:
   • Wenn Sie ein Private Cloud-Nutzer sind, können Sie die tcpdump-Daten auf dem entsprechenden Client oder Server erfassen. Ein Client kann die Client-App (für eingehende oder Northbound-Verbindungen) oder der Message Processor (für ausgehende oder Southbound-Verbindungen) sein. Ein Server kann der Edge-Router (für eingehende oder Northbound-Verbindungen) oder der Backend-Server (für ausgehende oder Southbound-Verbindungen) sein, je nachdem, was Sie in Schritt 1 festgelegt haben.
   • Wenn Sie ein Public Cloud-Nutzer sind, können Sie die tcpdump-Daten nur in der Client-App (für eingehende oder Northbound-Verbindungen) oder auf dem Backend-Server (für ausgehende oder Southbound-Verbindungen) erfassen, da Sie keinen Zugriff auf den Edge-Router oder Message Processor haben.

   tcpdump -i any -s 0 host IP address -w File name
   

   Weitere Informationen zur Verwendung des Befehls tcpdump finden Sie unter tcpdump-Daten.
3. Analysieren Sie die tcpdump-Daten mit Wireshark oder einem ähnlichen Tool.
4. Ermitteln Sie anhand der tcpdump-Ausgabe den Host (Client oder Server), der das Zertifikat während des Überprüfungsschritts ablehnt.
5. Sie können das vom anderen Ende gesendete Zertifikat aus der tcpdump-Ausgabe abrufen, sofern die Daten nicht verschlüsselt sind. Das ist hilfreich, um zu vergleichen, ob dieses Zertifikat mit dem im Truststore verfügbaren Zertifikat übereinstimmt.
6. Sehen Sie sich das Beispiel tcpdump für die SSL-Kommunikation zwischen dem Message Processor und dem Backend-Server an.

   Beispiel für tcpdump mit dem Fehler „Certificate Unknown“ (Zertifikat unbekannt)

   
   

   1. Der Message Processor (Client) sendet in Nachricht 59 „Client Hello“ an den Backend-Server (Server).
   2. Der Backend-Server sendet in Nachricht 61 „Server Hello“ an den Message Processor.
   3. Sie validieren gegenseitig die verwendeten Protokoll- und Cipher Suite-Algorithmen.
   4. Der Backend-Server sendet das Zertifikat und die Nachricht „Server Hello Done“ in Nachricht 68 an den Message Processor.
   5. Der Nachrichtenprozessor sendet in Nachricht 70 die schwerwiegende Warnung „Beschreibung: Zertifikat unbekannt“.
   6. Bei Nachricht 70 sind keine weiteren Details als die unten gezeigte Warnmeldung vorhanden:

      
      

   7. Sehen Sie sich Nachricht 68 an, um die Details zum vom Backend-Server gesendeten Zertifikat zu erhalten (siehe Abbildung unten):

      

   8. Das Zertifikat des Backend-Servers und die vollständige Kette sind alle im Bereich „Zertifikate“ verfügbar, wie in der Abbildung oben dargestellt.
7. Wenn das Zertifikat entweder vom Router (Northbound) oder vom Message Processor (Southbound) als unbekannt eingestuft wird, wie im Beispiel oben dargestellt, führen Sie die folgenden Schritte aus:
   1. Rufen Sie das Zertifikat und die zugehörige Kette ab, die im angegebenen Truststore gespeichert sind. Weitere Informationen finden Sie in der Konfiguration des virtuellen Hosts für den Router und in der Konfiguration des Zielendpunkts für den Message Processor. Sie können die folgenden APIs verwenden, um die Details des Zertifikats abzurufen:
      1. Zertifikatname im Truststore abrufen:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs

      2. Details des Zertifikats im Truststore abrufen:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name

   2. Prüfen Sie, ob das im Truststore des Routers (Northbound) oder des Nachrichtenprozessors (Southbound) gespeicherte Zertifikat mit dem Zertifikat übereinstimmt, das im Keystore der Clientanwendung (Northbound) oder des Zielservers (Southbound) gespeichert ist, oder mit dem Zertifikat, das aus der tcpdump-Ausgabe abgerufen wird. Wenn es eine Diskrepanz gibt, ist dies die Ursache für den fehlgeschlagenen TLS-/SSL-Handshake.
8. Wenn das Zertifikat entweder von der Clientanwendung (Northbound) oder vom Zielserver (Southbound) als unbekannt erkannt wird, gehen Sie so vor:
   1. Ruft die vollständige Zertifikatskette ab, die im Zertifikat verwendet wird, das im angegebenen Schlüsselspeicher gespeichert ist. Weitere Informationen finden Sie in der Konfiguration des virtuellen Hosts für den Router und in der Konfiguration des Zielendpunkts für den Message Processor. Sie können die folgenden APIs verwenden, um die Details des Zertifikats abzurufen:
      1. Zertifikatsnamen im Schlüsselspeicher abrufen:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      2. Details des Zertifikats im Keystore abrufen:
         

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
         

   2. Prüfen Sie, ob das im Keystore des Routers (Northbound) oder des Message Processors (Southbound) gespeicherte Zertifikat mit dem im Truststore der Clientanwendung (Northbound) oder des Zielservers (Southbound) gespeicherten Zertifikat oder dem aus der tcpdump-Ausgabe übereinstimmt. Wenn es eine Diskrepanz gibt, ist dies die Ursache für den fehlgeschlagenen SSL-Handshake.
9. Wenn das von einem Server/Client gesendete Zertifikat abgelaufen ist, lehnt der empfangende Client/Server das Zertifikat ab und Sie sehen die folgende Warnmeldung in tcpdump:

   Warnung (Schweregrad: Schwerwiegend, Beschreibung: Zertifikat abgelaufen)

10. Prüfen Sie, ob das Zertifikat im Keystore des entsprechenden Hosts abgelaufen ist.

Auflösung

Um das im obigen Beispiel beschriebene Problem zu beheben, laden Sie das Zertifikat des gültigen Backend-Servers in den Truststore auf dem Message Processor hoch.

In der folgenden Tabelle sind die Schritte zur Behebung des Problems zusammengefasst, je nach Ursache des Problems.

SNI-aktivierter Server

Der TLS-/SSL-Handshake-Fehler kann auftreten, wenn der Client mit einem SNI-fähigen (Server Name Indication) Server kommuniziert, der Client jedoch nicht SNI-fähig ist. Dies kann entweder bei der Verbindung in Richtung Norden oder in Richtung Süden in Edge passieren.

Zuerst müssen Sie den Hostnamen und die Portnummer des verwendeten Servers ermitteln und prüfen, ob SNI aktiviert ist.

Identifizierung von SNI-fähigen Servern

1. Führen Sie den Befehl openssl aus und versuchen Sie, eine Verbindung zum entsprechenden Serverhostnamen (Edge-Router oder Backend-Server) herzustellen, ohne den Servernamen zu übergeben, wie unten dargestellt:

   openssl s_client -connect hostname:port

   Möglicherweise erhalten Sie die Zertifikate und manchmal kann es zu einem Handshake-Fehler im openssl-Befehl kommen, wie unten gezeigt:
   

   CONNECTED(00000003)
   9362:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_clnt.c:593

2. Führen Sie den Befehl openssl aus und versuchen Sie, eine Verbindung zum entsprechenden Server-Hostname (Edge-Router oder Backend-Server) herzustellen, indem Sie den Servernamen übergeben, wie unten gezeigt:

   openssl s_client -connect hostname:port -servername hostname

3. Wenn Sie in Schritt 1 einen Handshake-Fehler erhalten oder in Schritt 1 und Schritt 2 unterschiedliche Zertifikate erhalten, deutet dies darauf hin, dass der angegebene Server SNI-fähig ist.

Nachdem Sie festgestellt haben, dass der Server SNI-fähig ist, können Sie mit den folgenden Schritten prüfen, ob der TLS-/SSL-Handshake-Fehler dadurch verursacht wird, dass der Client nicht mit dem SNI-Server kommunizieren kann.

Diagnose

1. Stellen Sie fest, ob der Fehler bei der Northbound- oder Southbound-Verbindung aufgetreten ist. Weitere Informationen zur Ermittlung der Fehlerquelle finden Sie unter Fehlerquelle ermitteln.
2. Führen Sie das Dienstprogramm tcpdump aus, um weitere Informationen zu erfassen:
   • Wenn Sie ein Private Cloud-Nutzer sind, können Sie die tcpdump-Daten auf dem entsprechenden Client oder Server erfassen. Ein Client kann die Client-App (für eingehende oder Northbound-Verbindungen) oder der Message Processor (für ausgehende oder Southbound-Verbindungen) sein. Ein Server kann der Edge-Router (für eingehende oder Northbound-Verbindungen) oder der Backend-Server (für ausgehende oder Southbound-Verbindungen) sein, je nachdem, was Sie in Schritt 1 festgelegt haben.
   • Wenn Sie ein Public Cloud-Nutzer sind, können Sie die tcpdump-Daten nur in der Client-App (für eingehende oder Northbound-Verbindungen) oder auf dem Backend-Server (für ausgehende oder Southbound-Verbindungen) erfassen, da Sie keinen Zugriff auf den Edge-Router oder Message Processor haben.

   tcpdump -i any -s 0 host IP address -w File name
   

   Weitere Informationen zur Verwendung des Befehls tcpdump finden Sie unter tcpdump-Daten.
3. Analysieren Sie die tcpdump-Ausgabe mit Wireshark oder einem ähnlichen Tool.
4. Hier ist die Beispielanalyse von tcpdump mit Wireshark:
   1. In diesem Beispiel ist der TLS/SSL-Handshake zwischen dem Edge Message Processor und dem Backend-Server (Southbound-Verbindung) fehlgeschlagen.
   2. In der Meldung 4 in der tcpdump-Ausgabe unten sehen Sie, dass der Message Processor (Quelle) eine „Client Hello“-Nachricht an den Backend-Server (Ziel) gesendet hat.

      

   3. Wenn Sie die Nachricht „Client Hello“ auswählen, sehen Sie, dass der Message Processor das TLSv1.2-Protokoll verwendet.

      

   4. Nachricht 4 zeigt, dass der Backend-Server die „Client Hello“-Nachricht vom Message Processor bestätigt.
   5. Der Backend-Server sendet sofort eine Fatal Alert : Handshake Failure an den Message Processor (Nachricht 5). Das bedeutet, dass der TLS/SSL-Handshake fehlgeschlagen ist und die Verbindung geschlossen wird.
   6. In Nachricht 6 finden Sie die folgenden Informationen:
      • Der Backend-Server unterstützt das TLSv1.2-Protokoll. Das bedeutet, dass das Protokoll zwischen dem Message Processor und dem Backend-Server übereinstimmt.
      • Der Backend-Server sendet jedoch weiterhin die Fatal Alert: Handshake Failure-Meldung an den Message Processor, wie in der Abbildung unten dargestellt:

        

   7. Dieser Fehler kann aus einem der folgenden Gründe auftreten:
      • Der Message Processor verwendet nicht die vom Backend-Server unterstützten Cipher-Suite-Algorithmen.
      • Der Back-End-Server ist SNI-fähig, aber die Clientanwendung sendet den Servernamen nicht.
   8. Sehen Sie sich die Nachricht 3 (Client Hello) in der tcpdump-Ausgabe genauer an. Beachten Sie, dass die Erweiterung: server_name fehlt, wie unten dargestellt:

      

   9. Das bestätigt, dass der Message Processor den server_name nicht an den SNI-fähigen Backend-Server gesendet hat.
   10. Dies ist die Ursache für den TLS/SSL-Handshake-Fehler und der Grund dafür, dass der Backend-Server die Fatal Alert: Handshake Failure-Meldung an den Message Processor sendet.
5. Prüfen Sie, ob jsse.enableSNIExtension property in system.properties auf „false“ gesetzt ist. So stellen Sie sicher, dass der Message Processor nicht für die Kommunikation mit dem SNI-fähigen Server aktiviert ist.

Auflösung

Aktivieren Sie die Kommunikation der Message Processors mit SNI-fähigen Servern, indem Sie die folgenden Schritte ausführen:

1. Erstellen Sie die Datei/opt/apigee/customer/application/message-processor.properties, falls sie noch nicht vorhanden ist.
2. Fügen Sie der Datei die folgende Zeile hinzu: conf_system_jsse.enableSNIExtension=true
3. Ändern Sie den Eigentümer dieser Datei zu apigee:apigee:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Starten Sie den Message Processor neu.

   /opt/apigee/apigee-service/bin/apigee-service message-processor restart

5. Wenn Sie mehr als einen Message Processor haben, wiederholen Sie die Schritte 1 bis 4 für alle Message Processors.

Wenn Sie die Ursache für den TLS/SSL-Handshake-Fehler nicht ermitteln und das Problem nicht beheben können oder weitere Unterstützung benötigen, wenden Sie sich an den Apigee Edge-Support. Geben Sie alle Details zum Problem sowie die tcpdump-Ausgabe an.