Servizio 503 non disponibile - Errore di handshake SSL

Monitoraggio delle API

Procedura 1: utilizzo del monitoraggio delle API

Per diagnosticare l'errore utilizzando API Monitoring:

1. Accedi alla UI di Apigee Edge come utente con un ruolo appropriato.

2. Passa all'organizzazione in cui vuoi esaminare il problema.

   
3. Vai alla pagina Analizza > Monitoraggio API > Esamina.
4. Seleziona il periodo di tempo specifico in cui hai osservato gli errori.

5. Traccia il codice di errore rispetto al tempo.

6. Seleziona una cella con il codice di errore messaging.adaptors.http.flow.SslHandshakeFailed come mostrato di seguito:

   ( visualizza immagine più grande)

   

7. Le informazioni sul codice di errore messaging.adaptors.http.flow.SslHandshakeFailed vengono visualizzate come mostrato di seguito:

   ( visualizza immagine più grande)

   

8. Fai clic su Visualizza log ed espandi la riga della richiesta non riuscita.

   ( visualizza immagine più grande)

   
9. Nella finestra Log, prendi nota dei seguenti dettagli:
   • ID messaggio richiesta
   • Codice di stato: 503
   • Origine del guasto: target
   • Codice guasto: messaging.adaptors.http.flow.SslHandshakeFailed

Traccia

Procedura n. 2: utilizzo dello strumento Trace

Per diagnosticare l'errore utilizzando lo strumento Trace:

1. Attiva l'opzione Traccia sessione e
   • Attendi che si verifichi l'errore 503 Service Unavailable con codice di errore messaging.adaptors.http.flow.SslHandshakeFailed oppure
   • Se riesci a riprodurre il problema, effettua la chiamata API per riprodurlo 503 Service Unavailable

2. Assicurati che l'opzione Mostra tutte le informazioni sul flusso sia abilitata:

   
3. Seleziona una delle richieste non riuscite ed esamina la traccia.
4. Esamina le diverse fasi della traccia e individua il punto in cui si è verificato l'errore.

5. In genere, l'errore si verifica dopo la fase Target Request Flow Started come mostrato di seguito:

   ( visualizza immagine più grande)

   
6. Prendi nota dei valori seguenti dalla traccia:
   • Errore: 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
   • Il valore dell'errore 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 indica che l'handshake SSL non è riuscito, in quanto il processore di messaggi di Apigee Edge non è riuscito a convalidare il certificato del server di backend.
7. Vai alla fase AX (dati di Analytics registrati) nella traccia e fai clic.

8. Scorri verso il basso fino alla sezione Intestazioni di errore dei dettagli della fase e determina i valori di X-Apigee-fault-code e X-Apigee-fault-source e X-Apigee-Message-ID come mostrato di seguito:

   ( visualizza immagine più grande)

   
9. Prendi nota dei valori di X-Apigee-fault-code, X-Apigee-fault-source e X-Apigee-Message-ID:

Intestazioni di errore	Valore
X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
X-Apigee-fault-source	target
X-Apigee-Message-ID	MESSAGE_ID

NGINX

Procedura n. 3: utilizzo dei log di accesso NGINX

Per diagnosticare l'errore utilizzando i log di accesso NGINX:

1. Se sei un utente di Private Cloud, puoi utilizzare i log di accesso NGINX per determinare le informazioni chiave su HTTP 503 Service Unavailable.

2. Controlla i log di accesso di NGINX:

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

3. Cerca eventuali errori 503 con codice di errore messaging.adaptors.http.flow.SslHandshakeFailed durante un periodo di tempo specifico (se il problema si è verificato in passato) o se sono ancora presenti richieste non riuscite con 503.

4. Se trovi errori 503 con X-Apigee-fault-code corrispondente al valore di messaging.adaptors.http.flow.SslHandshakeFailed, determina il valore di X-Apigee-fault-source.

   Esempio di errore 503 dal log di accesso NGINX:

   ( visualizza immagine più grande)

   

   La voce di esempio riportata sopra del log di accesso NGINX ha i seguenti valori per X-Apigee-fault-code e X-Apigee-fault-source:

   Intestazioni	Valore
   X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-fault-source	target

Log del processore di messaggi

Procedura n. 4: utilizzo dei log del processore di messaggi

1. Determina l'ID messaggio di una delle richieste non riuscite utilizzando API Monitoring, lo strumento Trace o i log di accesso NGINX, come spiegato in Passaggi comuni per la diagnosi.

2. Cerca l'ID messaggio di richiesta specifico nel log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log). Potresti riscontrare il seguente errore:

   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
   

   L'errore riportato sopra indica che l'handshake SSL non è riuscito tra il processore di messaggi e il server di backend.

   Seguirà un'eccezione con l'analisi dello stack dettagliata, come mostrato di seguito:

   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>
     

   Tieni presente che l'errore di handshake è dovuto a:

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

   Ciò indica che l'handshake SSL non è riuscito perché il processore di messaggi di Apigee Edge non è riuscito a convalidare il certificato del server di backend.

Fase 1

Fase 1: determina la catena di certificati del server di backend

Utilizza uno dei seguenti metodi per determinare la catena di certificati del server di backend:

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

Fase 2

Fase 2: confronta il certificato del server di backend e i certificati memorizzati nell'archivio attendibile del processore di messaggi

1. Determina la catena di certificati del server di backend.
2. Determina il certificato archiviato nel truststore del processore di messaggi utilizzando i seguenti passaggi:

   1. Recupera il nome di riferimento del truststore dall'elemento TrustStore nella sezione SSLInfo del file TargetEndpoint.

      Diamo un'occhiata a una sezione SSLInfo di esempio in una configurazione 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. Nell'esempio precedente, il nome di riferimento TrustStore è myCompanyTruststoreRef.

   3. Nell'interfaccia utente di Edge, seleziona Ambienti > Riferimenti. Prendi nota del nome nella colonna Riferimento per il riferimento specifico al truststore. Questo sarà il nome del truststore.

      ( visualizza immagine più grande)

      

   4. Nell'esempio precedente, il nome del truststore è:

      myCompanyTruststoreRef: myCompanyTruststore

3. Recupera i certificati archiviati nel truststore (determinato nel passaggio precedente) utilizzando le seguenti API:

   1. Recupera tutti i certificati per un archivio chiavi o un archivio attendibile. Questa API elenca tutti i certificati nell'archivio attendibile specifico.

      Utente del cloud pubblico:

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

      Utente 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"
      

      Dove:

      • ORGANIZATION_NAME è il nome dell'organizzazione
      • ENVIRONMENT_NAME è il nome dell'ambiente
      • KEYSTORE_NAME è il nome dell'archivio chiavi
      • $TOKEN è impostato sul tuo token di accesso OAuth 2.0 come descritto in Ottieni un token di accesso OAuth 2.0
      • Le opzioni curl utilizzate in questo esempio sono descritte in Utilizzare curl

      Esempio di output:

      I certificati dell'archivio attendibile di esempio myCompanyTruststore sono:

      [
        "serverCert"
      ]

   2. Recupera i dettagli del certificato specifico da un keystore o un truststore. Questa API restituisce le informazioni su un certificato specifico nell'archivio attendibile specifico.

      Utente del cloud pubblico:

      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"
      

      Utente 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"
      

      Dove:

      • ORGANIZATION_NAME è il nome dell'organizzazione
      • ENVIRONMENT_NAME è il nome dell'ambiente
      • KEYSTORE_NAME è il nome dell'archivio chiavi
      • CERT_NAME è il nome del certificato
      • $TOKEN è impostato sul tuo token di accesso OAuth 2.0 come descritto in Ottieni un token di accesso OAuth 2.0
      • Le opzioni curl utilizzate in questo esempio sono descritte in Utilizzare curl

      Output di esempio

      I dettagli di serverCert mostrano l'oggetto e l'emittente come segue:

      Certificato foglia/entità:

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

      Certificato intermedio:

      "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. Verifica che il certificato del server effettivo ottenuto nel passaggio 1 e il certificato memorizzato nell'archivio attendibile ottenuto nel passaggio 3 corrispondano. Se non corrispondono, questa è la causa del problema.

   Dall'esempio mostrato sopra, esaminiamo un certificato alla volta:

   1. Certificato end-entity:

      Dal server di backend:

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

      Dal truststore del processore di messaggi (client):

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

      Il certificato foglia memorizzato nel truststore corrisponde a quello del server di backend.

   2. Certificato intermedio:

      Dal server di backend:

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

      Dal truststore del processore di messaggi (client):

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

      Il certificato intermedio memorizzato nell'archivio attendibilità corrisponde a quello del server di backend.

   3. Certificato radice:

      Dal server di backend:

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

      Il certificato radice non è presente nell'archivio attendibilità di Message Processor.

   4. Poiché il certificato radice non è presente nell'archivio attendibilità, il processore di messaggi genera la seguente eccezione:

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

      e restituisce 503 Service Unavailable con il codice di errore messaging.adaptors.http.flow.SslHandshakeFailed alle applicazioni client.

FQDN corretto

Aggiorna il keystore del server di backend con il nome di dominio completo corretto, la catena di certificati valida e completa:

1. Se non disponi di un certificato del server di backend con il nome di dominio completo (FQDN) corretto, procurati il certificato appropriato da un'autorità di certificazione (CA) idonea.

2. Verifica di disporre di una catena di certificati del server di backend valida e completa.

3. Una volta ottenuta la catena di certificati valida e completa con il nome di dominio completo corretto del server di backend nel certificato dell'entità o foglia identico al nome host specificato nell'endpoint di destinazione, aggiorna l'archivio chiavi del backend con la catena di certificati completa.

Correggi il server di backend

Aggiorna l'endpoint di destinazione con il nome host del server di backend corretto:

1. Se il nome host è stato specificato in modo errato nell'endpoint di destinazione, aggiorna l'endpoint di destinazione in modo che abbia il nome host corretto che corrisponda all'FQDN nel certificato del server di backend.

2. Salva le modifiche al proxy API.

   Nell'esempio discusso in precedenza, se il nome host del server di backend è stato specificato in modo errato, puoi correggerlo utilizzando l'FQDN del certificato del server di backend, ovvero backend.apigee.net, come segue:

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