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

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Krótki opis problemu

Aplikacja kliencka otrzymuje odpowiedź HTTP 400 – Nieprawidłowe żądanie z komunikatem "The SSL certificate error" (Błąd certyfikatu SSL). Ten błąd jest zwykle wysyłany przez router Edge w konfiguracji TLS dwukierunkowego włączonej dla połączenia przychodzącego z Apigee Edge.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 400 Bad Request

Następnie wyświetla się ta 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 rozwiązywania problemów, których dotyczy
Certyfikat klienta wygasł Certyfikat wysłany przez klienta wygasł. Użytkownicy chmury prywatnej i publicznej Edge
Klient wysłał nieprawidłowy certyfikat Ten błąd jest zgłaszany, jeśli certyfikat wysłany przez aplikację kliencką nie jest zgodny z certyfikatem przechowywanym w magazynie zaufanych certyfikatów routera Edge. Użytkownicy chmury prywatnej i publicznej Edge
Brak głównego certyfikatu klienta w magazynie zaufanych certyfikatów Ten błąd występuje, jeśli w magazynie zaufania routera Edge brakuje głównego certyfikatu podpisanego przez urząd certyfikacji klienta. Użytkownicy chmury prywatnej i publicznej Edge
Certyfikaty klienta nie zostały wczytane do routera Edge Ten błąd jest zgłaszany, jeśli certyfikaty klienta przesłane do magazynu zaufanych certyfikatów nie zostały wczytane do routera. Użytkownicy chmury prywatnej Edge

Przyczyna: certyfikat klienta wygasł

Ten problem zwykle występuje w przypadku TLS dwukierunkowego, gdy certyfikat wysłany przez klienta wygasł. W przypadku TLS dwukierunkowego klient i serwer wymieniają się certyfikatami publicznymi, aby przeprowadzić uzgadnianie. Klient weryfikuje certyfikat serwera a serwer weryfikuje certyfikat klienta.

W Edge TLS dwukierunkowy jest implementowany na hoście wirtualnym, gdzie certyfikat serwera jest dodawany do magazynu kluczy, a certyfikat klienta jest dodawany do magazynów zaufania.

Jeśli podczas uzgadniania TLS okaże się, że certyfikat klienta wygasł, serwer wyśle odpowiedź 400 – Nieprawidłowe żądanie z komunikatem "The SSL certificate error".

Diagnostyka

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

    Host wirtualny do komunikacji TLS dwukierunkowej zwykle wygląda 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 odniesienie do magazynu zaufanych certyfikatów używane w hoście wirtualnym. W powyższym przykładzie, nazwa odniesienia do magazynu zaufanych certyfikatów to myTruststoreRef.

  3. Określ magazyn zaufanych certyfikatów, na który wskazuje odniesienie do magazynu zaufanych certyfikatów.
    1. W interfejsie Edge otwórz Administracja > Środowiska > Odniesienia i wyszukaj nazwę odniesienia do magazynu zaufania.

    2. Zanotuj nazwę w kolumnie Odniesienie dla konkretnego odniesienia do magazynu zaufania. Będzie to nazwa magazynu zaufania.

      Interfejs Edge z listą odwołań.
      Rysunek 1.

      W powyższym przykładzie widać, że myTruststoreRef odwołuje się do myTruststore. Dlatego nazwa magazynu zaufania to myTruststore.

  4. W interfejsie Edge otwórz Administracja > Środowiska > Magazyny kluczy protokołu TLS i poszukaj magazynu zaufanych certyfikatów znalezionego w kroku 3.

  5. Wybierz certyfikat w konkretnym magazynie zaufania (określonym w kroku 3 powyżej), jak pokazano poniżej:

    Rysunek 2.

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

  6. Sprawdź, czy certyfikat wygasł w przypadku aliasu certyfikatu w magazynie zaufanych certyfikatów.
  7. Jeśli certyfikat nie wygasł, przejdź do typowe czynności diagnostyczne w przypadku innych przyczyn.

Rozdzielczość

Uzyskaj nowy certyfikat i prześlij go:

  1. Utwórz nowy magazyn zaufania, np. myNewTruststore.
  2. Prześlij nowy certyfikat do nowo utworzonego magazynu zaufania.

  3. Zmień odniesienie do magazynu zaufanych certyfikatów używane w konkretnym hoście wirtualnym, aby wskazywało na nowy magazyn zaufanych certyfikatów, wykonując czynności opisane w sekcji Zmienianie odniesienia.

    W opisanym powyżej przykładzie odniesienie myTruststoreRef powinno wskazywać na myNewTruststore.

Typowe czynności diagnostyczne w przypadku innych przyczyn

  1. Aby zbadać ten problem, musisz przechwycić pakiety TCP/IP za pomocą narzędzia tcpdump.
    1. Jeśli jesteś użytkownikiem chmury prywatnej, możesz przechwytywać pakiety TCP/IP w aplikacji klienckiej lub routerze.
    2. Jeśli jesteś użytkownikiem chmury publicznej, przechwytuj pakiety TCP/IP w aplikacji klienckiej.

    3. Gdy zdecydujesz, gdzie chcesz przechwytywać pakiety TCP/IP, użyj tego tcpdump polecenia, aby je przechwycić:

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

      Uwaga: jeśli przechwytujesz pakiety TCP/IP w routerze, użyj publicznego adresu IP aplikacji klienckiej w poleceniu tcpdump.

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

      Więcej informacji o tym narzędziu i innych wariantach tego polecenia znajdziesz w dokumentacji tcpdump.

  2. Przeanalizuj pakiety TCP/IP zebrane za pomocą narzędzia Wireshark lub podobnego narzędzia, które znasz.

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

  1. Pakiet nr 30 w tcpdump (obraz poniżej) pokazuje, że aplikacja kliencka (źródło) wysłała „Client Hello” do routera (miejsce docelowe).
  2. Pakiet nr 34 pokazuje, że router potwierdza wiadomość Client Hello z aplikacji klienckiej.
  3. Router wysyła "Server Hello" w pakiecie nr 35, a następnie wysyła swój certyfikat i także prosi aplikację kliencką o wysłanie swojego certyfikatu w pakiecie nr 38.
  4. W pakiecie nr 38, w którym router wysyła „Certificate Request” pakiet, sprawdź sekcję „Distinguished Names”, która zawiera szczegóły dotyczące certyfikatu klienta, jego łańcucha i urzędów certyfikacji akceptowanych przez router (serwer).
    5. Rysunek 3.

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

    Rysunek 4.
  6. Sprawdź, czy podmiot i wystawca certyfikatu oraz jego łańcucha wysłanego przez aplikację kliencką (pakiet nr 41) są zgodne z akceptowanym certyfikatem i jego łańcuchem z routera (pakiet nr 38). Jeśli występuje niezgodność, jest to przyczyna tego błędu. Dlatego router (serwer) wysyła zaszyfrowany alert (pakiet nr 57), a następnie FIN, ACK (pakiet nr 58) do aplikacji klienckiej i ostatecznie połączenie zostaje zakończone.
  7. Niezgodność certyfikatu i jego łańcucha może być spowodowana scenariuszami opisanymi w kolejnych sekcjach.

Przyczyna: klient wysłał nieprawidłowy certyfikat

Zwykle dzieje się tak, jeśli podmiot lub wystawca certyfikatu lub jego łańcucha wysłanego przez aplikację kliencką nie jest zgodny z certyfikatem lub jego łańcuchem przechowywanym w magazynie zaufanych certyfikatów routera (serwera).

Diagnostyka

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

    Host wirtualny do komunikacji TLS dwukierunkowej zwykle wygląda 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 odniesienie do magazynu zaufanych certyfikatów używane w hoście wirtualnym.

    W powyższym przykładzie nazwa odniesienia do magazynu zaufanych certyfikatów to myCompanyTruststoreRef.

  3. Określ magazyn zaufanych certyfikatów, na który wskazuje odniesienie do magazynu zaufanych certyfikatów.
    1. W interfejsie Edge otwórz Administracja > Środowiska > Odniesienia i wyszukaj nazwę odniesienia do magazynu zaufanych certyfikatów.

    2. Zanotuj nazwę w kolumnie Odniesienie dla konkretnego odniesienia do magazynu zaufania. Będzie to nazwa magazynu zaufania.

      Interfejs Edge pokazujący odwołanie do magazynu zaufanych certyfikatów.
      Rysunek 5.

      W powyższym przykładzie widać, że myCompanyTruststoreRef odwołuje się do myCompanyTruststore. Dlatego nazwa magazynu zaufania to myCompanyTruststore.

  4. Pobierz certyfikaty przechowywane w magazynie zaufanych certyfikatów (określonym w poprzednim kroku) za pomocą tych interfejsów API:

    1. List certificates for a keystore or truststore API.

      Ten interfejs API wyświetla listę wszystkich certyfikatów w konkretnym magazynie zaufanych certyfikatów.

    2. Get cert details from a keystore or truststore API.

      Ten interfejs API zwraca informacje o konkretnym certyfikacie w konkretnym magazynie zaufania.

  5. Sprawdź, czy wystawca i podmiot każdego certyfikatu oraz jego łańcucha przechowywanego w myCompanyTruststore są zgodne z certyfikatem i jego łańcuchem widocznym 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 do routera Edge. Przejdź do sekcji Przyczyna: certyfikaty klienta nie zostały wczytane do routera Edge.
  6. Jeśli w kroku 5 nie znaleziono niezgodności, oznacza to, że aplikacja kliencka nie wysłała prawidłowego certyfikatu i jego łańcucha.

Rozdzielczość

Upewnij się, że aplikacja kliencka wysyła do Edge prawidłowy certyfikat i jego łańcuch.

Przyczyna: w magazynie zaufanych certyfikatów brakuje głównego certyfikatu klienta

Ten błąd występuje, jeśli w magazynie zaufania routera Edge brakuje głównego certyfikatu podpisanego przez urząd certyfikacji klienta.

Diagnostyka

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

    Host wirtualny do komunikacji TLS dwukierunkowej zwykle wygląda 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 odniesienie do magazynu zaufanych certyfikatów używane w hoście wirtualnym. W poprzednim przykładzie, nazwa odniesienia do magazynu zaufania to myCompanyTruststoreRef.
  3. Określ rzeczywisty magazyn zaufanych certyfikatów używany przez odniesienie do magazynu zaufanych certyfikatów.
  4. W interfejsie Edge otwórz Administracja > Środowiska > Odniesienia i wyszukaj nazwę odniesienia do magazynu zaufanych certyfikatów.

  5. Nazwa magazynu zaufanych certyfikatów dla konkretnego odniesienia do magazynu zaufanych certyfikatów znajduje się w kolumnie Odniesienie.

    Rysunek 6.

    W tym przykładzie widać, że myCompanyTruststoreRef ma myCompanyTruststore w kolumnie Odniesienie. Dlatego nazwa magazynu zaufanych certyfikatów to myCompanyTruststore.

  6. Pobierz certyfikaty przechowywane w magazynie zaufanych certyfikatów (określonym w poprzednim kroku) za pomocą tych interfejsów API:
    1. List certificates for a keystore or truststore API. Ten interfejs API wyświetla listę wszystkich certyfikatów w magazynie zaufanych certyfikatów.
    2. Get cert details from a keystore or truststore API. Ten interfejs API zwraca informacje o konkretnym certyfikacie w magazynie zaufania.

  7. Sprawdź, czy certyfikat zawiera pełny łańcuch, w tym główny certyfikat wysłany przez konkretnego klienta, jak widać w pakietach TCP/IP (patrz Rysunek 4). Magazyn zaufania musi zawierać główny certyfikat oraz certyfikat liścia klienta lub certyfikat liścia i certyfikat pośredni. Jeśli w magazynie zaufanych certyfikatów brakuje prawidłowego certyfikatu głównego klienta, jest to przyczyna błędu.

    Jeśli jednak w magazynie zaufanych certyfikatów znajduje się pełny łańcuch certyfikatów klienta, w tym certyfikat główny, oznacza to, że certyfikaty przesłane do magazynu zaufanych certyfikatów prawdopodobnie nie zostały wczytane do routera Edge. W takim przypadku przeczytaj sekcję Przyczyna: certyfikaty klienta nie zostały wczytane do routera Edge.

Rozdzielczość

Upewnij się, że w magazynie zaufanych certyfikatów routera Apigee Edge znajduje się prawidłowy certyfikat klienta, w tym certyfikat główny.

Przyczyna: certyfikaty klienta nie zostały wczytane do routera Edge

  1. Jeśli jesteś użytkownikiem chmury publicznej, skontaktuj się z zespołem pomocy Apigee Edge.
  2. Jeśli jesteś użytkownikiem chmury prywatnej, wykonaj te instrukcje na każdym routerze:
    1. Sprawdź, czy dla konkretnego hosta wirtualnego istnieje plik /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem. Jeśli plik nie istnieje, przejdź do sekcji Rozwiązanie poniżej.
    2. Jeśli plik istnieje, użyj tego polecenia openssl, aby uzyskać szczegóły certyfikatów dostępnych 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órykolwiek z tych elementów nie jest zgodny z tym, co zaobserwowano w magazynie zaufanych certyfikatów w interfejsie Edge lub za pomocą interfejsów API zarządzania, jest to przyczyna błędu.
    4. Możliwe, że router nie przeładował przesłanych certyfikatów.

Rozdzielczość

Uruchom ponownie router, aby mieć pewność, że najnowsze certyfikaty zostały wczytane, wykonując ten krok:

apigee-service edge-router restart

Ponownie uruchom interfejsy API i sprawdź wyniki. Jeśli problem nadal występuje, przejdź do sekcji Zbieranie informacji diagnostycznych.

Zbieranie informacji diagnostycznych

Jeśli problem nadal występuje po wykonaniu powyższych instrukcji, zbierz te informacje diagnostyczne. Skontaktuj się z zespołem pomocy Apigee Edge i udostępnij mu zebrane informacje:

  1. Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:
    1. Nazwa organizacji
    2. Nazwa środowiska
    3. Nazwa proxy interfejsu API
    4. Nazwa hosta wirtualnego
    5. Nazwa aliasu hosta
    6. Pełne polecenie curl do odtworzenia błędu
    7. Pakiety TCP/IP przechwycone w aplikacji klienckiej
  2. Jeśli jesteś użytkownikiem chmury prywatnej, podaj te informacje:
    1. Nazwa hosta wirtualnego i jego definicja za pomocą interfejsu API Get virtual host
    2. Nazwa aliasu hosta
    3. Pełny komunikat o błędzie
    4. Pakiety TCP/IP przechwycone w aplikacji klienckiej lub routerze.
    5. Dane wyjściowe interfejsu API List the certificates from the keystore API oraz szczegóły każdego certyfikatu uzyskane za pomocą interfejsu API Get cert details API.
  3. Szczegóły dotyczące sekcji tego przewodnika, które zostały przez Ciebie wypróbowane, oraz wszelkie inne informacje, które pomogą nam przyspieszyć rozwiązanie tego problemu.