400 Nieprawidłowe żądanie – błąd certyfikatu SSL

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Krótki opis problemu

Aplikacja kliencka otrzymuje odpowiedź HTTP 400 – Nieprawidłowe żądanie z kodem komunikat „Błąd certyfikatu SSL”. Ten błąd jest zwykle wysyłany przez router brzegowy w dwukierunkowej konfiguracji TLS dla połączenia przychodzącego z Apigee Edge.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 400 Bad Request

A następnie poniższa strona błędu HTML:

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

Możliwe przyczyny

Możliwe przyczyny tego problemu:

Przyczyna Opis Instrukcje dotyczące rozwiązywania problemów dotyczące
Wygasł certyfikat klienta Certyfikat wysłany przez klienta stracił ważność. Użytkownicy Edge Private Cloud i użytkownicy chmury publicznej
Nieprawidłowy certyfikat wysłany przez klienta Ten błąd jest zgłaszany, jeśli certyfikat wysłany przez aplikację kliencką nie pasuje z certyfikatem przechowywanym w magazynie zaufania routera Edge. Użytkownicy Edge Private Cloud i użytkownicy chmury publicznej
Brak certyfikatu głównego klienta w Truststore Ten błąd jest zgłaszany, jeśli w magazynu zaufania routera Edge. Użytkownicy Edge Private Cloud i użytkownicy chmury publicznej
Certyfikaty klienta nie zostały wczytane w routerze brzegowym Ten błąd jest zgłaszany, jeśli certyfikaty klienta przesłane do magazynu zaufania nie zostały wczytane w routerze. Użytkownicy Edge Private Cloud

Przyczyna: certyfikat klienta wygasł

Ten problem występuje zwykle w przypadku dwukierunkowego protokołu TLS, gdy certyfikat wysłany przez klienta wygaśnie. W przypadku dwukierunkowej wymiany TLS zarówno klient, jak i serwer ich certyfikaty publiczne w celu uzgadniania połączenia. Klient weryfikuje certyfikat serwera. a serwer weryfikuje certyfikat klienta.

W Edge dwukierunkowe szyfrowanie TLS jest wdrożone na hostze wirtualnym. gdzie certyfikat serwera jest dodawany do magazynu kluczy, a certyfikat klienta – do magazynów zaufania.

Jeśli podczas uzgadniania połączenia TLS okaże się, że certyfikat klienta wygasł, serwer wyśle komunikat 400 – Bad request (Nieprawidłowe żądanie) z komunikatem „Błąd certyfikatu SSL”.

Diagnostyka

  1. Zaloguj się w interfejsie Edge i wyświetl konkretną konfigurację hosta wirtualnego (Administracja > Hosty wirtualne), do których jest wysyłane żądanie do interfejsu API lub użyj interfejsu Get virtual host API Management API, aby uzyskać definicję konkretnego hosta wirtualnego.

    Host wirtualny do dwukierunkowej komunikacji TLS wygląda zwykle tak:

    <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. Określ odwołanie do magazynu zaufania używane na hoście wirtualnym. W tym przykładzie nazwa odniesienia do magazynu zaufania to myTruststoreRef.

  3. Określ magazyn zaufania, do którego wskazywana jest odwołanie do magazynu zaufania.
    1. W interfejsie Edge otwórz Administracja > Środowiska > Przydatne materiały i wyszukaj nazwę referencyjną do magazynu zaufania.

    2. Zanotuj nazwę w kolumnie Plik referencyjny dla konkretnej odwołania do Truststore. To będzie nazwa magazynu zaufania.

      Interfejs Edge z listą referencje
      Rysunek 1

      Zwróć uwagę, że w powyższym przykładzie myTruststoreRef zawiera odwołanie do: myTruststore. W związku z tym nazwa magazynu zaufania to myTruststore.

  4. W sekcji Administracja > Środowiska > Magazyny kluczy TLS w interfejsie Edge, przejdź do protokołu TLS. Magazyny kluczy i odszukaj magazyn Truststore znaleziony w kroku 3.

  5. Wybierz certyfikat w określonej usłudze Truststore (określonej w kroku 3 powyżej), jak pokazano poniżej:

    Rysunek 2

    Certyfikat z aliasem client-cert-markw w powyższym przykładzie wskazuje, że wygasła.

  6. Sprawdź, czy certyfikat dla aliasu certyfikatu magazynu zaufania nie wygasł.
  7. Jeśli certyfikat nie wygasł, przejdź do sekcji Typowe czynności diagnostyczne dotyczące innych przyczyn.

Rozdzielczość

Wygeneruj nowy certyfikat i prześlij certyfikat:

  1. Utwórz nowy magazyn zaufania, na przykład myNewTruststore.
  2. Prześlij nowy certyfikat do nowo utworzonego magazynu zaufania.

  3. Zmodyfikuj odniesienie dotrustore używane w konkretnym hoście wirtualnym, tak aby wskazywało nowy , korzystając z instrukcji podanych w argumencie zaufania Modyfikowanie pliku referencyjnego

    W przykładzie powyżej wskaż odniesienie do myTruststoreRef to myNewTruststore.

Typowe kroki diagnostyki innych przyczyn

  1. Aby zbadać ten problem, musisz przechwycić pakiety TCP/IP za pomocą protokołu Narzędzie tcpdump.
    1. Jeśli jesteś użytkownikiem Private Cloud, możesz przechwytywać pakiety TCP/IP w interfejsie aplikacji klienckiej lub routera.
    2. Jeśli jesteś użytkownikiem Public Cloud, przechwyć pakiety TCP/IP w aplikacji klienckiej.

    3. Gdy wybierzesz już miejsce, w którym chcesz przechwytywać pakiety TCP/IP, użyj tcpdump do przechwytywania pakietów TCP/IP:

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

      Uwaga: jeśli odbierasz pakiety TCP/IP na routerze, użyj publiczny adres IP aplikacji klienckiej w poleceniu tcpdump.

      Jeśli pobierasz pakiety TCP/IP z aplikacji klienckiej, użyj publicznego adresu IP i adresu nazwy hosta używanej w hoście wirtualnym w poleceniu tcpdump.

      Więcej informacji znajdziesz w artykule tcpdump. .

  2. Analizuj pakiety TCP/IP zebrane za pomocą Wireshark lub podobne narzędzie, które już znasz.

Analiza przykładowych danych pakietów TCP/IP za pomocą narzędzia Wireshark:

  1. Pakiet nr 30 w pliku tcpdump (obraz poniżej) pokazuje, że aplikacja kliencka (źródłowa) wysłał komunikat „Client Hello” do routera (miejsca docelowego).
  2. Pakiet 34 pokazuje, że router potwierdził komunikat „Client Hello” z aplikacji klienckiej.
  3. Router wysyła komunikat „Server Hello”. w pakiecie nr 35, a następnie wysyła jego certyfikat oraz żąda od aplikacji klienckiej wysłania certyfikatu w pakiecie nr 38.
  4. W pakiecie 38, gdzie router wysyła pakiet „Certificate Request”, sprawdź „Wyróżniające się nazwy” sekcji zawierającej szczegółowe informacje o certyfikacie klienta, jego łańcuchu oraz urzędy certyfikacji akceptowane przez router (serwer).
    5. Rysunek 3

  5. Aplikacja kliencka wysyła swój certyfikat w pakiecie nr 41. Sprawdź certyfikat Sprawdź sekcję w pakiecie nr 41 i określ certyfikat wysyłany przez aplikację kliencką.

    Rysunek 4
  6. Sprawdź, czy podmiot, wydawca certyfikatu i jego łańcuch wysłane przez klienta aplikacja (pakiet 41) jest zgodna z akceptowanym certyfikatem i jego łańcuchem z routera (pakiet 38). Jeśli coś się nie zgadza, właśnie to jest przyczyną tego błędu. Dlatego router (Serwer) wysyła zaszyfrowany alert (pakiet nr 57), po którym następuje numer FIN, ACK (pakiet 58) do Aplikacja kliencka i w końcu połączenie zostaje zakończone.
  7. Niezgodność certyfikatu i jego łańcucha może być spowodowana przez scenariusze opisane w w następujących sekcjach.

Przyczyna: nieprawidłowy certyfikat wysłany przez klienta

Zwykle dzieje się tak, gdy podmiot/wystawca certyfikatu lub jego łańcucha wysłanego przez aplikacja kliencka nie pasuje do certyfikatu lub jego łańcucha zapisanego w magazynie zaufania routera (serwera).

Diagnostyka

  1. Zaloguj się w interfejsie Edge i wyświetl konkretną konfigurację hosta wirtualnego (Administracja > Hosty wirtualne), do których jest wysyłane żądanie do interfejsu API lub użyj interfejsu Get virtual host API. Management API, aby uzyskać definicję konkretnego hosta wirtualnego.

    Host wirtualny do dwukierunkowej komunikacji TLS wygląda zwykle tak:

        <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. Określ odwołanie do magazynu zaufania używane na hoście wirtualnym.

    W powyższym przykładzie nazwa referencyjna Truststore to myCompanyTruststoreRef.

  3. Określ magazyn zaufania wskazywany przez odwołanie do magazynu zaufania.
    1. W interfejsie Edge otwórz Administracja > Odniesienia do środowisk i wyszukaj nazwę referencyjną do magazynu zaufania.

    2. Zanotuj nazwę w kolumnie Plik referencyjny dla konkretnej odwołania do Truststore. To będzie nazwa magazynu zaufania.

      Widok interfejsu Edge z odwołaniami do magazynu zaufania.
      Rysunek 5

      Zwróć uwagę, że w powyższym przykładzie myCompanyTruststoreRef zawiera wartość odniesienie do magazynu danych myCompanyTruststore. W związku z tym nazwa magazynu zaufania to myCompanyTruststore.

  4. Pobierz certyfikaty zapisane w Truststore (określone w poprzednim kroku) przy użyciu tych interfejsów API:

    1. Wyświetlanie listy certyfikatów dla magazynu kluczy lub interfejsu Truststore API

      Ten interfejs API zawiera listę wszystkich certyfikatów w określonym Truststore.

    2. Uzyskiwanie szczegółów certyfikatu z magazynu kluczy lub interfejsu Truststore API

      Ten interfejs API zwraca informacje o konkretnym certyfikacie w konkretnym Truststore.

  5. Sprawdź, czy wydawca i podmiot każdego certyfikatu i jego łańcucha są przechowywane w myCompanyTruststore jest zgodny z certyfikatem i jego łańcuchem jako widoczne w pakietach TCP/IP (patrz pakiet nr 38) powyżej. Jeśli występuje niezgodność, oznacza to, że certyfikaty przesłane do magazynu zaufania nie są wczytywane w routerze brzegowym. Przejdź do sekcji Przyczyna: certyfikaty klienta nie zostały wczytane w routerze brzegowym.
  6. Jeśli w kroku 5 nie znaleziono niezgodności, oznacza to, że aplikacja kliencka ją znalazła. nie wysyła odpowiedniego certyfikatu i jego łańcucha.

Rozdzielczość

Sprawdź, czy aplikacja kliencka wysyła do Edge odpowiedni certyfikat i jego łańcuch.

Przyczyna: brak głównego certyfikatu klienta w Truststore

Ten błąd jest zgłaszany, jeśli w magazynu zaufania routera Edge.

Diagnostyka

  1. Zaloguj się w interfejsie Edge i wyświetl konkretną konfigurację hosta wirtualnego, dla której interfejs API (Administracja > Hosty wirtualne > virtual_host) lub skorzystaj z . Pobierz interfejs API hosta wirtualnego, aby uzyskać definicję konkretnego hosta wirtualnego.

    Host wirtualny do dwukierunkowej komunikacji TLS wygląda zwykle tak:

        <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. Określ odwołanie do magazynu zaufania używanego na hoście wirtualnym. W poprzednim przykładzie nazwa odniesienia do magazynu zaufania to myCompanyTruststoreRef.
  3. Określ rzeczywisty magazyn zaufania używany przez odwołanie do magazynu zaufania.
  4. W interfejsie Edge wybierz Admin > (Administrator >). Środowiska > Pliki referencyjne i wyszukiwanie dla nazwy referencyjnej magazynu zaufania.

  5. Nazwa magazynu zaufania dla konkretnego odwołania do magazynu zaufania znajduje się w sekcji kolumnę Odwołanie.

    Rysunek 6

    Zwróć uwagę, że w tym przykładzie myCompanyTruststoreRef myCompanyTruststore w kolumnie Odwołanie. Dlatego magazyn zaufania nazywam się myCompanyTruststore.

  6. Pobierz certyfikaty zapisane w magazynie zaufania (określone w poprzednim kroku) za pomocą tych interfejsów API:
    1. Wyświetl listę certyfikatów dla magazynu kluczy lub interfejsu API Truststore Ten interfejs API zawiera listę wszystkich w magazynie zaufania.
    2. Pobierz szczegóły certyfikatu z magazynu kluczy lub interfejsu Truststore API Ten interfejs API zwraca informacje o konkretny certyfikat w magazynie zaufania.

  7. Sprawdź, czy certyfikat zawiera pełny łańcuch, w tym certyfikat główny wysyłane przez konkretnego klienta, tak jak w pakietach TCP/IP (zobacz ilustrację 4). Magazyn zaufania musi zawierać certyfikat główny, a także certyfikat lub liść klienta; certyfikatu pośredniego. Jeśli w magazynie zaufania brakuje prawidłowego certyfikatu głównego klienta, to właśnie on jest przyczyną błędu.

    Jeśli jednak kompletny łańcuch certyfikatów klienta, w tym certyfikat główny, istnieje w magazynie zaufania, oznacza to, że certyfikaty przesłane do magazyn zaufania prawdopodobnie nie został wczytany w routerze brzegowym. W takim przypadku zapoznaj się z artykułem Przyczyna: certyfikaty klienta nie zostały załadowane do routera brzegowego.

Rozdzielczość

Sprawdź, czy jest dostępny właściwy certyfikat klienta, w tym certyfikat główny w magazynie zaufania routera Apigee Edge.

Przyczyna: certyfikaty klienta nie zostały załadowane w routerze brzegowym

  1. Jeśli korzystasz z Public Cloud, skontaktuj się z zespołem pomocy Apigee Edge.
  2. Jeśli jesteś użytkownikiem Private Cloud, na każdym routerze wykonaj te czynności:
    1. Sprawdź, czy plik /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem istnieje dla konkretnego hosta wirtualnego. Jeśli plik nie istnieje, przejdź do Rozwiązanie poniżej.
    2. Jeśli plik istnieje, użyj poniższego polecenia openssl, aby pobrać szczegóły certyfikaty dostępne w routerze Edge: 
      openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
    3. Sprawdź wystawcę, podmiot i datę ważności certyfikatu. Jeśli któryś z tych elementów nie jest zgodny z żadnym z tych elementów z danymi zaobserwowanymi w Truststore w interfejsie Edge lub za pomocą interfejsów API do zarządzania. przyczyny błędu.
    4. Możliwe, że router nie załadował ponownie przesłanych certyfikatów.

Rozdzielczość

Ponownie uruchom router, aby sprawdzić, czy najnowsze certyfikaty zostały załadowane, wykonując czynności opisane poniżej:

apigee-service edge-router restart

Ponownie uruchom interfejsy API i sprawdź wyniki. Jeśli problem będzie się powtarzał, otwórz Gromadzenie informacji diagnostycznych.

Zbieranie informacji diagnostycznych

Jeśli po wykonaniu powyższych czynności problem nie ustąpi, zbierz poniższe informacje diagnostyczne. Skontaktuj się z zespołem pomocy Apigee Edge i udostępnij mu zgromadzone informacje:

  1. Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:
    1. Nazwa organizacji
    2. Nazwa środowiska
    3. Nazwa serwera proxy interfejsu API
    4. Nazwa hosta wirtualnego
    5. Nazwa aliasu hosta
    6. Wykonaj polecenie curl, aby odtworzyć błąd
    7. Pakiety TCP/IP przechwycone przez aplikację kliencką
  2. Jeśli jesteś użytkownikiem Private Cloud, podaj te informacje:
    1. Nazwa hosta wirtualnego i jej definicja za pomocą interfejsu Get virtual host API (Pobierz interfejs API hosta wirtualnego).
    2. Nazwa aliasu hosta
    3. Zaobserwowano pełny komunikat o błędzie
    4. Pakiety TCP/IP przechwycone przez aplikację kliencką lub router.
    5. Dane wyjściowe: Wyświetl listę certyfikatów z interfejsu API magazynu kluczy interfejsu API oraz szczegóły każdego certyfikatu uzyskanego za pomocą interfejsu Get cert details API.
  3. szczegółowe informacje o wypróbowanych sekcjach tego Poradnika oraz o innych statystykach, które pomóc nam w szybkim rozwiązaniu tego problemu.