Errori di handshake TLS/SSL

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Sintomo

Un errore di handshake TLS/SSL si verifica quando un client e un server non riescono a stabilire la comunicazione utilizzando il metodo TLS/SSL. Quando questo errore si verifica in Apigee Edge, il client riceve lo stato HTTP 503 con il messaggio Servizio non disponibile. Tu vedrai 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

Inoltre, quando si verifica un errore di handshake TLS/SSL, viene visualizzato questo messaggio di errore:

Received fatal alert: handshake_failure

Possibili cause

TLS (Transport Layer Security, il cui predecessore è SSL) è la tecnologia di sicurezza standard per stabilendo 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 set di secret chiavi con cui possono comunicare. Durante questo processo, il client e il server:

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

Se l'handshake TLS/SSL ha esito positivo, il client TLS/SSL e il server trasferiscono i dati a ogni le altre in modo sicuro. Altrimenti, 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 degli errori di handshake TLS/SSL sono:

Protocollo Mancata corrispondenza

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

Diagnosi

1. Determina se l'errore si è verificato nel limite nord o connessione in direzione sud. Per ulteriori indicazioni su come rendere per la determinazione, consulta Determinazione dell'origine del problema.
2. Esegui l' tcpdump per raccogliere ulteriori informazioni:
   .
   • Se sei un utente di Private Cloud, puoi raccogliere tcpdump presso il client o il server pertinente. Un client può essere l'app client (per gli annunci in entrata, o connessioni verso nord) o il messaggio Processore (per connessioni in uscita o verso sud). Un server può essere il router perimetrale (ad connessioni in entrata o in direzione nord) o al server di backend (per le connessioni in uscita o verso sud) in base alle condizioni stabilite nel passaggio 1.
   • Se sei un utente del cloud pubblico, puoi raccogliere tcpdump Dati solo sull'app client (per le connessioni in entrata o in direzione nord) o sul server di backend (per le connessioni in uscita o verso sud), perché non hanno accesso al router perimetrale o al processore di messaggi.

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

   Consulta tcpdump per ulteriori informazioni sull'uso del tcpdump .
3. Analizza i dati tcpdump con lo strumento Wireshark o uno strumento simile.
4. Di seguito è riportato un esempio di analisi tcpdump utilizzando Wireshark:
   .
   • In questo esempio, l'errore di handshake TLS/SSL si è verificato tra il processore di messaggi e il server di backend (la connessione in uscita o verso sud).
   • Il messaggio 4 nell'output tcpdump seguente indica che il processore di messaggi (origine) ha inviato un "Gentile cliente" al server di backend (Destinazione).
     

     

   • Se selezioni il messaggio Client Hello, questo indica che il processore di messaggi sta utilizzando TLSv1.2, come mostrato di seguito:

     

   • Il messaggio 5 indica che il server di backend riconosce "Client Hello" messaggio da il processore di messaggi.
   • Il server di backend invia immediatamente un avviso irreversibile : chiusura notifica al messaggio Processore di messaggi (messaggio n. 6). Ciò significa che l'handshake TLS/SSL non è riuscito e la connessione potrebbero essere chiusi.

   • Esaminando ulteriormente il messaggio 6, risulta che la causa dell'errore di handshake TLS/SSL è che server di backend supporta solo il protocollo TLSv1.0, come illustrato di seguito:

     

   • A causa di una mancata corrispondenza tra il protocollo utilizzato dal processore di messaggi e il server di backend, il server di backend ha inviato il messaggio: Messaggio di avviso irreversibile: chiusura Invia notifica.

Risoluzione

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

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

      <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 server di destinazione per il proxy, quindi utilizza . all'API di gestione per impostare il protocollo su TLSv1.0 nella configurazione del server di destinazione.

Mancata corrispondenza della crittografia

Puoi vedere un errore di handshake TLS/SSL se l'algoritmo della suite di crittografia 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 verso nord e sud.

Diagnosi

1. Determina se l'errore si è verificato nelle ore la connessione in direzione nord o sud. Per ulteriori indicazioni su come effettuare questa valutazione, consulta Determinare l'origine del problema.
2. Esegui l' tcpdump per raccogliere ulteriori informazioni:
   .
   • Se sei un utente di Private Cloud, puoi raccogliere tcpdump presso il client o il server pertinente. Un client può essere l'app client (per gli annunci in entrata, o connessioni verso nord) o il messaggio Processore (per connessioni in uscita o verso sud). Un server può essere il router perimetrale (ad connessioni in entrata o in direzione nord) o al server di backend (per le connessioni in uscita o verso sud) in base alle condizioni stabilite nel passaggio 1.
   • Se sei un utente del cloud pubblico, puoi raccogliere tcpdump Dati solo sull'app client (per le connessioni in entrata o in direzione nord) o sul server di backend (per le connessioni in uscita o verso sud), perché non hanno accesso al router perimetrale o al processore di messaggi.

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

   Consulta tcpdump per ulteriori informazioni sull'uso del comando tcpdump.
3. Analizza i dati di tcpdump utilizzando lo strumento Wireshark o qualsiasi altro strumento che conosci.
4. Ecco un esempio di analisi dell'output tcpdump mediante Wireshark:
   • In questo esempio, l'errore di handshake TLS/SSL si è verificato tra l'applicazione client e Router perimetrale (connessione nord). L'output tcpdump è stato raccolto su Edge o eseguire il provisioning di un router.

   • Il messaggio 4 nell'output tcpdump seguente indica che l'applicazione client (origine) ha inviato un "Gentile cliente" al router perimetrale (destinazione).

     

   • La selezione del messaggio Client Hello mostra che l'applicazione client sta utilizzando TLSv1.2.

     

   • Il messaggio 5 mostra che il router Edge riconosce "Client Hello" messaggio da l'applicazione client.
   • Il router perimetrale invia immediatamente un avviso irreversibile : handshake non riuscita a. l'applicazione client (messaggio n. 6). Ciò significa che l'handshake TLS/SSL non è riuscito e la connessione verrà chiuso.
   • Analizzando più in dettaglio il messaggio 6, vengono mostrate le seguenti informazioni:
     • Il router perimetrale supporta il protocollo TLSv1.2. Ciò significa che il protocollo corrisponde tra l'applicazione client e il router perimetrale.

     • Tuttavia, il router perimetrale invia comunque l'avviso irreversibile: handshake Errore nell'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 dalla Router Edge.
     • Il router perimetrale è abilitato per SNI, ma l'applicazione client non invia il il nome del server.
   • Il messaggio 4 nell'output tcpdump elenca gli algoritmi della suite di crittografia supportati dal client come mostrato di seguito:

     

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

Risoluzione

Devi assicurarti che il client utilizzi gli algoritmi della suite di crittografia supportate dal server. Per risolvere il problema descritto nella sezione Diagnosi, scarica e installa Java Cryptography Extension (JCE) e includerlo nel pacchetto Java per supportare gli algoritmi della suite di crittografia con crittografia elevata.

Certificato errato

Un errore di handshake TLS/SSL si verifica se sono presenti certificati errati nell'archivio chiavi/nell'archivio di attendibilità, alla connessione in entrata (verso nord) o in uscita (verso sud) in Apigee Edge. Vedi anche Informazioni sulle connessioni verso nord e sud.

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

Le seguenti sezioni elencano esempi di messaggi di errore e i passaggi per diagnosticare e risolvere il problema problema.

Messaggi di errore

Potrebbero essere visualizzati messaggi di errore diversi a seconda della causa dell'errore dell'handshake TLS/SSL. Di seguito è riportato un messaggio di errore di esempio che potrebbe essere visualizzato 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:

Nome host Mancata corrispondenza

Diagnosi

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

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

   Ad esempio:

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

2. Recupera il CN utilizzato nel certificato archiviato nell'archivio chiavi specifico. Puoi utilizzare lo seguenti API di gestione perimetrale per ottenere i dettagli del certificato:
   1. Recupero del nome del certificato nell'archivio chiavi:
      
      Se sei un utente Private Cloud, utilizza l'API di gestione come segue:
      

      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 come segue:
      

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

   2. Recupera i dettagli del certificato nell'archivio chiavi usando l'API Edge Management.
      
      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
      

      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 (consulta il passaggio 1 precedente) e l'oggetto nel certificato non corrisponde, ricevi l'errore dell'handshake TLS/SSL.

Risoluzione

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

• Ottenere un certificato (se non ne hai già uno) in cui il CN dell'oggetto ha un carattere jolly certificato, quindi 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 dell'oggetto, quindi carica il testo completo all'archivio chiavi.

Riferimenti

Keystore e Truststores

Catena di certificati incompleta o errata

Diagnosi

1. Recupera il CN utilizzato nel certificato archiviato nell'archivio chiavi specifico. Puoi utilizzare lo seguenti API di gestione perimetrale per ottenere i dettagli del certificato:
   1. Recupero del nome del certificato nell'archivio chiavi:
      
      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 nell'archivio chiavi:
      
      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 sia conforme. alle linee guida fornite nell'articolo Come funzionano le catene di certificati per garantire che sia valida e completa nella catena di certificati. Se la catena di certificati archiviata nell'archivio chiavi incompleto o non valido, vedrai l'handshake TLS/SSL errore.
   4. La tabella seguente 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 emittente e l'oggetto non corrisponde

   
   

Risoluzione

1. Richiedi un certificato (se non ne hai già uno) che includa un documento completo e valido nella catena di certificati.
2. Esegui questo comando Opensl per verificare che la catena di certificati sia corretta e completato:

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

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

Scaduto o sconosciuto certificato inviato dal server o client

Se il server/client invia un certificato errato/scaduto dal server/client nella zona nord o alla connessione verso sud, l'altra estremità (server/client) rifiuta il certificato che provoca un errore di handshake TLS/SSL.

Diagnosi

1. Determina se l'errore si è verificato nel limite nord o connessione in direzione sud. Per ulteriori indicazioni su come rendere per la determinazione, consulta Determinazione dell'origine del problema.
2. Esegui l' tcpdump per raccogliere ulteriori informazioni:
   .
   • Se sei un utente di Private Cloud, puoi raccogliere tcpdump presso il client o il server pertinente. Un client può essere l'app client (per gli annunci in entrata, o connessioni verso nord) o il messaggio Processore (per connessioni in uscita o verso sud). Un server può essere il router perimetrale (ad connessioni in entrata o in direzione nord) o al server di backend (per le connessioni in uscita o verso sud) in base alle condizioni stabilite nel passaggio 1.
   • Se sei un utente del cloud pubblico, puoi raccogliere tcpdump Dati solo sull'app client (per le connessioni in entrata o in direzione nord) o sul server di backend (per le connessioni in uscita o verso sud), perché non hanno accesso al router perimetrale o al processore di messaggi.

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

   Consulta tcpdump per ulteriori informazioni sull'uso del comando tcpdump.
3. Analizza i dati tcpdump utilizzando Wireshark o una strumento simile.
4. Dall'output tcpdump, determina l'host (client o server) che rifiuta il token durante la fase di verifica.
5. Puoi recuperare il certificato inviato dall'altra estremità dall'output tcpdump, a condizione che i dati non sono criptati. Sarà utile per confrontare se il certificato corrisponde a disponibile nell'archivio attendibilità.
6. Esamina l'esempio tcpdump per la comunicazione SSL tra il processore di messaggi e il server di backend.

   Esempio di tcpdump che mostra l'errore di certificato sconosciuto

   
   

   1. Il processore di messaggi (client) invia "Client Hello" al server di backend (server) nel messaggio 59.
   2. Il server di backend invia "Server Hello" al processore di messaggi nel messaggio 61.
   3. Convalidano reciprocamente il protocollo e gli algoritmi della suite di crittografia utilizzati.
   4. Il server di backend invia il messaggio del certificato e del server Hello Done al server Processore di messaggi nel messaggio n. 68.
   5. Il processore di messaggi invia l'avviso irreversibile "Descrizione: certificato Sconosciuto" nel messaggio 70.
   6. Esaminando il messaggio n. 70, non ci sono ulteriori dettagli. del messaggio di avviso come mostrato di seguito:

      
      

   7. Rivedi il messaggio n. 68 per ottenere i dettagli sul certificato inviato dal backend server web, come illustrato nella figura seguente:

      

   8. Il certificato del server di backend e la sua catena completa sono tutti disponibili sotto "Certificati" come mostrato nella figura sopra.
7. Se il certificato risulta sconosciuto dal router (in direzione nord) o Processore di messaggi (southbound) come nell'esempio illustrato sopra, segui queste istruzioni passaggi:
   1. Recuperare il certificato e la relativa catena archiviati nell'archivio attendibilità specifico. (Consulta alla configurazione dell'host virtuale per il router e alla configurazione dell'endpoint di destinazione il processore di messaggi). Puoi utilizzare le seguenti API per ottenere i dettagli certificato:
      1. Recupera il nome del certificato nell'archivio attendibilità:

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

      2. Ottieni 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. Verificare se il certificato è archiviato nel truststore del router (in direzione nord) Il processore di messaggi (in direzione sud) corrisponde al certificato archiviato nella dell'applicazione client (in direzione nord) o del server di destinazione (in direzione sud), oppure uno ottenuto dall'output tcpdump. L'eventuale mancata corrispondenza è la causa l'errore dell'handshake TLS/SSL.
8. Se il certificato risulta sconosciuto dall'applicazione client (verso nord) o il server di destinazione (in direzione sud), procedi nel seguente modo:
   1. Recuperare la catena di certificati completa utilizzata nel certificato archiviato nel un archivio chiavi. Fai riferimento alla configurazione dell'host virtuale per il router e l'endpoint di destinazione configurazione per il processore di messaggi). Puoi utilizzare le API seguenti per ottenere dettagli del certificato:
      1. Visualizza 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 sia archiviato nell'archivio chiavi del router (in direzione nord) Il processore di messaggi (in direzione sud) corrisponde al certificato archiviato nel truststore del l'applicazione client (in direzione nord) o il server di destinazione (in direzione sud) o il server ottenuto dall'output tcpdump. Un'errata corrispondenza è la causa dell'errore SSL handshake non riuscito.
9. Se il certificato inviato da un server/client risulta scaduto, allora il client rifiuta il certificato e viene visualizzato il seguente messaggio di avviso nella tcpdump:

   Avviso (livello: irreversibile, descrizione: certificato scaduto)

10. Verifica che il certificato nell'archivio chiavi dell'host appropriato sia scaduto.

Risoluzione

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

La seguente tabella riassume i passaggi per risolvere il problema in base alla causa problema.

SNI abilitato Server

L'errore di handshake TLS/SSL può verificarsi quando il client comunica con un server Indicazione del nome (SNI) abilitata Il server, ma il client non è abilitato per SNI. Questo può accadere nella zona nord o verso sud in Edge.

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

Identificazione del server abilitato SNI

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

   openssl s_client -connect hostname:port
   

   Potresti ricevere i certificati e a volte potresti notare un errore di handshake in il comando Opensl, 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 Edge o server di backend) trasmettendo 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 ottieni certificati diversi nel passaggio 1 e al passaggio 2, significa che il server specificato è abilitato per SNI.

Dopo aver identificato che il server è abilitato per SNI, puoi seguire questi passaggi per controlla se l'errore dell'handshake TLS/SSL è causato dall'impossibilità da parte del client di comunicare con il server SNI.

Diagnosi

1. Determina se l'errore si è verificato nel limite nord o connessione in direzione sud. Per ulteriori indicazioni su come rendere per la determinazione, consulta Determinazione dell'origine del problema.
2. Esegui l' tcpdump per raccogliere ulteriori informazioni:
   .
   • Se sei un utente di Private Cloud, puoi raccogliere tcpdump presso il client o il server pertinente. Un client può essere l'app client (per gli annunci in entrata, o connessioni verso nord) o il messaggio Processore (per connessioni in uscita o verso sud). Un server può essere il router perimetrale (ad connessioni in entrata o in direzione nord) o al server di backend (per le connessioni in uscita o verso sud) in base alle condizioni stabilite nel passaggio 1.
   • Se sei un utente del cloud pubblico, puoi raccogliere tcpdump Dati solo sull'app client (per le connessioni in entrata o in direzione nord) o sul server di backend (per le connessioni in uscita o verso sud), perché non hanno accesso al router perimetrale o al processore di messaggi.

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

   Consulta tcpdump per ulteriori informazioni sull'uso del comando tcpdump.
3. Analizza l'output tcpdump utilizzando Wireshark o una strumento simile.
4. Ecco un esempio di analisi di tcpdump con Wireshark:
   1. In questo esempio, l'errore di handshake TLS/SSL si è verificato tra il messaggio Edge Processore e server di backend (connessione verso sud).
   2. Il messaggio 4 nell'output tcpdump seguente indica che il processore di messaggi (origine) ha inviato un "Client Hello" al server di backend (destinazione).

      

   3. Selezionando "Client Hello" mostra che l'oggetto Messaggio Il processore utilizza il protocollo TLSv1.2.

      

   4. Il messaggio 4 indica che il server di backend conferma il messaggio "Client Hello" messaggio del processore di messaggi.
   5. Il server di backend invia immediatamente un avviso irreversibile : handshake Errore del processore di messaggi (messaggio n. 5). Ciò significa che l'handshake TLS/SSL non è riuscito e la connessione verrà chiusa.
   6. Leggi il messaggio 6 per scoprire le seguenti informazioni
      • Il server di backend non supporta il protocollo TLSv1.2. Ciò significa che il protocollo tra il processore di messaggi e il server di backend.
      • Tuttavia, il server di backend invia comunque l'avviso irreversibile: handshake Errore del processore di messaggi, come mostrato nella figura seguente:

        

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

      

   9. Questo conferma che il processore di messaggi non ha inviato il messaggio server_name al server di backend abilitato per SNI.
   10. Questa è la causa dell'errore dell'handshake TLS/SSL e il motivo per cui il backend server invia Avviso irreversibile: handshake di handshake al messaggio Processore.
5. Verifica che jsse.enableSNIExtension property in system.properties è impostato su false nel processore di messaggi per confermare che Il processore di messaggi non è abilitato per comunicare con il server abilitato SNI.

Risoluzione

Consenti ai processori di messaggi di comunicare con i server abilitati per SNI eseguendo le seguenti passaggi:

1. Crea la /opt/apigee/customer/application/message-processor.properties (se non esiste già).
2. Aggiungi la seguente riga al file: conf_system_jsse.enableSNIExtension=true
3. Assegna il proprietario di questo file a 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 si dispone di più di un processore di messaggi, ripetere i passaggi da 1 a 4 su tutte le Processori di messaggi.

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