503 Usługa niedostępna – błąd uzgadniania połączenia SSL

Monitorowanie interfejsów API

Procedura 1. Korzystanie z monitorowania interfejsów API

Aby zdiagnozować błąd za pomocą monitorowania interfejsów API:

1. Zaloguj się w interfejsie Apigee Edge jako użytkownik z uprawnieniami odpowiednią rolę.

2. Przełącz się na organizację, w której chcesz zbadać problem.

   
3. Przejdź do przycisku Analiza > Monitorowanie interfejsów API > Zbadaj stronę.
4. Wybierz okres, w którym zaobserwowano błędy.

5. Porównaj Kod błędu z czasem.

6. Wybierz komórkę, która zawiera kod błędu messaging.adaptors.http.flow.SslHandshakeFailed jak pokazano na ekranie poniżej:

   ( wyświetl większy obraz)

   

7. Informacje o kodzie błędu messaging.adaptors.http.flow.SslHandshakeFailed jest wyświetlany jako poniżej:

   ( wyświetl większy obraz)

   

8. Kliknij Wyświetl logi i rozwiń wiersz nieudanego żądania.

   ( wyświetl większy obraz)

   
9. W oknie Logi zwróć uwagę na te informacje:
   • Request Message ID (Identyfikator wiadomości żądania)
   • Kod stanu: 503
   • Źródło błędu: target
   • Kod błędu: messaging.adaptors.http.flow.SslHandshakeFailed

Śledzenie

Procedura 2. Używanie narzędzia śledzenia

Aby zdiagnozować błąd za pomocą narzędzia śledzenia:

1. Włącz sesję śledzenia i wykonaj jedną z tych czynności:
   • Poczekaj na pojawienie się błędu 503 Service Unavailable z kodem błędu messaging.adaptors.http.flow.SslHandshakeFailed lub
   • Jeśli możesz odtworzyć problem, wykonaj wywołanie interfejsu API, aby odtworzyć problem. 503 Service Unavailable

2. Sprawdź, czy opcja Show all FlowInfos jest włączona:

   
3. Wybierz jedno z nieudanych żądań i sprawdź log czasu.
4. Przejdź przez różne fazy śledzenia i znajdź miejsca, w których wystąpił błąd.

5. Błąd pojawia się zwykle po etapie Rozpoczęto docelowy przepływ żądań jak poniżej:

   ( wyświetl większy obraz)

   
6. Zanotuj te wartości ze logu czasu:
   • błąd: SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.cause: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.class::com.apigee.errors.http.server.ServiceUnavailableException
   • Wartość błędu SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target oznacza, że uzgadnianie połączenia SSL nie powiodło się. ponieważ procesor komunikatów Apigee Edge nie mógł sprawdzić poprawności certyfikat.
7. Przejdź do fazy AX (zarejestrowane dane Analytics) i kliknij ją.

8. Przewiń w dół do sekcji Phase Details Error Headers (Nagłówki błędów szczegółów etapu) i określ wartości X-Apigee-fault-code i X-Apigee-fault-source; X-Apigee-Message-ID zgodnie z poniższym przykładem:

   ( wyświetl większy obraz)

   
9. Zwróć uwagę na wartości X-Apigee-fault-code, X-Apigee-fault-source, i X-Apigee-Message-ID:

Nagłówki błędów	Wartość
X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
X-Apigee-fault-source	target
X-Apigee-Message-ID	MESSAGE_ID

NGINX

Procedura 3. Używanie logów dostępu NGINX

Aby zdiagnozować błąd przy użyciu logów dostępu NGINX:

1. Jeśli jesteś użytkownikiem Private Cloud, możesz użyć logów dostępu NGINX, aby określić Kluczowe informacje o HTTP 503 Service Unavailable.

2. Sprawdź logi dostępu NGINX:

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

3. Wyszukaj błędy (503) z kodem błędu messaging.adaptors.http.flow.SslHandshakeFailed w określonym czasie (jeśli problem wystąpił w wcześniejsze) lub jeśli jakieś żądania z usługą 503 nadal kończą się niepowodzeniem.

4. Jeśli znajdziesz błędy 503 przy dopasowaniu X-Apigee-fault-code wartość messaging.adaptors.http.flow.SslHandshakeFailed, a następnie określić wartość źródła X-Apigee-fault-source..

   Przykładowy błąd 503 z dziennika dostępu NGINX:

   ( wyświetl większy obraz)

   

   Powyższy przykładowy wpis z logu dostępu NGINX zawiera następujące wartości dla: X-Apigee-fault-code i X-Apigee-fault-code

   Nagłówki	Wartość
   X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-fault-source	target

Logi procesora wiadomości

Procedura 4. Korzystanie z logów procesora wiadomości

1. Ustal identyfikator wiadomości jednego z nieudanych żądań za pomocą monitorowania interfejsów API, narzędzia do śledzenia lub logów dostępu NGINX. Więcej informacji znajdziesz w sekcji Typowe kroki diagnostyki.

2. Wyszukaj identyfikator wiadomości z określonym żądaniem w dzienniku procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log). Możesz zaobserwować ten błąd:

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
   SSLClientChannel[Connected: Remote:X.X.X.X:443
   Local:192.168.194.140:55102]@64596 useCount=1
   bytesRead=0 bytesWritten=0 age=233ms  lastIO=233ms
   isOpen=true handshake failed, message: General SSLEngine problem
   

   Powyższy błąd oznacza, że nie udało się nawiązać połączenia SSL między procesorem wiadomości i serwer backendu.

   Po tym czasie będzie miał wyjątek ze szczegółowym zrzutem stosu, jak poniżej:

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
   RequestWriteListener.onException(HTTPRequest@1522922c)
   javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478)
   	at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
   	... <snipped>
   Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Alerts.getSSLException(Alerts.java:203)
   	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
   	... <snipped>
   Caused by: sun.security.validator.ValidatorException: PKIX path building failed:
   sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
   certification path to requested target
   	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
   	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
   	... <snipped>
     

   Pamiętaj, że niepowodzenie uzgadniania połączenia może mieć następujące przyczyny:

   Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

   Oznacza to, że nie udało się uzgadniać połączenia SSL, ponieważ procesor komunikatów Apigee Edge nie udało się zweryfikować certyfikatu serwera backendu.

Faza 1

Etap 1. Określ łańcuch certyfikatów serwera backendu

Aby określić łańcuch certyfikatów serwera backendu, użyj jednej z tych metod:

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

Certificate chain
 0 s:/CN=mocktarget.apigee.net
   i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
 1 s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
 2 s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

Faza 2

Etap 2. Porównaj certyfikaty serwera backendu oraz certyfikaty przechowywane w Truststore procesora wiadomości

1. Określ łańcuch certyfikatów serwera backendu.
2. Określ certyfikat przechowywany w magazynie zaufania podmiotu przetwarzającego wiadomości za pomocą te kroki:

   1. Pobierz nazwę referencyjną magazynu zaufania z elementu TrustStore w sekcji SSLInfo w TargetEndpoint.

      Spójrzmy na przykładową sekcję SSLInfo w TargetEndpoint. Konfiguracja:

      <TargetEndpoint name="default">
      ...
         <HTTPTargetConnection>
            <Properties />
            <SSLInfo>
               <Enabled>true</Enabled>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <KeyStore>ref://myKeystoreRef</KeyStore>
               <KeyAlias>myKey</KeyAlias>
               <TrustStore>
                  ref://myCompanyTrustStoreRef
               </TrustStore>
            </SSLInfo>
         </HTTPTargetConnection>
         ...
      </TargetEndpoint>
      

   2. W tym przykładzie nazwa odniesienia TrustStore to myCompanyTruststoreRef

   3. W interfejsie Edge wybierz Środowiska > Pliki referencyjne. Zapisz nazwę w Kolumna Odniesienie do konkretnej odwołania do magazynu zaufania. To będzie Twój nazwę magazynu zaufania.

      ( wyświetl większy obraz)

      

   4. W tym przykładzie nazwa magazynu zaufania to:

      myCompanyTruststoreRef: myCompanyTruststore

3. Pobierz certyfikaty zapisane w magazynie zaufania (określone w poprzednim kroku) przy użyciu następujących interfejsów API:

   1. Pobieranie wszystkich certyfikatów magazynu kluczy lub magazynu zaufania Ten interfejs API zawiera listę wszystkich certyfikatów w określonym magazynie zaufania.

      Użytkownik Public Cloud:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      Użytkownik Private Cloud:

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      Gdzie:

      • ORGANIZATION_NAME to nazwa organizacji
      • ENVIRONMENT_NAME to nazwa środowiska.
      • KEYSTORE_NAME to nazwa magazynu kluczy
      • $TOKEN jest ustawiony na Twój token dostępu OAuth 2.0 zgodnie z opisem w Uzyskiwanie tokena dostępu OAuth 2.0
      • Opcje curl użyte w tym przykładzie zostały opisane tutaj: Użyj curl

      Przykładowe wyniki:

      Certyfikaty z przykładowego magazynu zaufania myCompanyTruststore:

      [
        "serverCert"
      ]
      

   2. Uzyskaj szczegóły certyfikatu konkretnego certyfikatu z magazynu kluczy lub Truststore. Ten interfejs API zwraca informacje o konkretnym certyfikacie w sekcji magazynu zaufania.

      Użytkownik Public Cloud:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      Użytkownik Private Cloud

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#>/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      Gdzie:

      • ORGANIZATION_NAME to nazwa organizacji
      • ENVIRONMENT_NAME to nazwa środowiska.
      • KEYSTORE_NAME to nazwa magazynu kluczy
      • CERT_NAME to nazwa certyfikatu
      • $TOKEN jest ustawiony na Twój token dostępu OAuth 2.0 zgodnie z opisem w Uzyskiwanie tokena dostępu OAuth 2.0
      • Opcje curl użyte w tym przykładzie zostały opisane tutaj: Użyj curl

      Przykładowe dane wyjściowe

      Szczegóły etykiety serverCert wyświetlają się w następujący sposób:

      Certyfikat liścia/jednostki:

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      

      Certyfikat średniozaawansowany:

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",
      

4. Sprawdź, czy certyfikat serwera uzyskany w kroku 1 oraz certyfikat przechowywanych w magazynie zaufania uzyskanym w kroku 3. Jeśli nazwy się nie zgadzają, jest to przyczyna problemu.

   Na podstawie przykładu powyżej sprawdźmy po jednym certyfikacie naraz:

   1. Certyfikat liścia:

      Z serwera backendu:

      s:/CN=mocktarget.apigee.net
      i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
      

      W magazynie zaufania podmiotu przetwarzającego wiadomości (klienta):

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      

      Certyfikat liścia przechowywany w magazynie zaufania jest zgodny z certyfikatem backendu serwera.

   2. Certyfikat średniozaawansowany:

      Z serwera backendu:

      s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      

      W magazynie zaufania podmiotu przetwarzającego wiadomości (klienta):

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",
      

      Certyfikat pośredni przechowywany w magazynie zaufania jest zgodny z certyfikatem z serwera backendu.

   3. Certyfikat główny:

      Z serwera backendu:

      s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      

      W procesorze wiadomości brakuje w pełni certyfikatu głównego magazynu zaufania.

   4. Ponieważ w magazynie zaufania brakuje certyfikatu głównego, Procesor wiadomości zgłasza następujący wyjątek:

      sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
      

      i zwraca 503 Service Unavailable z kodem błędu messaging.adaptors.http.flow.SslHandshakeFailed dla klienta aplikacji.

Prawidłowa pełna i jednoznaczna nazwa domeny

Zaktualizuj magazyn kluczy serwera backendu, podając prawidłową pełną i jednoznaczną nazwę domeny, prawidłowy i kompletny certyfikat łańcuch:

1. Jeśli nie masz certyfikatu serwera backendu z prawidłową nazwą domeny, a potem kup odpowiedni certyfikat z odpowiedniego urzędu certyfikacji.

2. Potwierdź, że posiadasz poprawnego i pełnego łańcucha certyfikatów serwera backendu.

3. Gdy masz już prawidłowy i kompletny łańcuch certyfikatów z prawidłową i pełną nazwą domeny serwer backendu w liściu lub w certyfikacie jednostki identycznym z nazwą hosta określonego w docelowym punkcie końcowym, zaktualizuj magazyn kluczy backendu za pomocą funkcji do pełnego łańcucha certyfikatów.

Prawidłowy serwer backendu

Zaktualizuj docelowy punkt końcowy, podając prawidłową nazwę hosta serwera backendu:

1. Jeśli w docelowym punkcie końcowym nazwa hosta została błędnie określona, zaktualizuj parametr docelowy punkt końcowy tak, aby miał prawidłową nazwę hosta, która zgadza się z pełną i jednoznaczną nazwą domeny w backendzie certyfikat serwera.

2. Zapisz zmiany na serwerze proxy interfejsu API.

   W omówionym powyżej przykładzie nazwa hosta serwera backendu była nieprawidłowa możesz go naprawić, używając pełnej i jednoznacznej nazwy domeny z certyfikatu serwera backendu. to backend.apigee.net w następujący sposób:

   <TargetEndpoint name="default">
      …
      <HTTPTargetConnection>
         <Properties />
         <SSLInfo>
            <Enabled>true</Enabled>
            <TrustStore>ref://myTrustStoreRef</TrustStore>
         </SSLInfo>
         <URL>https://backend.apigee.net/resource</URL>
      </HTTPTargetConnection>
   </TargetEndpoint>