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

400 Falsche Anfrage – SSL-Zertifikatfehler

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

Symptom

Die Clientanwendung erhält eine HTTP 400-Antwort (Ungültige Anfrage) mit der Meldung "The SSL certificate error". Dieser Fehler wird in der Regel vom Edge-Router in einer bidirektionalen TLS-Einrichtung gesendet, die für die eingehende Verbindung zu Apigee Edge aktiviert ist.

Fehlermeldung

Die Clientanwendung erhält den folgenden Antwortcode:

HTTP/1.1 400 Bad Request

Gefolgt von der folgenden 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 für dieses Problem:

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
Abgelaufenes Clientzertifikat	Das vom Client gesendete Zertifikat ist abgelaufen.	Nutzer von Edge Private und Public Cloud
Falsches Zertifikat vom Client gesendet	Dieser Fehler wird ausgelöst, 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-Root-Zertifikat im Truststore	Dieser Fehler wird ausgelöst, wenn das vom Client signierte Root-Zertifikat der Zertifizierungsstelle im Truststore des Edge-Routers fehlt.	Nutzer von Edge Private und Public Cloud
Clientzertifikate nicht in den Edge-Router geladen	Dieser Fehler wird ausgelöst, wenn die in den Truststore hochgeladenen Clientzertifikate nicht in den Router geladen werden.	Nutzer von Edge Private Cloud

Ursache: Abgelaufenes Clientzertifikat

Dieses Problem tritt in der Regel bei einer bidirektionalen TLS-Verbindung auf, wenn das vom Client gesendete Zertifikat abgelaufen ist. Bei einer bidirektionalen TLS-Verbindung tauschen sowohl Client als auch Server ihre öffentlichen Zertifikate aus, um den Handshake durchzuführen. Der Client validiert das Serverzertifikat und der Server validiert das Clientzertifikat.

In Edge wird die bidirektionale TLS-Verbindung auf virtueller Hostebene implementiert, dabei wird das Serverzertifikat dem Schlüsselspeicher und das Clientzertifikat den Truststores hinzugefügt.

Wenn während des TLS-Handshakes festgestellt wird, dass das Clientzertifikat abgelaufen ist, sendet der Server 400 (Ungültige Anfrage) mit der Meldung "The SSL certificate error".

Diagnose

Melden Sie sich in der Edge-Benutzeroberfläche an und rufen Sie die Konfiguration des virtuellen Hosts (Admin > Virtuelle Hosts) auf, für den die API-Anfrage gestellt wird. Alternativ können Sie die API Virtuellen Host abrufen verwenden, um die Definition des virtuellen Hosts abzurufen.

Ein virtueller Host für die bidirektionale TLS-Kommunikation sieht in der Regel 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>

Bestimmen Sie die Truststore-Referenz, die im virtuellen Host verwendet wird. Im obigen Beispiel lautet der Name der Truststore-Referenz myTruststoreRef.
Bestimmen Sie den Truststore, auf den die Truststore-Referenz verweist.
1. Rufen Sie in der Edge-Benutzeroberfläche Admin > Umgebungen > Verweise auf und suchen Sie nach dem Namen der Truststore-Referenz.
2. Notieren Sie sich den Namen in der Spalte Verweis für die jeweilige Truststore-Referenz. Das ist der Name Ihres Truststore.
  
  Abbildung 1
  
  Im obigen Beispiel verweist myTruststoreRef auf myTruststore. Daher lautet der Name des Truststore myTruststore.
Rufen Sie in der Edge-Benutzeroberfläche Admin > Umgebungen > TLS-Schlüsselspeicher auf und suchen Sie nach dem Truststore, der in Schritt 3 gefunden wurde.
Wählen Sie das Zertifikat unter dem jeweiligen Truststore aus (in Schritt 3 bestimmt), wie unten gezeigt:

Abbildung 2

Das Zertifikat mit dem Alias client-cert-markw im obigen Beispiel ist abgelaufen.
Prüfen Sie, ob das Zertifikat für den Zertifikatsalias Ihres Truststore abgelaufen ist.
Wenn das Zertifikat nicht abgelaufen ist, fahren Sie mit den allgemeinen Diagnoseschritten für die anderen 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 die Truststore-Referenz, die im virtuellen Host verwendet wird, so, dass sie auf den neuen Truststore verweist. Folgen Sie dazu der Anleitung unter Verweis ändern.

Im oben beschriebenen Beispiel verweisen Sie die Referenz myTruststoreRef auf myNewTruststore.

Allgemeine Diagnoseschritte für die anderen Ursachen

Um dieses Problem zu untersuchen, müssen Sie TCP/IP-Pakete mit dem tcpdump Tool erfassen.
1. Wenn Sie Private Cloud-Nutzer sind, können Sie die TCP/IP-Pakete in der Clientanwendung oder im Router erfassen.
2. Wenn Sie Public Cloud-Nutzer 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 im Router erfassen, verwenden Sie die öffentliche IP-Adresse der Clientanwendung im tcpdump Befehl.
  
  Wenn Sie die TCP/IP-Pakete in der Clientanwendung erfassen, verwenden Sie die öffentliche IP Adresse des Hostnamens, der im virtuellen Host verwendet wird, im tcpdump Befehl.
  
  Weitere Informationen zu diesem Tool und zu anderen Varianten dieses Befehls finden Sie unter tcpdump
Analysieren Sie die erfassten TCP/IP-Pakete mit dem Tool „Wireshark“ oder einem ähnlichen Tool, mit dem Sie vertraut sind.

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

Paket 30 im „tcpdump“ (siehe Abbildung 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 und dann sein Zertifikat. Außerdem fordert er die Clientanwendung auf, ihr Zertifikat in Paket 38 zu senden.
Prüfen Sie in Paket 38, in dem der Router das Paket „Certificate Request“ sendet, den Abschnitt „Distinguished Names“. Dort finden Sie Details zum Clientzertifikat, zur Zertifikatskette und zu den Zertifizierungsstellen, die vom Router (Server) akzeptiert werden.

Die Clientanwendung sendet ihr Zertifikat in Paket 41. Prüfen Sie den Certificate Verify Abschnitt in Paket 41 und bestimmen Sie das Zertifikat, das von der Clientanwendung gesendet wird.

Abbildung 4
Prüfen Sie, ob der Betreff und der Aussteller des Zertifikats und der Zertifikatskette, die von der Client anwendung gesendet wurden (Paket 41), mit dem akzeptierten Zertifikat und der Zertifikatskette vom Router (Paket 38) übereinstimmen. Wenn es eine Abweichung gibt, ist dies die Ursache für diesen Fehler. Daher sendet der Router (Server) die verschlüsselte Warnung (Paket 57) gefolgt von FIN, ACK (Paket 58) an die Clientanwendung und schließlich wird die Verbindung beendet.
Die Abweichung des Zertifikats und der Zertifikatskette kann durch die in den folgenden Abschnitten beschriebenen Szenarien verursacht werden.

Ursache: Falsches Zertifikat vom Client gesendet

Dies tritt in der Regel auf, wenn der Betreff/Aussteller des Zertifikats und/oder der Zertifikatskette, die von der Clientanwendung gesendet wurden, nicht mit dem Zertifikat und/oder der Zertifikatskette übereinstimmt, die im Truststore des Routers (Server) gespeichert sind.

Diagnose

Melden Sie sich in der Edge-Benutzeroberfläche an und rufen Sie die Konfiguration des virtuellen Hosts (Admin > Virtuelle Hosts) auf, für den die API-Anfrage gestellt wird. Alternativ können Sie die API „Virtuellen Host abrufen“ verwenden, um die Definition des virtuellen Hosts abzurufen.

Ein virtueller Host für die bidirektionale TLS-Kommunikation sieht in der Regel 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>

Bestimmen Sie die Truststore-Referenz, die im virtuellen Host verwendet wird.
Im obigen Beispiel lautet der Name der Truststore-Referenz myCompanyTruststoreRef.
Bestimmen Sie den Truststore, auf den die Truststore-Referenz verweist.
1. Rufen Sie in der Edge-Benutzeroberfläche Admin > Umgebungen > Verweise auf und suchen Sie nach dem Namen der Truststore-Referenz.
2. Notieren Sie sich den Namen in der Spalte Verweis für die jeweilige Truststore-Referenz. Das ist der Name Ihres Truststore.
  
  Abbildung 5
  
  Im obigen Beispiel verweist myCompanyTruststoreRef auf myCompanyTruststore. Daher lautet der Name des Truststore myCompanyTruststore.
Rufen Sie die im Truststore gespeicherten Zertifikate (im vorherigen Schritt bestimmt) mit den folgenden APIs ab:
1. API „Zertifikate für einen Schlüsselspeicher oder Truststore auflisten“.
  
  Diese API listet alle Zertifikate im jeweiligen Truststore auf.
2. API „Zertifikatsdetails aus einem Schlüsselspeicher oder Truststore abrufen“.
  
  Diese API gibt Informationen zu einem bestimmten Zertifikat im jeweiligen Truststore zurück.
Prüfen Sie, ob der Aussteller und der Betreff jedes Zertifikats und der Zertifikatskette, die in myCompanyTruststore gespeichert sind, mit dem Zertifikat und der Zertifikatskette in den TCP/IP-Paketen (siehe Paket 38 oben) übereinstimmen. Wenn es eine Abweichung gibt, bedeutet das dass die in den Truststore hochgeladenen Zertifikate nicht in den Edge-Router geladen werden. Fahren Sie mit Ursache: Clientzertifikate nicht in den Edge-Router geladen fort.
Wenn in Schritt 5 keine Abweichung gefunden wurde, bedeutet das, dass die Clientanwendung nicht das richtige Zertifikat und die richtige Zertifikatskette gesendet hat.

Auflösung

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

Ursache: Fehlendes Client-Root-Zertifikat im Truststore

Dieser Fehler wird ausgelöst, wenn das vom Client signierte Root-Zertifikat der Zertifizierungsstelle 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 API „Virtuellen Host abrufen“, um die Definition des virtuellen Hosts abzurufen.

Ein virtueller Host für die bidirektionale TLS-Kommunikation sieht in der Regel 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>

Bestimmen Sie die Truststore-Referenz, die im virtuellen Host verwendet wird. Im obigen Beispiel lautet der Name der Truststore-Referenz myCompanyTruststoreRef.
Bestimmen Sie den Truststore, der von der Truststore-Referenz verwendet wird.
Rufen Sie in der Edge-Benutzeroberfläche Admin > Umgebungen > Verweise auf und suchen Sie nach dem Namen der Truststore-Referenz.
Der Name des Truststore für die jeweilige Truststore-Referenz befindet sich in der Verweis Spalte.

Abbildung 6

In diesem Beispiel enthält myCompanyTruststoreRef in der Spalte „Verweis“ myCompanyTruststore. Daher lautet der Name des Truststore ist myCompanyTruststore.
Rufen Sie die im Truststore gespeicherten Zertifikate (im vorherigen Schritt bestimmt) mit den folgenden APIs ab:
1. API „Zertifikate für einen Schlüsselspeicher oder Truststore auflisten“. Diese API listet alle Zertifikate im Truststore auf.
2. API „Zertifikatsdetails aus einem Schlüsselspeicher oder Truststore 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 Root-Zertifikats , das vom jeweiligen Client gesendet wurde (siehe Abbildung 4). Der Truststore muss das Root-Zertifikat sowie das Blattzertifikat des Clients oder das Blatt- und Zwischenzertifikat enthalten. Wenn das gültige Root-Zertifikat des Clients im Truststore fehlt, ist das die Ursache des Fehlers.

Wenn die vollständige Zertifikatskette des Clients einschließlich des Root-Zertifikats im Truststore vorhanden ist, bedeutet das, dass die in den Truststore hochgeladenen Zertifikate möglicherweise nicht in den Edge-Router geladen werden. In diesem Fall lesen Sie Ursache: Clientzertifikate nicht in den Edge-Router geladen.

Auflösung

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

Ursache: Clientzertifikate nicht in den Edge-Router geladen

Wenn Sie Public Cloud-Nutzer sind, wenden Sie sich an den Apigee Edge-Support.
Wenn Sie Private Cloud-Nutzer sind, folgen Sie der Anleitung unten für jeden Router:
1. Prüfen Sie, ob die Datei /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem für den jeweiligen virtuellen Host vorhanden ist. Wenn die Datei nicht vorhanden ist, fahren Sie mit dem Abschnitt „Auflösung“ unten 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 diese nicht mit den Angaben im Truststore in der Edge-Benutzeroberfläche oder mit den Angaben, die mit den Verwaltungs-APIs abgerufen wurden, übereinstimmen, ist das 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. Folgen Sie dazu der Anleitung unten:

apigee-service edge-router restart

Führen Sie die APIs noch einmal aus und prüfen Sie die Ergebnisse. Wenn das Problem weiterhin besteht, lesen Sie den Abschnitt Diagnoseinformationen erfassen.

Diagnoseinformationen erfassen

Wenn das Problem auch nach dem Ausführen der obigen Anleitung weiterhin besteht, erfassen Sie die folgenden Diagnoseinformationen. Wenden Sie sich an den Apigee Edge-Support und teilen Sie ihm die erfassten Informationen mit:

Wenn Sie Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
1. Name der Organisation
2. Umgebungsname
3. Name des API-Proxys
4. Name des virtuellen Hosts
5. Name des Hostalias
6. Vollständiger „curl“-Befehl zum Reproduzieren des Fehlers
7. TCP/IP-Pakete, die in der Clientanwendung erfasst wurden
Wenn Sie Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
1. Name des virtuellen Hosts und seine Definition mit der API „Virtuellen Host abrufen“
2. Name des Hostalias
3. Vollständige Fehlermeldung
4. TCP/IP-Pakete, die in der Clientanwendung oder im Router erfasst wurden
5. Ausgabe der API „Zertifikate aus dem Schlüsselspeicher auflisten“ und Details zu jedem Zertifikat, die mit der API „Zertifikatsdetails abrufen“ abgerufen wurden
Details zu den Abschnitten in diesem Playbook, die Sie ausprobiert haben, und alle anderen Informationen, die uns helfen, das Problem schnell zu beheben