Nieudane uzgadnianie połączenia TLS/SSL

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

Krótki opis problemu

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

Komunikaty o błędach

HTTP/1.1 503 Service Unavailable

Ten komunikat o błędzie może się też pojawić w przypadku nieudanego uzgadniania połączenia TLS/SSL:

Received fatal alert: handshake_failure

Możliwe przyczyny

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

1. uzgodnić wersję protokołu do użycia;
2. Wybierz algorytm kryptograficzny, którego chcesz użyć.
3. uwierzytelniać się nawzajem przez wymianę i weryfikację certyfikatów cyfrowych;

Jeśli uzgadnianie połączenia TLS/SSL zakończy się powodzeniem, klient i serwer TLS/SSL będą bezpiecznie przesyłać dane do siebie. W przeciwnym razie, jeśli dojdzie do niepowodzenia uzgadniania TLS/SSL, połączenie zostanie przerwane, a klient otrzyma błąd 503 Service Unavailable.

Możliwe przyczyny nieudanego uzgodnienia połączenia za pomocą protokołu TLS/SSL:

Niezgodność protokołu

Błąd uzgadniania połączenia TLS/SSL występuje, jeśli protokół używany przez klienta nie jest obsługiwany przez serwer w przypadku połączenia przychodzącego (północnego) lub wychodzącego (południowego). Zobacz też Omówienie połączeń wychodzących i przychodzących.

Diagnostyka

1. Sprawdź, czy błąd wystąpił w przypadku połączenia wychodzącego czy przychodzącego. Więcej informacji o tym, jak to ustalić, znajdziesz w sekcji Określanie źródła problemu.
2. Uruchom narzędzie tcpdump, aby zebrać więcej informacji:
   • Jeśli jesteś użytkownikiem chmury prywatnej, możesz zbierać dane tcpdump na odpowiednim kliencie lub serwerze. Klientem może być aplikacja kliencka (w przypadku połączeń przychodzących lub wychodzących) albo procesor wiadomości (w przypadku połączeń wychodzących lub przychodzących). Serwerem może być router brzegowy (w przypadku połączeń przychodzących lub północnych) albo serwer backendu (w przypadku połączeń wychodzących lub południowych) w zależności od tego, co zostało ustalone w kroku 1.
   • Jeśli jesteś użytkownikiem chmury publicznej, możesz zbierać dane tcpdumptylko w aplikacji klienta (w przypadku połączeń przychodzących lub północnych) albo na serwerze backendu (w przypadku połączeń wychodzących lub południowych), ponieważ nie masz dostępu do routera brzegowego ani procesora komunikatów.

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

   Więcej informacji o używaniu polecenia tcpdump znajdziesz w danych tcpdump.
3. Analizuj dane tcpdump za pomocą narzędzia Wireshark lub podobnego.
4. Oto przykładowa analiza danych z narzędzia tcpdump za pomocą Wiresharka:
   • W tym przykładzie błąd uzgadniania protokołu TLS/SSL wystąpił między procesorem komunikatów a serwerem backendu (połączenie wychodzące lub południowe).
   • Wiadomość 4 w tcpdump poniżej pokazuje, że procesor komunikatów (źródło) wysłał wiadomość „Client Hello” do serwera backendu (miejsce docelowe).
     

     

   • Jeśli wybierzesz wiadomość Client Hello, zobaczysz, że procesor komunikatów używa protokołu TLSv1.2, jak pokazano poniżej:

     

   • Wiadomość 5 pokazuje, że serwer backendu potwierdza wiadomość „Client Hello” z procesora komunikatów.
   • Serwer backendu natychmiast wysyła do procesora komunikatów komunikat Fatal Alert : Close Notify (wiadomość nr 6). Oznacza to, że uzgadnianie połączenia TLS/SSL nie powiodło się i połączenie zostanie zamknięte.

   • Dalsza analiza wiadomości nr 6 pokazuje, że przyczyną niepowodzenia uzgadniania połączenia TLS/SSL jest to, że serwer backendu obsługuje tylko protokół TLSv1.0, jak pokazano poniżej:

     

   • Wystąpiła niezgodność między protokołem używanym przez procesor komunikatów a serwerem backendu, dlatego serwer backendu wysłał komunikat: Fatal Alert Message: Close Notify.

Rozdzielczość

Procesor komunikatów działa w środowisku Java 8 i domyślnie używa protokołu TLSv1.2. Jeśli serwer backendu nie obsługuje protokołu TLSv1.2, możesz wykonać jedną z tych czynności, aby rozwiązać ten problem:

1. Zaktualizuj 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 komunikatów używanie protokołu TLSv1.0 do komunikacji z serwerem backendu, wykonując te czynności:
   1. Jeśli w definicji TargetEndpoint serwera proxy nie został określony serwer docelowy, 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 w przypadku serwera proxy skonfigurowano serwer docelowy, użyj tego interfejsu Management API, aby ustawić protokół TLSv1.0 w konkretnej konfiguracji serwera docelowego.

Niezgodność mechanizmu szyfrowania

Błąd uzgadniania połączenia TLS/SSL może wystąpić, jeśli algorytm zestawu szyfrów używany przez klienta nie jest obsługiwany przez serwer w przypadku połączenia przychodzącego (północnego) lub wychodzącego (południowego) w Apigee Edge. Zobacz też Omówienie połączeń wychodzących i przychodzących.

Diagnostyka

1. Sprawdź, czy błąd wystąpił w przypadku połączenia wychodzącego czy przychodzącego. Więcej informacji o tym, jak to ustalić, znajdziesz w artykule Określanie źródła problemu.
2. Uruchom narzędzie tcpdump, aby zebrać więcej informacji:
   • Jeśli jesteś użytkownikiem chmury prywatnej, możesz zbierać dane tcpdump na odpowiednim kliencie lub serwerze. Klientem może być aplikacja kliencka (w przypadku połączeń przychodzących lub wychodzących) albo procesor wiadomości (w przypadku połączeń wychodzących lub przychodzących). Serwerem może być router brzegowy (w przypadku połączeń przychodzących lub północnych) albo serwer backendu (w przypadku połączeń wychodzących lub południowych) w zależności od tego, co zostało ustalone w kroku 1.
   • Jeśli jesteś użytkownikiem chmury publicznej, możesz zbierać dane tcpdumptylko w aplikacji klienta (w przypadku połączeń przychodzących lub północnych) albo na serwerze backendu (w przypadku połączeń wychodzących lub południowych), ponieważ nie masz dostępu do routera brzegowego ani procesora komunikatów.

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

   Więcej informacji o używaniu polecenia tcpdump znajdziesz w danych tcpdump.
3. Analizuj tcpdump dane za pomocą narzędzia Wireshark lub dowolnego innego narzędzia, które znasz.
4. Oto przykładowa analiza danych wyjściowych tcpdump za pomocą narzędzia Wireshark:
   • W tym przykładzie błąd uzgadniania TLS/SSL wystąpił między aplikacją klienta a routerem brzegowym (połączenie wychodzące). Dane wyjściowe tcpdump zostały zebrane na routerze brzegowym.

   • Wiadomość 4 w tcpdump poniżej pokazuje, że aplikacja kliencka (źródło) wysłała wiadomość „Client Hello” do routera brzegowego (miejsce docelowe).

     

   • Wybranie wiadomości Client Hello pokazuje, że aplikacja kliencka używa protokołu TLSv1.2.

     

   • Wiadomość 5 pokazuje, że router brzegowy potwierdza otrzymanie wiadomości „Client Hello” z aplikacji klienckiej.
   • Router brzegowy natychmiast wysyła do aplikacji klienckiej Fatal Alert : Handshake Failure (wiadomość nr 6). Oznacza to, że uzgadnianie połączenia TLS/SSL nie powiodło się i połączenie zostanie zamknięte.
   • Szczegółowe informacje o wiadomości nr 6:
     • Router brzegowy obsługuje protokół TLSv1.2. Oznacza to, że protokół jest zgodny między aplikacją kliencką a routerem brzegowym.

     • Router brzegowy nadal wysyła do aplikacji klienta komunikat Fatal Alert: Handshake Failure, jak pokazano na zrzucie ekranu poniżej:

       

   • Przyczyną tego błędu może być jeden z tych problemów:
     • Aplikacja kliencka nie używa algorytmów zestawu szyfrów obsługiwanych przez router brzegowy.
     • Router brzegowy ma włączoną funkcję SNI, ale aplikacja kliencka nie wysyła nazwy serwera.
   • Komunikat 4 w danych wyjściowych tcpdump zawiera listę algorytmów zestawu szyfrów obsługiwanych przez aplikację kliencką, jak pokazano poniżej:

     

   • Lista algorytmów zestawu 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 żadnego z algorytmów zestawu szyfrów o wysokim poziomie bezpieczeństwa. Ta niezgodność jest przyczyną nieudanego uzgadniania połączenia TLS/SSL.
   • Ponieważ router brzegowy obsługuje SNI, przewiń w dół do komunikatu 4 w tcpdump danych wyjściowych i sprawdź, czy aplikacja kliencka prawidłowo wysyła nazwę serwera, jak pokazano na ilustracji poniżej:
     
     
     
   • Jeśli ta nazwa jest prawidłowa, możesz wywnioskować, że nie udało się nawiązać połączenia TLS/SSL, ponieważ algorytmy pakietu szyfrującego używane przez aplikację kliencką nie są obsługiwane przez router brzegowy.

Rozdzielczość

Musisz zadbać o to, aby 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), a następnie uwzględnij go w instalacji Javy, aby obsługiwać algorytmy zestawu szyfrów High Encryption.

Nieprawidłowy certyfikat

Błąd uzgadniania TLS/SSL występuje, jeśli w magazynie kluczy lub magazynie zaufanych certyfikatów znajdują się nieprawidłowe certyfikaty, zarówno w przypadku połączenia przychodzącego (północnego), jak i wychodzącego (południowego) w Apigee Edge. Zobacz też Omówienie połączeń wychodzących i przychodzących.

Jeśli problem dotyczy ruchu wychodzącego, mogą pojawić się różne komunikaty o błędach w zależności od przyczyny.

W sekcjach poniżej znajdziesz przykładowe komunikaty o błędach oraz czynności, które pozwolą Ci zdiagnozować i rozwiązać ten problem.

Komunikaty o błędach

W zależności od przyczyny niepowodzenia uzgadniania TLS/SSL mogą pojawiać się różne komunikaty o błędzie. Oto przykładowy komunikat o błędzie, który może się pojawić podczas wywoływania 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

Typowe przyczyny tego problemu to:

Niezgodność nazwy hosta

Diagnostyka

1. Zanotuj nazwę hosta używaną w adresie URL zwróconym przez to wywołanie interfejsu Edge Management API:

   curl -v https://myorg.domain.com/v1/getinfo

   Przykład:

   curl -v https://api.enterprise.apigee.com/v1/getinfo

2. Pobierz nazwę CN używaną w certyfikacie przechowywanym w określonym magazynie kluczy. Aby uzyskać szczegółowe informacje o certyfikacie, możesz użyć tych interfejsów API do zarządzania Edge:
   1. Pobierz nazwę certyfikatu z magazynu kluczy:
      
      Jeśli jesteś użytkownikiem chmury prywatnej, użyj interfejsu API zarządzania Google Analytics w ten 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 API zarządzania Google Analytics w ten sposób:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Pobierz szczegóły certyfikatu w magazynie kluczy za pomocą interfejsu Edge Management API.
      
      Jeśli jesteś użytkownikiem chmury 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 podstawowym ma CN jako something.domain.com.

      Ponieważ nazwa hosta użyta w adresie URL żądania do interfejsu API (patrz krok 1 powyżej) i nazwa podmiotu w certyfikacie nie pasują do siebie, następuje błąd uzgadniania protokołu TLS/SSL.

Rozdzielczość

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

• Uzyskaj certyfikat (jeśli go jeszcze nie masz), w którym nazwa CN podmiotu ma certyfikat wieloznaczny, a następnie prześlij nowy pełny łańcuch certyfikatów do magazynu kluczy. Na przykład:

  "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",

• Uzyskaj certyfikat (jeśli jeszcze go nie masz) z istniejącym polem CN podmiotu, ale użyj your-org.your-domain jako alternatywną nazwę podmiotu, a następnie prześlij do magazynu kluczy pełny łańcuch certyfikatów.

Odniesienia

Magazyny kluczy i magazyny zaufanych certyfikatów

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

Diagnostyka

1. Pobierz nazwę CN używaną w certyfikacie przechowywanym w określonym magazynie kluczy. Aby uzyskać szczegółowe informacje o certyfikacie, możesz użyć tych interfejsów API do zarządzania Edge:
   1. Pobierz nazwę certyfikatu z magazynu 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. Uzyskaj szczegółowe informacje o certyfikacie w magazynie kluczy:
      
      Jeśli jesteś użytkownikiem chmury prywatnej:
      

      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 są zgodne z wytycznymi podanymi w artykule Jak działają łańcuchy certyfikatów, aby mieć pewność, ż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, zobaczysz błąd uzgadniania TLS/SSL.
   4. Ilustracja przedstawia przykładowy certyfikat z nieprawidłowym łańcuchem certyfikatów, w którym certyfikaty pośredni i główny nie pasują do siebie:

   Przykładowy certyfikat pośredni i certyfikat główny, w którym wystawca i podmiot są niezgodne

   
   

Rozdzielczość

1. Uzyskaj certyfikat (jeśli go jeszcze nie masz), który zawiera pełny i ważny łańcuch certyfikatów.
2. Aby sprawdzić, czy łańcuch certyfikatów jest prawidłowy i kompletny, uruchom to polecenie openssl:

   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 w połączeniu wychodzącym lub przychodzącym, druga strona (serwer lub klient) odrzuci certyfikat, co spowoduje niepowodzenie uzgadniania protokołu TLS/SSL.

Diagnostyka

1. Sprawdź, czy błąd wystąpił w przypadku połączenia wychodzącego czy przychodzącego. Więcej informacji o tym, jak to ustalić, znajdziesz w sekcji Określanie źródła problemu.
2. Uruchom narzędzie tcpdump, aby zebrać więcej informacji:
   • Jeśli jesteś użytkownikiem chmury prywatnej, możesz zbierać dane tcpdump na odpowiednim kliencie lub serwerze. Klientem może być aplikacja kliencka (w przypadku połączeń przychodzących lub wychodzących) albo procesor wiadomości (w przypadku połączeń wychodzących lub przychodzących). Serwerem może być router brzegowy (w przypadku połączeń przychodzących lub północnych) albo serwer backendu (w przypadku połączeń wychodzących lub południowych) w zależności od tego, co zostało ustalone w kroku 1.
   • Jeśli jesteś użytkownikiem chmury publicznej, możesz zbierać dane tcpdumptylko w aplikacji klienta (w przypadku połączeń przychodzących lub północnych) albo na serwerze backendu (w przypadku połączeń wychodzących lub południowych), ponieważ nie masz dostępu do routera brzegowego ani procesora komunikatów.

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

   Więcej informacji o używaniu polecenia tcpdump znajdziesz w danych tcpdump.
3. Analizuj dane tcpdump za pomocą narzędzia Wireshark lub podobnego.
4. Na podstawie danych wyjściowych tcpdump określ hosta (klienta lub serwer), który odrzuca certyfikat podczas weryfikacji.
5. Certyfikat wysłany z drugiej strony 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 zaufanych certyfikatów.
6. Zapoznaj się z przykładowym tcpdump dotyczącym komunikacji SSL między procesorem komunikatów a serwerem backendu.

   Przykładowy tcpdump z błędem Certificate Unknown

   
   

   1. Procesor wiadomości (klient) wysyła do serwera backendu (serwera) wiadomość „Client Hello” (#59).
   2. Serwer backendu wysyła do procesora wiadomości komunikat „Server Hello” w wiadomości nr 61.
   3. Wzajemnie weryfikują używane algorytmy protokołu i zestawu szyfrów.
   4. Serwer backendu wysyła do procesora komunikatów komunikat Certificate i Server Hello Done (nr 68).
   5. Procesor wiadomości wysyła krytyczny alert „Opis: Certyfikat Nieznany” w wiadomości 70.
   6. Wiadomość nr 70 nie zawiera żadnych dodatkowych szczegółów poza alertem widocznym poniżej:

      
      

   7. Sprawdź wiadomość 68, aby uzyskać szczegółowe informacje o certyfikacie wysłanym przez serwer backendu, jak pokazano na poniższym rysunku:

      

   8. Certyfikat serwera backendu i jego pełny łańcuch są dostępne w sekcji „Certyfikaty”, jak pokazano na powyższym rysunku.
7. Jeśli certyfikat jest nieznany routerowi (w kierunku północnym) lub procesorowi komunikatów (w kierunku południowym), jak w przykładzie powyżej, wykonaj te czynności:
   1. Pobierz certyfikat i jego łańcuch przechowywany w określonym magazynie zaufanych certyfikatów. (Patrz konfiguracja hosta wirtualnego dla routera i konfiguracja docelowego punktu końcowego dla procesora komunikatów). Aby uzyskać szczegółowe informacje o certyfikacie, możesz użyć tych interfejsów API:
      1. Pobierz nazwę certyfikatu z magazynu zaufanych certyfikatów:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs

      2. Sprawdź szczegóły certyfikatu w magazynie zaufanych certyfikatów:

         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 (ruch wychodzący) lub procesora komunikatów (ruch przychodzący) jest zgodny z certyfikatem przechowywanym w magazynie kluczy aplikacji klienckiej (ruch wychodzący) lub serwera docelowego (ruch przychodzący) albo z certyfikatem uzyskanym z danych wyjściowych polecenia tcpdump. Jeśli wystąpi niezgodność, będzie to przyczyną niepowodzenia uzgadniania połączenia TLS/SSL.
8. Jeśli certyfikat zostanie uznany za nieznany przez aplikację kliencką (w kierunku północnym) lub serwer docelowy (w kierunku południowym), wykonaj te czynności:
   1. Pobierz pełny łańcuch certyfikatów używany w certyfikacie przechowywanym w określonym magazynie kluczy. (Zapoznaj się z konfiguracją hosta wirtualnego dla routera i konfiguracją docelowego punktu końcowego dla procesora komunikatów). Aby uzyskać szczegółowe informacje o certyfikacie, możesz użyć tych interfejsów API:
      1. Pobierz nazwę certyfikatu w magazynie kluczy:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      2. Sprawdź 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 (ruch wychodzący) lub procesora komunikatów (ruch przychodzący) jest zgodny z certyfikatem przechowywanym w magazynie zaufanych certyfikatów aplikacji klienckiej (ruch wychodzący) lub serwera docelowego (ruch przychodzący) albo z certyfikatem uzyskanym z danych wyjściowych tcpdump. Jeśli wystąpi niezgodność, będzie to przyczyną nieudanego uzgodnienia połączenia SSL.
9. Jeśli certyfikat wysłany przez serwer lub klienta wygasł, klient lub serwer odbierający odrzuca certyfikat i w tcpdump wyświetla się ten komunikat z ostrzeżeniem:

   Alert (Level: Fatal, Description: Certificate expired)

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

Rozdzielczość

Aby rozwiązać problem wskazany w przykładzie powyżej, prześlij prawidłowy certyfikat serwera backendu do magazynu zaufanych certyfikatów na procesorze komunikatów.

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

SNI włączone Serwer

Błąd uzgadniania połączenia TLS/SSL może wystąpić, gdy klient komunikuje się z serwerem z włączonym SNI (Server Name Indication), ale sam nie ma włączonego SNI. Może to nastąpić w przypadku połączenia wychodzącego lub przychodzącego w Edge.

Najpierw musisz określić nazwę hosta i numer portu używanego serwera oraz sprawdzić, czy jest on obsługiwany przez 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 otrzymać certyfikaty, ale czasami w poleceniu openssl może wystąpić błąd uzgadniania, 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 (router brzegowy lub serwer backendu), przekazując nazwę serwera w sposób pokazany poniżej:

   openssl s_client -connect hostname:port -servername hostname

3. Jeśli w kroku 1 wystąpi błąd uzgadniania lub w kroku 1 i 2 otrzymasz różne certyfikaty, oznacza to, że podany serwer ma włączoną funkcję SNI.

Gdy stwierdzisz, że serwer obsługuje SNI, wykonaj poniższe czynności, aby sprawdzić, czy błąd uzgadniania TLS/SSL jest spowodowany tym, że klient nie może komunikować się z serwerem SNI.

Diagnostyka

1. Sprawdź, czy błąd wystąpił w przypadku połączenia wychodzącego czy przychodzącego. Więcej informacji o tym, jak to ustalić, znajdziesz w sekcji Określanie źródła problemu.
2. Uruchom narzędzie tcpdump, aby zebrać więcej informacji:
   • Jeśli jesteś użytkownikiem chmury prywatnej, możesz zbierać dane tcpdump na odpowiednim kliencie lub serwerze. Klientem może być aplikacja kliencka (w przypadku połączeń przychodzących lub wychodzących) albo procesor wiadomości (w przypadku połączeń wychodzących lub przychodzących). Serwerem może być router brzegowy (w przypadku połączeń przychodzących lub północnych) albo serwer backendu (w przypadku połączeń wychodzących lub południowych) w zależności od tego, co zostało ustalone w kroku 1.
   • Jeśli jesteś użytkownikiem chmury publicznej, możesz zbierać dane tcpdumptylko w aplikacji klienta (w przypadku połączeń przychodzących lub północnych) albo na serwerze backendu (w przypadku połączeń wychodzących lub południowych), ponieważ nie masz dostępu do routera brzegowego ani procesora komunikatów.

   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ą narzędzia Wireshark lub podobnego.
4. Oto przykładowa analiza tcpdump za pomocą narzędzia Wireshark:
   1. W tym przykładzie błąd uzgadniania TLS/SSL wystąpił między procesorem wiadomości Edge a serwerem backendu (połączenie wychodzące).
   2. Wiadomość 4 w tcpdump danych wyjściowych poniżej pokazuje, że procesor komunikatów (źródło) wysłał wiadomość „Client Hello” do serwera backendu (miejsce docelowe).

      

   3. Wybranie wiadomości „Client Hello” pokazuje, że procesor wiadomości używa protokołu TLSv1.2.

      

   4. Wiadomość 4 pokazuje, że serwer backendu potwierdza wiadomość „Client Hello” z procesora wiadomości.
   5. Serwer backendu natychmiast wysyła do procesora komunikatów Fatal Alert : Handshake Failure (wiadomość nr 5). Oznacza to, że uzgadnianie TLS/SSL nie powiodło się i połączenie zostanie zamknięte.
   6. Wiadomość 6 zawiera te informacje:
      • Serwer backendu obsługuje protokół TLSv1.2. Oznacza to, że protokół jest zgodny między procesorem komunikatów a serwerem backendu.
      • Serwer backendu nadal wysyła jednak do procesora komunikatów komunikat Fatal Alert: Handshake Failure, jak pokazano na ilustracji poniżej:

        

   7. Ten błąd może wystąpić z jednego z tych powodów:
      • Procesor komunikatów nie używa algorytmów zestawu szyfrów obsługiwanych przez serwer backendu.
      • Serwer backendu obsługuje SNI, ale aplikacja kliencka nie wysyła nazwy serwera.
   8. Przyjrzyj się dokładniej wiadomości nr 3 (Client Hello) w tcpdump danych wyjściowych. Zwróć uwagę, że brakuje Extension: server_name, jak pokazano poniżej:

      

   9. Potwierdza to, że procesor komunikatów nie wysłał do serwera backendu obsługującego SNI nazwy server_name.
   10. Jest to przyczyna nieudanego uzgadniania TLS/SSL i powód, dla którego serwer backendu wysyła do procesora wiadomości Fatal Alert: Handshake Failure (Krytyczny alert: nieudane uzgadnianie).
5. Sprawdź, czy wartość jsse.enableSNIExtension property w system.properties jest ustawiona na false (fałsz) w procesorze komunikatów, aby potwierdzić, że procesor komunikatów nie może komunikować się z serwerem obsługującym SNI.

Rozdzielczość

Aby umożliwić procesorom komunikatów komunikację z serwerami z włączonym rozszerzeniem SNI, wykonaj 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. Zmień właściciela tego pliku na apigee:apigee:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Uruchom ponownie procesor komunikatów.

   /opt/apigee/apigee-service/bin/apigee-service message-processor restart

5. Jeśli masz więcej niż 1 procesor komunikatów, powtórz kroki 1–4 na wszystkich procesorach komunikatów.

Jeśli nie możesz ustalić przyczyny niepowodzenia uzgadniania TLS/SSL i rozwiązać problemu lub potrzebujesz dodatkowej pomocy, skontaktuj się z zespołem pomocy Apigee Edge. Podaj szczegółowe informacje o problemie wraz z wynikiem działania polecenia tcpdump.