Nieudane uzgadnianie połączenia TLS/SSL

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja 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 przy użyciu Protokół TLS/SSL. Gdy ten błąd wystąpi w Apigee Edge, klient aplikacja otrzymuje stan HTTP 503 i komunikat Service Unavailable (Usługa niedostępna). Ty zobaczysz ten błąd po każdym wywołaniu interfejsu API, które powoduje niepowodzenie uzgadniania połączenia TLS/SSL.

Komunikaty o błędach

HTTP/1.1 503 Service Unavailable

Ten komunikat o błędzie może się też wyświetlić, gdy wystąpi błąd uzgadniania połączenia TLS/SSL:

Received fatal alert: handshake_failure

Możliwe przyczyny

TLS (Transport Layer Security, którego poprzednik to protokół SSL) to standardowa technologia zabezpieczeń nawiązania zaszyfrowanego połączenia między serwerem WWW a klientem internetowym, np. przeglądarką lub aplikacją. Uzgadnianie połączenia to proces, który umożliwia klientowi i serwerowi TLS/SSL ustanowienie zestawu obiektów tajnych za pomocą których mogą się one komunikować. W trakcie tego procesu klient i serwer:

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

Jeśli uzgadnianie połączenia TLS/SSL zakończy się powodzeniem, klient TLS/SSL i serwer przesyłają dane do każdego inne bezpieczne. W przeciwnym razie, jeśli wystąpi niepowodzenie uzgadniania połączenia TLS/SSL, połączenie zostanie zakończone, a klient otrzymuje błąd 503 Service Unavailable.

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

Protokół Niezgodność

Błąd uzgadniania połączenia TLS/SSL występuje, jeśli protokół używany przez klienta nie jest obsługiwany przez – do połączenia przychodzącego (w kierunku północnym) lub wychodzącego (południowo). Zobacz też Informacje o połączeniach w kierunku północnym i południowym.

Diagnostyka

1. Ustal, czy błąd wystąpił na północnej lub południowo. Dalsze wskazówki determinacja, zobacz Określanie źródła problemu.
2. Użycie tcpdump, aby uzyskać więcej informacji:
   • Jeśli jesteś użytkownikiem Private Cloud, możesz zbierać tcpdump dane na odpowiednim kliencie lub serwerze. Klientem może być aplikacja kliencka (w przypadku aplikacji klienckich, lub połączeń w kierunku północnym) bądź Wiadomości Procesor (na potrzeby połączeń wychodzących lub wychodzących). Serwerem może być router brzegowy (dla połączenia przychodzące lub skierowane w kierunku północnym) lub serwer backendu (w przypadku połączeń wychodzących lub południowych) na podstawie danych określonych w kroku 1.
   • Jeśli jesteś użytkownikiem Public Cloud, możesz zbierać tcpdump dane tylko w aplikacji klienckiej (w przypadku połączeń przychodzących lub w kierunku północnym) albo na serwerze backendu (w przypadku połączeń wychodzących lub wychodzących), ponieważ nie mają dostępu do routera brzegowego ani procesora wiadomości.

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

   Zobacz tcpdump, aby dowiedzieć się więcej o korzystaniu z tcpdump. .
3. Przeprowadź analizę danych tcpdump za pomocą narzędzia Wireshark lub podobnym narzędziu.
4. Oto przykładowa analiza tcpdump za pomocą programu Wireshark:
   • W tym przykładzie wystąpił błąd uzgadniania połączenia TLS/SSL pomiędzy serwer backendu (połączenie wychodzące lub południowe).
   • Komunikat nr 4 w poniższych danych wyjściowych tcpdump informuje, że procesor wiadomości (źródło) wysłał „Client Hello” wiadomość do serwera backendu (miejsce docelowe).
     

     

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

     

   • Komunikat nr 5 pokazuje, że serwer backendu potwierdza wiadomość „Client Hello” wiadomość od do procesora wiadomości.
   • Serwer backendu natychmiast wysyła komunikat Alert krytyczny : Zamknij powiadomienie do Procesor wiadomości (komunikat 6). Oznacza to, że nie udało się uzgadniać połączenia TLS/SSL, a połączenie zostać zamknięte.

   • Analiza komunikatu nr 6 wskazuje, że przyczyną niepowodzenia 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 serwer backendu, serwer backendu wysłał komunikat: Komunikat o błędzie krytycznym: Zamknij Powiadom.

Rozdzielczość

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

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 wymuszanie przez procesor wiadomości używania protokołu TLSv1.0 do komunikacji z z serwerem backendu, wykonując te czynności:
   1. Jeśli nie określono serwera docelowego w definicji docelowego punktu końcowego serwera proxy, ustaw wartość element Protocol na TLSv1.0, jak pokazano na ilustracji 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 skonfigurowano serwera docelowego dla serwera proxy, a potem użyj ten interfejs API do zarządzania, aby ustawić protokół na TLSv1.0 w konkretnym konfigurację serwera docelowego.

Niezgodność szyfrowania

Jeśli algorytm zestawu szyfrów używany przez klienta nie jest używany, możesz zobaczyć błąd uzgadniania połączenia TLS/SSL obsługiwane przez serwer na połączeniu przychodzącym (w kierunku północnym) lub wychodzącego (południowo) w Apigee Edge. Zobacz też . Informacje o połączeniach w kierunku północnym i południowym.

Diagnostyka

1. Sprawdź, czy błąd wystąpił połączenie kierunkowe na północ lub południowe. Dalsze wskazówki, które pomogą Ci w podejmowaniu takiej decyzji, znajdziesz tutaj: Ustalanie źródło problemu.
2. Użycie tcpdump, aby uzyskać więcej informacji:
   • Jeśli jesteś użytkownikiem Private Cloud, możesz zbierać tcpdump dane na odpowiednim kliencie lub serwerze. Klientem może być aplikacja kliencka (w przypadku aplikacji klienckich, lub połączeń w kierunku północnym) bądź Wiadomości Procesor (na potrzeby połączeń wychodzących lub wychodzących). Serwerem może być router brzegowy (dla połączenia przychodzące lub skierowane w kierunku północnym) lub serwer backendu (w przypadku połączeń wychodzących lub południowych) na podstawie danych określonych w kroku 1.
   • Jeśli jesteś użytkownikiem Public Cloud, możesz zbierać tcpdump dane tylko w aplikacji klienckiej (w przypadku połączeń przychodzących lub w kierunku północnym) albo na serwerze backendu (w przypadku połączeń wychodzących lub wychodzących), ponieważ nie mają dostępu do routera brzegowego ani procesora wiadomości.

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

   Zobacz tcpdump, aby dowiedzieć się więcej o korzystaniu z polecenia tcpdump.
3. Przeprowadź analizę danych tcpdump za pomocą narzędzia Wireshark lub innym narzędziu, które znasz.
4. Oto przykładowa analiza danych wyjściowych tcpdump za pomocą programu Wireshark:
   • W tym przykładzie wystąpił błąd uzgadniania połączenia TLS/SSL między aplikacją kliencką Router brzegowy (połączenie w kierunku północnym). Dane wyjściowe usługi tcpdump zostały zebrane na urządzeniu Edge ani nim zarządzać.

   • Komunikat nr 4 w poniższych danych wyjściowych tcpdump wskazuje, że aplikacja kliencka (źródłowa) wysłała „Client Hello” wiadomość do routera brzegowego (miejsce docelowe).

     

   • Wybranie komunikatu Client Hello pokazuje, że aplikacja kliencka używa Protokół TLSv1.2.

     

   • Komunikat nr 5 pokazuje, że router brzegowy potwierdził użycie polecenia „Client Hello” wiadomość od do aplikacji klienckiej.
   • Router brzegowy natychmiast wysyła alert krytyczny : błąd uzgadniania połączenia do aplikację kliencką (komunikat 6). Oznacza to, że uzgadnianie połączenia TLS/SSL nie powiodło się, a połączenie zostanie zamknięte.
   • Szczegółowa analiza komunikatu nr 6 zawiera następujące 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 alert krytyczny: uzgadnianie połączenia Błąd w aplikacji klienckiej, jak na zrzucie ekranu poniżej:

       

   • Możliwe przyczyny tego 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 nazwę serwera.
   • Wiadomość nr 4 w danych wyjściowych tcpdump zawiera listę algorytmów zestawu szyfrów obsługiwanych przez klienta aplikacji, jak pokazano poniżej:

     

   • Lista algorytmów zestawu szyfrów obsługiwanych przez router brzegowy znajduje się w /opt/nginx/conf.d/0-default.conf. W tym przykładzie router brzegowy obsługuje wyłącznie algorytmy zestawu szyfrów High Encryption.
   • Aplikacja kliencka nie używa żadnego z algorytmów zestawu szyfrów o wysokim stopniu szyfrowania. Ta niezgodność jest przyczyną Nie udało się uzgadniać połączenia TLS/SSL.
   • Ponieważ router brzegowy ma włączoną obsługę SNI, przewiń w dół do komunikatu nr 4 w danych wyjściowych tcpdump, a następnie Sprawdź, czy aplikacja kliencka poprawnie wysyła nazwę serwera, jak widać w ilustracja poniżej:
     
     
     
   • Jeśli ta nazwa jest prawidłowa, możesz wywnioskować, że niepowodzenie uzgadniania połączenia TLS/SSL wystąpiła, ponieważ algorytmy zestawu szyfrów używane przez aplikację kliencką nie są obsługiwane routera brzegowego.

Rozdzielczość

Musisz się upewnić, że klient używa algorytmów zestawu szyfrów, które są obsługiwany przez serwer. Rozwiązanie problemu opisanego powyżej Diagnostyka, pobierz i zainstaluj pakietu Java Cryptography Extension (JCE) i umieść je w języku Java na potrzeby obsługi algorytmów zestawu szyfrów High Encryption.

Nieprawidłowy certyfikat

Błąd uzgadniania połączenia TLS/SSL występuje, jeśli masz nieprawidłowe certyfikaty w magazynie kluczy/magazynie kluczy albo na połączeniu przychodzącym (w kierunku północnym) lub wychodzącego (południowo) w Apigee Edge. Zobacz też Informacje o połączeniach w kierunku północnym i południowym.

Jeśli problem występuje w kierunku północnym, mogą być wyświetlane różne komunikaty o błędach w zależności od ich przyczyny.

W sekcjach poniżej znajdziesz przykładowe komunikaty o błędach oraz instrukcje diagnozowania i rozwiązywania tego problemu Google Cloud.

Komunikaty o błędach

W zależności od przyczyny niepowodzenia uzgadniania połączenia TLS/SSL możesz zobaczyć różne komunikaty o błędach. Oto przykładowy komunikat o błędzie, który możesz zobaczyć 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

Oto typowe przyczyny:

Nazwa hosta Niezgodność

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

   Na przykład:

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

2. Pobierz numer CN używany w certyfikacie zapisanym w konkretnym magazynie kluczy. Za pomocą te interfejsy API do zarządzania brzegiem, aby pobrać szczegóły certyfikatu:
   1. Pobierz nazwę certyfikatu z magazynu kluczy:
      
      Jeśli jesteś użytkownikiem Private Cloud, możesz używać interfejsu Management API 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 Public Cloud Cloud, możesz używać interfejsu Management API 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 z magazynu 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 Public Cloud Cloud:
      

      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 jako something.domain.com.

      Ponieważ nazwa hosta użyta w adresie URL żądania interfejsu API (patrz krok nr 1 powyżej) i temat nazwa w certyfikacie nie jest zgodna, wystąpi 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), w którym CN podmiotu ma symbol wieloznaczny certyfikatu, 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ącą wartością CN podmiotu, ale użyj your-orgyour-domain jako alternatywną nazwę tematu, a następnie prześlij pełną łańcucha certyfikatów do magazynu kluczy.

Pliki referencyjne

Magazyny kluczy Truststores

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

Diagnostyka

1. Pobierz numer CN używany w certyfikacie zapisanym w konkretnym magazynie kluczy. Za pomocą te interfejsy API do zarządzania brzegiem, aby pobrać szczegóły certyfikatu:
   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 Public Cloud Cloud:
      

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

   2. Pobierz szczegóły 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/cert-name
      

      Jeśli jesteś użytkownikiem Public Cloud Cloud:
      

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

   3. Zweryfikuj certyfikat i jego łańcuch oraz upewnij się, że są zgodne zgodnie z wytycznymi podanymi w artykule Jak działają łańcuchy certyfikatów, aby zapewnić prawidłowość i kompletność certyfikatów łańcucha certyfikatów. Jeśli łańcuch certyfikatów przechowywany w magazynie kluczy to jest niekompletna lub nieprawidłowa, pojawia się uzgadnianie połączenia TLS/SSL. niepowodzenie.
   4. Na diagramie poniżej widać przykładowy certyfikat z nieprawidłowym łańcuchem certyfikatów które nie są zgodne z certyfikatem pośrednim i certyfikatem głównym:

   Przykładowy certyfikat pośredni i główny, gdzie wydawca i nie pasuje do tematu

   
   

Rozdzielczość

1. Uzyskaj certyfikat (jeśli jeszcze go nie masz) zawierający kompletny i ważny łańcucha certyfikatów.
2. Uruchom to polecenie opensl, aby sprawdzić, czy łańcuch certyfikatów jest prawidłowy i zakończono:

   openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert

3. Prześlij łańcuch zweryfikowanych certyfikatów do magazynu kluczy.

Wygasłe lub nieznane certyfikat wysłany przez serwer lub klienta

Jeśli serwer/klient wysłał nieprawidłowy lub wygasły certyfikat albo w kierunku północnym, lub w połączeniu południowym, serwer/klient odrzuca certyfikat. co prowadzi do niepowodzenia uzgadniania połączenia TLS/SSL.

Diagnostyka

1. Ustal, czy błąd wystąpił na północnej lub południowo. Dalsze wskazówki determinacja, zobacz Określanie źródła problemu.
2. Użycie tcpdump, aby uzyskać więcej informacji:
   • Jeśli jesteś użytkownikiem Private Cloud, możesz zbierać tcpdump dane na odpowiednim kliencie lub serwerze. Klientem może być aplikacja kliencka (w przypadku aplikacji klienckich, lub połączeń w kierunku północnym) bądź Wiadomości Procesor (na potrzeby połączeń wychodzących lub wychodzących). Serwerem może być router brzegowy (dla połączenia przychodzące lub skierowane w kierunku północnym) lub serwer backendu (w przypadku połączeń wychodzących lub południowych) na podstawie danych określonych w kroku 1.
   • Jeśli jesteś użytkownikiem Public Cloud, możesz zbierać tcpdump dane tylko w aplikacji klienckiej (w przypadku połączeń przychodzących lub w kierunku północnym) albo na serwerze backendu (w przypadku połączeń wychodzących lub wychodzących), ponieważ nie mają dostępu do routera brzegowego ani procesora wiadomości.

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

   Zobacz tcpdump, aby dowiedzieć się więcej o korzystaniu z polecenia tcpdump.
3. Przeprowadź analizę danych tcpdump za pomocą Wireshark lub podobnego narzędzia.
4. Na podstawie danych wyjściowych tcpdump określ hosta (klient lub serwer), który odrzuca podczas weryfikacji.
5. Certyfikat wysłany z drugiego końca strony możesz pobrać z danych wyjściowych tcpdump, pod warunkiem że: dane nie są zaszyfrowane. Przyda się to do porównania, czy ten certyfikat jest zgodny z który jest dostępny w magazynie zaufania.
6. Zapoznaj się z przykładowym dokumentem tcpdump dotyczącym komunikacji SSL między procesorem wiadomości a do serwera backendu.

   Przykładowy tcpdump z błędem „Nieznany certyfikat”

   
   

   1. Procesor wiadomości (klient) wysyła komunikat „Client Hello”. do serwera backendu (serwer) w komunikacie nr 59.
   2. Serwer backendu wysyła komunikat „Server Hello”. do procesora wiadomości w wiadomości 61.
   3. Sprawdzają one wzajemnie używane algorytmy protokołu i zestawu szyfrów.
   4. Serwer backendu wysyła komunikat Certificate and Hello Done do Procesor wiadomości w wiadomości nr 68.
   5. The Message Processor wysyła alert krytyczny „Description: Certificate” Nieznana” w komunikacie nr 70.
   6. Po zapoznaniu się z komunikatem nr 70 nie ma żadnych dodatkowych szczegółów niż komunikat z ostrzeżeniem, jak pokazano poniżej:

      
      

   7. Sprawdź komunikat nr 68, aby uzyskać szczegóły certyfikatu wysłanego przez backend zgodnie z tą ilustracją:

      

   8. Certyfikat serwera backendu i jego pełny łańcuch są dostępne poniżej sekcji „Certyfikaty” tak jak na ilustracji powyżej.
7. Jeśli certyfikat jest nieznany przez router (w kierunku północnym) albo Procesor wiadomości (na zewnątrz) jak w przykładzie powyżej, a następnie postępuj zgodnie z kroki:
   1. Pobierz certyfikat i jego łańcuch, który jest przechowywany w określonym magazynie zaufania. (Strona odsyłająca do konfiguracji hosta wirtualnego dla routera i konfiguracji docelowego punktu końcowego (procesora wiadomości). Za pomocą poniższych interfejsów API możesz uzyskać szczegółowe informacje certyfikat:
      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 Truststore:

         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 zaufania routera (w kierunku północnym) lub Procesor komunikatów (południowy) jest zgodny z certyfikatem przechowywanym w magazynu kluczy aplikacji klienckiej (w kierunku północnym) lub serwera docelowego (w kierunku południowym) lub który jest uzyskiwany z danych wyjściowych tcpdump. Jeśli dane nie są zgodne, to właśnie one są przyczyną nie uda się uzgadniać połączenia TLS/SSL.
8. Jeśli certyfikat jest nieznany przez aplikację kliencką (w kierunku północnym) lub serwer docelowy (południowy), wykonaj te czynności:
   1. Uzyskaj pełny łańcuch certyfikatów używany w certyfikacie zapisanym w określonym do magazynu kluczy. Zapoznaj się z konfiguracją hosta wirtualnego dla routera i docelowego punktu końcowego dla procesora wiadomości). Możesz użyć poniższych interfejsów API, aby pobrać szczegóły certyfikatu:
      1. Pobierz nazwę certyfikatu z magazynu kluczy:

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

      2. Pobierz szczegóły certyfikatu z magazynu 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 (w kierunku północnym) lub Procesor wiadomości (południowy) jest zgodny z certyfikatem zapisanym w magazynie zaufania aplikacji klienckiej (w kierunku północnym) lub serwerze docelowym (w kierunku południowym) bądź uzyskane z danych wyjściowych tcpdump. Niezgodność jest przyczyną występowania nieprawidłowości SSL niepowodzenie uzgadniania połączenia.
9. Jeśli okaże się, że certyfikat wysłany przez serwer/klienta stracił ważność, klient/serwer odrzuca certyfikat i w sekcji tcpdump:

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

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 kod serwera backendu i umieścić certyfikat w trustore w ramach procesora wiadomości.

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

Włączono SNI Serwer

Błąd uzgadniania połączenia TLS/SSL może wystąpić, gdy klient komunikuje się z serwerem Włączono Name Indication (SNI) Serwer, ale klient nie ma włączonego rozszerzenia SNI. Może to być na północy połączenie w kierunku południowym w Edge.

Najpierw podaj nazwę hosta i numer portu używanego serwera oraz sprawdź, czy czy rozszerzenie SNI jest włączone, czy nie.

Identyfikacja serwera z włączonym SNI

1. Wykonaj polecenie openssl i spróbuj połączyć się z odpowiednią nazwą hosta serwera (Edge routera lub serwera backendu) bez przekazywania nazwy serwera, jak w przykładzie poniżej:

   openssl s_client -connect hostname:port
   

   Możesz otrzymać certyfikaty, a czasami może wystąpić błąd uzgadniania połączenia użyj polecenia 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 (router brzegowy lub serwer backendu), przekazując nazwę serwera w ten sposób:

   openssl s_client -connect hostname:port -servername hostname
   

3. Jeśli w kroku 1 wystąpi błąd uzgadniania połączenia lub uzyskasz inne certyfikaty w kroku 1 i kroku nr 2, oznacza to, że podany serwer ma włączony protokół SNI.

Jeśli wykryjesz, że serwer ma włączony rozszerzenie SNI, możesz wykonać poniższe czynności, aby Sprawdź, czy niepowodzenie uzgadniania połączenia TLS/SSL jest spowodowane tym, że klient nie może się komunikować z oraz serwer SNI.

Diagnostyka

1. Ustal, czy błąd wystąpił na północnej lub południowo. Dalsze wskazówki determinacja, zobacz Określanie źródła problemu.
2. Użycie tcpdump, aby uzyskać więcej informacji:
   • Jeśli jesteś użytkownikiem Private Cloud, możesz zbierać tcpdump dane na odpowiednim kliencie lub serwerze. Klientem może być aplikacja kliencka (w przypadku aplikacji klienckich, lub połączeń w kierunku północnym) bądź Wiadomości Procesor (na potrzeby połączeń wychodzących lub wychodzących). Serwerem może być router brzegowy (dla połączenia przychodzące lub skierowane w kierunku północnym) lub serwer backendu (w przypadku połączeń wychodzących lub południowych) na podstawie danych określonych w kroku 1.
   • Jeśli jesteś użytkownikiem Public Cloud, możesz zbierać tcpdump dane tylko w aplikacji klienckiej (w przypadku połączeń przychodzących lub w kierunku północnym) albo na serwerze backendu (w przypadku połączeń wychodzących lub wychodzących), ponieważ nie mają dostępu do routera brzegowego ani procesora wiadomości.

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

   Zobacz . tcpdump, aby dowiedzieć się więcej o korzystaniu z polecenia tcpdump.
3. Przeanalizuj dane wyjściowe tcpdump za pomocą programu Wireshark lub podobnego narzędzia.
4. Oto przykładowa analiza tcpdump przy użyciu Wireshark:
   1. W tym przykładzie nie udało się uzgadniać połączenia TLS/SSL między wiadomością brzegową Procesor i serwer backendu (połączenie wychodzące).
   2. Komunikat nr 4 w poniższych danych wyjściowych tcpdump wskazuje, że procesor wiadomości (źródło) wysłał Polecenie „Client Hello” wiadomość do serwera backendu (miejsce docelowe).

      

   3. Wybieranie komunikatu „Client Hello” że komunikat Procesor używa protokołu TLSv1.2.

      

   4. Komunikat nr 4 pokazuje, że serwer backendu potwierdza wiadomość „Client Hello”. wiadomość z procesora wiadomości.
   5. Serwer backendu natychmiast wysyła Alert krytyczny : uzgadnianie połączenia Awaria procesora wiadomości (komunikat nr 5). Oznacza to, że uzgadnianie połączenia TLS/SSL nie udało się i połączenie zostanie zamknięte.
   6. Przeczytaj wiadomość nr 6, aby uzyskać następujące informacje:
      • Serwer backendu obsługuje protokół TLSv1.2. Oznacza to, że protokół między procesorami wiadomości a serwerem backendu.
      • Jednak serwer backendu nadal wysyła Alert krytyczny: uzgadnianie połączenia Awaria procesora wiadomości, jak na ilustracji poniżej:

        

   7. Ten błąd może wystąpić z jednej z tych przyczyn:
      • Procesor wiadomości nie używa algorytmów zestawu szyfrów obsługiwanych przez z serwera backendu.
      • Na serwerze backendu jest włączony rozszerzenie SNI, ale aplikacja kliencka nie wysyła wiadomości nazwę serwera.
   8. Sprawdź bardziej szczegółowo wiadomość nr 3 (Client Hello) w danych wyjściowych tcpdump. Pamiętaj, że parametr Brak rozszerzenia server_name, jak pokazano poniżej:

      

   9. Jest to potwierdzenie, że procesor wiadomości nie wysłał server_name do serwera backendu z obsługą SNI.
   10. Jest to przyczyna niepowodzenia uzgadniania połączenia TLS/SSL i przyczyna, dla której backend Serwer wysyła do komunikatu Alert krytyczny: brak uzgadniania połączenia Procesor.
5. Sprawdź, czy klucz jsse.enableSNIExtension property w: system.properties ma wartość Fałsz w procesorze wiadomości, aby potwierdzić, że Procesor komunikatów nie został włączony do komunikowania się z serwerem obsługującym SNI.

Rozdzielczość

Włącz procesory wiadomości na potrzeby komunikacji z serwerami z obsługą SNI, wykonując następujące kroki:

1. Utwórz /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 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ż jeden procesor wiadomości, powtórz kroki od 1 do 4 na Procesory wiadomości.

Jeśli nie możesz określić przyczyny błędu uzgadniania połączenia TLS/SSL i rozwiązanie problemu. Jeśli potrzebujesz dodatkowej pomocy, skontaktuj się z Obsługa Apigee Edge Podaj pełne informacje o problemie wraz z informacjami, dane wyjściowe funkcji tcpdump.