Diese Seite wurde von der Cloud Translation API übersetzt.

400 Falsche Anfrage – SSL-Zertifikatfehler

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

Symptom

Die Clientanwendung erhält eine Antwort HTTP 400 - Bad request mit der Meldung "The SSL certificate error". Dieser Fehler wird vom Edge Router in der Regel in zwei Richtungen gesendet, die TLS für die eingehende Verbindung zu Apigee Edge aktiviert haben.

Fehlermeldung

Die Clientanwendung erhält den folgenden Antwortcode:

HTTP/1.1 400 Bad Request

Darauf folgt die folgende HTML-Fehlerseite:

<html>
  <head>
    <title>400 The SSL certificate error</title>
  </head>
  <body bgcolor="white">
    <center> <h1>400 Bad Request</h1>
    </center>
    <center>The SSL certificate error</center>
    <hr>
    <center>nginx</center>
  </body>
</html>

Mögliche Ursachen

Mögliche Ursachen:

Ursache	Beschreibung	Gilt für die Anleitung zur Fehlerbehebung
Abgelaufenes Clientzertifikat	Das vom Client gesendete Zertifikat ist abgelaufen.	Nutzer von Edge Private und Public Cloud
Falsches Zertifikat vom Client gesendet	Dieser Fehler wird ausgegeben, wenn das von der Clientanwendung gesendete Zertifikat nicht mit dem im Truststore des Edge-Routers gespeicherten Zertifikat übereinstimmt.	Nutzer von Edge Private und Public Cloud
Fehlendes Client-Stammzertifikat in Truststore	Dieser Fehler wird ausgegeben, wenn das von der Zertifizierungsstelle signierte Root-Zertifikat im Truststore des Edge-Routers fehlt.	Nutzer von Edge Private und Public Cloud
Clientzertifikate nicht in den Edge Router geladen	Dieser Fehler wird ausgegeben, wenn die in den Truststore hochgeladenen Clientzertifikate nicht auf den Router geladen werden.	Edge Private Cloud-Nutzer

Ursache: Abgelaufenes Clientzertifikat

Dieses Problem tritt normalerweise bei 2-Wege-TLS auf, wenn das vom Client gesendete Zertifikat abgelaufen ist. Bei einem 2-Wege-TLS tauschen sowohl der Client als auch der Server ihre öffentlichen Zertifikate aus, um den Handshake auszuführen. Der Client validiert das Serverzertifikat und der Server das Clientzertifikat.

In Edge wird 2-Wege-TLS auf dem virtuellen Host implementiert. Dabei wird das Serverzertifikat dem Schlüsselspeicher und das Clientzertifikat zu Truststores hinzugefügt.

Wenn während des TLS-Handshakes festgestellt wird, dass das Clientzertifikat abgelaufen ist, sendet der Server die Anfrage 400 - Bad request mit der Meldung The SSL certificate error.

Diagnose

Melden Sie sich bei der Edge-Benutzeroberfläche an und rufen Sie die Konfiguration des virtuellen Hosts auf (Verwaltung > Virtuelle Hosts), für die die API-Anfrage gestellt wird, oder verwenden Sie die Verwaltungs-API Get virtual host API, um die Definition des spezifischen virtuellen Hosts abzurufen.

In der Regel sieht ein virtueller Host für die Zwei-Wege-TLS-Kommunikation so aus:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>api.myCompany.com</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <TrustStore>ref://myTruststoreRef</TrustStore>
    </SSLInfo>
</VirtualHost>

Ermitteln Sie die Truststore-Referenz, die im virtuellen Host verwendet wird. Im obigen Beispiel lautet der Truststore-Referenzname myTruststoreRef.
Bestimmen Sie den Truststore, auf den die Truststore-Referenz verweist.
1. Gehen Sie in der Edge-Benutzeroberfläche zu Verwaltung > Umgebungen > Referenzen und suchen Sie nach dem Truststore-Referenznamen.
2. Notieren Sie sich den Namen in der Spalte Referenz für die spezifische Truststore-Referenz. Dies ist Ihr Truststore-Name.
  
  Abbildung 1
  
  Beachten Sie im obigen Beispiel, dass myTruststoreRef auf myTruststore verweist. Daher lautet der Truststore-Name myTruststore.
Gehen Sie in der Edge-Benutzeroberfläche unter Admin > Environments > TLS Keystores (Verwaltung > Umgebungen > TLS-Schlüsselspeicher) zu TLS-Schlüsselspeichern und suchen Sie nach dem Truststore in Schritt 3.
Wählen Sie wie in Schritt 3 oben das Zertifikat unter dem jeweiligen Truststore aus:

Abbildung 2

Das Zertifikat mit dem Alias client-cert-markw im obigen Beispiel zeigt an, dass es abgelaufen ist.
Prüfen Sie, ob das Zertifikat für den Zertifikatalias für Ihren Truststore abgelaufen ist.
Wenn das Zertifikat nicht abgelaufen ist, fahren Sie mit Häufige Diagnoseschritte für andere Ursachen fort.

Auflösung

Beschaffen Sie ein neues Zertifikat und laden Sie es hoch:

Erstellen Sie einen neuen Truststore, z. B. myNewTruststore.
Laden Sie das neue Zertifikat in den neu erstellten Truststore hoch.
Ändern Sie den Trustore-Verweis, der im jeweiligen virtuellen Host verwendet wird, so, dass er auf den neuen Truststore verweist. Folgen Sie dazu den Schritten unter Referenz ändern.

Verweisen Sie im oben beschriebenen Beispiel den Verweis myTruststoreRef auf myNewTruststore.

Häufige Diagnoseschritte für andere Ursachen

Zur Untersuchung dieses Problems müssen Sie TCP/IP-Pakete mit dem Tool tcpdump erfassen.
1. Wenn Sie die Private Cloud nutzen, können Sie die TCP/IP-Pakete auf der Clientanwendung oder dem Router erfassen.
2. Wenn Sie ein Nutzer der öffentlichen Cloud sind, erfassen Sie die TCP/IP-Pakete in der Clientanwendung.
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:
```
tcpdump -i any -s 0 host <IP address> -w <File name>
```
  Hinweis: Wenn Sie die TCP/IP-Pakete auf dem Router abrufen, verwenden Sie die öffentliche IP-Adresse der Clientanwendung im Befehl tcpdump.
  
  Wenn Sie die TCP/IP-Pakete auf der Clientanwendung abrufen, verwenden Sie die öffentliche IP-Adresse des Hostnamens, der im virtuellen Host verwendet wird, im Befehl tcpdump.
  
  Weitere Informationen zu diesem Tool und anderen Varianten dieses Befehls finden Sie unter tcpdump.
Analysieren Sie die erfassten TCP/IP-Pakete mit dem Wireshark-Tool oder einem anderen Ihnen bekannten Tool.

Hier ist die Analyse von Beispieldaten von TCP/IP-Paketen mit dem Wireshark-Tool:

Paket 30 im tcpdump (Bild unten) zeigt, dass die Clientanwendung (Quelle) eine "Client Hello"-Nachricht an den Router (Ziel) gesendet hat.
Paket 34 zeigt, dass der Router die Client-Hello-Nachricht von der Clientanwendung bestätigt.
Der Router sendet die „Server Hello“-Nachricht in Paket 35, sendet dann sein Zertifikat und fordert die Clientanwendung auf, dieses im Paket 38 zu senden.
Prüfen Sie im Paket 38, an das der Router das Paket "Certificate Request" sendet, den Abschnitt "Distinguished Names". Dieser enthält Details zum Clientzertifikat, zu seiner Kette und zu den Zertifizierungsstellen, die vom Router (Server) akzeptiert werden.

Die Clientanwendung sendet ihr Zertifikat in Paket 41. Prüfen Sie den Abschnitt Zertifikatsüberprüfung in Paket 41 und ermitteln Sie das Zertifikat, das von der Clientanwendung gesendet wird.

Abbildung 4
Prüfen Sie, ob der Subjekt und der Aussteller des Zertifikats und seiner von der Clientanwendung (Paket 41) gesendeten Kette mit dem akzeptierten Zertifikat und seiner Kette vom Router (Paket 38) übereinstimmen. Wenn eine Abweichung vorliegt, ist das die Ursache für den Fehler. Daher sendet der Router (Server) die verschlüsselte Benachrichtigung (Paket 57), gefolgt von FIN, ACK (Paket 58) an die Clientanwendung und wird schließlich beendet.
Die Abweichung zwischen Zertifikat und Kette kann durch die in den folgenden Abschnitten beschriebenen Szenarien verursacht werden.

Ursache: Falsches Zertifikat vom Client gesendet

Dies geschieht in der Regel, wenn der Betreff/Aussteller des Zertifikats und/oder seiner Kette, die von der Clientanwendung gesendet wurde, nicht mit dem Zertifikat und/oder der Kette übereinstimmt, die im Truststore des Routers (Servers) gespeichert ist.

Diagnose

Melden Sie sich in der Edge-Benutzeroberfläche an und rufen Sie die Konfiguration des virtuellen Hosts auf (Verwaltung > Virtuelle Hosts), für die die API-Anfrage gestellt wird, oder verwenden Sie die Verwaltungs-API Get virtual host API, um die Definition des spezifischen virtuellen Hosts abzurufen.

In der Regel sieht ein virtueller Host für die Zwei-Wege-TLS-Kommunikation so aus:

    <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
                <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>

Ermitteln Sie die Truststore-Referenz, die im virtuellen Host verwendet wird.
Im Beispiel oben lautet der Truststore-Referenzname myCompanyTruststoreRef.
Bestimmen Sie den Truststore, auf den die Truststore-Referenz verweist.
1. Gehen Sie in der Edge-Benutzeroberfläche zu Verwaltung > Umgebungsreferenzen und suchen Sie nach dem Truststore-Referenznamen.
2. Notieren Sie sich den Namen in der Spalte Referenz für die spezifische Truststore-Referenz. Dies ist Ihr Truststore-Name.
  
  Abbildung 5
  
  Beachten Sie im obigen Beispiel, dass myCompanyTruststoreRef einen Verweis auf myCompanyTruststore hat. Der Truststore-Name lautet daher „myCompanyTruststore“.
Rufen Sie die im Truststore gespeicherten Zertifikate (im vorherigen Schritt ermittelt) mit den folgenden APIs ab:
1. Zertifikate für einen Keystore oder eine Truststore API auflisten
  
  Diese API listet alle Zertifikate im jeweiligen Truststore auf.
2. Zertifikatdetails aus einem Schlüsselspeicher oder einer Truststore API abrufen
  
  Diese API gibt Informationen zu einem bestimmten Zertifikat im jeweiligen Truststore zurück.
Prüfen Sie, ob Aussteller und Betreff jedes Zertifikats und seiner in myCompanyTruststore gespeicherten Kette mit denen des Zertifikats und seiner Kette übereinstimmen, wie in den TCP/IP-Paketen (siehe Paket 38) oben dargestellt. Wenn eine Abweichung vorliegt, weist dies darauf hin, dass die in den Truststore hochgeladenen Zertifikate nicht in den Edge Router geladen werden. Gehen Sie zu Ursache: Clientzertifikate nicht in den Edge Router geladen.
Wenn in Schritt 5 keine Diskrepanz gefunden wurde, weist dies darauf hin, dass die Clientanwendung nicht das richtige Zertifikat und seine Kette gesendet hat.

Auflösung

Achten Sie darauf, dass das richtige Zertifikat und seine Kette von der Clientanwendung an Edge gesendet werden.

Ursache: Root-Zertifikat des Clients fehlt im Truststore

Dieser Fehler wird ausgegeben, wenn das von der Zertifizierungsstelle signierte Root-Zertifikat im Truststore des Edge-Routers fehlt.

Diagnose

Melden Sie sich in der Edge-Benutzeroberfläche an und rufen Sie die Konfiguration des virtuellen Hosts auf, für den die API-Anfrage gestellt wird (Admin > Virtuelle Hosts > virtual_host) oder verwenden Sie die Get virtual host API, um die Definition des spezifischen virtuellen Hosts abzurufen.

In der Regel sieht ein virtueller Host für die Zwei-Wege-TLS-Kommunikation so aus:

    <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
            <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>

Ermitteln Sie die Truststore-Referenz, die im virtuellen Host verwendet wird. Im vorherigen Beispiel lautet der Truststore-Referenzname myCompanyTruststoreRef.
Bestimmen Sie den tatsächlichen Truststore, der von der Truststore-Referenz verwendet wird.
Gehen Sie in der Edge-Benutzeroberfläche zu Verwaltung > Umgebungen > Referenzen und suchen Sie nach dem Truststore-Referenznamen.
Der Truststore-Name für den jeweiligen Truststore-Verweis befindet sich in der Spalte Referenz.

Abbildung 6

In diesem Beispiel ist für myCompanyTruststoreRef in der Spalte "Referenz" myCompanyTruststore angegeben. Der Truststore-Name lautet daher myCompanyTruststore.
Rufen Sie die im vorherigen Schritt im Truststore gespeicherten Zertifikate mit den folgenden APIs ab:
1. Zertifikate für einen Keystore oder eine Truststore API auflisten. Diese API listet alle Zertifikate im Truststore auf.
2. Zertifikatdetails aus einem Schlüsselspeicher oder einer Truststore API abrufen Diese API gibt Informationen zu einem bestimmten Zertifikat im Truststore zurück.
Prüfen Sie, ob das Zertifikat eine vollständige Kette enthält, einschließlich des vom jeweiligen Client gesendeten Root-Zertifikats in den TCP/IP-Paketen (siehe Abbildung 4). Der Truststore muss das Root-Zertifikat sowie das untergeordnete Zertifikat des Clients bzw. das untergeordnete und Zwischenzertifikat enthalten. Wenn im Truststore das gültige Root-Zertifikat des Clients fehlt, ist dies die Ursache des Fehlers.

Wenn jedoch die vollständige Zertifikatskette des Clients, einschließlich des Root-Zertifikats, im Truststore vorhanden ist, weist dies darauf hin, dass die in den Truststore hochgeladenen Zertifikate möglicherweise nicht in den Edge Router geladen wurden. Wenn dies der Fall ist, lesen Sie die Informationen unter Ursache: Clientzertifikate nicht in den Edge Router geladen.

Auflösung

Achten Sie darauf, dass das richtige Clientzertifikat, einschließlich Root-Zertifikat, im Truststore des Apigee Edge-Routers verfügbar ist.

Ursache: Clientzertifikate nicht in den Edge Router geladen

Wenn Sie die öffentliche Cloud nutzen, wenden Sie sich an den Apigee Edge-Support.
Wenn Sie die Private Cloud nutzen, folgen Sie der Anleitung für jeden Router:
1. Prüfen Sie, ob die Datei /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem für den bestimmten virtuellen Host vorhanden ist. Wenn die Datei nicht vorhanden ist, fahren Sie unten mit dem Abschnitt Lösung fort.
2. Wenn die Datei vorhanden ist, verwenden Sie den folgenden openssl-Befehl, um die Details der Zertifikate abzurufen, die auf dem Edge Router verfügbar sind:
```
openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
```
3. Prüfen Sie den Aussteller, den Betreff und das Ablaufdatum des Zertifikats. Wenn eine dieser Angaben nicht mit dem übereinstimmt, was im Truststore in der Edge-Benutzeroberfläche oder bei der Verwendung der Verwaltungs-APIs beobachtet wurde, ist dies die Ursache des Fehlers.
4. 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, gehen Sie zu Diagnoseinformationen erfassen.

Diagnosedaten erfassen

Wenn das Problem trotz Befolgen der obigen Anweisungen weiterhin besteht, stellen Sie die folgenden Diagnoseinformationen zusammen. Wenden Sie sich an den Apigee Edge-Support und geben Sie die erhobenen Informationen frei:

Wenn Sie Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
1. Name der Organisation
2. Name der Umgebung
3. API-Proxy-Name
4. Name des virtuellen Hosts
5. Name des Host-Alias
6. Führen Sie den curl-Befehl aus, um den Fehler zu reproduzieren
7. In der Clientanwendung erfasste TCP/IP-Pakete
Wenn Sie die private Cloud nutzen, geben Sie die folgenden Informationen an:
1. Name des virtuellen Hostnamens und seine Definition mit Get virtual host API
2. Name des Host-Alias
3. Vollständige Fehlermeldung angezeigt
4. TCP/IP-Pakete, die von der Clientanwendung oder dem Router erfasst wurden.
5. Ausgabe von Zertifikate aus der Keystore API auflisten sowie die Details aller Zertifikate, die mit der Get cert details API abgerufen wurden.
Details zu den Abschnitten in diesem Playbook, die du ausprobiert hast, und zu anderen Informationen, die uns helfen könnten, dieses Problem schnell zu lösen.