Die Clientanwendung empfängt die Antwort HTTP 400 - Bad request mit dem Fehler
"Der SSL-Zertifikatfehler" wird angezeigt. Dieser Fehler wird normalerweise vom Edge Router gesendet
in einer Zwei-Wege-TLS-Einrichtung, die für die eingehende Verbindung zu Apigee Edge aktiviert ist.
Fehlermeldung
Die Clientanwendung ruft den folgenden Antwortcode ab:
Dieser Fehler wird ausgegeben, wenn das von der Clientanwendung gesendete Zertifikat nicht übereinstimmt
mit dem Zertifikat, das im Truststore des Edge Routers gespeichert ist.
Dieser Fehler wird ausgegeben, wenn die in den Truststore hochgeladenen Clientzertifikate nicht geladen werden
auf dem Router.
Edge Private Cloud-Nutzer
Ursache: Abgelaufenes Clientzertifikat
Dieses Problem tritt normalerweise bei einem zweifachen TLS auf,
Das vom Client gesendete Zertifikat ist abgelaufen. Bei 2-Wege-TLS tauschen Client und Server
ihre öffentlichen Zertifikate,
um den Handshake durchzuführen. Der Client validiert das Serverzertifikat.
und der Server validiert das Clientzertifikat.
In Edge ist 2-Wege-TLS auf dem virtuellen Host implementiert,
Dabei wird das Serverzertifikat dem Schlüsselspeicher und das Clientzertifikat Truststores hinzugefügt.
Wenn während des TLS-Handshakes festgestellt wird, dass das Clientzertifikat abgelaufen ist, hat der Server
Es wird 400 - Bad request mit der Meldung The SSL certificate error gesendet.
Diagnose
Bei der Edge-Benutzeroberfläche anmelden und die spezifische Konfiguration des virtuellen Hosts anzeigen
(Admin > Virtuelle Hosts), für die die API-Anfrage durchgeführt wird.
oder Get Virtual Host API verwenden
Management API abrufen, um die Definition des jeweiligen virtuellen Hosts zu erhalten.
Ein virtueller Host für die Zwei-Wege-TLS-Kommunikation sieht normalerweise so aus:
Beachten Sie im obigen Beispiel, dass myTruststoreRef die Referenz enthält.
an myTruststore. Daher lautet der Truststore-Name myTruststore.
Klicken Sie auf Verwaltung > Umgebungen > TLS-Schlüsselspeicher in der Edge-Benutzeroberfläche, gehen Sie zu TLS.
Schlüsselspeicher und suchen Sie nach dem Truststore aus Schritt 3.
Wählen Sie das Zertifikat im Truststore aus (oben in Schritt 3 ermittelt), wie unten gezeigt:
Hinweis: Wenn Sie die TCP/IP-Pakete auf dem Router übertragen, verwenden Sie die Methode
öffentliche IP-Adresse der Clientanwendung im Befehl tcpdump.
Wenn Sie die TCP/IP-Pakete auf der Clientanwendung übernehmen, verwenden Sie die öffentliche IP-Adresse
Adresse des Hostnamens, der im virtuellen Host im Befehl tcpdump verwendet wird.
Weitere Informationen finden Sie unter tcpdump.
finden Sie weitere Informationen zu diesem Tool und anderen Varianten dieses Befehls.
Analysieren Sie die gesammelten TCP/IP-Pakete mithilfe der
Wireshark-Tool oder ein ähnliches Tool, mit dem Sie vertraut sind.
Hier sehen Sie die Analyse von TCP/IP-Beispieldaten mit dem Wireshark-Tool:
Paket 30 in „tcpdump“ (Bild unten) zeigt, dass die Clientanwendung (Quelle)
hat eine "Client Hello"-Nachricht gesendet. an den Router (Ziel).
Paket 34 zeigt, dass der Router die Client Hello-Nachricht von der Clientanwendung bestätigt.
Der Router sendet die Nachricht "Server Hello" und sendet dann sein Zertifikat.
fordert die Clientanwendung auf, ihr Zertifikat im Paket 38 zu senden.
Prüfen Sie im Paket 38, bei dem der Router das Paket "Certificate Request" sendet,
„ Distinguished Names“ (Distinguished Names) mit Details zum Clientzertifikat, seiner Kette
und Zertifizierungsstellen, die vom Router (Server) akzeptiert werden.
Die Clientanwendung sendet ihr Zertifikat im Paket 41. Prüfen Sie das Zertifikat
Überprüfen im Paket Nr. 41 und ermitteln Sie das von der Clientanwendung gesendete Zertifikat.
Prüfen, ob Subjekt und Aussteller des Zertifikats und seiner Kette vom Client gesendet wurden
Anwendung (Paket Nr. 41) stimmt mit dem akzeptierten Zertifikat und seiner Kette vom Router überein.
(Paket 38). Wenn es eine Diskrepanz gibt, ist dies die Ursache für diesen Fehler. Daher ist der Router
(Server) sendet die verschlüsselte Warnung (Paket 57) gefolgt von FIN und ACK (Paket 58) an den
Clientanwendung und schließlich wird die Verbindung beendet.
Eine Diskrepanz zwischen dem Zertifikat und seiner Kette kann folgende Ursachen haben:
in den folgenden Abschnitten.
Ursache: Falsches Zertifikat vom Client gesendet
Dies geschieht in der Regel, wenn der Antragsteller/Aussteller des Zertifikats und/oder seiner Kette vom
Clientanwendung stimmt nicht mit dem Zertifikat und/oder seiner Kette im Truststore des Routers (Servers) überein.
Diagnose
Bei der Edge-Benutzeroberfläche anmelden und die spezifische Konfiguration des virtuellen Hosts anzeigen
(Admin > Virtuelle Hosts), für die die API-Anfrage durchgeführt wird.
oder die Get Virtual Host API verwenden
Management API abrufen, um die Definition des jeweiligen virtuellen Hosts zu erhalten.
Ein virtueller Host für die Zwei-Wege-TLS-Kommunikation sieht normalerweise so aus:
Beachten Sie im Beispiel oben, dass für myCompanyTruststoreRef der Parameter
Referenz zu myCompanyTruststore. Daher lautet der Truststore-Name „myCompanyTruststore“.
Rufen Sie die im Truststore gespeicherten Zertifikate (im vorherigen Schritt ermittelt) mithilfe der folgenden APIs ab:
<ph type="x-smartling-placeholder"></ph>
Diese API gibt Informationen zu einem bestimmten Zertifikat im jeweiligen Truststore zurück.
Prüfen Sie, ob der Aussteller und das Subjekt jedes Zertifikats und seiner Kette in
myCompanyTruststore stimmt mit dem des Zertifikats und seiner Kette als
wie in den TCP/IP-Paketen (siehe Paket Nr. 38) oben zu sehen. Bei einer Abweichung bedeutet das,
dass die in den Truststore hochgeladenen Zertifikate nicht in den Edge Router geladen werden.
Gehen Sie zu Ursache: Clientzertifikate nicht im Edge Router geladen.
Wenn in Schritt 5 keine Abweichung gefunden wurde, bedeutet dies, dass die Clientanwendung
nicht das richtige Zertifikat und seine Kette senden.
Auflösung
Stellen Sie sicher, dass das richtige Zertifikat und seine Kette von der Clientanwendung an Edge gesendet werden.
Ursache: Fehlendes Root-Zertifikat im Truststore
Dieser Fehler wird ausgegeben, wenn das signierte Root-Zertifikat der Zertifizierungsstelle des Clients im
Truststore des Edge-Routers.
Diagnose
Melden Sie sich bei der Edge-Benutzeroberfläche an und sehen Sie sich die spezifische virtuelle Hostkonfiguration an, für die die API
Anfrage wird gestellt (Verwaltung > Virtuelle Hosts > virtual_host)
oder verwenden Sie die
<ph type="x-smartling-placeholder"></ph>
Rufen Sie die Virtual Host API ab, um die Definition des spezifischen virtuellen Hosts zu erhalten.
Ein virtueller Host für die Zwei-Wege-TLS-Kommunikation sieht normalerweise so aus:
Ermitteln Sie die auf dem virtuellen Host verwendete Truststore-Referenz. Im vorherigen Beispiel
Der Truststore-Referenzname lautet myCompanyTruststoreRef.
Ermitteln Sie den tatsächlichen Truststore, der von der Truststore-Referenz verwendet wird.
Navigieren Sie in der Edge-Benutzeroberfläche zu Admin > Umgebungen > Quellenangaben und Suche
für den Truststore-Referenznamen.
Der Truststore-Name für die spezifische Truststore-Referenz befindet sich in der
Spalte Referenz:
Beachten Sie in diesem Beispiel, dass für myCompanyTruststoreRef der Wert
myCompanyTruststore in der Referenzspalte. Daher enthält der Truststore
Der Name lautet myCompanyTruststore.
Rufen Sie die im Truststore gespeicherten Zertifikate (im vorherigen Schritt ermittelt) mithilfe von
die folgenden APIs:
<ph type="x-smartling-placeholder"></ph>
Prüfen, ob das Zertifikat eine vollständige Kette einschließlich des Root-Zertifikats enthält
wie in den TCP/IP-Paketen dargestellt (siehe Abbildung 4). Der Truststore
muss sowohl das Stammzertifikat als auch das untergeordnete oder untergeordnete Zertifikat des Clients enthalten.
Zwischenzertifikat. Wenn das gültige Root-Zertifikat des Clients im Truststore fehlt,
ist das die Ursache des Fehlers.
Ist jedoch die gesamte Zertifikatskette des Clients, einschließlich des Root-Zertifikats,
im Truststore vorhanden ist, bedeutet dies, dass die in den
möglicherweise nicht im Edge Router geladen. In diesem Fall lesen Sie
Ursache: Clientzertifikate wurden nicht im Edge Router geladen.
Auflösung
Achten Sie darauf, dass das richtige Clientzertifikat, einschließlich des Root-Zertifikats, verfügbar ist
im Truststore des Apigee Edge-Routers.
Ursache: Clientzertifikate wurden nicht im Edge Router geladen
Wenn Sie ein Nutzer von Public Cloud sind, wenden Sie sich an den Apigee Edge-Support.
Wenn Sie ein Private Cloud-Nutzer sind, folgen Sie auf jedem Router die folgende Anleitung:
<ph type="x-smartling-placeholder"></ph>
Prüfen Sie, ob die Datei /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem existiert
für den jeweiligen virtuellen Host. Falls die Datei nicht vorhanden ist, wechseln Sie zum
Lösung weiter unten.
Wenn die Datei vorhanden ist, verwenden Sie den unten stehenden openssl-Befehl, um die Details des
Zertifikate, die auf dem Edge Router verfügbar sind:
Prüfen Sie den Aussteller, den Inhaber und das Ablaufdatum des Zertifikats. Wenn einer dieser Werte nicht übereinstimmt
mit dem, was im Truststore in der Edge-Benutzeroberfläche oder bei Verwendung der Verwaltungs-APIs beobachtet wurde, ist das
die Ursache des Fehlers.
Möglicherweise hat der Router die hochgeladenen Zertifikate nicht neu geladen.
Auflösung
Starten Sie den Router neu, um sicherzustellen, dass die neuesten Zertifikate geladen werden. Gehen Sie dazu so vor:
apigee-service edge-router restart
Führen Sie die APIs noch einmal aus und prüfen Sie die Ergebnisse. Wenn das Problem weiterhin besteht, gehe zu
Erheben Sie Diagnoseinformationen.
Diagnoseinformationen einholen
Wenn das Problem trotz Befolgen der obigen Anweisungen weiterhin besteht, holen Sie die folgenden Diagnoseinformationen zusammen.
Wenden Sie sich an den Apigee Edge-Support und geben Sie die erfassten Informationen weiter:
Wenn Sie ein Nutzer der öffentlichen Cloud sind, geben Sie die folgenden Informationen an:
<ph type="x-smartling-placeholder"></ph>
Name der Organisation
Name der Umgebung
API-Proxy-Name
Virtueller Hostname
Name des Host-Alias
Führen Sie den curl-Befehl aus, um den Fehler zu reproduzieren.
In der Clientanwendung erfasste TCP/IP-Pakete
Wenn Sie ein Nutzer der Private Cloud sind, geben Sie die folgenden Informationen an:
<ph type="x-smartling-placeholder"></ph>
Details dazu, welche Abschnitte in diesem Playbook du ausprobiert hast und welche weiteren Informationen dir wichtig sind
helfen Sie uns bei der schnellen Lösung dieses Problems.