400 Falsche Anfrage – SSL-Zertifikatfehler

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

Symptom

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:

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

Das kann folgende Ursachen haben:

Ursache Beschreibung Geltende Anleitung zur Fehlerbehebung
Abgelaufenes Clientzertifikat Das vom Client gesendete Zertifikat ist abgelaufen. Private und öffentliche Edge-Cloud-Nutzer
Falsches vom Client gesendetes Zertifikat Dieser Fehler wird ausgegeben, wenn das von der Clientanwendung gesendete Zertifikat nicht übereinstimmt mit dem Zertifikat, das im Truststore des Edge Routers gespeichert ist. Private und öffentliche Edge-Cloud-Nutzer
Fehlendes Client-Root-Zertifikat im Truststore Dieser Fehler wird ausgegeben, wenn das signierte Root-Zertifikat der Zertifizierungsstelle des Clients im Truststore des Edge-Routers. Private und öffentliche Edge-Cloud-Nutzer
Clientzertifikate nicht im Edge Router geladen 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

  1. 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:

    <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>

  2. Ermitteln Sie die im virtuellen Host verwendete Truststore-Referenz. Im obigen Beispiel Der Name der Truststore-Referenz lautet myTruststoreRef.

  3. Ermitteln Sie den Truststore, auf den die Truststore-Referenz verweist.
    1. Navigieren Sie in der Edge-Benutzeroberfläche zu Admin > 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.

      <ph type="x-smartling-placeholder">
      </ph> Die Edge-Benutzeroberfläche mit einer Liste von Referenzen
      Abbildung 1

      Beachten Sie im obigen Beispiel, dass myTruststoreRef die Referenz enthält. an myTruststore. Daher lautet der Truststore-Name myTruststore.

  4. 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.

  5. Wählen Sie das Zertifikat im Truststore aus (oben in Schritt 3 ermittelt), wie unten gezeigt:

    <ph type="x-smartling-placeholder">
    </ph>
    Abbildung 2

    Das Zertifikat mit dem Alias client-cert-markw im obigen Beispiel zeigt, dass es abgelaufen.

  6. Prüfen Sie, ob das Zertifikat für den Zertifikatsalias Ihres Truststore abgelaufen ist.
  7. Wenn das Zertifikat noch nicht abgelaufen ist, fahren Sie mit den häufigen Diagnoseschritten für die anderen Ursachen fort.

Auflösung

Beschaffen Sie sich ein neues Zertifikat und laden Sie es hoch:

  1. Erstellen Sie einen neuen Truststore, z. B. myNewTruststore.
  2. Laden Sie das neue Zertifikat in den neu erstellten Truststore hoch.

  3. Ändern Sie die im jeweiligen virtuellen Host verwendete Trustore-Referenz so, dass sie auf den neuen mithilfe der im Abschnitt Referenz ändern

    Verweisen Sie im oben beschriebenen Beispiel auf die Referenz myTruststoreRef auf myNewTruststore.

Häufige Diagnoseschritte für andere Ursachen

  1. Um dieses Problem zu untersuchen, müssen Sie TCP/IP-Pakete mit der Methode tcpdump.
    1. Als Private Cloud-Nutzer können Sie die TCP/IP-Pakete auf der Clientanwendung oder Router.
    2. Wenn Sie Public Cloud-Nutzer sind, erfassen Sie die TCP/IP-Pakete in der Clientanwendung.

    3. Sobald Sie sich entschieden haben, wo Sie TCP/IP-Pakete erfassen möchten, verwenden Sie tcpdump zum Erfassen von TCP/IP-Paketen verwenden:

      tcpdump -i any -s 0 host <IP address> -w <File name>

      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.

  2. 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:

  1. Paket 30 in „tcpdump“ (Bild unten) zeigt, dass die Clientanwendung (Quelle) hat eine "Client Hello"-Nachricht gesendet. an den Router (Ziel).
  2. Paket 34 zeigt, dass der Router die Client Hello-Nachricht von der Clientanwendung bestätigt.
  3. Der Router sendet die Nachricht "Server Hello" und sendet dann sein Zertifikat. fordert die Clientanwendung auf, ihr Zertifikat im Paket 38 zu senden.
  4. 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.
    5. <ph type="x-smartling-placeholder">
    </ph>
    Abbildung 3

  5. 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.

    <ph type="x-smartling-placeholder">
    </ph>
    Abbildung 4
  6. 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.
  7. 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

  1. 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:

        <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>
  2. Ermitteln Sie die im virtuellen Host verwendete Truststore-Referenz.

    Im obigen Beispiel lautet der Truststore-Referenzname myCompanyTruststoreRef.

  3. Ermitteln Sie den Truststore, auf den die Truststore-Referenz verweist.
    1. Navigieren Sie in der Edge-Benutzeroberfläche zu Admin > Referenzen zu Umgebungen 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.

      <ph type="x-smartling-placeholder">
      </ph> Edge-Benutzeroberfläche mit Truststore-Referenz.
      Abbildung 5

      Beachten Sie im Beispiel oben, dass für myCompanyTruststoreRef der Parameter Referenz zu myCompanyTruststore. Daher lautet der Truststore-Name „myCompanyTruststore“.

  4. Rufen Sie die im Truststore gespeicherten Zertifikate (im vorherigen Schritt ermittelt) mithilfe der folgenden APIs ab: <ph type="x-smartling-placeholder">
      </ph>

    1. Zertifikate für einen Schlüsselspeicher 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.

  5. 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.
  6. 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

  1. 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:

        <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>
  2. Ermitteln Sie die auf dem virtuellen Host verwendete Truststore-Referenz. Im vorherigen Beispiel Der Truststore-Referenzname lautet myCompanyTruststoreRef.
  3. Ermitteln Sie den tatsächlichen Truststore, der von der Truststore-Referenz verwendet wird.
  4. Navigieren Sie in der Edge-Benutzeroberfläche zu Admin > Umgebungen > Quellenangaben und Suche für den Truststore-Referenznamen.

  5. Der Truststore-Name für die spezifische Truststore-Referenz befindet sich in der Spalte Referenz:

    <ph type="x-smartling-placeholder">
    </ph>
    Abbildung 6

    Beachten Sie in diesem Beispiel, dass für myCompanyTruststoreRef der Wert myCompanyTruststore in der Referenzspalte. Daher enthält der Truststore Der Name lautet myCompanyTruststore.

  6. Rufen Sie die im Truststore gespeicherten Zertifikate (im vorherigen Schritt ermittelt) mithilfe von die folgenden APIs: <ph type="x-smartling-placeholder">
      </ph>
    1. <ph type="x-smartling-placeholder"></ph> Zertifikate für einen Schlüsselspeicher oder eine Truststore API auflisten Diese API listet alle Zertifikate im Truststore.
    2. <ph type="x-smartling-placeholder"></ph> Zertifikatdetails aus einem Schlüsselspeicher oder einer Truststore API abrufen Diese API gibt Informationen über ein bestimmtes Zertifikat im Truststore.

  7. 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

  1. Wenn Sie ein Nutzer von Public Cloud sind, wenden Sie sich an den Apigee Edge-Support.
  2. Wenn Sie ein Private Cloud-Nutzer sind, folgen Sie auf jedem Router die folgende Anleitung: <ph type="x-smartling-placeholder">
      </ph>
    1. 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.
    2. 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: 
      openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
    3. 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.
    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, 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:

  1. Wenn Sie ein Nutzer der öffentlichen Cloud sind, geben Sie die folgenden Informationen an: <ph type="x-smartling-placeholder">
      </ph>
    1. Name der Organisation
    2. Name der Umgebung
    3. API-Proxy-Name
    4. Virtueller Hostname
    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
  2. Wenn Sie ein Nutzer der Private Cloud sind, geben Sie die folgenden Informationen an: <ph type="x-smartling-placeholder">
      </ph>
    1. Name des virtuellen Hosts und seine Definition mit Get virtual host API
    2. Name des Host-Alias
    3. Vollständige Fehlermeldung beobachtet
    4. TCP/IP-Pakete, die in der Clientanwendung oder dem Router erfasst wurden
    5. Ausgabe von Zertifikate aus der Keystore API auflisten API sowie die Details der einzelnen Zertifikate, die Sie über die Get cert details API erhalten haben.
  3. 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.