Diese Seite wurde von der Cloud Translation API übersetzt.

TLS/SSL-Handshakefehler

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Symptom

Ein TLS/SSL-Handshake-Fehler tritt auf, wenn ein Client und ein Server keine Kommunikation über das TLS/SSL-Protokoll. Wenn dieser Fehler in Apigee Edge auftritt, wird der Client Die Anwendung empfängt den HTTP-Status 503 mit der Meldung Service Unavailable. Ich erhalten Sie diesen Fehler nach API-Aufrufen, bei denen ein Fehler beim TLS/SSL-Handshake auftritt.

Fehlermeldungen

HTTP/1.1 503 Service Unavailable

Sie können auch die folgende Fehlermeldung sehen, wenn ein Fehler beim TLS/SSL-Handshake auftritt:

Received fatal alert: handshake_failure

Mögliche Ursachen

TLS (Transport Layer Security, dessen Vorgänger SSL) ist die standardmäßige Sicherheitstechnologie für Herstellen einer verschlüsselten Verbindung zwischen einem Webserver und einem Webclient, z. B. einem Browser oder einer Anwendung. Ein Handshake ist ein Prozess, mit dem der TLS/SSL-Client und -Server einen Satz von Secrets erstellen können. Schlüssel, mit denen sie kommunizieren können. Während dieses Vorgangs führen der Client und der Server folgende Schritte aus:

Vereinbaren Sie eine Version des zu verwendenden Protokolls.
Wählen Sie den zu verwendenden kryptografischen Algorithmus aus.
Sich gegenseitig durch Austausch und Validierung digitaler Zertifikate authentifizieren

Wenn der TLS/SSL-Handshake erfolgreich ist, übertragen der TLS/SSL-Client und der Server Daten an die beiden auf andere Weise zu schützen. Andernfalls wird bei einem TLS/SSL-Handshake-Fehler die Verbindung beendet und der Client erhält den Fehler 503 Service Unavailable.

Mögliche Ursachen für TLS/SSL-Handshake-Fehler:

Ursache	Beschreibung	Wer kann die Schritte zur Fehlerbehebung durchführen?
Protokoll stimmt nicht überein	Das vom Client verwendete Protokoll wird vom Server nicht unterstützt.	Nutzer von privaten und öffentlichen Clouds
Cipher Suite stimmt nicht überein	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 die auf Serverseite gespeichert sind.	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
	Der Client sendet ein falsches oder abgelaufenes Zertifikat an den Server oder vom Server. an die Kundschaft.	Nutzer von privaten und öffentlichen Clouds
SNI-fähiger Server	Für den Backend-Server ist Server Name Indication (SNI) aktiviert. Der Kunde kann jedoch nicht mit dem SNI-Server	Nur Nutzer der privaten Cloud

Protokoll Abweichend

Ein TLS/SSL-Handshake-Fehler tritt auf, wenn das vom Client verwendete Protokoll nicht vom entweder bei der eingehenden Verbindung (Richtung Norden) oder bei der ausgehenden Verbindung (Richtung Süden) des Servers. Siehe auch <ph type="x-smartling-placeholder"></ph> Verbindungen in nördliche und südliche Richtung

Diagnose

Stellen Sie fest, ob der Fehler in der Richtung Norden oder southbound-Verbindung Weitere Informationen dazu, Determination, siehe <ph type="x-smartling-placeholder"></ph> Ermitteln der Ursache des Problems
Führen Sie den <ph type="x-smartling-placeholder"></ph> tcpdump, um weitere Informationen zu erhalten: <ph type="x-smartling-placeholder">
- Wenn Sie ein Private Cloud-Nutzer sind, können Sie die tcpdump erfassen. auf dem jeweiligen Client oder Server. Ein Client kann die Client-App sein (für eingehende, Verbindungen nach Norden) oder die Nachricht Prozessor (für ausgehende Verbindungen oder Verbindungen in Richtung Süden) Ein Server kann der Edge Router (für eingehende Verbindungen oder Verbindungen nach Norden) oder der Back-End-Server (für ausgehende Verbindungen oder Verbindungen in Richtung Süden), basierend auf Ihrer Bestimmung in Schritt 1.
- Wenn Sie ein Nutzer einer öffentlichen Cloud sind, können Sie die tcpdump erfassen. Daten nur in der Client-App (für eingehende oder nördliche Verbindungen) oder auf dem Back-End-Server (für ausgehende Verbindungen oder Verbindungen in Richtung Süden), da Sie keinen Zugriff auf den Edge Router oder Message Processor haben.
```
tcpdump -i any -s 0 host IP address -w File name
```
Siehe tcpdump-Daten. Dort finden Sie weitere Informationen zur Verwendung von tcpdump. .
Analysiere die tcpdump-Daten mit dem Wireshark-Tool. oder ein ähnliches Tool.
Hier ist eine Beispielanalyse <ph type="x-smartling-placeholder"></ph> tcpdump mit Wireshark: <ph type="x-smartling-placeholder">
- In diesem Beispiel ist der TLS/SSL-Handshake zwischen dem Message Processor und Back-End-Server (ausgehende Verbindung oder Verbindung in Richtung Süden).
- Nachricht 4 in der unten stehenden tcpdump-Ausgabe zeigt, dass der Message Processor (Quelle) eine Nachricht gesendet hat, „Hallo Kunde“ an den Back-End-Server (Ziel).
- Wenn Sie die Nachricht Client Hello auswählen, wird angezeigt, dass der Message Processor die Methode TLSv1.2-Protokolls, wie unten gezeigt:
- Nachricht 5 zeigt, dass der Back-End-Server die "Client Hello"-Nachricht bestätigt Nachricht von Message Processor.
- Der Backend-Server sendet sofort die Schwerwiegende Warnung : Close Notify an den Message Processor (Nachricht 6). Dies bedeutet, dass der TLS/SSL-Handshake fehlgeschlagen ist und die Verbindung geschlossen sein.
- Ein genauerer Blick auf Nachricht Nr. 6 zeigt, dass der TLS/SSL-Handshake fehlgeschlagen ist, dass der Backend-Server unterstützt nur das TLSv1.0-Protokoll, wie unten gezeigt:
- Da es eine Diskrepanz zwischen dem vom Message Processor verwendeten Protokoll und dem Backend-Server hat der Backend-Server folgende Nachricht gesendet: Schwerwiegende Warnmeldung: Schließen Benachrichtigen.

Auflösung

Der Message Processor wird auf Java 8 ausgeführt und verwendet standardmäßig das TLSv1.2-Protokoll. Wenn das Backend Server nicht das TLSv1.2-Protokoll unterstützt, können Sie einen der folgenden Schritte ausführen, um das dieses Problem:

Aktualisieren Sie Ihren Backend-Server, damit er das TLSv1.2-Protokoll unterstützt. Dies ist eine empfohlene Lösung, da ist das Protokoll TLSv1.2 sicherer.
Wenn Sie Ihren Backend-Server aus irgendeinem Grund nicht sofort aktualisieren können, erzwingen, dass der Message Processor das TLSv1.0-Protokoll für die Kommunikation mit Back-End-Server, indem Sie die folgenden Schritte ausführen: <ph type="x-smartling-placeholder">
1. Wenn Sie in der TargetEndpoint-Definition des Proxys keinen Zielserver angegeben haben, legen Sie das Protocol-Element auf TLSv1.0, wie gezeigt unten:
```
<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 eine <ph type="x-smartling-placeholder"></ph> Zielserver für Ihren Proxy ein und verwenden Sie <ph type="x-smartling-placeholder"></ph> dieser Verwaltungs-API, um das Protokoll in der spezifischen API auf TLSv1.0 Konfiguration des Zielservers.

Cipher stimmt nicht überein

Sie sehen einen TLS/SSL-Handshake-Fehler, wenn der vom Client verwendete Cipher Suite-Algorithmus nicht die vom Server entweder an der eingehenden (Richtung) oder der ausgehenden (südseitigen) Verbindung in Apigee Edge unterstützt wird. Siehe auch Verbindungen in nördliche und südliche Richtung

Diagnose

Stellen Sie fest, ob der Fehler am folgenden Tag aufgetreten ist: Verbindung nach northbound oder southbound Weitere Informationen zu dieser Feststellung finden Sie unter Bestimmen der die Ursache des Problems
Führen Sie den <ph type="x-smartling-placeholder"></ph> tcpdump, um weitere Informationen zu erhalten: <ph type="x-smartling-placeholder">
- Wenn Sie ein Private Cloud-Nutzer sind, können Sie die tcpdump erfassen. auf dem jeweiligen Client oder Server. Ein Client kann die Client-App sein (für eingehende, Verbindungen nach Norden) oder die Nachricht Prozessor (für ausgehende Verbindungen oder Verbindungen in Richtung Süden) Ein Server kann der Edge Router (für eingehende Verbindungen oder Verbindungen nach Norden) oder der Back-End-Server (für ausgehende Verbindungen oder Verbindungen in Richtung Süden), basierend auf Ihrer Bestimmung in Schritt 1.
- Wenn Sie ein Nutzer einer öffentlichen Cloud sind, können Sie die tcpdump erfassen. Daten nur in der Client-App (für eingehende oder nördliche Verbindungen) oder auf dem Back-End-Server (für ausgehende Verbindungen oder Verbindungen in Richtung Süden), da Sie keinen Zugriff auf den Edge Router oder Message Processor haben.
```
tcpdump -i any -s 0 host IP address -w File name
```
Siehe tcpdump finden Sie weitere Informationen zur Verwendung des Befehls tcpdump.
Analysieren Sie die tcpdump-Daten mit dem Wireshark-Tool. oder ein anderes Tool, mit dem Sie vertraut sind.
Hier ist die Beispielanalyse der tcpdump-Ausgabe mit Wireshark: <ph type="x-smartling-placeholder">
- In diesem Beispiel ist der TLS/SSL-Handshake-Fehler zwischen der Clientanwendung und Edge-Router (Verbindung nach Norden) Die Ausgabe von tcpdump wurde am Edge erfasst Router.
- Die Nachricht 4 in der folgenden tcpdump-Ausgabe zeigt, dass die Clientanwendung (Quelle) eine Nachricht gesendet hat, „Hallo Kunde“ an den Edge Router (Ziel).
- Wenn Sie die Client Hello-Nachricht auswählen, wird angezeigt, dass die Clientanwendung das TLSv1.2-Protokoll.
- Nachricht 5 zeigt, dass der Edge Router die Nachricht „Client Hello“ bestätigt Nachricht von der Clientanwendung.
- Der Edge-Router sendet sofort eine schwerwiegende Warnung: Handshakefehler an die folgende Adresse: der Clientanwendung (Nachricht 6). Das bedeutet, dass der TLS/SSL-Handshake fehlgeschlagen ist und die Verbindung wird geschlossen.
- Ein Blick in die Nachricht Nr. 6 zeigt die folgenden Informationen: <ph type="x-smartling-placeholder">
  - Der Edge Router unterstützt das TLSv1.2-Protokoll. Das bedeutet, dass das Protokoll zwischen der Clientanwendung und dem Edge Router.
  - Der Edge-Router sendet jedoch weiterhin die schwerwiegende Warnung: Handshake Fehler an der Client-Anwendung (siehe Screenshot unten):
- Der Fehler kann folgende Ursachen haben: <ph type="x-smartling-placeholder">
  - Die Clientanwendung verwendet nicht die Algorithmen der Cipher Suite, die vom Edge Router.
  - Der Edge Router ist SNI-fähig, aber die Clientanwendung sendet den Servernamen.
- In Nachricht 4 in der tcpdump-Ausgabe werden die vom Client unterstützten Cipher Suite-Algorithmen aufgelistet wie unten dargestellt:
- Die Liste der vom Edge Router unterstützten Cipher Suite-Algorithmen finden Sie in der /opt/nginx/conf.d/0-default.conf-Datei. In diesem Beispiel hat der Edge Router unterstützt nur die Algorithmen der High Encryption Cipher Suite.
- Die Clientanwendung verwendet keinen der Algorithmen der High Encryption Cipher Suite. Diese Abweichung ist die Ursache TLS/SSL-Handshake fehlgeschlagen.
- Da der Edge Router SNI-fähig ist, scrollen Sie nach unten zu Nachricht Nr. 4 in der tcpdump-Ausgabe und dass die Client-Anwendung den Servernamen korrekt sendet (siehe Abbildung unten:
- Wenn dieser Name gültig ist, können Sie ableiten, dass der TLS/SSL-Handshake fehlgeschlagen ist. ist aufgetreten, weil die von der Clientanwendung verwendeten Cipher Suite-Algorithmen von den Edge Router.

Auflösung

Sie müssen sicherstellen, dass der Client die Algorithmen der Cipher Suite verwendet, die die vom Server unterstützt werden. Um das oben beschriebene Problem zu beheben, im Bereich zur Diagnose auf, laden Sie die <ph type="x-smartling-placeholder"></ph> Java Cryptography Extension (JCE)-Paket und in das Java aufnehmen um Algorithmen der High Encryption Cipher Suite zu unterstützen.

Falsches Zertifikat

Ein TLS/SSL-Handshake-Fehler tritt auf, wenn im Schlüsselspeicher/Truststore falsche Zertifikate vorhanden sind. entweder an der eingehenden Verbindung (Richtung Norden) oder an der ausgehenden Verbindung (Richtung Süden) in Apigee Edge. Siehe auch <ph type="x-smartling-placeholder"></ph> Verbindungen in nördliche und südliche Richtung

Wenn das Problem in nördlicher Richtung liegt, sehen Sie möglicherweise andere Fehlermeldungen. abhängig von der zugrunde liegenden Ursache.

In den folgenden Abschnitten sind Beispielfehlermeldungen und die Schritte zur Diagnose und Behebung des Problems aufgeführt. Problem.

Fehlermeldungen

Je nach Ursache des TLS/SSL-Handshakes können unterschiedliche Fehlermeldungen angezeigt werden. Hier ist ein Beispiel für eine Fehlermeldung, die Sie möglicherweise sehen, 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 durchführen?
Hostname stimmt nicht überein	Der in der URL verwendete Hostname und das Zertifikat im Schlüsselspeicher des Routers Übereinstimmung. Eine Abweichung tritt beispielsweise auf, wenn der Hostname, der in der URL verwendet wird, `myorg.domain.com` lautet, während Der Hostname des Zertifikats im CN lautet `CN=something.domain.com.`.	Private und öffentliche Edge-Cloud-Nutzer
Unvollständiges oder falsches Zertifikat Kette	Die Zertifikatskette ist nicht vollständig oder nicht korrekt.	Nur Edge-Nutzer von privaten und öffentlichen Clouds
Abgelaufenes oder unbekanntes Zertifikat, das vom Server oder Client	Ein abgelaufenes oder unbekanntes Zertifikat wird vom Server oder Client entweder in nördlicher Richtung oder unter Verbindung nach Süden.	Edge Private Cloud- und Edge Public Cloud-Nutzer

Hostname Abweichend

Diagnose

Notieren Sie sich den Hostname, der in der URL verwendet wird, die vom folgenden Edge-Management-API-Aufruf zurückgegeben wird:
```
curl -v https://myorg.domain.com/v1/getinfo
```
Hier einige Beispiele:
```
curl -v https://api.enterprise.apigee.com/v1/getinfo
```

Ruft das CN ab, das im Zertifikat verwendet wird, das im jeweiligen Schlüsselspeicher gespeichert ist. Sie können die folgenden Edge-Management-APIs, um die Details des Zertifikats abzurufen: <ph type="x-smartling-placeholder">

<ph type="x-smartling-placeholder"></ph> 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 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
```

<ph type="x-smartling-placeholder"></ph> Rufen Sie die Details des Zertifikats im Schlüsselspeicher mithilfe der Edge Management 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 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 das CN als something.domain.com.

Da der in der API-Anfrage-URL verwendete Hostname (siehe Schritt 1 oben) und der Betreff im Zertifikat nicht übereinstimmen, tritt ein Fehler beim TLS/SSL-Handshake auf.

Auflösung

Dieses Problem kann auf zwei Arten behoben werden:

Fordern Sie ein Zertifikat an (falls Sie noch keines haben), in dem das Antragsteller-CN einen Platzhalter hat. Zertifikat und 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",
```
Erhalten Sie ein Zertifikat (sofern Sie noch keines haben) mit einem vorhandenen Themen-CN. Verwenden Sie jedoch your-orgyour-domain als alternativen Antragstellernamen. Laden Sie dann den vollständigen zum Schlüsselspeicher hinzufügen.

Verweise

Schlüsselspeicher und Truststores

Unvollständige oder falsche Zertifikatskette

Diagnose

Ruft das CN ab, das im Zertifikat verwendet wird, das im jeweiligen Schlüsselspeicher gespeichert ist. Sie können die folgenden Edge-Management-APIs, um die Details des Zertifikats abzurufen: <ph type="x-smartling-placeholder">
1. <ph type="x-smartling-placeholder"></ph> Rufen Sie den Zertifikatsnamen im Schlüsselspeicher ab:
  
  Wenn Sie Private Cloud-Nutzer sind:
```
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
```
  Wenn Sie Public Cloud-Nutzer sind:
```
curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
```
2. <ph type="x-smartling-placeholder"></ph> Rufen Sie die Details des Zertifikats im Schlüsselspeicher ab:
  
  Wenn Sie 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 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. Zertifikat und Kette validieren und auf Einhaltung der Richtlinien prüfen an die Richtlinien im Artikel <ph type="x-smartling-placeholder"></ph> Funktionsweise von Zertifikatsketten, um sicherzustellen, dass sie gültig und vollständig sind Zertifikatkette. Wenn die im Schlüsselspeicher gespeicherte Zertifikatskette unvollständig oder ungültig ist, wird der TLS/SSL-Handshake Fehler.
4. Die folgende Grafik zeigt ein Beispielzertifikat mit einer ungültigen Zertifikatskette. wobei das Zwischen- und das Root-Zertifikat nicht übereinstimmen:

Auflösung

Holen Sie sich ein Zertifikat, das eine vollständige und gültige Zertifikatkette.
Führen Sie den folgenden openssl-Befehl aus, um zu überprüfen, ob die Zertifikatskette korrekt ist. Abgeschlossen:
```
openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert
```
Laden Sie die validierte Zertifikatskette in den Schlüsselspeicher hoch.

Abgelaufen oder unbekannt vom Server oder Client gesendetes Zertifikat

Wenn vom Server/Client ein falsches/abgelaufenes Zertifikat gesendet wird, entweder in nördlicher Richtung oder bei der Verbindung in Richtung Süden, lehnt das andere Ende (Server/Client) das Zertifikat ab. was zu einem Fehler beim TLS/SSL-Handshake führt.

Diagnose

Stellen Sie fest, ob der Fehler in der Richtung Norden oder southbound-Verbindung Weitere Informationen dazu, Determination, siehe <ph type="x-smartling-placeholder"></ph> Ermitteln der Ursache des Problems
Führen Sie den <ph type="x-smartling-placeholder"></ph> tcpdump, um weitere Informationen zu erhalten: <ph type="x-smartling-placeholder">
- Wenn Sie ein Private Cloud-Nutzer sind, können Sie die tcpdump erfassen. auf dem jeweiligen Client oder Server. Ein Client kann die Client-App sein (für eingehende, Verbindungen nach Norden) oder die Nachricht Prozessor (für ausgehende Verbindungen oder Verbindungen in Richtung Süden) Ein Server kann der Edge Router (für eingehende Verbindungen oder Verbindungen nach Norden) oder der Back-End-Server (für ausgehende Verbindungen oder Verbindungen in Richtung Süden), basierend auf Ihrer Bestimmung in Schritt 1.
- Wenn Sie ein Nutzer einer öffentlichen Cloud sind, können Sie die tcpdump erfassen. Daten nur in der Client-App (für eingehende oder nördliche Verbindungen) oder auf dem Back-End-Server (für ausgehende Verbindungen oder Verbindungen in Richtung Süden), da Sie keinen Zugriff auf den Edge Router oder Message Processor haben.
```
tcpdump -i any -s 0 host IP address -w File name
```
Siehe tcpdump finden Sie weitere Informationen zur Verwendung des Befehls tcpdump.
Analysieren Sie die tcpdump-Daten mit Wireshark oder einem ähnliches Tool.
Ermitteln Sie in der Ausgabe von tcpdump den Host (Client oder Server), der die während des Verifizierungsschritts.
Sie können das vom anderen Ende gesendete Zertifikat aus der tcpdump-Ausgabe abrufen, sofern das die Daten nicht verschlüsselt sind. Dies ist hilfreich, um zu vergleichen, ob dieses Zertifikat mit dem Zertifikat, das im Truststore verfügbar ist.
Sehen Sie sich das tcpdump-Beispiel für die SSL-Kommunikation zwischen dem Message Processor und auf dem Back-End-Server.
Beispiel tcpdump mit dem Fehler „Unbekanntes Zertifikat“
1. Der Message Processor (Client) sendet „Client Hello“. zum Backend-Server (Server) in Nachricht Nr. 59.
2. Der Backend-Server sendet „Server Hello“. an den Message Processor in der Nachricht 61.
3. Sie validieren die verwendeten Protokoll- und Cipher Suite-Algorithmen gegenseitig.
4. Der Backend-Server sendet das Zertifikat und die Server-Nachricht „Hello Done“ an den Message Processor in Nachricht Nr. 68.
5. Der Message Processor sendet die schwerwiegende Warnung "Description: Certificate Unbekannt“ in Nachricht Nr. 70.
6. Weiter mit Nachricht Nr. 70: Es gibt keine weiteren Details. als die unten stehende Warnmeldung angezeigt wird:
7. Lesen Sie die Nachricht 68, um Details zum vom Back-End gesendeten Zertifikat abzurufen. wie in der folgenden Grafik dargestellt:
8. Das Zertifikat des Backend-Servers und seine vollständige Kette sind alle verfügbar. unter „Zertifikate“ wie in der Abbildung oben dargestellt.
Falls das Zertifikat entweder vom Router (in Nordausrichtung) oder dem Message Processor (Richtung Süden) wie im obigen Beispiel dargestellt und folgen dann diesen Schritte: <ph type="x-smartling-placeholder">
1. Rufen Sie das Zertifikat und seine Kette ab, die im jeweiligen Truststore gespeichert sind. (Verweis mit der virtuellen Hostkonfiguration für den Router und die Zielendpunktkonfiguration für Message Processor). Mit den folgenden APIs können Sie die Details zu den Zertifikat: <ph type="x-smartling-placeholder">
  1. <ph type="x-smartling-placeholder"></ph> Rufen Sie den Zertifikatsnamen im Truststore ab:
```
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs
```
  2. <ph type="x-smartling-placeholder"></ph> 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 gespeicherte Zertifikat (in Nordausrichtung) oder Message Processor (Southbound) stimmt mit dem Zertifikat überein, das im Schlüsselspeicher der Client-Anwendung (Richtung Norden) oder Zielserver (Richtung Süden) oder der die aus der tcpdump-Ausgabe abgerufen wird. Wenn es eine Diskrepanz gibt, ist das der Grund Fehler beim TLS/SSL-Handshake.
Wenn das Zertifikat entweder von der Clientanwendung als unbekannt eingestuft wird (in Nordausrichtung) oder auf den Zielserver (Richtung Süden) und führen Sie dann folgende Schritte aus: <ph type="x-smartling-placeholder">
1. Rufen Sie die vollständige Zertifikatskette ab, die im Zertifikat verwendet wird, das in der spezifischen keystore. Weitere Informationen finden Sie in der Konfiguration des virtuellen Hosts für den Router und den Zielendpunkt. Konfiguration für den Message Processor.) Mit den folgenden APIs können Sie die Details zum Zertifikat: <ph type="x-smartling-placeholder">
  1. <ph type="x-smartling-placeholder"></ph> Rufen Sie den Zertifikatsnamen im Schlüsselspeicher ab:
```
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
```
  2. <ph type="x-smartling-placeholder"></ph> 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. Überprüfen Sie, ob das im Schlüsselspeicher des Routers gespeicherte Zertifikat (Richtung Norden) oder Message Processor (southbound) entspricht dem Zertifikat, das im Truststore der Clientanwendung (Richtung Norden) oder Zielserver (Richtung Süden) bzw. derjenige, der die aus der tcpdump-Ausgabe abgerufen werden. Wenn es eine Diskrepanz gibt, ist das die Ursache für die Handshake-Fehler.
Wenn das von einem Server/Client gesendete Zertifikat abgelaufen ist, Client/Server lehnt das Zertifikat ab und in der Datei tcpdump:
Warnung (Stufe: Schwerwiegend, Beschreibung: Zertifikat abgelaufen)
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 die an den Trustore im Message Processor.

In der folgenden Tabelle sind die Schritte zusammengefasst, mit denen das Problem abhängig von der Ursache des Fehlers behoben werden kann. Problem.

Ursache	Beschreibung	Lösung
Abgelaufenes Zertifikat	NorthBound <ph type="x-smartling-placeholder"> </ph> Das im Schlüsselspeicher des Routers gespeicherte Zertifikat ist abgelaufen. Das im Schlüsselspeicher der Clientanwendung gespeicherte Zertifikat ist abgelaufen (zweiseitige SSL) erkennen.	Laden Sie ein neues Zertifikat und seine vollständige Kette in den Schlüsselspeicher auf der entsprechenden Host.
Abgelaufenes Zertifikat	SouthBound <ph type="x-smartling-placeholder"> </ph> Das im Schlüsselspeicher des Zielservers gespeicherte Zertifikat ist abgelaufen. Das im Schlüsselspeicher des Message Processor gespeicherte Zertifikat ist abgelaufen (zweifach SSL) erkennen.	Laden Sie ein neues Zertifikat und seine vollständige Kette in den Schlüsselspeicher auf der entsprechenden Host.
Unbekanntes Zertifikat	NorthBound <ph type="x-smartling-placeholder"> </ph> Das im Truststore der Clientanwendung gespeicherte Zertifikat stimmt nicht überein das Zertifikat des Routers. Das im Truststore des Routers gespeicherte Zertifikat stimmt nicht mit dem Client überein Zertifikat der Anwendung (2-Wege-SSL).	Laden Sie das gültige Zertifikat in den Truststore auf dem entsprechenden Host hoch.
Unbekanntes Zertifikat	SouthBound <ph type="x-smartling-placeholder"> </ph> Das im Truststore des Zielservers gespeicherte Zertifikat stimmt nicht mit dem Zertifikat des Message Processor. Das im Truststore des Message Processor gespeicherte Zertifikat stimmt nicht überein das Zertifikat des Zielservers (Zwei-Wege-SSL)	Laden Sie das gültige Zertifikat in den Truststore auf dem entsprechenden Host hoch.

SNI-fähig Server

Der TLS/SSL-Handshake kann fehlschlagen, wenn der Client mit einem Server Name Indication (SNI) aktiviert Server, aber der Client ist nicht SNI-fähig. Dies kann an der Nord- oder Verbindung nach Süden in Edge.

Identifizieren Sie zunächst den Hostnamen und die Portnummer des verwendeten Servers und prüfen Sie, ob SNI aktiviert ist oder nicht.

Identifizierung des SNI-fähigen Servers

Führen Sie den Befehl openssl aus und versuchen Sie, eine Verbindung zum relevanten Server-Hostnamen herzustellen (Edge - Router oder Backend-Server, ohne den Servernamen zu übergeben:
```
openssl s_client -connect hostname:port
```
Möglicherweise erhalten Sie die Zertifikate und manchmal tritt ein Handshakefehler in den Befehl „openssl“ aus:
```
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
```
Führen Sie den Befehl openssl aus und versuchen Sie, eine Verbindung zum relevanten Serverhostnamen herzustellen (Edge-Router oder Backend-Server), indem Sie den Servernamen übergeben, wie unten gezeigt:
```
openssl s_client -connect hostname:port -servername hostname
```
Wenn in Schritt 1 ein Handshake-Fehler auftritt oder Sie in Schritt 1 andere Zertifikate erhalten und Schritt 2 ein, dann wird angezeigt, dass der angegebene Server SNI-fähig ist.

Sobald du festgestellt hast, dass der Server SNI-fähig ist, kannst du die folgenden Schritte ausführen, um Prüfen Sie, ob der TLS/SSL-Handshake-Fehler dadurch verursacht wird, dass der Client nicht mit mit dem SNI-Server verbunden.

Diagnose

Stellen Sie fest, ob der Fehler in der Richtung Norden oder southbound-Verbindung Weitere Informationen dazu, Determination, siehe <ph type="x-smartling-placeholder"></ph> Ermitteln der Ursache des Problems
Führen Sie den <ph type="x-smartling-placeholder"></ph> tcpdump, um weitere Informationen zu erhalten: <ph type="x-smartling-placeholder">
- Wenn Sie ein Private Cloud-Nutzer sind, können Sie die tcpdump erfassen. auf dem jeweiligen Client oder Server. Ein Client kann die Client-App sein (für eingehende, Verbindungen nach Norden) oder die Nachricht Prozessor (für ausgehende Verbindungen oder Verbindungen in Richtung Süden) Ein Server kann der Edge Router (für eingehende Verbindungen oder Verbindungen nach Norden) oder der Back-End-Server (für ausgehende Verbindungen oder Verbindungen in Richtung Süden), basierend auf Ihrer Bestimmung in Schritt 1.
- Wenn Sie ein Public Cloud-Nutzer sind, können Sie die tcpdump erfassen. Daten nur in der Client-App (für eingehende oder nördliche Verbindungen) oder auf dem Back-End-Server (für ausgehende Verbindungen oder Verbindungen in Richtung Süden), 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 finden Sie unter <ph type="x-smartling-placeholder"></ph> tcpdump finden Sie weitere Informationen zur Verwendung des Befehls tcpdump.
Analysieren Sie die tcpdump-Ausgabe mit Wireshark oder einem ähnliches Tool.
Hier ist die Beispielanalyse von tcpdump mit Wireshark: <ph type="x-smartling-placeholder">
1. In diesem Beispiel ist der TLS/SSL-Handshake zwischen der Edge-Nachricht Prozessor und Backend-Server (Verbindung nach Süden).
2. Die Nachricht 4 in der unten stehenden tcpdump-Ausgabe zeigt, dass der Message Processor (Quelle) a „Client Hello“ an den Back-End-Server (Ziel).
3. „Client Hello“ auswählen zeigt an, dass die Nachricht Der Prozessor verwendet das TLSv1.2-Protokoll.
4. Die Meldung Nr. 4 zeigt, dass der Back-End-Server die "Client Hello"-Anfrage bestätigt, Nachricht vom Message Processor.
5. Der Backend-Server sendet sofort eine schwerwiegende Warnung : Handshake Fehler an den Message Processor (Nachricht 5). Das bedeutet, dass der TLS/SSL-Handshake ist fehlgeschlagen. Die Verbindung wird getrennt.
6. Lesen Sie Nachricht Nr. 6 durch, um die folgenden Informationen zu erhalten <ph type="x-smartling-placeholder">
  - Der Backend-Server unterstützt das TLSv1.2-Protokoll. Das bedeutet, dass das Protokoll zwischen dem Message Processor und dem Back-End-Server.
  - Der Backend-Server sendet jedoch weiterhin die schwerwiegende Benachrichtigung: Handshake Fehler an den Message Processor, wie in der folgenden Abbildung dargestellt:
7. Dieser Fehler kann aus einem der folgenden Gründe auftreten: <ph type="x-smartling-placeholder">
  - Der Message Processor verwendet nicht die Cipher Suite-Algorithmen, die vom Back-End-Server.
  - Der Backend-Server ist SNI-fähig, aber die Clientanwendung sendet keine Daten den Servernamen.
8. Sehen Sie sich die Nachricht 3 (Client Hello) in der tcpdump-Ausgabe genauer an. Das Feld Extension: server_name fehlt:
9. Damit wird bestätigt, dass der Message Processor die server_name zum SNI-fähigen Back-End-Server
10. Dies ist die Ursache für den TLS/SSL-Handshake-Fehler und der Grund, dass das Back-End die schwerwiegende Benachrichtigung: Handshakefehler an die Nachricht sendet Prozessor.
Prüfen Sie, ob die jsse.enableSNIExtension property in system.properties wird im Message Processor auf „false“ gesetzt, um zu bestätigen, dass der Message Processor ist nicht für die Kommunikation mit dem SNI-fähigen Server aktiviert.

Auflösung

Ermöglichen Sie den Nachrichtenprozessoren, mit SNI-fähigen Servern zu kommunizieren, indem Sie den folgenden Schritten:

Erstellen Sie die /opt/apigee/customer/application/message-processor.properties -Datei (falls sie noch nicht vorhanden ist).
Fügen Sie der Datei die folgende Zeile hinzu: conf_system_jsse.enableSNIExtension=true

Übernehmen Sie den Eigentümer dieser Datei an apigee:apigee:

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

Starten Sie den Message Processor neu.

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

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 können und beheben Sie das Problem. Wenn Sie weitere Hilfe benötigen, wenden Sie sich an Apigee Edge-Unterstützung Teilen Sie uns alle Details zum Problem mit und Die tcpdump-Ausgabe.