Errori di handshake TLS/SSL

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Sintomo

Un errore di handshake TLS/SSL si verifica quando un client e un server non riescono a stabilire la comunicazione utilizzando il protocollo TLS/SSL. Quando si verifica questo errore in Apigee Edge, l'applicazione client riceve uno stato HTTP 503 con il messaggio Servizio non disponibile. Visualizzi questo errore dopo qualsiasi chiamata API in cui si verifica un errore di handshake TLS/SSL.

Messaggi di errore

HTTP/1.1 503 Service Unavailable

Puoi visualizzare questo messaggio di errore anche quando si verifica un errore di handshake TLS/SSL:

Received fatal alert: handshake_failure

Possibili cause

TLS (Transport Layer Security, il cui predecessore è SSL) è la tecnologia di sicurezza standard per stabilire un collegamento criptato tra un server web e un client web, ad esempio un browser o un'app. Un handshake è un processo che consente al client e al server TLS/SSL di stabilire un insieme di chiavi segrete con cui possono comunicare. Durante questo processo, il client e il server:

1. Concordare la versione del protocollo da utilizzare.
2. Seleziona l'algoritmo crittografico da utilizzare.
3. Autenticarsi a vicenda scambiando e convalidando i certificati digitali.

Se l'handshake TLS/SSL va a buon fine, il client e il server TLS/SSL si trasferiscono i dati in modo sicuro. In caso contrario, se si verifica un errore di handshake TLS/SSL, la connessione viene terminata e il client riceve un errore 503 Service Unavailable.

Le possibili cause di errori di handshake TLS/SSL sono:

Mancata corrispondenza del protocollo

Un errore di handshake TLS/SSL si verifica se il protocollo utilizzato dal client non è supportato dal server nella connessione in entrata (verso nord) o in uscita (verso sud). Vedi anche Informazioni sulle connessioni in uscita e in entrata.

Diagnosi

1. Determina se l'errore si è verificato nella connessione in direzione nord o in direzione sud. Per ulteriori indicazioni su come effettuare questa determinazione, consulta Determinare l'origine del problema.
2. Esegui l'utilità tcpdump per raccogliere ulteriori informazioni:
   • Se sei un utente di Private Cloud, puoi raccogliere i dati tcpdump sul client o sul server pertinente. Un client può essere l'app client (per le connessioni in entrata o in uscita) o il processore di messaggi (per le connessioni in uscita o in entrata). Un server può essere l'Edge Router (per le connessioni in entrata o in uscita) o il server di backend (per le connessioni in uscita o in entrata) in base alla tua determinazione del passaggio 1.
   • Se sei un utente del cloud pubblico, puoi raccogliere i dati tcpdump solo nell'app client (per le connessioni in entrata o in uscita) o nel server di backend (per le connessioni in uscita o in entrata), perché non hai accesso al router edge o al processore di messaggi.

   tcpdump -i any -s 0 host IP address -w File name
   

   Per saperne di più sull'utilizzo del comando tcpdump, consulta i dati di tcpdump.
3. Analizza i dati tcpdump utilizzando lo strumento Wireshark o uno strumento simile.
4. Ecco un'analisi di esempio di tcpdump utilizzando Wireshark:
   • In questo esempio, l'handshake TLS/SSL non è riuscito tra il processore di messaggi e il server di backend (la connessione in uscita o southbound).
   • Il messaggio n. 4 nell'output tcpdump riportato di seguito mostra che il processore di messaggi (origine) ha inviato un messaggio "Client Hello" al server di backend (destinazione).
     

     

   • Se selezioni il messaggio Client Hello, viene visualizzato che il processore di messaggi utilizza il protocollo TLSv1.2, come mostrato di seguito:

     

   • Il messaggio n. 5 mostra che il server di backend riconosce il messaggio "Client Hello" del processore di messaggi.
   • Il server di backend invia immediatamente Fatal Alert : Close Notify al processore di messaggi (messaggio n. 6). Ciò significa che l'handshake TLS/SSL non è riuscito e la connessione verrà chiusa.

   • Analizzando più nel dettaglio il messaggio n. 6, si nota che la causa dell'errore di handshake TLS/SSL è che il server di backend supporta solo il protocollo TLSv1.0, come mostrato di seguito:

     

   • Poiché esiste una mancata corrispondenza tra il protocollo utilizzato dal processore di messaggi e il server di backend, quest'ultimo ha inviato il messaggio: Fatal Alert Message: Close Notify.

Risoluzione

Il processore di messaggi viene eseguito su Java 8 e utilizza il protocollo TLSv1.2 per impostazione predefinita. Se il server di backend non supporta il protocollo TLSv1.2, puoi eseguire uno dei seguenti passaggi per risolvere il problema:

1. Esegui l'upgrade del server di backend per supportare il protocollo TLSv1.2. Questa è una soluzione consigliata perché il protocollo TLSv1.2 è più sicuro.
2. Se per qualche motivo non riesci a eseguire immediatamente l'upgrade del server di backend, puoi forzare il processore di messaggi a utilizzare il protocollo TLSv1.0 per comunicare con il server di backend seguendo questi passaggi:
   1. Se non hai specificato un server di destinazione nella definizione TargetEndpoint del proxy, imposta l'elemento Protocol su TLSv1.0 come mostrato di seguito:

      <TargetEndpoint name="default">
       …
       <HTTPTargetConnection>
         <SSLInfo>
             <Enabled>true</Enabled>
             <Protocols>
                 <Protocol>TLSv1.0</Protocol>
             </Protocols>
         </SSLInfo>
         <URL>https://myservice.com</URL>
       </HTTPTargetConnection>
       …
      </TargetEndpoint>

   2. Se hai configurato un server di destinazione per il proxy, utilizza questa API di gestione per impostare il protocollo su TLSv1.0 nella configurazione specifica del server di destinazione.

Cipher Mismatch

Puoi visualizzare un errore di handshake TLS/SSL se l'algoritmo della suite di cifrari utilizzato dal client non è supportato dal server nella connessione in entrata (verso nord) o in uscita (verso sud) in Apigee Edge. Vedi anche Informazioni sulle connessioni in uscita e in entrata.

Diagnosi

1. Determina se l'errore si è verificato nella connessione inbound o outbound. Per ulteriori indicazioni su come prendere questa decisione, consulta la sezione Determinare l'origine del problema.
2. Esegui l'utilità tcpdump per raccogliere ulteriori informazioni:
   • Se sei un utente di Private Cloud, puoi raccogliere i dati tcpdump sul client o sul server pertinente. Un client può essere l'app client (per le connessioni in entrata o in uscita) o il processore di messaggi (per le connessioni in uscita o in entrata). Un server può essere l'Edge Router (per le connessioni in entrata o in uscita) o il server di backend (per le connessioni in uscita o in entrata) in base alla tua determinazione del passaggio 1.
   • Se sei un utente del cloud pubblico, puoi raccogliere i dati tcpdump solo nell'app client (per le connessioni in entrata o in uscita) o nel server di backend (per le connessioni in uscita o in entrata), perché non hai accesso al router edge o al processore di messaggi.

   tcpdump -i any -s 0 host IP address -w File name
   

   Per saperne di più sull'utilizzo del comando tcpdump, consulta i dati di tcpdump.
3. Analizza i dati tcpdump utilizzando lo strumento Wireshark o qualsiasi altro strumento che conosci.
4. Ecco l'analisi di esempio dell'output tcpdump utilizzando Wireshark:
   • In questo esempio, l'errore di handshake TLS/SSL si è verificato tra l'applicazione client e il router Edge (connessione in uscita). L'output tcpdump è stato raccolto sul router edge.

   • Il messaggio n. 4 nell'output tcpdump riportato di seguito mostra che l'applicazione client (origine) ha inviato un messaggio "Client Hello" al router di frontiera (destinazione).

     

   • Selezionando il messaggio Client Hello, viene visualizzato che l'applicazione client utilizza il protocollo TLSv1.2.

     

   • Il messaggio n. 5 mostra che l'Edge Router riconosce il messaggio "Client Hello" dall'applicazione client.
   • Il router Edge invia immediatamente un Fatal Alert : Handshake Failure all'applicazione client (messaggio n. 6). Ciò significa che l'handshake TLS/SSL non è riuscito e la connessione verrà chiusa.
   • Un'analisi più approfondita del messaggio n. 6 mostra le seguenti informazioni:
     • L'Edge Router supporta il protocollo TLSv1.2. Ciò significa che il protocollo corrisponde tra l'applicazione client e l'Edge Router.

     • Tuttavia, il router Edge invia comunque l'avviso irreversibile: errore di handshake all'applicazione client, come mostrato nello screenshot seguente:

       

   • L'errore potrebbe essere il risultato di uno dei seguenti problemi:
     • L'applicazione client non utilizza gli algoritmi della suite di crittografia supportati dal router Edge.
     • L'Edge Router è abilitato per SNI, ma l'applicazione client non invia il nome del server.
   • Il messaggio n. 4 nell'output tcpdump elenca gli algoritmi delle suite di crittografia supportati dall'applicazione client, come mostrato di seguito:

     

   • L'elenco degli algoritmi delle suite di crittografia supportati dall'Edge Router è riportato nel file /opt/nginx/conf.d/0-default.conf. In questo esempio, l'Edge Router supporta solo gli algoritmi della suite di crittografia High Encryption.
   • L'applicazione client non utilizza nessuno degli algoritmi della suite di crittografia High Encryption. Questa mancata corrispondenza è la causa dell'handshake TLS/SSL non riuscito.
   • Poiché Edge Router è abilitato per SNI, scorri verso il basso fino al messaggio n. 4 nell'output tcpdump e verifica che l'applicazione client invii correttamente il nome del server, come mostrato nella figura seguente:
     
     
     
   • Se questo nome è valido, puoi dedurre che l'errore di handshake TLS/SSL si è verificato perché gli algoritmi delle suite di crittografia utilizzati dall'applicazione client non sono supportati dal router Edge.

Risoluzione

Devi assicurarti che il client utilizzi gli algoritmi della suite di crittografia supportati dal server. Per risolvere il problema descritto nella sezione Diagnosi precedente, scarica e installa il pacchetto Java Cryptography Extension (JCE) e includilo nell'installazione di Java per supportare gli algoritmi della suite di crittografia High Encryption.

Certificato errato

Un errore di handshake TLS/SSL si verifica se hai certificati errati nel keystore/truststore, nella connessione in entrata (inbound) o in uscita (outbound) in Apigee Edge. Vedi anche Informazioni sulle connessioni in uscita e in entrata.

Se il problema è in uscita, potresti visualizzare messaggi di errore diversi a seconda della causa sottostante.

Le sezioni seguenti elencano messaggi di errore di esempio e i passaggi per diagnosticare e risolvere questo problema.

Messaggi di errore

Potresti visualizzare messaggi di errore diversi a seconda della causa dell'errore di handshake TLS/SSL. Ecco un esempio di messaggio di errore che potresti visualizzare quando chiami un proxy API:

* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

Possibili cause

Le cause tipiche di questo problema sono:

Mancata corrispondenza del nome host

Diagnosi

1. Prendi nota del nome host utilizzato nell'URL restituito dalla seguente chiamata API di gestione Edge:

   curl -v https://myorg.domain.com/v1/getinfo

   Ad esempio:

   curl -v https://api.enterprise.apigee.com/v1/getinfo

2. Recupera il nome comune utilizzato nel certificato memorizzato nell'archivio chiavi specifico. Puoi utilizzare le seguenti API di gestione Edge per ottenere i dettagli del certificato:
   1. Recupera il nome del certificato nel keystore:
      
      Se sei un utente di cloud privato, utilizza l'API di gestione nel seguente modo:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      Se sei un utente del cloud pubblico, utilizza l'API di gestione nel seguente modo:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Recupera i dettagli del certificato nel keystore utilizzando l'API di gestione Edge.
      
      Se sei un utente Private Cloud:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Se sei un utente del cloud pubblico:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Certificato di esempio:

      "certInfo": [
          {
            "basicConstraints": "CA:FALSE",
            "expiryDate": 1456258950000,
            "isValid": "No",
            "issuer": "SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=\"GoDaddy.com, Inc.\", L=Scottsdale, ST=Arizona, C=US",
            "publicKey": "RSA Public Key, 2048 bits",
            "serialNumber": "07:bc:a7:39:03:f1:56",
            "sigAlgName": "SHA1withRSA",
            "subject": "CN=something.domain.com, OU=Domain Control Validated, O=something.domain.com",
            "validFrom": 1358287055000,
            "version": 3
          },

      Il nome del soggetto nel certificato principale ha il CN come something.domain.com.

      Poiché il nome host utilizzato nell'URL della richiesta API (vedi il passaggio 1 sopra) e il nome del soggetto nel certificato non corrispondono, si verifica l'errore di handshake TLS/SSL.

Risoluzione

Questo problema può essere risolto in uno dei due modi seguenti:

• Ottieni un certificato (se non ne hai già uno) in cui il nome comune del soggetto ha un carattere jolly e poi carica la nuova catena di certificati completa nell'archivio chiavi. Ad esempio:

  "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",

• Ottieni un certificato (se non ne hai già uno) con un CN soggetto esistente, ma utilizza your-org.your-domain come nome alternativo del soggetto, quindi carica la catena di certificati completa nell'archivio chiavi.

Riferimenti

Keystore e Truststore

Catena di certificati incompleta o errata

Diagnosi

1. Recupera il nome comune utilizzato nel certificato memorizzato nell'archivio chiavi specifico. Puoi utilizzare le seguenti API di gestione Edge per ottenere i dettagli del certificato:
   1. Recupera il nome del certificato nel keystore:
      
      Se sei un utente di Private Cloud:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

      Se sei un utente del cloud pubblico:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Visualizza i dettagli del certificato nel keystore:
      
      Se sei un utente di Private Cloud:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Se sei un utente del cloud pubblico:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

   3. Convalida il certificato e la relativa catena e verifica che rispetti le linee guida fornite nell'articolo Come funzionano le catene di certificati per assicurarti che sia una catena di certificati valida e completa. Se la catena di certificati memorizzata nel keystore è incompleta o non valida, viene visualizzato l'errore di handshake TLS/SSL.
   4. La seguente immagine mostra un certificato di esempio con una catena di certificati non valida, in cui i certificati intermedi e radice non corrispondono:

   Esempio di certificato intermedio e radice in cui l'emittente e il soggetto non corrispondono

   
   

Risoluzione

1. Ottieni un certificato (se non ne hai già uno) che includa una catena di certificati completa e valida.
2. Esegui il seguente comando openssl per verificare che la catena di certificati sia corretta e completa:

   openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert

3. Carica la catena di certificati convalidata nell'archivio chiavi.

Certificato scaduto o sconosciuto inviato dal server o dal client

Se un certificato errato/scaduto viene inviato dal server/client nella connessione in uscita o in entrata, l'altra estremità (server/client) rifiuta il certificato, causando un errore di handshake TLS/SSL.

Diagnosi

1. Determina se l'errore si è verificato nella connessione in direzione nord o in direzione sud. Per ulteriori indicazioni su come effettuare questa determinazione, consulta Determinare l'origine del problema.
2. Esegui l'utilità tcpdump per raccogliere ulteriori informazioni:
   • Se sei un utente di Private Cloud, puoi raccogliere i dati tcpdump sul client o sul server pertinente. Un client può essere l'app client (per le connessioni in entrata o in uscita) o il processore di messaggi (per le connessioni in uscita o in entrata). Un server può essere l'Edge Router (per le connessioni in entrata o in uscita) o il server di backend (per le connessioni in uscita o in entrata) in base alla tua determinazione del passaggio 1.
   • Se sei un utente del cloud pubblico, puoi raccogliere i dati tcpdump solo nell'app client (per le connessioni in entrata o in uscita) o nel server di backend (per le connessioni in uscita o in entrata), perché non hai accesso al router edge o al processore di messaggi.

   tcpdump -i any -s 0 host IP address -w File name
   

   Per saperne di più sull'utilizzo del comando tcpdump, consulta i dati di tcpdump.
3. Analizza i dati tcpdump utilizzando Wireshark o uno strumento simile.
4. Dall'output di tcpdump, determina l'host (client o server) che rifiuta il certificato durante il passaggio di verifica.
5. Puoi recuperare il certificato inviato dall'altra parte dall'output tcpdump, a condizione che i dati non siano criptati. Ciò sarà utile per confrontare se questo certificato corrisponde al certificato disponibile nell'archivio attendibile.
6. Esamina l'esempio di tcpdump per la comunicazione SSL tra processore di messaggi e il server di backend.

   Esempio di tcpdump che mostra l'errore Certificato sconosciuto

   
   

   1. Il processore di messaggi (client) invia "Client Hello" al server di backend (server) nel messaggio n. 59.
   2. Il server di backend invia "Server Hello" al processore di messaggi nel messaggio n. 61.
   3. Convalidano reciprocamente gli algoritmi del protocollo e della suite di crittografia utilizzati.
   4. Il server di backend invia il messaggio Certificate and Server Hello Done al processore di messaggi nel messaggio n. 68.
   5. Il processore di messaggi invia l'avviso irreversibile "Descrizione: Certificato sconosciuto" nel messaggio n. 70.
   6. Analizzando ulteriormente il messaggio n. 70, non sono presenti altri dettagli oltre al messaggio di avviso mostrato di seguito:

      
      

   7. Esamina il messaggio n. 68 per visualizzare i dettagli del certificato inviato dal server di backend, come mostrato nella seguente immagine:

      

   8. Il certificato del server di backend e la relativa catena completa sono tutti disponibili nella sezione "Certificati", come mostrato nella figura precedente.
7. Se il certificato risulta sconosciuto al router (in direzione nord) o al processore di messaggi (in direzione sud), come nell'esempio illustrato sopra, segui questi passaggi:
   1. Recupera il certificato e la relativa catena memorizzati nell'archivio attendibile specifico. (fai riferimento alla configurazione dell'host virtuale per il router e alla configurazione dell'endpoint di destinazione per il processore di messaggi). Puoi utilizzare le seguenti API per ottenere i dettagli del certificato:
      1. Ottieni il nome del certificato nel truststore:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs

      2. Visualizza i dettagli del certificato nel truststore:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name

   2. Controlla se il certificato memorizzato nel truststore del router (in uscita) o del processore di messaggi (in entrata) corrisponde a quello memorizzato nel keystore dell'applicazione client (in uscita) o del server di destinazione (in entrata) oppure a quello ottenuto dall'output di tcpdump. In caso di mancata corrispondenza, questo è il motivo dell'handshake TLS/SSL non riuscito.
8. Se il certificato risulta sconosciuto all'applicazione client (inbound) o al server di destinazione (outbound), segui questi passaggi:
   1. Ottieni la catena di certificati completa utilizzata nel certificato memorizzato nell'archivio chiavi specifico. (Fai riferimento alla configurazione dell'host virtuale per il router e alla configurazione dell'endpoint di destinazione per il processore di messaggi.) Puoi utilizzare le seguenti API per ottenere i dettagli del certificato:
      1. Ottieni il nome del certificato nell'archivio chiavi:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      2. Visualizza i dettagli del certificato nell'archivio chiavi:
         

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
         

   2. Verifica che il certificato memorizzato nel keystore del router (in uscita) o del processore di messaggi (in entrata) corrisponda a quello memorizzato nel truststore dell'applicazione client (in uscita) o del server di destinazione (in entrata) oppure a quello ottenuto dall'output di tcpdump. In caso di mancata corrispondenza, questo è il motivo dell'errore di handshake SSL.
9. Se viene rilevato che il certificato inviato da un server/client è scaduto, il client/server ricevente rifiuta il certificato e viene visualizzato il seguente messaggio di avviso in tcpdump:

   Avviso (livello: fatale, descrizione: certificato scaduto)

10. Verifica che il certificato nel keystore dell'host appropriato sia scaduto.

Risoluzione

Per risolvere il problema identificato nell'esempio precedente, carica il certificato valido del server di backend nel trustore del processore di messaggi.

La seguente tabella riassume i passaggi per risolvere il problema a seconda della causa.

SNI abilitato Server

L'errore di handshake TLS/SSL può verificarsi quando il client comunica con un server con SNI (Server Name Indication) abilitato, ma il client non ha SNI abilitato. Questo può verificarsi nella connessione in direzione nord o sud in Edge.

Innanzitutto, devi identificare il nome host e il numero di porta del server utilizzato e verificare se SNI è abilitato o meno.

Identificazione del server abilitato per SNI

1. Esegui il comando openssl e prova a connetterti al nome host del server pertinente (router Edge o server di backend) senza passare il nome del server, come mostrato di seguito:

   openssl s_client -connect hostname:port

   Potresti ricevere i certificati e a volte potresti notare l'errore di handshake nel comando openssl, come mostrato di seguito:
   

   CONNECTED(00000003)
   9362:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_clnt.c:593

2. Esegui il comando openssl e prova a connetterti al nome host del server pertinente (router di frontiera o server di backend) passando il nome del server come mostrato di seguito:

   openssl s_client -connect hostname:port -servername hostname

3. Se si verifica un errore di handshake nel passaggio 1 o se si ottengono certificati diversi nel passaggio 1 e nel passaggio 2, significa che il server specificato è abilitato per SNI.

Una volta verificato che il server è abilitato per SNI, puoi seguire i passaggi riportati di seguito per controllare se l'errore di handshake TLS/SSL è causato dall'impossibilità del client di comunicare con il server SNI.

Diagnosi

1. Determina se l'errore si è verificato nella connessione in direzione nord o in direzione sud. Per ulteriori indicazioni su come effettuare questa determinazione, consulta Determinare l'origine del problema.
2. Esegui l'utilità tcpdump per raccogliere ulteriori informazioni:
   • Se sei un utente di Private Cloud, puoi raccogliere i dati tcpdump sul client o sul server pertinente. Un client può essere l'app client (per le connessioni in entrata o in direzione nord) o il processore di messaggi (per le connessioni in uscita o in direzione sud). Un server può essere l'Edge Router (per le connessioni in entrata o in uscita) o il server di backend (per le connessioni in uscita o in entrata) in base alla tua determinazione del passaggio 1.
   • Se sei un utente del cloud pubblico, puoi raccogliere i dati tcpdump solo nell'app client (per le connessioni in entrata o in uscita) o nel server di backend (per le connessioni in uscita o in entrata), perché non hai accesso al router edge o al processore di messaggi.

   tcpdump -i any -s 0 host IP address -w File name
   

   Per saperne di più sull'utilizzo del comando tcpdump, consulta i dati tcpdump.
3. Analizza l'output tcpdump utilizzando Wireshark o uno strumento simile.
4. Ecco l'analisi di esempio di tcpdump utilizzando Wireshark:
   1. In questo esempio, l'handshake TLS/SSL non è riuscito tra Edge Message Processor e il server di backend (connessione in uscita).
   2. Il messaggio n. 4 nell'output tcpdump riportato di seguito mostra che il processore di messaggi (origine) ha inviato un messaggio "Client Hello" al server di backend (destinazione).

      

   3. Selezionando il messaggio "Client Hello" viene visualizzato che Message Processor utilizza il protocollo TLSv1.2.

      

   4. Il messaggio n. 4 mostra che il server di backend riconosce il messaggio "Client Hello" dal processore di messaggi.
   5. Il server di backend invia immediatamente un Fatal Alert : Handshake Failure al processore di messaggi (messaggio n. 5). Ciò significa che l'handshake TLS/SSL non è riuscito e la connessione verrà chiusa.
   6. Esamina il messaggio n. 6 per scoprire le seguenti informazioni
      • Il server di backend supporta il protocollo TLSv1.2. Ciò significa che il protocollo corrisponde tra il processore di messaggi e il server di backend.
      • Tuttavia, il server di backend invia comunque Fatal Alert: Handshake Failure al processore di messaggi, come mostrato nella figura seguente:

        

   7. Questo errore può verificarsi per uno dei seguenti motivi:
      • Il processore di messaggi non utilizza gli algoritmi della suite di crittografia supportati dal server di backend.
      • Il server di backend è abilitato per SNI, ma l'applicazione client non invia il nome del server.
   8. Esamina più in dettaglio il messaggio n. 3 (Client Hello) nell'output tcpdump. Tieni presente che manca l'estensione: server_name, come mostrato di seguito:

      

   9. Ciò conferma che il processore di messaggi non ha inviato server_name al server di backend abilitato per SNI.
   10. Questo è il motivo dell'errore di handshake TLS/SSL e il motivo per cui il server backend invia l'avviso irreversibile: errore di handshake al processore di messaggi.
5. Verifica che jsse.enableSNIExtension property in system.properties sia impostato su false in processore di messaggi per confermare che il processore di messaggi non sia abilitato a comunicare con il server abilitato per SNI.

Risoluzione

Consenti ai processori di messaggi di comunicare con i server abilitati per SNI seguendo questi passaggi:

1. Crea il file/opt/apigee/customer/application/message-processor.properties (se non esiste già).
2. Aggiungi la seguente riga a questo file: conf_system_jsse.enableSNIExtension=true
3. Modifica il proprietario di questo file in apigee:apigee:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Riavvia il processore di messaggi.

   /opt/apigee/apigee-service/bin/apigee-service message-processor restart

5. Se hai più di un processore di messaggi, ripeti i passaggi da 1 a 4 su tutti i processori di messaggi.

Se non riesci a determinare la causa dell'errore di handshake TLS/SSL e a risolvere il problema o hai bisogno di ulteriore assistenza, contatta l'assistenza Apigee Edge. Condividi i dettagli completi del problema insieme all'output di tcpdump.