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 interfejsu API:

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

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

   
3. Otwórz stronę Analiza > Monitorowanie interfejsów API > Zbadaj.
4. Wybierz przedział czasu, w którym zaobserwowano błędy.

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

6. Wybierz komórkę z kodem błędu messaging.adaptors.http.flow.SslHandshakeFailed, jak pokazano poniżej:

   ( wyświetl większy obraz)

   

7. Informacje o kodzie błędu messaging.adaptors.http.flow.SslHandshakeFailed są wyświetlane jak 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:
   • Identyfikator wiadomości żądania
   • Kod stanu: 503
   • Źródło błędu: target
   • Kod błędu: messaging.adaptors.http.flow.SslHandshakeFailed

Trace

Procedura 2. Korzystanie z narzędzia do śledzenia

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

1. Włącz sesję śledzenia i
   • Poczekaj na wystąpienie 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 go odtworzyć. 503 Service Unavailable

2. Sprawdź, czy opcja Show all FlowInfos (Pokaż wszystkie informacje) jest włączona:

   
3. Wybierz 1 z nieudanych żądań i sprawdź log czasu.
4. Przejdź przez różne fazy śledzenia i znajdź miejsce błędu.

5. Błąd pojawia się zwykle po fazie rozpoczęcia przepływu żądania docelowego, jak pokazano poniżej:

   ( wyświetl większy obraz)

   
6. Zapisz 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 wskazuje, że uzgadnianie połączenia SSL nie powiodło się, ponieważ procesor wiadomości Apigee Edge nie był w stanie zweryfikować certyfikatu serwera backendu.
7. Przejdź do fazy AX (rejestrowane dane Analytics) w logu czasu i kliknij ją.

8. Przewiń w dół do sekcji Nagłówki błędów szczegółów i ustal wartości X-Apigee-fault-code, X-Apigee-fault-source oraz X-Apigee-Message-ID, jak pokazano poniżej:

   ( wyświetl większy obraz)

   
9. Zapisz 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 dziennikó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 do określenia kluczowych informacji o HTTP 503 Service Unavailable.

2. Sprawdź logi dostępu do NGINX:

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

3. Sprawdź, czy występują jakieś błędy 503 z kodem błędu messaging.adaptors.http.flow.SslHandshakeFailed w danym czasie (jeśli problem wystąpił w przeszłości) lub czy są jakieś żądania, które nadal kończą się niepowodzeniem z 503.

4. Jeśli znajdziesz błędy 503 z kodem X-Apigee-fault-code pasującym do wartości messaging.adaptors.http.flow.SslHandshakeFailed, sprawdź wartość źródła błędów X-Apigee.

   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 ma następujące wartości kodu X-Apigee-fault-code i X-Apigee-fault-code :

   nagłówków,	Wartość
   X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-fault-source	target

Logi procesora wiadomości

Procedura 4. Używanie dzienników procesora wiadomości

1. Ustal identyfikator wiadomości jednego z nieudanych żądań za pomocą monitorowania interfejsu API, narzędzia do śledzenia lub logów dostępu NGINX zgodnie z opisem w częstych krokach diagnostyki.

2. Wyszukaj identyfikator komunikatu żądania w logu procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log). Możesz zobaczyć taki 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ę uzgadniać połączenia SSL między procesorem wiadomości a serwerem backendu.

   Po tym pojawi się wyjątek ze szczegółowym zrzutem stosu, jak pokazano 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>
     

   Przyczyny błędu uzgadniania połączenia:

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

   Wskazuje to, że uzgadnianie połączenia SSL nie powiodło się, ponieważ procesor wiadomości Apigee Edge nie był w stanie zweryfikować certyfikatu serwera backendu.

Faza 1

Faza 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 certyfikat serwera backendu i certyfikaty zapisane w magazynie zaufania procesora wiadomości

1. Określ łańcuch certyfikatów serwera backendu.
2. Aby określić certyfikat zapisany w magazynie zaufania podmiotu przetwarzającego wiadomości, wykonaj te czynności:

   1. Pobierz nazwę odwołania do magazynu zaufania z elementu TrustStore w sekcji SSLInfo w TargetEndpoint.

      Przyjrzyjmy się przykładowej sekcji SSLInfo w konfiguracji TargetEndpoint:

      <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 do TrustStore to myCompanyTruststoreRef.

   3. W interfejsie użytkownika Edge wybierz Środowiska > Materiały referencyjne. Zapisz nazwę w kolumnie Dokumentacja, aby znaleźć konkretne odwołanie do magazynu zaufania. Będzie to nazwa magazynu zaufania.

      ( wyświetl większy obraz)

      

   4. W powyższym przykładzie nazwa magazynu zaufanych certyfikatów to:

      myCompanyTruststoreRef: myCompanyTruststore

3. Pobierz certyfikaty zapisane w magazynie zaufania (określone w poprzednim kroku) przy użyciu tych interfejsów API:

   1. Pobierz wszystkie certyfikaty z magazynu kluczy lub magazynu zaufanych. Ten interfejs API zawiera listę wszystkich certyfikatów w określonym magazynie zaufania.

      Użytkownik chmury publicznej:

      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
      • Parametr $TOKEN jest ustawiony na token dostępu OAuth 2.0 zgodnie z opisem w sekcji Uzyskiwanie tokena dostępu OAuth 2.0
      • Opcje curl użyte w tym przykładzie są opisane w sekcji Użycie curl

      Przykładowe wyniki:

      Certyfikaty z przykładowego magazynu zaufania myCompanyTruststore to:

      [
        "serverCert"
      ]
      

   2. Pobierz szczegóły certyfikatu dla konkretnego certyfikatu z magazynu kluczy lub Truststore Ten interfejs API zwraca informacje o konkretnym certyfikacie w określonym magazynie zaufania.

      Użytkownik chmury publicznej:

      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
      • Parametr $TOKEN jest ustawiony na token dostępu OAuth 2.0 zgodnie z opisem w sekcji Uzyskiwanie tokena dostępu OAuth 2.0
      • Opcje curl użyte w tym przykładzie są opisane w sekcji Użycie curl

      Przykładowe dane wyjściowe

      Szczegóły dotyczące serverCert zawierają temat i wydawcę:

      Certyfikat liścia/podmiotu:

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

      Certyfikat pośredni:

      "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 rzeczywisty certyfikat serwera uzyskany w kroku 1 i certyfikat zapisany w magazynie zaufania uzyskany w kroku 3 są zgodne. Jeśli nie, to jest przyczyną problemu.

   Na podstawie powyższego przykładu przeanalizujmy tylko jeden certyfikat:

   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 serwera backendu.

   2. Certyfikat pośredni:

      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 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 magazynie zaufania podmiotu przetwarzającego wiadomości w ogóle nie ma certyfikatu głównego.

   4. Ponieważ w magazynie zaufania brakuje certyfikatu głównego, podmiot przetwarzający wiadomości zgłasza ten 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 do aplikacji klienckich 503 Service Unavailable z kodem błędu messaging.adaptors.http.flow.SslHandshakeFailed.

Prawidłowa pełna i jednoznaczna nazwa domeny

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

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

2. Sprawdź, czy masz prawidłowy i kompletny łańcuch certyfikatów serwera backendu.

3. Gdy będziesz mieć prawidłowy i pełny łańcuch certyfikatów z prawidłową pełną i jednoznaczną nazwą domeny serwera backendu w certyfikacie liścia lub jednostki identyczną z nazwą hosta określoną w docelowym punkcie końcowym, zaktualizuj magazyn kluczy backendu, podając pełny łańcuch certyfikatów.

Prawidłowy serwer backendu

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

1. Jeśli nazwa hosta została nieprawidłowo określona w docelowym punkcie końcowym, zaktualizuj docelowy punkt końcowy tak, aby miał prawidłową nazwę hosta zgodną z pełną i jednoznaczną nazwą domeny w certyfikacie serwera backendu.

2. Zapisz zmiany w serwerze proxy interfejsu API.

   Jeśli w omówionym powyżej przykładzie nazwa hosta serwera backendu jest nieprawidłowo określona, możesz rozwiązać ten problem, używając pełnej i jednoznacznej nazwy domeny z certyfikatu serwera backendu, czyli backend.apigee.net w ten 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>