Servizio 503 non disponibile - Errore di handshake SSL

Monitoraggio delle API

Procedura 1: utilizzo del monitoraggio delle API

Per diagnosticare l'errore utilizzando il monitoraggio delle API:

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 riscontrato gli errori.

5. Traccia Codice di errore su Ora.

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

   ( visualizza immagine ingrandita)

   

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

   ( visualizza immagine ingrandita)

   

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

   ( visualizza immagine ingrandita)

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

Traccia

Procedura 2: utilizzo dello strumento Trace

Per diagnosticare l'errore utilizzando lo strumento Trace:

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

2. Assicurati che l'opzione Mostra tutte le FlowInfos sia abilitata:

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

5. In genere, l'errore viene visualizzato dopo la fase Inizio del flusso di richiesta target, come mostrato di seguito:

   ( visualizza immagine ingrandita)

   
6. Prendi nota dei valori di quanto segue 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 perché il processore di messaggi di Apigee Edge non è riuscito a convalidare il certificato del server di backend.
7. Vai alla fase AX (Analytics Data Recorded) della traccia e fai clic.

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

   ( visualizza immagine ingrandita)

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

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

NGINX

Procedura 3: utilizzo dei log degli accessi di NGINX

Per diagnosticare l'errore utilizzando i log degli accessi di NGINX:

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

2. Controlla i log degli accessi di NGINX:

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

3. Cerca per vedere se si sono verificati errori 503 con il codice di errore messaging.adaptors.http.flow.SslHandshakeFailed durante un periodo di tempo specifico (se il problema si è verificato in passato) o se ci sono ancora richieste che continuano a non funzionare con 503.

4. Se riscontri 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 degli accessi di NGINX:

   ( visualizza immagine ingrandita)

   

   La voce di esempio sopra riportata dal log degli accessi di 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 4: utilizzo dei log del processore di messaggi

1. Determina l'ID messaggio di una delle richieste con esito negativo utilizzando API Monitoring, lo strumento Trace o i log degli accessi NGINX, come spiegato nella sezione Passaggi di diagnostica comuni.

2. Cerca l'ID messaggio della richiesta specifico nel log dell'elaborazione dei messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log). Potresti notare 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 un'analisi dettagliata dello stack, 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

   Questo 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: determinazione della 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 e i certificati del server di backend archiviati nel truststore del processore di messaggi

1. Determina la catena di certificati del server di backend.
2. Per determinare il certificato archiviato nel truststore del processore di messaggi:

   1. Recupera il nome di riferimento dell'archivio attendibilità dall'elemento TrustStore nella sezione SSLInfo di 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 dell'archivio attendibilità. Questo sarà il nome del tuo archivio attendibilità.

      ( visualizza immagine ingrandita)

      

   4. Nell'esempio precedente, il nome dell'archivio attendibilità è:

      myCompanyTruststoreRef: myCompanyTruststore

3. Recupera i certificati archiviati nell'archivio attendibilità (determinato nel passaggio precedente) utilizzando le seguenti API:

   1. Ottieni tutti i certificati per un archivio chiavi o un archivio attendibilità. Questa API elenca tutti i certificati nell'archivio di attendibilità 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 sia impostato sul token di accesso OAuth 2.0 come descritto in Ottenere un token di accesso per OAuth 2.0
      • Le opzioni curl utilizzate in questo esempio sono descritte in Utilizzare curl

      Esempio di output:

      I certificati dell'archivio di attendibilità di esempio myCompanyTruststore sono:

      [
        "serverCert"
      ]
      

   2. Ottieni i dettagli del certificato specifico da un archivio chiavi o da un archivio attendibilità. Questa API restituisce le informazioni su un certificato specifico nell'archivio attendibilità 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 sia impostato sul token di accesso OAuth 2.0 come descritto in Ottenere un token di accesso per OAuth 2.0
      • Le opzioni curl utilizzate in questo esempio sono descritte in Utilizzare curl

      Esempio di output

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

      Fogliolina/certificato di 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 archiviato nell'archivio attendibilità ottenuto nel passaggio 3 corrispondano. Se non corrispondono, è questo il motivo.

   Nell'esempio riportato sopra, diamo un'occhiata a un certificato alla volta:

   1. Certificato Fogliolina:

      Dal server di backend:

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

      Dal truststore (client) del processore di messaggi:

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

      Il certificato foglia archiviato nell'archivio attendibilità 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 (client) del processore di messaggi:

      "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 archiviato 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 è completamente mancante nel truststore del processore di messaggi.

   4. Poiché il certificato radice manca 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.

Nome di dominio completo corretto

Aggiorna l'archivio chiavi del server di backend con un nome di dominio completo corretto e una catena di certificati valida e completa:

1. Se non hai un certificato del server di backend con il nome di dominio completo corretto, richiedi il certificato corretto a una CA (autorità di certificazione) appropriata.

2. Conferma di avere una catena di certificati valida e completa del server di backend.

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

Server di backend corretto

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 corrispondente al nome di dominio completo nel certificato del server di backend.

2. Salva le modifiche apportate al proxy API.

   Nell'esempio descritto sopra, se il nome host del server di backend è stato specificato in modo errato, puoi correggerlo utilizzando il nome di dominio completo 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>