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 ruolo appropriato.

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

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

5. Traccia il codice di errore in base all'ora.

6. Seleziona una cella che contiene il codice di errore messaging.adaptors.http.flow.SslHandshakeFailed come mostrato sotto:

   ( visualizza immagine ingrandita)

   

7. Informazioni sul codice di errore messaging.adaptors.http.flow.SslHandshakeFailed visualizzato come 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, tieni presente i seguenti dettagli:
   .
   • ID messaggio di richiesta
   • Codice di stato: 503
   • Origine errore:target
   • Codice di errore: messaging.adaptors.http.flow.SslHandshakeFailed

Trace

Procedura 2: utilizzo dello strumento Trace

Per diagnosticare l'errore utilizzando lo strumento Trace:

1. Attiva la sessione di traccia e
   .
   • Attendi l'errore 503 Service Unavailable con il codice di errore messaging.adaptors.http.flow.SslHandshakeFailed affinché si verifichino o
   • Se riesci a riprodurre il problema, esegui la chiamata API per riprodurlo. 503 Service Unavailable

2. Assicurati che l'opzione Mostra tutte le informazioni di Flow sia attivata:

   
3. Seleziona una delle richieste non riuscite ed esamina la traccia.
4. Naviga attraverso le diverse fasi della traccia e individua dove si è verificato l'errore.

5. In genere troverai l'errore dopo la fase Flusso di richiesta target avviato come mostrato di seguito:

   ( visualizza immagine ingrandita)

   
6. Prendi nota dei seguenti valori della 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. poiché il processore di messaggi di Apigee Edge non era in grado di convalidare certificato.
7. Vai alla fase AX (dati registrati di Analytics) della traccia e fai clic su quest'ultima.

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

   ( visualizza immagine ingrandita)

   
9. Nota i 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: usare i log di accesso NGINX

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

1. Se sei un utente 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 NGINX:

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

3. Cerca per vedere se ci sono errori 503 con codice di errore messaging.adaptors.http.flow.SslHandshakeFailed per un periodo di tempo specifico (se il problema si è verificato nella precedenti) o se ci sono ancora richieste che non vanno a buon fine con 503.

4. Se trovi errori 503 con la corrispondenza X-Apigee-fault-code il valore di messaging.adaptors.http.flow.SslHandshakeFailed, determinare il valore della X-Apigee-fault-source.

   Esempio di errore 503 nel log di accesso NGINX:

   ( visualizza immagine ingrandita)

   

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

   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. Determinare l'ID messaggio di una delle richieste non riuscite utilizzando API Monitoring, lo strumento Trace o NGINX, come spiegato nella sezione Passaggi di diagnostica comuni.

2. Cerca l'ID messaggio di richiesta specifico nel log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) Puoi osservare 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.

   Segue un'eccezione con l'analisi dettagliata dello stack, come illustrato 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 era non è in grado di 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 e i certificati del server di backend archiviati nella Truststore del processore di messaggi

1. Determina la catena di certificati del server di backend.
2. Determinare il certificato archiviato nell'archivio di attendibilità del processore di messaggi utilizzando segui questi passaggi:

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

      Diamo un'occhiata a una sezione SSLInfo di esempio in un TargetEndpoint. configurazione:

      <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. Nella UI di Edge, seleziona Ambienti > Riferimenti. Prendi nota del nome nella Colonna Riferimento per il riferimento specifico dell'archivio attendibilità. Questo sarà il tuo nome archivio attendibilità.

      ( visualizza immagine ingrandita)

      

   4. Nell'esempio precedente il nome dell'archivio attendibili è:

      myCompanyTruststoreRef: myCompanyTruststore

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

   1. Recupero di tutti i certificati per un archivio chiavi o un archivio attendibilità Questa API elenca tutte le certificati nell'archivio di attendibilità specifico.

      Utente 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 token di accesso OAuth 2.0, come descritto in Ottenere 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 di attendibilità myCompanyTruststore di esempio sono:

      [
        "serverCert"
      ]
      

   2. Recupera i dettagli della certificazione per un certificato specifico da un archivio chiavi o un archivio attendibilità. Questa API restituisce le informazioni su un certificato specifico in archivio attendibilità.

      Utente 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 token di accesso OAuth 2.0, come descritto in Ottenere un token di accesso OAuth 2.0
      • Le opzioni curl utilizzate in questo esempio sono descritte in Utilizzare curl

      Output di esempio

      Dettagli di serverCert mostrano l'oggetto e l'emittente come segue:

      Certificato Fogliolina/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 archiviati in truststore ottenuti nel passaggio 3. Se non corrispondono, causa del problema.

   Nell'esempio mostrato sopra, esaminiamo 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
      

      Dall'archivio di attendibilità (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 nel truststore corrisponde a quello del backend server web.

   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
      

      Dall'archivio di attendibilità (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 nel truststore corrisponde a quello del 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 riquadro archivio attendibilità.

   4. Poiché il certificato radice non è presente nell'archivio attendibili, la classe 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 al cliente diverse applicazioni.

FQDN corretto

Aggiorna l'archivio chiavi del server di backend con il nome di dominio completo corretto e un certificato valido e completo :

1. Se non disponi di un certificato del server di backend con il nome di dominio completo corretto, quindi procurati il certificato appropriato a un'autorità di certificazione appropriata.

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

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

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 il valore dell'endpoint di destinazione in modo che il nome host sia corretto e che corrisponda al nome di dominio completo nel backend con il certificato del server.

2. Salva le modifiche apportate al proxy API.

   Nell'esempio discusso sopra, se il nome host del server di backend non era corretto specificato, puoi correggerlo utilizzando il nome di dominio completo del certificato del server di backend, che è 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>