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

Monitorowanie interfejsów API

Procedura 1. Korzystanie z monitorowania interfejsu 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 interfejsu API > Zbadaj.
4. Wybierz konkretny przedział czasowy, w którym wystąpiły błędy.

5. Wykreśl kod błędu na osi czasu.

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

   ( wyświetl większy obraz)

   

7. Informacje o kodzie błędumessaging.adaptors.http.flow.SslHandshakeFailed są wyświetlane w sposób pokazany 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 Dzienniki zanotuj te informacje:
   • Identyfikator wiadomości z żądaniem
   • Kod stanu: 503
   • Źródło błędu: target
   • Kod błędu: messaging.adaptors.http.flow.SslHandshakeFailed

Śledzenie

Procedura 2. Używanie narzędzia Śledzenie

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

1. Włącz śledzenie sesji i wybierz jedną z tych opcji:
   • Poczekaj na błąd 503 Service Unavailable o kodzie 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 Pokaż wszystkie informacje o przepływach jest włączona:

   
3. Wybierz jedno z nieudanych żądań i sprawdź ślad.
4. Przeglądaj różne fazy śledzenia i sprawdź, gdzie wystąpił błąd.

5. Błąd zwykle występuje po fazie Target Request Flow Started, jak pokazano poniżej:

   ( wyświetl większy obraz)

   
6. Zapisz te wartości ze śladu:
   • 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 protokołu SSL nie powiodło się, ponieważ procesor komunikatów Apigee Edge nie mógł zweryfikować certyfikatu serwera backendu.
7. W śladzie przejdź do fazy AX (Analytics Data Recorded) i kliknij ją.

8. Przewiń w dół do sekcji Phase Details Error Headers (Nagłówki błędów szczegółów fazy) i określ wartości X-Apigee-fault-code, X-Apigee-fault-source i X-Apigee-Message-ID, jak pokazano poniżej:

   ( wyświetl większy obraz)

   
9. Zanotuj 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. Korzystanie z dzienników dostępu NGINX

Aby zdiagnozować błąd za pomocą dzienników dostępu NGINX:

1. Jeśli jesteś użytkownikiem chmury prywatnej, możesz używać dzienników dostępu NGINX do określania kluczowych informacji o żądaniach HTTP 503 Service Unavailable.

2. Sprawdź logi dostępu NGINX:

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

3. Sprawdź, czy w określonym czasie wystąpiły jakieś 503 błędy z kodem błędumessaging.adaptors.http.flow.SslHandshakeFailed (jeśli problem wystąpił w przeszłości) lub czy nadal występują jakieś nieudane żądania z kodem 503.

4. Jeśli znajdziesz błędy 503, w których X-Apigee-fault-code ma wartość messaging.adaptors.http.flow.SslHandshakeFailed, określ wartość 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 dziennika dostępu NGINX zawiera te wartości atrybutów X-Apigee-fault-code i X-Apigee-fault-source:

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

Dzienniki procesora komunikatów

Procedura 4. Korzystanie z dzienników procesora komunikatów

1. Określ identyfikator wiadomości jednego z nieudanych żądań za pomocą narzędzia do monitorowania interfejsu API, narzędzia śledzenia lub dzienników dostępu NGINX zgodnie z opisem w artykule Typowe czynności diagnostyczne.

2. Wyszukaj w dzienniku procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log) identyfikator konkretnej wiadomości z żądaniem. Może pojawić się następujący 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ę uzgodnić połączenia protokołu SSL między procesorem komunikatów a serwerem backendu.

   Nastąpi 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>
     

   Zwróć uwagę, że niepowodzenie uzgadniania połączenia jest spowodowane:

   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 uzgadnianie protokołu SSL nie powiodło się, ponieważ procesor komunikatów Apigee Edge nie mógł 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 certyfikat serwera backendu z certyfikatami przechowywanymi w magazynie zaufanych certyfikatów procesora wiadomości

1. Określ łańcuch certyfikatów serwera backendu.
2. Określ certyfikat przechowywany w magazynie zaufanych certyfikatów procesora wiadomości, wykonując te czynności:

   1. Pobierz nazwę odwołania do magazynu zaufanych certyfikatów z elementu TrustStore w sekcji SSLInfo w pliku TargetEndpoint.

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

      <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 powyższym przykładzie nazwa odwołania TrustStore to myCompanyTruststoreRef.

   3. W interfejsie Edge wybierz Środowiska > Pliki referencyjne. Zwróć uwagę na nazwę w kolumnie Reference (Odwołanie) dla konkretnego odwołania do magazynu zaufanych certyfikatów. Będzie to nazwa magazynu zaufanych certyfikatów.

      ( wyświetl większy obraz)

      

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

      myCompanyTruststoreRef: myCompanyTruststore

3. Pobierz certyfikaty przechowywane w magazynie zaufanych certyfikatów (określonym w poprzednim kroku) za pomocą tych interfejsów API:

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

      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.
      • Zmienna $TOKEN jest ustawiona na token dostępu OAuth 2.0 zgodnie z opisem w sekcji Uzyskiwanie tokena dostępu OAuth 2.0.
      • curl opcje użyte w tym przykładzie są opisane w artykule Używanie curl.

      Przykładowe dane wyjściowe:

      Certyfikaty z przykładowego magazynu zaufanych certyfikatów myCompanyTruststore to:

      [
        "serverCert"
      ]

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

      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 chmury 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.
      • Zmienna $TOKEN jest ustawiona na token dostępu OAuth 2.0 zgodnie z opisem w sekcji Uzyskiwanie tokena dostępu OAuth 2.0.
      • curl opcje użyte w tym przykładzie są opisane w artykule Używanie curl.

      Przykładowe dane wyjściowe

      Szczegóły serverCert zawierają temat i wystawcę w tym formacie:

      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 przechowywany w magazynie zaufanych certyfikatów uzyskany w kroku 3 są zgodne. Jeśli się nie zgadzają, to jest to przyczyna problemu.

   Na podstawie powyższego przykładu przeanalizujmy po kolei poszczególne certyfikaty:

   1. Certyfikat wierzchołka ścieżki:

      Z serwera backendu:

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

      Z magazynu zaufanych certyfikatów procesora 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 zaufanych certyfikatów 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

      Z magazynu zaufanych certyfikatów procesora 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 zaufanych certyfikatów 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 zaufanych certyfikatów procesora wiadomości całkowicie brakuje certyfikatu głównego.

   4. Ponieważ w magazynie zaufanych certyfikatów brakuje certyfikatu głównego, procesor komunikatów 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 kod błędu 503 Service Unavailable messaging.adaptors.http.flow.SslHandshakeFailed do aplikacji klienckich.

Prawidłowa pełna i jednoznaczna nazwa domeny

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

1. Jeśli nie masz certyfikatu serwera backendu z prawidłową nazwą FQDN, uzyskaj odpowiedni certyfikat od właściwego 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 kompletny łańcuch certyfikatów z prawidłową pełną i jednoznaczną nazwą domeny serwera backendu w certyfikacie liścia lub encji, która jest identyczna z nazwą hosta podaną w docelowym punkcie końcowym, zaktualizuj magazyn kluczy backendu za pomocą kompletnego łańcucha certyfikatów.

Poprawny serwer backendu

Zaktualizuj punkt końcowy docelowy, 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, aby zawierał prawidłową nazwę hosta zgodną z w pełni kwalifikowaną nazwą domeny w certyfikacie serwera backendu.

2. Zapisz zmiany w proxy interfejsu API.

   W omówionym powyżej przykładzie, jeśli nazwa hosta serwera backendu została nieprawidłowo określona, możesz to naprawić, 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>