Nieudane uzgadnianie połączenia TLS/SSL

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Krótki opis problemu

Błąd uzgadniania połączenia TLS/SSL występuje, gdy klient i serwer nie mogą nawiązać komunikacji z użyciem protokołu TLS/SSL. Gdy ten błąd wystąpi w Apigee Edge, aplikacja kliencka otrzyma stan HTTP 503 z komunikatem Service Niedostępne (Usługa niedostępna). Ten błąd występuje po każdym wywołaniu interfejsu API, w którym wystąpił błąd uzgadniania połączenia TLS/SSL.

Komunikaty o błędach

HTTP/1.1 503 Service Unavailable

Ten komunikat o błędzie możesz też zobaczyć w przypadku wystąpienia błędu uzgadniania połączenia TLS/SSL:

Received fatal alert: handshake_failure

Możliwe przyczyny

TLS (Transport Layer Security, którego poprzednikiem jest SSL) to standardowa technologia zabezpieczeń do ustanowienia zaszyfrowanego połączenia między serwerem WWW a klientem internetowym, takim jak przeglądarka lub aplikacja. Uzgadnianie połączenia to proces, który umożliwia klientowi i serwerowi TLS/SSL ustanowienie zestawu tajnych kluczy, z którymi mogą się komunikować. Podczas tego procesu klient i serwer:

  1. Uzgodnij wersję protokołu, której chcesz używać.
  2. Wybierz algorytm kryptograficzny, którego chcesz używać.
  3. Uwierzytelniaj się, wymieniając i weryfikując certyfikaty cyfrowe.

Jeśli uzgadnianie połączenia TLS/SSL zakończy się powodzeniem, klient TLS/SSL i serwer będą bezpiecznie przesyłać dane między sobą. W przeciwnym razie, jeśli wystąpi błąd uzgadniania połączenia TLS/SSL, połączenie zostanie zakończone, a klient otrzyma błąd 503 Service Unavailable.

Możliwe przyczyny niepowodzeń uzgadniania połączenia TLS/SSL:

Przyczyna Opis Kto może rozwiązywać problemy
Niezgodność protokołu Protokół używany przez klienta nie jest obsługiwany przez serwer. Użytkownicy chmury prywatnej i publicznej
Niezgodność pakietu Cipher Suite Zestaw mechanizmów szyfrowania używany przez klienta nie jest obsługiwany przez serwer. Użytkownicy chmury prywatnej i publicznej
Nieprawidłowy certyfikat Nazwa hosta w adresie URL używanym przez klienta nie jest zgodna z nazwą hosta w certyfikacie zapisanym po stronie serwera. Użytkownicy chmury prywatnej i publicznej
Po stronie klienta lub serwera przechowywany jest niepełny lub nieprawidłowy łańcuch certyfikatów. Użytkownicy chmury prywatnej i publicznej
Klient wysyła nieprawidłowy lub nieważny certyfikat na serwer lub z serwera do klienta. Użytkownicy chmury prywatnej i publicznej
Serwer z włączoną usługą SNI Serwer backendu ma włączoną opcję SNI, ale klient nie może komunikować się z serwerami SNI. Tylko użytkownicy Private Cloud

Niezgodność protokołu

Niepowodzenie uzgadniania połączenia TLS/SSL występuje, jeśli protokół używany przez klienta nie jest obsługiwany przez serwer na połączeniu przychodzącym (granicznym północnym) lub wychodzącym (południowym). Zapoznaj się też z informacjami o połączeniach w kierunku północnym i południowym.

Diagnostyka

  1. Sprawdź, czy błąd wystąpił w połączeniu północnym czy southbound. Więcej wskazówek, które pomogą Ci w określeniu tego problemu, znajdziesz w artykule Ustalanie źródła problemu.
  2. Uruchom narzędzie tcpdump, aby zebrać więcej informacji:
    • Jeśli jesteś użytkownikiem Private Cloud, możesz zbierać dane tcpdump u odpowiedniego klienta lub serwera. Klientem może być aplikacja klienta (w przypadku połączeń przychodzących lub kierowanych na północ) albo procesor wiadomości (w przypadku połączeń wychodzących lub południowych). Serwerem może być router brzegowy (dla połączeń przychodzących lub kierowanych na północ) lub serwer backendu (dla połączeń wychodzących lub południowych) w zależności od tego, jak określono w kroku 1.
    • Jeśli jesteś użytkownikiem chmury publicznej, możesz zbierać dane tcpdump tylko w aplikacji klienckiej (w przypadku połączeń przychodzących lub kierowanych na północ) albo na serwerze backendu (na potrzeby połączeń wychodzących lub południowych), ponieważ nie masz dostępu do routera brzegowego ani procesora wiadomości.
    tcpdump -i any -s 0 host IP address -w File name
    Aby dowiedzieć się więcej o korzystaniu z polecenia tcpdump, zapoznaj się z danymi tcpdump.
  3. Przeanalizuj dane tcpdump za pomocą narzędzia Wireshark lub podobnego.
  4. Oto przykładowa analiza narzędzia tcpdump z użyciem Wiresharka:
    • W tym przykładzie wystąpił błąd uzgadniania połączenia TLS/SSL między procesorem wiadomości a serwerem backendu (połączeniem wychodzącym lub południowym).
    • Komunikat 4 w danych wyjściowych tcpdump poniżej oznacza, że podmiot przetwarzający wiadomości (źródło) wysłał komunikat „Client Hello” do serwera backendu (miejsce docelowe).

    • Jeśli wybierzesz komunikat Client Hello, będzie on oznaczał, że procesor wiadomości używa protokołu TLSv1.2, jak pokazano poniżej:

    • Komunikat 5 pokazuje, że serwer backendu przyjmuje wiadomość „Cześć klienta” od procesora wiadomości.
    • Serwer backendu natychmiast wysyła alert krytyczny : Zamknij powiadomienie do podmiotu przetwarzającego wiadomości (komunikat nr 6). Oznacza to, że uzgadnianie połączenia TLS/SSL nie powiodło się i połączenie zostanie zamknięte.

    • Zgłębienie wiadomości nr 6 wskazuje, że przyczyną błędu uzgadniania połączenia TLS/SSL jest to, że serwer backendu obsługuje tylko protokół TLSv1.0, jak pokazano poniżej:

    • Ponieważ występuje niezgodność między protokołem używanym przez procesor wiadomości a serwerem backendu, serwer backendu wysłał komunikat Komunikat alertu o błędzie: Zamknij powiadomienie.

Rozdzielczość

Procesor wiadomości działa w Javie 8 i domyślnie używa protokołu TLSv1.2. Jeśli serwer backendu nie obsługuje protokołu TLSv1.2, możesz rozwiązać ten problem, wykonując jedną z tych czynności:

  1. Uaktualnij serwer backendu, aby obsługiwał protokół TLSv1.2. Jest to zalecane rozwiązanie, ponieważ protokół TLSv1.2 jest bezpieczniejszy.
  2. Jeśli z jakiegoś powodu nie możesz od razu uaktualnić serwera backendu, możesz wymusić na procesorze wiadomości użycie protokołu TLSv1.0 do komunikacji z serwerem backendu, wykonując te czynności:
    1. Jeśli nie określisz serwera docelowego w definicji elementu TargetEndpoint na serwerze proxy, ustaw element Protocol na TLSv1.0, jak pokazano poniżej: 
      <TargetEndpoint name="default">
 …
 <HTTPTargetConnection>
   <SSLInfo>
       <Enabled>true</Enabled>
       <Protocols>
           <Protocol>TLSv1.0</Protocol>
       </Protocols>
   </SSLInfo>
   <URL>https://myservice.com</URL>
 </HTTPTargetConnection>
 …
</TargetEndpoint>
    2. Jeśli dla serwera proxy skonfigurowano serwer docelowy, użyj tego interfejsu API do zarządzania, aby ustawić protokół TLSv1.0 w konkretnej konfiguracji serwera docelowego.

Niezgodność cyfr

Jeśli algorytm zestawu szyfrów używany przez klienta nie jest obsługiwany przez serwer na połączeniu przychodzącym (granicznym północnym) lub wychodzącym (południowym) w Apigee Edge, może wystąpić błąd uzgadniania połączenia TLS/SSL. Zapoznaj się też z informacjami o połączeniach na północ i południe.

Diagnostyka

  1. Sprawdź, czy błąd wystąpił na połączeniu północnym czy południowym. Więcej wskazówek, które pomogą Ci w określeniu tego problemu, znajdziesz w artykule Określanie źródła problemu.
  2. Uruchom narzędzie tcpdump, aby zebrać więcej informacji:
    • Jeśli jesteś użytkownikiem Private Cloud, możesz zbierać dane tcpdump u odpowiedniego klienta lub serwera. Klientem może być aplikacja klienta (w przypadku połączeń przychodzących lub kierowanych na północ) albo procesor wiadomości (w przypadku połączeń wychodzących lub południowych). Serwerem może być router brzegowy (dla połączeń przychodzących lub kierowanych na północ) lub serwer backendu (dla połączeń wychodzących lub południowych) w zależności od tego, jak określono w kroku 1.
    • Jeśli jesteś użytkownikiem chmury publicznej, możesz zbierać dane tcpdump tylko w aplikacji klienckiej (w przypadku połączeń przychodzących lub kierowanych na północ) albo na serwerze backendu (na potrzeby połączeń wychodzących lub południowych), ponieważ nie masz dostępu do routera brzegowego ani procesora wiadomości.
    tcpdump -i any -s 0 host IP address -w File name
    Aby dowiedzieć się więcej o korzystaniu z polecenia tcpdump, zapoznaj się z danymi tcpdump.
  3. Przeanalizuj dane tcpdump za pomocą narzędzia Wireshark lub innego, które znasz.
  4. Oto przykładowa analiza danych wyjściowych tcpdump przy użyciu programu Wireshark:
    • W tym przykładzie między aplikacją klienta a routerem brzegowym (połączenie północne) wystąpił błąd uzgadniania połączenia TLS/SSL. Dane wyjściowe tcpdump zostały zebrane na routerze brzegowym.

    • Komunikat nr 4 w danych wyjściowych tcpdump poniżej oznacza, że aplikacja kliencka (źródło) wysłała komunikat „Client Hello” do routera brzegowego (docelowego).

    • Wybranie komunikatu Client Hello oznacza, że aplikacja kliencka używa protokołu TLSv1.2.

    • Komunikat nr 5 oznacza, że router brzegowy przyjmuje komunikat „Client Hello” (Witaj klienta) od aplikacji klienckiej.
    • Router brzegowy natychmiast wysyła do aplikacji klienckiej alert krytyczny : błąd uzgadniania połączenia (komunikat nr 6). Oznacza to, że uzgadnianie połączenia TLS/SSL nie powiodło się i połączenie zostanie zamknięte.
    • Przejście do wiadomości nr 6 zawiera te informacje:
      • Router brzegowy obsługuje protokół TLSv1.2. Oznacza to, że protokół jest zgodny między aplikacją kliencką a routerem brzegowym.

      • Jednak router brzegowy nadal wysyła do aplikacji klienckiej komunikat Fatal Alert: Handshakeure (Błąd krytyczny: błąd uzgadniania połączenia) do aplikacji klienckiej, jak pokazano na zrzucie ekranu poniżej:

    • Możliwe przyczyny błędu:
      • Aplikacja kliencka nie używa algorytmów zestawu szyfrów obsługiwanych przez router brzegowy.
      • Router brzegowy ma włączoną obsługę SNI, ale aplikacja kliencka nie wysyła nazwy serwera.
    • Komunikat nr 4 w danych wyjściowych tcpdump zawiera listę algorytmów pakietu szyfrów obsługiwanych przez aplikację kliencką, jak pokazano poniżej:

    • Lista algorytmów pakietu szyfrów obsługiwanych przez router brzegowy znajduje się w pliku /opt/nginx/conf.d/0-default.conf. W tym przykładzie router brzegowy obsługuje tylko algorytmy zestawu szyfrów High Encryption.
    • Aplikacja kliencka nie używa żadnych algorytmów pakietu szyfrów High Encryption. Ta niezgodność jest przyczyną błędu uzgadniania połączenia TLS/SSL.
    • Ponieważ router brzegowy obsługuje SNI, przewiń stronę w dół do komunikatu nr 4 w danych wyjściowych tcpdump i sprawdź, czy aplikacja kliencka wysyła nazwę serwera prawidłowo, jak pokazano na ilustracji poniżej:


    • Jeśli ta nazwa jest prawidłowa, możesz wywnioskować, że wystąpił błąd uzgadniania połączenia TLS/SSL, ponieważ algorytmy zestawu szyfrów używane przez aplikację kliencką nie są obsługiwane przez router brzegowy.

Rozdzielczość

Musisz się upewnić, że klient używa algorytmów zestawu szyfrów obsługiwanych przez serwer. Aby rozwiązać problem opisany w poprzedniej sekcji Diagnostyka, pobierz i zainstaluj pakiet Java Cryptography Extension (JCE) i umieść go w instalacji w języku Java, aby zapewnić obsługę algorytmów pakietu szyfrów High Encryption.

Nieprawidłowy certyfikat

Nieudana próba uzgadniania połączenia TLS/SSL występuje, jeśli w magazynie kluczy/magazynie zaufania masz nieprawidłowe certyfikaty w przypadku połączenia przychodzącego (na północ) lub wychodzącego (południowego) w Apigee Edge. Zapoznaj się też z informacjami o połączeniach w kierunku północnym i południowym.

Jeśli problem jest związany z problemem północnym, w zależności od jego przyczyny możesz zobaczyć różne komunikaty o błędach.

Poniżej znajdziesz przykładowe komunikaty o błędach oraz sposoby diagnozowania i rozwiązywania tego problemu.

Komunikaty o błędach

W zależności od przyczyny niepowodzenia uzgadniania połączenia TLS/SSL mogą wyświetlić się różne komunikaty o błędach. Oto przykładowy komunikat o błędzie, który może się pojawić po wywołaniu serwera proxy interfejsu API:

* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

Możliwe przyczyny

Oto typowe przyczyny:

Przyczyna Opis Kto może rozwiązywać problemy
Niezgodna nazwa hosta Nazwa hosta w adresie URL różni się od nazwy certyfikatu w magazynie kluczy routera. Na przykład niezgodność występuje, jeśli nazwa hosta używana w adresie URL to myorg.domain.com, a nazwa hosta w certyfikacie to CN=something.domain.com..

 Użytkownicy chmury prywatnej i publicznej Cloud
Niekompletny lub nieprawidłowy łańcuch certyfikatów Łańcuch certyfikatów nie jest kompletny lub nieprawidłowy. Tylko użytkownicy prywatnych i publicznych chmury Edge
Wygasły lub nieznany certyfikat wysłany przez serwer lub klienta Wygasły lub nieznany certyfikat jest wysyłany przez serwer lub klienta w kierunku północnym lub południowym. Użytkownicy chmury Private Cloud i użytkownicy chmury publicznej Edge

Niezgodna nazwa hosta

Diagnostyka

  1. Zwróć uwagę na nazwę hosta używaną w adresie URL zwracanym przez to wywołanie interfejsu Edge Management API: 
    curl -v https://myorg.domain.com/v1/getinfo
    Na przykład: 
    curl -v https://api.enterprise.apigee.com/v1/getinfo
  2. Pobierz numer CN użyty w certyfikacie zapisanym w określonym magazynie kluczy. Aby uzyskać szczegóły certyfikatu, możesz użyć tych interfejsów API do zarządzania urządzeniami brzegowymi:
    1. Uzyskaj nazwę certyfikatu z magazynu kluczy:

      Jeśli jesteś użytkownikiem Private Cloud, użyj interfejsu API zarządzania w następujący sposób:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      Jeśli jesteś użytkownikiem chmury publicznej, użyj interfejsu Management API w następujący sposób:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
    2. Uzyskaj szczegółowe informacje o certyfikacie w magazynie kluczy za pomocą interfejsu Edge Management API.

      Jeśli jesteś użytkownikiem Private Cloud:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      Jeśli jesteś użytkownikiem chmury publicznej:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name

      Przykładowy certyfikat:

      "certInfo": [
    {
      "basicConstraints": "CA:FALSE",
      "expiryDate": 1456258950000,
      "isValid": "No",
      "issuer": "SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=\"GoDaddy.com, Inc.\", L=Scottsdale, ST=Arizona, C=US",
      "publicKey": "RSA Public Key, 2048 bits",
      "serialNumber": "07:bc:a7:39:03:f1:56",
      "sigAlgName": "SHA1withRSA",
      "subject": "CN=something.domain.com, OU=Domain Control Validated, O=something.domain.com",
      "validFrom": 1358287055000,
      "version": 3
    },

      Nazwa podmiotu w certyfikacie głównym ma numer CN wynoszący something.domain.com.

      Ponieważ nazwa hosta w adresie URL żądania do interfejsu API (patrz krok 1 powyżej) i nazwa podmiotu w certyfikacie nie są zgodne, występuje błąd uzgadniania połączenia TLS/SSL.

Rozdzielczość

Ten problem można rozwiązać na 2 sposoby:

  • Uzyskaj certyfikat (jeśli jeszcze go nie masz), z którym dana sieć komputerowa ma certyfikat z symbolem wieloznacznym, a następnie prześlij do magazynu kluczy nowy pełny łańcuch certyfikatów. Przykład: 
    "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",
  • Uzyskaj certyfikat (jeśli jeszcze go nie masz) dla istniejącej nazwy CN, ale użyj atrybutu your-org.your-domain jako alternatywną nazwę podmiotu, a następnie prześlij do magazynu kluczy pełny łańcuch certyfikatów.

Odniesienia

Magazyny i magazyny zaufania

Niekompletny lub nieprawidłowy łańcuch certyfikatów

Diagnostyka

  1. Pobierz numer CN użyty w certyfikacie zapisanym w określonym magazynie kluczy. Aby uzyskać szczegóły certyfikatu, możesz użyć tych interfejsów API do zarządzania urządzeniami brzegowymi:
    1. Uzyskaj nazwę certyfikatu w magazynie kluczy:

      Jeśli jesteś użytkownikiem Private Cloud:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      Jeśli jesteś użytkownikiem chmury publicznej:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
    2. Sprawdź szczegóły certyfikatu w magazynie kluczy:

      Jeśli jesteś użytkownikiem Private Cloud:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      Jeśli jesteś użytkownikiem chmury publicznej:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
    3. Sprawdź certyfikat i jego łańcuch oraz upewnij się, że jest on zgodny ze wskazówkami zawartymi w artykule Jak działają łańcuchy certyfikatów, aby upewnić się, że jest to prawidłowy i kompletny łańcuch certyfikatów. Jeśli łańcuch certyfikatów przechowywany w magazynie kluczy jest niekompletny lub nieprawidłowy, pojawia się błąd uzgadniania połączenia TLS/SSL.
    4. Poniższy wykres przedstawia przykładowy certyfikat z nieprawidłowym łańcuchem certyfikatów, w którym certyfikaty pośrednie i główne nie są zgodne:

      5. Przykładowy certyfikat pośredni i główny, w przypadku którego wystawca nie jest zgodny z podmiotem


Rozdzielczość

  1. Uzyskaj certyfikat (jeśli jeszcze go nie masz) zawierający kompletny i prawidłowy łańcuch certyfikatów.
  2. Uruchom to polecenie opensl, aby sprawdzić, czy łańcuch certyfikatów jest prawidłowy i kompletny: 
    openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert
  3. Prześlij zweryfikowany łańcuch certyfikatów do magazynu kluczy.

Wygasły lub nieznany certyfikat wysłany przez serwer lub klienta

Jeśli serwer lub klient wyśle nieprawidłowy lub wygasły certyfikat na stronie północnej albo na połączeniu południowym, jego drugi koniec (serwer/klient) odrzuci certyfikat, co spowoduje błąd uzgadniania połączenia TLS/SSL.

Diagnostyka

  1. Sprawdź, czy błąd wystąpił w połączeniu północnym czy southbound. Więcej wskazówek, które pomogą Ci w określeniu tego problemu, znajdziesz w artykule Ustalanie źródła problemu.
  2. Uruchom narzędzie tcpdump, aby zebrać więcej informacji:
    • Jeśli jesteś użytkownikiem Private Cloud, możesz zbierać dane tcpdump u odpowiedniego klienta lub serwera. Klientem może być aplikacja klienta (w przypadku połączeń przychodzących lub kierowanych na północ) albo procesor wiadomości (w przypadku połączeń wychodzących lub południowych). Serwerem może być router brzegowy (dla połączeń przychodzących lub kierowanych na północ) lub serwer backendu (dla połączeń wychodzących lub południowych) w zależności od tego, jak określono w kroku 1.
    • Jeśli jesteś użytkownikiem chmury publicznej, możesz zbierać dane tcpdump tylko w aplikacji klienckiej (w przypadku połączeń przychodzących lub kierowanych na północ) albo na serwerze backendu (na potrzeby połączeń wychodzących lub południowych), ponieważ nie masz dostępu do routera brzegowego ani procesora wiadomości.
    tcpdump -i any -s 0 host IP address -w File name
    Aby dowiedzieć się więcej o korzystaniu z polecenia tcpdump, zapoznaj się z danymi tcpdump.
  3. Przeanalizuj dane tcpdump za pomocą Wireshark lub podobnego narzędzia.
  4. Na podstawie danych wyjściowych tcpdump określ hosta (klienta lub serwer), który odrzuca certyfikat na etapie weryfikacji.
  5. Certyfikat wysłany z drugiego końca możesz pobrać z danych wyjściowych tcpdump, o ile dane nie są zaszyfrowane. Będzie to przydatne do porównania, czy ten certyfikat pasuje do certyfikatu dostępnego w magazynie zaufania.
  6. Sprawdź przykład tcpdump pod kątem komunikacji SSL między procesorem wiadomości a serwerem backendu.

    Przykładowy element tcpdump z wyświetlonym błędem „Nieznany certyfikat”


    1. Procesor wiadomości (klient) wysyła komunikat „Cześć klienta” do serwera backendu (serwera) w komunikacie nr 59.
    2. Serwer backendu wysyła do podmiotu przetwarzającego wiadomości wiadomość „Server Hello” w wiadomości #61.
    3. Wzajemnie weryfikują one protokół i algorytmy zestawu szyfrów.
    4. Serwer backendu wysyła certyfikat i komunikat Hello Done do serwera wiadomości do podmiotu przetwarzającego wiadomości w komunikacie nr 68.
    5. Procesor wiadomości wysyła alert krytyczny „Description: Certificate Unknown” (Opis: certyfikat nieznany) w komunikacie nr 70.
    6. W wiadomości #70 nie ma żadnych dodatkowych informacji poza komunikatem o alercie, jak pokazano poniżej:


    7. Zapoznaj się z wiadomością nr 68, aby uzyskać szczegółowe informacje o certyfikacie wysłanym przez serwer backendu, jak pokazano na tej ilustracji:

    8. Certyfikat serwera backendu i jego pełny łańcuch są dostępne w sekcji „Certyfikaty”, jak pokazano na ilustracji powyżej.
  7. Jeśli router (od strony północnej) lub procesor wiadomości (southbound) jest nieznany (jak w przykładzie powyżej), wykonaj te czynności:
    1. Pobierz certyfikat i jego łańcuch zapisany w konkretnym magazynie zaufania. (Sprawdź konfigurację hosta wirtualnego routera i docelowego punktu końcowego dla procesora wiadomości). Aby uzyskać szczegóły certyfikatu, możesz użyć tych interfejsów API:
      1. Pobierz nazwę certyfikatu z magazynu zaufania: 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs
      2. Pobierz szczegóły certyfikatu z magazynu zaufania: 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name
    2. Sprawdź, czy certyfikat przechowywany w magazynie zaufanych certyfikatów routera (northbound) lub procesor wiadomości (southbound) jest zgodny z certyfikatem przechowywanym w magazynie kluczy aplikacji klienta (na północ) lub na serwerze docelowym (southbound) albo z certyfikatem uzyskanym na podstawie danych wyjściowych tcpdump. Jeśli występuje niezgodność, jest ona przyczyną błędu uzgadniania połączenia TLS/SSL.
  8. Jeśli okaże się, że certyfikat jest nieznany przez aplikację kliencką (w kierunku północnym) lub przez serwer docelowy (południowy), wykonaj te czynności:
    1. Pobierz pełny łańcuch certyfikatów używany w certyfikacie zapisanym w konkretnym magazynie kluczy. Zapoznaj się z konfiguracją hosta wirtualnego routera i docelowego punktu końcowego procesora wiadomości. Aby uzyskać szczegóły certyfikatu, możesz użyć tych interfejsów API:
      1. Uzyskaj nazwę certyfikatu z magazynu kluczy: 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      2. Znajdź szczegóły certyfikatu w magazynie kluczy:
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
    2. Sprawdź, czy certyfikat przechowywany w magazynie kluczy routera (na północ) lub przez procesor wiadomości (southbound) jest zgodny z certyfikatem zapisanym w magazynie zaufania aplikacji klienckiej (na północ) lub na serwerze docelowym (southbound) albo z certyfikatem uzyskanym na podstawie danych wyjściowych tcpdump. Jeśli występuje niezgodność, jest ona przyczyną błędu uzgadniania połączenia SSL.
  9. Jeśli okaże się, że certyfikat wysłany przez serwer/klienta stracił ważność, klient/serwer odbierający odrzuci certyfikat, a w tcpdump zobaczysz ten alert:

    Alert (Poziom: krytyczny, opis: certyfikat wygasł)

  10. Sprawdź, czy certyfikat w magazynie kluczy odpowiedniego hosta wygasł.

Rozdzielczość

Aby rozwiązać problem wskazany w powyższym przykładzie, prześlij prawidłowy certyfikat serwera backendu do instancji trustore w procesorze wiadomości.

W tabeli poniżej znajdziesz podsumowanie czynności, które należy wykonać, aby rozwiązać problem w zależności od jego przyczyny.

Przyczyna Opis Rozwiązanie
Certyfikat wygasł NorthBound
  • Certyfikat zapisany w magazynie kluczy routera wygasł.
  • Certyfikat przechowywany w magazynie kluczy aplikacji klienckiej wygasł (dwukierunkowy protokół SSL).
 Prześlij nowy certyfikat i jego pełny łańcuch do magazynu kluczy na odpowiednim hoście.
SouthBound
  • Certyfikat przechowywany w magazynie kluczy serwera docelowego wygasł.
  • Certyfikat przechowywany w magazynie kluczy procesora wiadomości utracił ważność (dwukierunkowy protokół SSL).
 Prześlij nowy certyfikat i jego pełny łańcuch do magazynu kluczy na odpowiednim hoście.
Nieznany certyfikat NorthBound
  • Certyfikat przechowywany w magazynie zaufania aplikacji klienckiej nie pasuje do certyfikatu routera.
  • Certyfikat przechowywany w magazynie zaufania routera nie pasuje do certyfikatu aplikacji klienckiej (dwukierunkowy protokół SSL).
 Prześlij prawidłowy certyfikat do magazynu zaufania na odpowiednim hoście.
SouthBound
  • Certyfikat przechowywany w magazynie zaufania serwera docelowego nie pasuje do certyfikatu podmiotu przetwarzającego wiadomości.
  • Certyfikat przechowywany w magazynie zaufania procesora wiadomości nie jest zgodny z certyfikatem serwera docelowego (dwukierunkowy protokół SSL).
 Prześlij prawidłowy certyfikat do magazynu zaufania na odpowiednim hoście.

Serwer z włączoną usługą SNI

Nieudana próba uzgadniania połączenia TLS/SSL może wystąpić, gdy klient komunikuje się z serwerem z włączonym dodatkiem SNI, ale klient nie jest włączony. Może się to zdarzyć w jego części północnej lub południowej w Edge.

Najpierw musisz określić nazwę hosta i numer portu używanego serwera oraz sprawdzić, czy włączony jest SNI.

Identyfikacja serwera z włączonym SNI

  1. Wykonaj polecenie openssl i spróbuj połączyć się z odpowiednią nazwą hosta serwera (router brzegowy lub serwer backendu) bez przekazywania nazwy serwera, jak pokazano poniżej: 
    openssl s_client -connect hostname:port
    Możesz uzyskać certyfikaty i czasami może wystąpić błąd uzgadniania połączenia w poleceniu opensl, jak pokazano poniżej:
    CONNECTED(00000003)
9362:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_clnt.c:593
  2. Wykonaj polecenie openssl i spróbuj połączyć się z odpowiednią nazwą hosta serwera (routerem brzegowym lub serwerem backendu), przesyłając nazwę serwera, jak pokazano poniżej: 
    openssl s_client -connect hostname:port -servername hostname
  3. Jeśli w kroku 1 wystąpi błąd uzgadniania połączenia lub w kroku 1 i w kroku 2 uzyskasz inne certyfikaty, oznacza to, że określony serwer jest włączony w usłudze SNI.

Po sprawdzeniu, czy serwer ma włączoną obsługę SNI, możesz wykonać poniższe czynności, aby sprawdzić, czy błąd połączenia TLS/SSL nie jest spowodowany tym, że klient nie może połączyć się z serwerem SNI.

Diagnostyka

  1. Sprawdź, czy błąd wystąpił w połączeniu północnym czy southbound. Więcej wskazówek, które pomogą Ci w określeniu tego problemu, znajdziesz w artykule Ustalanie źródła problemu.
  2. Uruchom narzędzie tcpdump, aby zebrać więcej informacji:
    • Jeśli jesteś użytkownikiem Private Cloud, możesz zbierać dane tcpdump u odpowiedniego klienta lub serwera. Klientem może być aplikacja klienta (w przypadku połączeń przychodzących lub kierowanych na północ) albo procesor wiadomości (w przypadku połączeń wychodzących lub południowych). Serwerem może być router brzegowy (dla połączeń przychodzących lub kierowanych na północ) lub serwer backendu (dla połączeń wychodzących lub południowych) w zależności od tego, jak określono w kroku 1.
    • Jeśli jesteś użytkownikiem chmury publicznej, możesz zbierać dane tcpdump tylko w aplikacji klienckiej (w przypadku połączeń przychodzących lub kierowanych na północ) albo na serwerze backendu (na potrzeby połączeń wychodzących lub południowych), ponieważ nie masz dostępu do routera brzegowego ani procesora wiadomości.
    tcpdump -i any -s 0 host IP address -w File name
    Więcej informacji o używaniu polecenia tcpdump znajdziesz w danych tcpdump.
  3. Przeanalizuj dane wyjściowe tcpdump za pomocą Wireshark lub podobnego narzędzia.
  4. Oto przykładowa analiza obiektu tcpdump przy użyciu programu Wireshark:
    1. W tym przykładzie wystąpił błąd uzgadniania połączenia TLS/SSL między procesorem wiadomości brzegowych a serwerem backendu (połączenie wychodzące).
    2. Komunikat nr 4 w danych wyjściowych tcpdump poniżej oznacza, że procesor wiadomości (źródło) wysłał komunikat „Client Hello” do serwera backendu (miejsce docelowe).

    3. Kliknięcie komunikatu „Cześć klienta” oznacza, że procesor wiadomości używa protokołu TLSv1.2.

    4. Komunikat nr 4 oznacza, że serwer backendu przyjmuje wiadomość „Cześć klienta” od procesora wiadomości.
    5. Serwer backendu natychmiast wysyła alert krytyczny : błąd uzgadniania połączenia do podmiotu przetwarzającego wiadomości (komunikat nr 5). Oznacza to, że uzgadnianie połączenia TLS/SSL nie powiodło się i połączenie zostanie zamknięte.
    6. W wiadomości nr 6 znajdziesz te informacje:
      • Serwer backendu obsługuje protokół TLSv1.2. Oznacza to, że protokół został dopasowany między procesorem wiadomości a serwerem backendu.
      • Jednak serwer backendu nadal wysyła alert krytyczny: błąd uzgadniania połączenia do podmiotu przetwarzającego wiadomości, jak pokazano na ilustracji poniżej:

    7. Ten błąd może wystąpić z jednego z tych powodów:
      • Procesor wiadomości nie używa algorytmów zestawu szyfrów obsługiwanych przez serwer backendu.
      • Serwer backendu ma włączoną obsługę SNI, ale aplikacja kliencka nie wysyła nazwy serwera.
    8. Zapoznaj się bardziej szczegółowo z komunikatem nr 3 (Cześć klienta) w danych wyjściowych tcpdump. Pamiętaj, że brakuje pola Rozszerzenie: nazwa_serwera, jak pokazano poniżej:

    9. Jest to potwierdzenie, że procesor wiadomości nie wysłał wartości server_name do serwera backendu z obsługą SNI.
    10. Jest to przyczyna błędu uzgadniania połączenia TLS/SSL i powód, dla którego serwer backendu wysyła alert krytyczny: błąd uzgadniania połączenia do procesora wiadomości.
  5. Sprawdź, czy jsse.enableSNIExtension property w system.properties ma wartość Fałsz w procesorze wiadomości, aby upewnić się, że ten procesor nie może komunikować się z serwerem obsługującym SNI.

Rozdzielczość

Włącz procesory wiadomości do komunikacji z serwerami obsługującymi SNI, wykonując te czynności:

  1. Utwórz plik /opt/apigee/customer/application/message-processor.properties (jeśli jeszcze nie istnieje).
  2. Dodaj do tego pliku ten wiersz: conf_system_jsse.enableSNIExtension=true
  3. Przenieś właściciela tego pliku na użytkownika apigee:apigee: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. Ponownie uruchom procesor wiadomości. 
    /opt/apigee/apigee-service/bin/apigee-service message-processor restart
  5. Jeśli masz więcej niż 1 procesor wiadomości, powtórz kroki od 1 do 4 w przypadku każdego z nich.

Jeśli nie możesz ustalić przyczyny błędu uzgadniania połączenia TLS/SSL i rozwiązać problem lub potrzebujesz dalszej pomocy, skontaktuj się z zespołem pomocy Apigee Edge. Podaj pełne informacje o problemie wraz z danymi wyjściowymi tcpdump.