Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

SSL-Handshake schlägt fehl – Fehlerhaftes Clientzertifikat

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu Apigee X. info

Symptom

Die Clientanwendung erhält als Antwort auf eine API-Anfrage den HTTP-Statuscode 503 mit der Meldung Service Unavailable. Im UI-Trace sehen Sie, dass error.cause im Zielanfrageablauf für die fehlgeschlagene API-Anfrage Received fatal alert: bad_certificate ist.

Wenn Sie Zugriff auf Message Processor-Logs haben, sehen Sie die Fehlermeldung als Received fatal alert: bad_certificate für die fehlgeschlagene API-Anfrage. Dieser Fehler tritt während des SSL-Handshake Prozesses zwischen dem Message Processor und dem Backend-Server in einer bidirektionalen TLS-Einrichtung auf.

Fehlermeldung

Die Clientanwendung erhält den folgenden Antwortcode:

HTTP/1.1 503 Service Unavailable

Außerdem wird möglicherweise die folgende Fehlermeldung angezeigt:

{
 "fault": {
    "faultstring":"The Service is temporarily unavailable",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.ServiceUnavailable"
    }
 }
}

Private Cloud-Nutzer sehen in den Message Processor-Logs /opt/apigee/var/log/edge-message-processor/system.log den folgenden Fehler für die jeweilige API-Anfrage:

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1 bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate

Mögliche Ursachen

Mögliche Ursachen für dieses Problem:

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
Kein Clientzertifikat	Der im Zielendpunkt des Zielservers verwendete Schlüsselspeicher enthält kein Clientzertifikat.	Edge Private und Public Cloud-Nutzer
Fehler bei der Zertifizierungsstelle	Die Zertifizierungsstelle des Blattzertifikats (das erste Zertifikat in der Zertifikatskette) im Schlüsselspeicher des Message Processors stimmt nicht mit einer der vom Backend-Server akzeptierten Zertifizierungsstellen überein.	Edge Private und Public Cloud-Nutzer

Allgemeine Diagnoseschritte

Aktivieren Sie den Trace in der Edge-UI, führen Sie den API-Aufruf aus und reproduzieren Sie das Problem.
Gehen Sie in den UI-Traceergebnissen die einzelnen Phasen durch und ermitteln Sie, wo der Fehler aufgetreten ist. Der Fehler ist im Zielanfrageablauf aufgetreten.
Prüfen Sie den Ablauf, in dem der Fehler angezeigt wird. Sie sollten den Fehler wie im folgenden Beispiel-Trace sehen:
Wie Sie im Screenshot oben sehen, ist error.cause ist "Received fatal alert: bad_certificate".

Wenn Sie ein Private Cloud-Nutzer sind, folgen Sie der Anleitung unten:

Sie können die Nachrichten-ID für die fehlgeschlagene API-Anfrage abrufen, indem Sie den Wert des Fehlerheaders "X-Apigee.Message-ID" in der Phase ermitteln, die im Trace mit AX gekennzeichnet ist.

Suchen Sie in den Message Processor-Logs /opt/apigee/var/log/edge-message-processor/system.log nach dieser Nachrichten-ID und prüfen Sie, ob Sie weitere Informationen zum Fehler finden:

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1
bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate
2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLInfo:
KeyStore:java.security.KeyStore@52de60d9 KeyAlias:KeyAlias TrustStore:java.security.KeyStore@6ec45759
2017-10-23 05:28:57,814 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
RequestWriteListener.onException(HTTPRequest@6071a73d)
javax.net.ssl.SSLException: Received fatal alert: bad_certificate
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800) ~[na:1.8.0_101]
at com.apigee.nio.NIOSelector$SelectedIterator.findNext(NIOSelector.java:496) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:312) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:302) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:59) [nio-1.0.0.jar:na]

Das Message Processor-Log enthielt einen Stacktrace für den Fehler Received fatal alert: bad_certificate, aber es sind keine weiteren Informationen zur Ursache dieses Problems verfügbar.

Um dieses Problem weiter zu untersuchen, müssen Sie TCP/IP-Pakete mit dem Tool „ tcpdump“ erfassen.
1. Wenn Sie ein Private Cloud-Nutzer sind, können Sie die TCP/IP-Pakete auf dem Backend-Server oder Message Processor erfassen. Erfassen Sie sie vorzugsweise auf dem Backend-Server, da die Pakete dort entschlüsselt werden auf dem Backend-Server.
2. Wenn Sie ein Public Cloud-Nutzer sind, erfassen Sie die TCP/IP Pakete auf dem Backend-Server.
3. Nachdem Sie entschieden haben, wo Sie TCP/IP-Pakete erfassen möchten, verwenden Sie den folgenden tcpdump Befehl, um TCP/IP-Pakete zu erfassen.
Analysieren Sie die TCP/IP-Pakete mit dem Tool Wireshark oder einem ähnlichen Tool, mit dem Sie vertraut sind.

Hier ist die Analyse von Beispiel-TCP/IP-Paketdaten mit dem Tool Wireshark:

alt_text

Nachricht 4 im obigen tcpdump zeigt, dass der Message Processor (Quelle) eine Client Hello -Nachricht an den Backend-Server (Ziel) gesendet hat.
Nachricht 5 zeigt, dass der Backend-Server die Client Hello-Nachricht vom Message Processor bestätigt.
Der Backend-Server sendet die Nachricht „Server Hello“ zusammen mit seinem Zertifikat, und fordert dann den Client auf, sein Zertifikat in Nachricht 7 zu senden.
Der Message Processor schließt die Überprüfung des Zertifikats ab und bestätigt die ServerHello-Nachricht des Backend-Servers in Nachricht 8.
Der Message Processor sendet sein Zertifikat in Nachricht 9 an den Backend-Server.
Der Backend-Server bestätigt den Empfang des Zertifikats des Message Processors Zertifikats in Nachricht 11.
Er sendet jedoch sofort eine Fatal Alert: Bad Certificate an den Message Processor (Nachricht 12). Dies weist darauf hin, dass das vom Message Processor gesendete Zertifikat ungültig war und daher die Zertifikatsüberprüfung auf dem Backend-Server fehlgeschlagen ist. Infolgedessen ist der SSL-Handshake fehlgeschlagen und die Verbindung wird geschlossen.
Sehen wir uns nun Nachricht 9 an, um den Inhalt des vom Message Processor gesendeten Zertifikats zu prüfen:
Wie Sie sehen, hat der Backend-Server kein Zertifikat vom Client erhalten (Certificate Length: 0). Daher sendet der Backend-Server die Nachricht „Fatal Alert: Bad Certificate“.
Dies geschieht in der Regel, wenn der Client, d. h. der Message Processor (ein Java-basierter Prozess):
1. Kein Clientzertifikat in seinem Schlüsselspeicher hat oder
2. Kein Clientzertifikat senden kann. Das kann passieren, wenn kein Zertifikat gefunden wird, das von einer der akzeptablen Zertifizierungsstellen des Backend-Servers ausgestellt wurde. Wenn die Zertifizierungsstelle des Blattzertifikats des Clients (d.h. des ersten Zertifikats in der Kette) nicht mit einer der akzeptablen Zertifizierungsstellen des Backend-Servers übereinstimmt, sendet der Message Processor das Zertifikat nicht.

Sehen wir uns jede dieser Ursachen einzeln an.

Ursache: Kein Clientzertifikat

Diagnose

Wenn im Schlüsselspeicher, der im Abschnitt „SSLInfo“ des Zielendpunkts oder des im Zielendpunkt verwendeten Zielservers angegeben ist, kein Zertifikat vorhanden ist, ist dies die Ursache für diesen Fehler.

Führen Sie die folgenden Schritte aus, um zu prüfen, ob dies die Ursache ist:

Ermitteln Sie den im Zielendpunkt oder Zielserver für den jeweiligen API-Proxy verwendeten Schlüsselspeicher. Gehen Sie dazu so vor:
1. Rufen Sie den Namen der Schlüsselspeicherreferenz aus dem Keystore Element in SSLInfo Abschnitt des Zielendpunkts oder Zielservers ab.
  Hier ein Beispiel für einen SSLInfo-Abschnitt in einer Zielendpunktkonfiguration:
```
<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>true</ClientAuthEnabled>
  <KeyStore>ref://myKeystoreRef</KeyStore>
  <KeyAlias>myKey</KeyAlias>
  <TrustStore>ref://myTrustStoreRef</TrustStore>
</SSLInfo>
```
2. Im obigen Beispiel ist der Name der Schlüsselspeicherreferenz "myKeystoreRef".
3. Wählen Sie in der Edge-UI API-Proxys > Umgebungskonfigurationen aus.
  Wählen Sie den Tab Referenzen aus und suchen Sie nach dem Namen der Schlüsselspeicherreferenz. Notieren Sie sich den Namen in der Spalte Referenz für die jeweilige Schlüsselspeicherreferenz. Das ist der Name Ihres Schlüsselspeichers.
4. Im obigen Beispiel sehen Sie, dass myKeystoreRef auf „myKeystore“ verweist . Der Name des Schlüsselspeichers ist also „myKeystore“.
Prüfen Sie, ob dieser Schlüsselspeicher das Zertifikat enthält. Verwenden Sie dazu entweder die Edge-UI oder die API „List certs for keystore“.
Wenn der Schlüsselspeicher Zertifikate enthält, fahren Sie mit Ursache: Fehler bei der Zertifizierungsstelle fort.
Wenn der Schlüsselspeicher kein Zertifikat enthält, ist das der Grund, warum das Clientzertifikat nicht vom Message Processor gesendet wird.

Auflösung

Achten Sie darauf, dass die richtige und vollständige Clientzertifikatskette in den jeweiligen Schlüsselspeicher im Message Processor hochgeladen wird.

Ursache: Fehler bei der Zertifizierungsstelle

Wenn der Server den Client auffordert, sein Zertifikat zu senden, gibt er in der Regel die akzeptierten Aussteller oder Zertifizierungsstellen an. Wenn der Aussteller oder die Zertifizierungsstelle des Blattzertifikats (d.h. des ersten Zertifikats in der Zertifikatskette) im Schlüsselspeicher des Message Processors nicht mit einer der vom Backend-Server akzeptierten Zertifizierungsstellen übereinstimmt, sendet der Message Processor (ein Java-basierter Prozess) das Zertifikat nicht an den Backend-Server.

Führen Sie die folgenden Schritte aus, um zu prüfen, ob dies der Fall ist:

API „List certs for keystore“ verwenden.
Rufen Sie mit der API „Get cert for keystore“ die Details der einzelnen Zertifikate ab, die Sie in Schritt 1 erhalten haben.

Notieren Sie sich den Aussteller des Blattzertifikats (d.h. des ersten Zertifikats in der Zertifikatskette), das im Schlüsselspeicher gespeichert ist.

Beispiel für ein Blattzertifikat

{
  "certInfo" : [ {
    "basicConstraints" : "CA:FALSE",
    "expiryDate" : 1578889324000,
    "isValid" : "Yes",
    "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com",
    "publicKey" : "RSA Public Key, 2048 bits",
    "serialNumber" : "65:00:00:00:d2:3e:12:d8:56:fa:e2:a9:69:00:06:00:00:00:d2",
    "sigAlgName" : "SHA256withRSA",
    "subject" : "CN=nonprod-api.mycompany.com, OU=ITS, O=MyCompany, L=MELBOURNE, ST=VIC, C=AU",
    "subjectAlternativeNames" : [ ],
    "validFrom" : 1484281324000,
    "version" : 3
  } ],
  "certName" : "nonprod-api.mycompany.com.key.pem-cert"
}

Im obigen Beispiel ist der Aussteller oder die Zertifizierungsstelle "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com"

Ermitteln Sie die akzeptierte Liste der Aussteller oder Zertifizierungsstellen des Backend-Servers mit einer der folgenden Methoden:
Verfahren Nr. 1: Verwenden Sie den folgenden openssl-Befehl:
```
openssl s_client -host <backend server host name> -port <Backend port#> -cert <Client Certificate> -key <Client Private Key>
```
Sehen Sie sich im Ergebnis dieses Befehls den Abschnitt "Acceptable Client Certificate CA names" an, wie unten gezeigt:
```
Acceptable client certificate CA names
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
```
Methode 2: Prüfen Sie das Paket Certificate Request in den TCP/IP-Paketen, in dem der Backend-Server den Client auffordert, sein Zertifikat zu senden:

In den oben gezeigten Beispiel-TCP/IP-Paketen ist das Certificate Request Paket Nachricht 7. Sehen Sie sich den Abschnitt „Distinguished Names“ an, der die akzeptablen Zertifizierungsstellen des Backend-Servers enthält.

Hinweis: Die Liste der akzeptablen Zertifizierungsstellen des Backend-Servers wird erstellt, indem die Aussteller aller im Truststore des Backend-Servers gespeicherten Zertifikate hinzugefügt werden.
Prüfen Sie, ob die in Schritt 3 ermittelte Zertifizierungsstelle mit der Liste der akzeptablen Aussteller oder Zertifizierungsstellen des Backend-Servers übereinstimmt, die in Schritt 4 ermittelt wurde. Wenn es eine Abweichung gibt, sendet der Message Processor das Clientzertifikat an den Backend-Server.

Im obigen Beispiel sehen Sie, dass der Aussteller des Blattzertifikats des Clients im Schlüsselspeicher des Message Processors nicht mit einer der akzeptablen Zertifizierungsstellen des Backend-Servers übereinstimmt. Daher sendet der Message Processor das Clientzertifikat nicht an den Backend-Server. Dadurch schlägt der SSL-Handshake fehl und der Backend-Server sendet die Nachricht Fatal alert: bad_certificate.

Auflösung

Achten Sie darauf, dass das Zertifikat mit dem Aussteller oder der Zertifizierungsstelle, die mit dem Aussteller oder der Zertifizierungsstelle des Blattzertifikats des Clients (erstes Zertifikat in der Kette) übereinstimmt, im Truststore des Backend-Servers gespeichert ist.
Im in diesem Playbook beschriebenen Beispiel wurde das Zertifikat mit dem Aussteller "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com" dem Truststore des Backend-Servers hinzugefügt, um das Problem zu beheben.

Wenn das Problem weiterhin besteht, lesen Sie unten den Abschnitt Erfassen von Diagnoseinformationen erforderlich.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, erfassen Sie die folgenden Diagnoseinformationen. Wenden Sie sich an den Apigee Edge-Support und teilen Sie ihm die Informationen mit: Apigee Edge Support:

Wenn Sie ein Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
1. Name der Organisation
2. Umgebungsname
3. Name des API-Proxys
4. Vollständiger curl-Befehl zum Reproduzieren des Fehlers
5. Trace-Datei mit dem Fehler
6. Auf dem Backend-Server erfasste TCP/IP-Pakete
Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
1. Vollständige Fehlermeldung
2. API-Proxy-Bundle
3. Trace-Datei mit dem Fehler
4. Message Processor-Logs /opt/apigee/var/log/edge-message-processor/logs/system.log
5. Auf dem Backend-Server oder Message Processor erfasste TCP/IP-Pakete
6. Ausgabe der API „Get cert for keystore“
Details zu den Abschnitten in diesem Playbook, die Sie ausprobiert haben, und alle anderen Informationen, die uns helfen, das Problem schnell zu beheben.