TLS/SSL-Handshakefehler

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

Symptom

Ein TLS/SSL-Handshake tritt auf, wenn ein Client und ein Server keine Kommunikation mit dem TLS/SSL-Protokoll herstellen können. Wenn dieser Fehler in Apigee Edge auftritt, empfängt die Client-Anwendung den HTTP-Status 503 mit der Meldung Service Nicht verfügbar. Dieser Fehler wird nach jedem API-Aufruf angezeigt, bei dem ein TLS/SSL-Handshakefehler auftritt.

Fehlermeldungen

HTTP/1.1 503 Service Unavailable

Diese Fehlermeldung wird auch angezeigt, wenn ein TLS/SSL-Handshake fehlschlägt:

Received fatal alert: handshake_failure

Mögliche Ursachen

TLS (Transport Layer Security, dessen Vorgänger SSL) ist die Standardsicherheitstechnologie zum Herstellen einer verschlüsselten Verbindung zwischen einem Webserver und einem Webclient, z. B. einem Browser oder einer Anwendung. Ein Handshake ist ein Prozess, durch den der TLS/SSL-Client und -Server eine Reihe geheimer Schlüssel für die Kommunikation einrichten können. Während dieses Vorgangs führen Client und Server folgende Schritte aus:

  1. Vereinbaren Sie, welche Version des Protokolls verwendet werden soll.
  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 der Server die Daten sicher untereinander. Wenn ein TLS/SSL-Handshake fehlschlägt, wird die Verbindung beendet und der Client erhält den Fehler 503 Service Unavailable.

Mögliche Ursachen für TLS/SSL-Handshakefehler sind:

Ursache Beschreibung Wer kann die Schritte zur Fehlerbehebung ausführen?
Nicht übereinstimmende Protokolle Das vom Client verwendete Protokoll wird vom Server nicht unterstützt. Nutzer von privaten und öffentlichen Clouds
Abweichende Verschlüsselungs-Suite Die vom Client verwendete Cipher Suite wird vom Server nicht unterstützt. Nutzer von privaten und öffentlichen Clouds
Falsches Zertifikat Der Hostname in der vom Client verwendeten URL stimmt nicht mit dem Hostnamen im Zertifikat überein, das auf Serverseite gespeichert ist. Nutzer von privaten und öffentlichen Clouds
Eine unvollständige oder ungültige Zertifikatskette wird auf Client- oder Serverseite gespeichert. Nutzer von privaten und öffentlichen Clouds
Ein falsches oder abgelaufenes Zertifikat wird vom Client an den Server oder vom Server an den Client gesendet. Nutzer von privaten und öffentlichen Clouds
SNI-fähiger Server Für den Back-End-Server ist Server Name Indication (SNI) aktiviert. Der Client kann jedoch nicht mit den SNI-Servern kommunizieren. Nur Private Cloud-Nutzer

Nicht übereinstimmende Protokolle

Ein TLS/SSL-Handshake-Fehler tritt auf, wenn das vom Client verwendete Protokoll beim Server weder bei der eingehenden Verbindung (northbound) noch bei ausgehender Verbindung (Southbound) unterstützt wird. Weitere Informationen finden Sie unter Verbindungen nach Norden und Süden verstehen.

Diagnose

  1. Ermitteln Sie, ob der Fehler an der Verbindung northbound oder southbound aufgetreten ist. Weitere Hinweise dazu, wie Sie die Ursache des Problems ermitteln können, finden Sie unter Ursache des Problems ermitteln.
  2. Führen Sie das Dienstprogramm tcpdump aus, um weitere Informationen zu erhalten:
    • Wenn Sie ein Private Cloud-Nutzer sind, können Sie die tcpdump-Daten auf dem entsprechenden Client oder Server erfassen. Ein Client kann die Clientanwendung (für eingehende Verbindungen oder Verbindungen nach Norden) oder der Nachrichtenprozessor (für ausgehende oder in Richtung Süden verlaufende Verbindungen) sein. Ein Server kann je nach Ihrer Einschätzung in Schritt 1 der Edge Router (für eingehende oder nach Norden gerichtete Verbindungen) oder der Back-End-Server (für ausgehende oder südliche Verbindungen) sein.
    • Wenn Sie ein Public Cloud-Nutzer sind, können Sie die tcpdump-Daten nur in der Clientanwendung (für eingehende oder in Richtung Norden gehende Verbindungen) oder auf dem Back-End-Server (für ausgehende oder südliche Verbindungen) erfassen, da Sie keinen Zugriff auf den Edge Router oder den 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 von tcpdump mit Wireshark:
    • In diesem Beispiel ist der TLS/SSL-Handshake zwischen dem Nachrichtenprozessor und dem Back-End-Server (der ausgehenden oder südlichen Verbindung) aufgetreten.
    • Nachricht 4 in der tcpdump-Ausgabe unten zeigt, dass der Message Processor (Quelle) eine „Client Hello“-Nachricht an den Back-End-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 Back-End-Server die Nachricht „Client Hello“ vom Message Processor bestätigt.
    • Der Back-End-Server sendet sofort Fatal Alert : Close Notify an den Message Processor (Nachricht Nr. 6). Dies bedeutet, dass der TLS/SSL-Handshake fehlgeschlagen ist und die Verbindung beendet wird.

    • Eine ausführlichere Prüfung von Nachricht 6 zeigt, dass der Grund für den Fehler des TLS/SSL-Handshakes darin besteht, dass der Back-End-Server nur das TLSv1.0-Protokoll unterstützt, wie unten dargestellt:

    • Da zwischen dem vom Message Processor verwendeten Protokoll und dem Back-End-Server eine Diskrepanz besteht, hat der Back-End-Server die Nachricht Fatal Alert Message: Close Notify gesendet.

Auflösung

Der Message Processor läuft auf Java 8 und verwendet standardmäßig das TLSv1.2-Protokoll. Wenn der Back-End-Server das TLSv1.2-Protokoll nicht unterstützt, können Sie das Problem mit einem der folgenden Schritte beheben:

  1. Aktualisieren Sie Ihren Back-End-Server so, dass er das TLSv1.2-Protokoll unterstützt. Diese Lösung wird empfohlen, da das Protokoll TLSv1.2 sicherer ist.
  2. Wenn Sie Ihren Back-End-Server aus irgendeinem Grund nicht sofort aktualisieren können, können Sie erzwingen, dass der Message Processor das Protokoll TLSv1.0 für die Kommunikation mit dem Back-End-Server verwendet. Gehen Sie dazu so vor:
    1. Wenn Sie in der TargetEndpoint-Definition des Proxys keinen Zielserver angegeben haben, setzen Sie das Element Protocol auf TLSv1.0, 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 Verwaltungs-API, um das Protokoll in der spezifischen Zielserverkonfiguration auf TLSv1.0 festzulegen.

Abweichende Cipher

Ein TLS/SSL-Handshake schlägt fehl, wenn der vom Client verwendete Algorithmus der Chiffrensammlung weder bei der eingehenden Verbindung (nordgebunden) noch bei ausgehender Verbindung (nach Süden) in Apigee Edge vom Server unterstützt wird. Weitere Informationen finden Sie unter Verbindungen nach Norden und Süden verstehen.

Diagnose

  1. Ermitteln Sie, ob der Fehler bei der Verbindung northbound oder southbound aufgetreten ist. Weitere Hinweise dazu, wie Sie die Ursache des Problems ermitteln können, finden Sie unter Ursache des Problems ermitteln.
  2. Führen Sie das Dienstprogramm tcpdump aus, um weitere Informationen zu erhalten:
    • Wenn Sie ein Private Cloud-Nutzer sind, können Sie die tcpdump-Daten auf dem entsprechenden Client oder Server erfassen. Ein Client kann die Clientanwendung (für eingehende Verbindungen oder Verbindungen nach Norden) oder der Nachrichtenprozessor (für ausgehende oder in Richtung Süden verlaufende Verbindungen) sein. Ein Server kann je nach Ihrer Einschätzung in Schritt 1 der Edge Router (für eingehende oder nach Norden gerichtete Verbindungen) oder der Back-End-Server (für ausgehende oder südliche Verbindungen) sein.
    • Wenn Sie ein Public Cloud-Nutzer sind, können Sie die tcpdump-Daten nur in der Clientanwendung (für eingehende oder in Richtung Norden gehende Verbindungen) oder auf dem Back-End-Server (für ausgehende oder südliche Verbindungen) erfassen, da Sie keinen Zugriff auf den Edge Router oder den 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 Ihnen bekannten Tool.
  4. Hier ist die Beispielanalyse der tcpdump-Ausgabe mit Wireshark:
    • In diesem Beispiel ist der TLS/SSL-Handshake zwischen der Clientanwendung und dem Edge-Router (nordgebundene Verbindung) aufgetreten. Die tcpdump-Ausgabe wurde auf dem Edge-Router erfasst.

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

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

    • Nachricht 5 zeigt, dass der Edge Router die Nachricht „Client Hello“ von der Clientanwendung bestätigt.
    • Der Edge-Router sendet sofort eine Schwerwiegende Warnung : Handshakefehler an die Clientanwendung (Nachricht 6). Dies bedeutet, dass der TLS/SSL-Handshake fehlgeschlagen ist und die Verbindung beendet wird.
    • Wenn wir uns Nachricht 6 näher ansehen, werden die folgenden Informationen angezeigt:
      • Der Edge Router unterstützt das TLSv1.2-Protokoll. Dies bedeutet, dass das Protokoll zwischen der Clientanwendung und dem Edge Router übereinstimmt.

      • Der Edge-Router sendet jedoch weiterhin die Meldung Schwerwiegende Benachrichtigung: Handshakefehler an die Clientanwendung, wie im folgenden Screenshot dargestellt:

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

    • Die Liste der vom Edge Router unterstützten Cipher Suite-Algorithmen ist in der Datei /opt/nginx/conf.d/0-default.conf aufgeführt. In diesem Beispiel unterstützt der Edge Router nur die Algorithmen der Verschlüsselungssuite High Encryption.
    • Die Clientanwendung verwendet keinen der Algorithmen der Verschlüsselungssuite High Encryption. Diese Abweichung ist auf den Fehler beim TLS/SSL-Handshake zurückzuführen.
    • Da der Edge Router SNI-fähig ist, scrollen Sie in der Ausgabe tcpdump nach unten zu Nachricht 4 und prüfen Sie, ob die Clientanwendung den Servernamen korrekt sendet, wie in der folgenden Abbildung gezeigt:


    • Wenn dieser Name gültig ist, können Sie daraus ableiten, dass der TLS/SSL-Handshakefehler aufgetreten ist, da die von der Clientanwendung verwendeten Chiffresammlungsalgorithmen nicht vom Edge Router unterstützt werden.

Auflösung

Der Client muss die vom Server unterstützten Algorithmen der Cipher Suite verwenden. Um das im vorherigen Abschnitt zur Diagnose beschriebene Problem zu beheben, laden Sie das Paket JCE (Java Cryptography Extension) herunter und installieren Sie es. Nehmen Sie es in die Java-Installation auf, damit die Algorithmen der Cipher Suite High Encryption unterstützt werden.

Falsches Zertifikat

Ein TLS/SSL-Handshake-Fehler tritt auf, wenn im Keystore/Truststore falsche Zertifikate vorhanden sind, entweder bei der eingehenden (northbound) oder ausgehenden (Southbound)-Verbindung in Apigee Edge. Weitere Informationen finden Sie unter Verbindungen nach Norden und Süden verstehen.

Wenn das Problem in Nordausrichtung liegt, werden je nach Ursache möglicherweise unterschiedliche Fehlermeldungen angezeigt.

In den folgenden Abschnitten finden Sie Beispiele für Fehlermeldungen und die Schritte zur Diagnose und Behebung dieses Problems.

Fehlermeldungen

Je nach Ursache des TLS/SSL-Handshakefehlers können verschiedene Fehlermeldungen angezeigt werden. Hier ist ein Beispiel für eine Fehlermeldung, die möglicherweise angezeigt wird, wenn Sie einen API-Proxy aufrufen:

* 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

Typische Ursachen für dieses Problem:

Ursache Beschreibung Wer kann die Schritte zur Fehlerbehebung ausführen?
Hostname stimmt nicht überein Der in der URL verwendete Hostname stimmt nicht mit dem Zertifikat im Schlüsselspeicher des Routers überein. Eine Abweichung tritt beispielsweise auf, wenn der in der URL verwendete Hostname myorg.domain.com ist, während das Zertifikat den Hostnamen im CN des Zertifikats CN=something.domain.com. hat

 Nutzer von Edge Private und Public Cloud
Zertifikatskette unvollständig oder falsch Die Zertifikatskette ist nicht vollständig oder nicht korrekt. Nur für Nutzer von Edge Private und Public Cloud
Abgelaufenes oder unbekanntes Zertifikat vom Server oder Client gesendet Ein abgelaufenes oder unbekanntes Zertifikat wird vom Server oder Client entweder an der Nord- oder Südverbindung gesendet. Nutzer von Edge Private Cloud und Edge Public Cloud

Hostname stimmt nicht überein

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 im jeweiligen Schlüsselspeicher gespeicherten Zertifikat verwendet wird. Sie können die folgenden Edge Management APIs verwenden, um die Details des Zertifikats abzurufen:
    1. Rufen Sie den Zertifikatsnamen im Schlüsselspeicher ab:

      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. Rufen Sie die Details des Zertifikats im Schlüsselspeicher mithilfe der Edge-Verwaltungs-API ab.

      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

      Beispielzertifikat:

      "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 in der API-Anfrage-URL verwendete Hostname (siehe Schritt 1 oben) und der Antragstellername im Zertifikat nicht übereinstimmen, tritt der TLS/SSL-Handshakefehler auf.

Auflösung

Sie haben zwei Möglichkeiten, dieses Problem zu beheben:

  • Fordern Sie ein Zertifikat an (falls Sie noch keines haben), bei dem der Inhaber-CN ein Platzhalterzertifikat hat. Laden Sie dann die neue vollständige Zertifikatskette in den Schlüsselspeicher hoch. Beispiel: 
    "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",
  • Fordern Sie ein Zertifikat mit einem vorhandenen Subjekt-CN an (falls Sie noch keines haben), verwenden Sie aber your-org.your-domain als alternativer Antragstellername und laden Sie dann die vollständige Zertifikatskette in den Schlüsselspeicher hoch.

Verweise

Schlüsselspeicher und Truststores

Die Zertifikatskette ist unvollständig oder falsch

Diagnose

  1. Ruft den CN ab, der im im jeweiligen Schlüsselspeicher gespeicherten Zertifikat verwendet wird. Sie können die folgenden Edge Management APIs verwenden, um die Details des Zertifikats abzurufen:
    1. Zertifikatsnamen im Schlüsselspeicher 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. Rufen Sie die Details des Zertifikats im Schlüsselspeicher ab:

      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 seine Kette und achten Sie darauf, dass sie die im Artikel Funktionsweise von Zertifikatsketten bereitgestellten Richtlinien einhält. So sorgen Sie dafür, dass die Zertifikatskette gültig und vollständig ist. Wenn die im Schlüsselspeicher gespeicherte Zertifikatskette entweder unvollständig oder ungültig ist, wird der TLS/SSL-Handshakefehler angezeigt.
    4. Die folgende Grafik zeigt ein Beispielzertifikat mit einer ungültigen Zertifikatskette, bei dem das Zwischenzertifikat und das Root-Zertifikat nicht übereinstimmen:

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


Auflösung

  1. Fordern Sie ein Zertifikat an, das eine vollständige und gültige Zertifikatskette enthält, falls Sie noch keines haben.
  2. Führen Sie den folgenden openssl-Befehl aus, um zu prüfen, ob die Zertifikatskette 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 vom Server oder Client gesendet

Wenn der Server/Client ein falsches oder abgelaufenes Zertifikat sendet, entweder an der Nord- oder Südverbindung, lehnt das andere Ende (Server/Client) das Zertifikat ab, was zu einem TLS/SSL-Handshakefehler führt.

Diagnose

  1. Ermitteln Sie, ob der Fehler an der Verbindung northbound oder southbound aufgetreten ist. Weitere Hinweise dazu, wie Sie die Ursache des Problems ermitteln können, finden Sie unter Ursache des Problems ermitteln.
  2. Führen Sie das Dienstprogramm tcpdump aus, um weitere Informationen zu erhalten:
    • Wenn Sie ein Private Cloud-Nutzer sind, können Sie die tcpdump-Daten auf dem entsprechenden Client oder Server erfassen. Ein Client kann die Clientanwendung (für eingehende Verbindungen oder Verbindungen nach Norden) oder der Nachrichtenprozessor (für ausgehende oder in Richtung Süden verlaufende Verbindungen) sein. Ein Server kann je nach Ihrer Einschätzung in Schritt 1 der Edge Router (für eingehende oder nach Norden gerichtete Verbindungen) oder der Back-End-Server (für ausgehende oder südliche Verbindungen) sein.
    • Wenn Sie ein Public Cloud-Nutzer sind, können Sie die tcpdump-Daten nur in der Clientanwendung (für eingehende oder in Richtung Norden gehende Verbindungen) oder auf dem Back-End-Server (für ausgehende oder südliche Verbindungen) erfassen, da Sie keinen Zugriff auf den Edge Router oder den 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. Bestimmen Sie anhand der Ausgabe von tcpdump 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, vorausgesetzt die Daten sind nicht verschlüsselt. Damit können Sie vergleichen, ob dieses Zertifikat mit dem im Truststore verfügbaren Zertifikat übereinstimmt.
  6. Sehen Sie sich das tcpdump-Beispiel für die SSL-Kommunikation zwischen dem Nachrichtenprozessor und dem Back-End-Server an.

    Beispiel tcpdump mit Fehler „Unbekannter Zertifikat“


    1. Der Message Processor (Client) sendet in Nachricht Nr. 59 "Client Hello" an den Back-End-Server (Server).
    2. Der Back-End-Server sendet in Nachricht 61 „Server Hello“ an den Message Processor.
    3. Die verwendeten Protokoll- und Cipher Suite-Algorithmen werden gegenseitig validiert.
    4. Der Back-End-Server sendet das Zertifikat und die Server Hello Done-Nachricht in Nachricht 68 an den Message Processor.
    5. Der Message Processor sendet die schwerwiegende Warnung "Description: Certificate Unknown" in Nachricht 70.
    6. Wenn wir uns näher mit Nachricht Nr. 70 befassen, gibt es außer der unten gezeigten Benachrichtigung keine weiteren Details:


    7. Lesen Sie Nachricht 68, um die Details zum Zertifikat abzurufen, die vom Back-End-Server gesendet wurden, wie in der folgenden Grafik gezeigt:

    8. Das Zertifikat des Back-End-Servers und seine vollständige Kette sind alle unter dem Abschnitt „Zertifikate“ verfügbar, wie in der Abbildung oben dargestellt.
  7. Wenn das Zertifikat wie im obigen Beispiel entweder vom Router (in nördlicher Richtung) oder vom Message Processor (in Süden) unbekannt ist, gehen Sie so vor:
    1. Rufen Sie das Zertifikat und seine Kette ab, die im jeweiligen Truststore gespeichert sind. Weitere Informationen finden Sie in der Konfiguration des virtuellen Hosts für den Router und 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 Truststore abrufen: 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs
      2. Rufen Sie die Details des Zertifikats im Truststore ab: 
        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 (Richtung Norden) oder Nachrichtenprozessor (Süden) gespeicherte Zertifikat mit dem Zertifikat übereinstimmt, das im Schlüsselspeicher der Clientanwendung (Nordgebunden) oder des Zielservers (Süden) gespeichert ist, oder mit dem Zertifikat, das aus der Ausgabe tcpdump abgerufen wird. Wenn eine Abweichung auftritt, ist das die Ursache für den TLS/SSL-Handshakefehler.
  8. Wenn das Zertifikat entweder von der Clientanwendung (in nördlicher Richtung) oder vom Zielserver (in Süden) unbekannt ist, gehen Sie so vor:
    1. Rufen Sie die vollständige Zertifikatskette ab, die im Zertifikat verwendet wird, das im jeweiligen Schlüsselspeicher gespeichert ist. Weitere Informationen finden Sie in der Konfiguration des virtuellen Hosts für den Router und 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. Rufen Sie die Details des Zertifikats im Schlüsselspeicher ab:
        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 Schlüsselspeicher des Routers (Richtung Norden) oder Nachrichtenprozessor (Süden) gespeicherte Zertifikat mit dem Zertifikat übereinstimmt, das im Truststore der Clientanwendung (Richtung Norden) oder des Zielservers (Süden) gespeichert ist, oder mit dem Zertifikat, das aus der Ausgabe tcpdump abgerufen wird. Wenn eine Diskrepanz vorliegt, ist das die Ursache für den SSL-Handshakefehler.
  9. Wenn festgestellt wird, dass das von einem Server/Client gesendete Zertifikat abgelaufen ist, lehnt der empfangende Client/Server das Zertifikat ab und Sie sehen die folgende Warnmeldung im tcpdump:

    Warnung (Ebene: Schwerwiegend, Beschreibung: Zertifikat abgelaufen)

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

Auflösung

Um das im obigen Beispiel identifizierte Problem zu beheben, laden Sie das gültige Back-End-Serverzertifikat in den Trustore des Message Processor hoch.

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

Ursache Beschreibung Lösung
Abgelaufenes Zertifikat NorthBound
  • Das im Schlüsselspeicher des Routers gespeicherte Zertifikat ist abgelaufen.
  • Das im Schlüsselspeicher der Clientanwendung gespeicherte Zertifikat ist abgelaufen (2-Wege-SSL).
 Laden Sie ein neues Zertifikat und seine vollständige Kette in den Schlüsselspeicher auf dem entsprechenden Host hoch.
SouthBound
  • Das im Schlüsselspeicher des Zielservers gespeicherte Zertifikat ist abgelaufen.
  • Das im Schlüsselspeicher des Message Processor gespeicherte Zertifikat ist abgelaufen (2-Wege-SSL).
 Laden Sie ein neues Zertifikat und seine vollständige Kette in den Schlüsselspeicher auf dem entsprechenden Host hoch.
Unbekanntes Zertifikat NorthBound
  • Das im Truststore der Clientanwendung gespeicherte Zertifikat stimmt nicht mit dem Zertifikat des Routers überein.
  • Das im Truststore des Routers gespeicherte Zertifikat stimmt nicht mit dem Zertifikat der Clientbibliothek (2-Wege-SSL) überein.
 Laden Sie das gültige Zertifikat in den Truststore des entsprechenden Hosts hoch.
SouthBound
  • Das im Truststore des Zielservers gespeicherte Zertifikat stimmt nicht mit dem Zertifikat des Message Processor überein.
  • Das im Truststore des Message Processor gespeicherte Zertifikat stimmt nicht mit dem Zertifikat des Zielservers (2-Wege-SSL) überein.
 Laden Sie das gültige Zertifikat in den Truststore des entsprechenden Hosts hoch.

SNI-fähiger Server

Ein TLS/SSL-Handshake-Fehler kann auftreten, wenn der Client mit einem SNI-fähigen Server kommuniziert, der Client jedoch nicht SNI-aktiviert ist. Dies kann entweder an der Nord- oder an der Südverbindung in Edge geschehen.

Ermitteln Sie zuerst den Hostnamen und die Portnummer des verwendeten Servers und prüfen Sie, ob SNI aktiviert ist.

Identifikation des SNI-fähigen Servers

  1. Führen Sie den Befehl openssl aus und versuchen Sie, eine Verbindung zum entsprechenden Server-Hostnamen (Edge-Router oder Back-End-Server) herzustellen, ohne den Servernamen zu übergeben, wie unten gezeigt: 
    openssl s_client -connect hostname:port
    Möglicherweise erhalten Sie die Zertifikate und manchmal tritt ein Handshake im Befehl „openssl“ wie unten gezeigt auf:
    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-Hostnamen (Edge-Router oder Back-End-Server) herzustellen. Dazu müssen Sie den Servernamen wie unten gezeigt übergeben: 
    openssl s_client -connect hostname:port -servername hostname
  3. Wenn in Schritt 1 ein Handshakefehler auftritt oder Sie in Schritt 1 und Schritt 2 unterschiedliche Zertifikate erhalten, bedeutet dies, dass der angegebene Server SNI aktiviert ist.

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

Diagnose

  1. Ermitteln Sie, ob der Fehler an der Verbindung northbound oder southbound aufgetreten ist. Weitere Hinweise dazu, wie Sie die Ursache des Problems ermitteln können, finden Sie unter Ursache des Problems ermitteln.
  2. Führen Sie das Dienstprogramm tcpdump aus, um weitere Informationen zu erhalten:
    • Wenn Sie ein Private Cloud-Nutzer sind, können Sie die tcpdump-Daten auf dem entsprechenden Client oder Server erfassen. Ein Client kann die Clientanwendung (für eingehende Verbindungen oder Verbindungen nach Norden) oder der Nachrichtenprozessor (für ausgehende oder in Richtung Süden verlaufende Verbindungen) sein. Ein Server kann je nach Ihrer Einschätzung in Schritt 1 der Edge Router (für eingehende oder nach Norden gerichtete Verbindungen) oder der Back-End-Server (für ausgehende oder südliche Verbindungen) sein.
    • Wenn Sie ein Public Cloud-Nutzer sind, können Sie die tcpdump-Daten nur in der Clientanwendung (für eingehende oder in Richtung Norden gehende Verbindungen) oder auf dem Back-End-Server (für ausgehende oder südliche Verbindungen) erfassen, da Sie keinen Zugriff auf den Edge Router oder den 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 für tcpdump mit Wireshark:
    1. In diesem Beispiel ist der TLS/SSL-Handshake zwischen dem Edge-Nachrichtenprozessor und dem Back-End-Server (Southbound-Verbindung) aufgetreten.
    2. Die Nachricht 4 in der tcpdump-Ausgabe unten zeigt, dass der Message Processor (Quelle) eine „Client Hello“-Nachricht an den Back-End-Server (Ziel) gesendet hat.

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

    4. Die Nachricht Nr. 4 zeigt, dass der Back-End-Server die Nachricht "Client Hello" vom Message Processor bestätigt.
    5. Der Back-End-Server sendet sofort eine Schwerwiegende Warnung : Handshakefehler an den Message Processor (Nachricht Nr. 5). Dies bedeutet, dass der TLS/SSL-Handshake fehlgeschlagen ist und die Verbindung beendet wird.
    6. Lesen Sie Nachricht 6, um die folgenden Informationen zu erhalten:
      • Der Back-End-Server unterstützt das TLSv1.2-Protokoll. Dies bedeutet, dass das Protokoll zwischen dem Message Processor und dem Back-End-Server übereinstimmt.
      • Dennoch sendet der Back-End-Server die Nachricht Schwerwiegende Warnung: Handshakefehler an den Message Processor, wie in der folgenden Abbildung dargestellt:

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

    9. Dadurch wird bestätigt, dass der Message Processor den server_name nicht an den SNI-fähigen Back-End-Server gesendet hat.
    10. Dies ist die Ursache für den TLS/SSL-Handshakefehler und der Grund dafür, dass der Back-End-Server die Schwerwiegende Warnung: Handshakefehler an den Nachrichtenprozessor sendet.
  5. Prüfen Sie, ob jsse.enableSNIExtension property in system.properties auf dem Message Processor auf „false“ gesetzt ist, um zu bestätigen, dass der Message Processor nicht für die Kommunikation mit dem SNI-fähigen Server aktiviert ist.

Auflösung

Aktivieren Sie die Kommunikation zwischen den Message Processorn und SNI-fähigen Servern durch die folgenden Schritte:

  1. Erstellen Sie die Datei /opt/apigee/customer/application/message-processor.properties (falls sie noch nicht vorhanden ist).
  2. Fügen Sie die folgende Zeile in diese Datei ein: conf_system_jsse.enableSNIExtension=true
  3. Legen Sie den Eigentümer dieser Datei auf apigee:apigee fest: 
    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 Processor.

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