Errori di handshake TLS/SSL

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Sintomo

Un errore di handshake TLS/SSL si verifica quando un client e un server non sono in grado di stabilire una 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. Questo errore viene visualizzato 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 set di chiavi secret con cui possono comunicare. Durante questo processo, client e server:

  1. Accetta 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 e il server TLS/SSL trasferiscono i dati l'uno all'altro 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:

Causa Descrizione Chi può eseguire la procedura di risoluzione dei problemi
Mancata corrispondenza del protocollo Il protocollo utilizzato dal client non è supportato dal server. Utenti del cloud privato e pubblico
Il pacchetto di crittografia non corrisponde Il pacchetto di crittografia utilizzato dal client non è supportato dal server. Utenti del cloud privato e pubblico
Certificato non corretto Il nome host nell'URL utilizzato dal client non corrisponde al nome host nel certificato archiviato al lato server. Utenti del cloud privato e pubblico
Una catena di certificati incompleta o non valida viene archiviata sul lato client o server. Utenti del cloud privato e pubblico
Un certificato errato o scaduto viene inviato dal client al server o dal server al client. Utenti del cloud privato e pubblico
Server abilitato SNI Sul server di backend è abilitata l'indicazione SNI (Server Name Indication), ma il client non può comunicare con i server SNI. Solo utenti Private Cloud

Mancata corrispondenza del protocollo

Un errore di handshake TLS/SSL si verifica se il protocollo utilizzato dal client non è supportato dal server alla connessione in entrata (northbound) o in uscita (southbound). Vedi anche Informazioni sui collegamenti in direzione nord e sud.

Diagnostica

  1. Determina se l'errore si è verificato alla connessione northbound o southbound. 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 Private Cloud, puoi raccogliere i dati di tcpdump presso il client o 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 il router perimetrale (per le connessioni in entrata o in direzione nord) o il server di backend (per le connessioni in uscita o in direzione sud) in base alla tua determinazione nel 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 direzione nord) o sul server di backend (per le connessioni in uscita o in direzione sud), poiché non hai accesso al router perimetrale o al processore di messaggi.
    tcpdump -i any -s 0 host IP address -w File name
    Consulta i dati di tcpdump per maggiori informazioni sull'utilizzo del comando tcpdump.
  3. Analizza i dati di tcpdump con lo strumento Wireshark o uno strumento simile.
  4. Ecco un esempio di analisi di tcpdump mediante 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 in direzione sud).
    • Il messaggio n. 4 nell'output tcpdump riportato di seguito mostra che il processore di messaggi (sorgente) ha inviato un messaggio "Client Hello" al server di backend (destinazione).

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

    • Il messaggio n. 5 mostra che il server di backend conferma il messaggio "Client Hello" dal processore di messaggi.
    • Il server di backend invia immediatamente Avviso irreversibile : notifica di chiusura all'elaboratore di messaggi (messaggio n. 6). Questo significa che l'handshake TLS/SSL non è riuscito e la connessione verrà chiusa.

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

    • Dal momento che il protocollo utilizzato dal processore di messaggi e il server di backend non corrisponde, il server di backend ha inviato il messaggio Messaggio di avviso irreversibile: Chiudi notifica.

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 poiché il protocollo TLSv1.2 è più sicuro.
  2. Se per qualche motivo non riesci a eseguire immediatamente l'upgrade del tuo server di backend, puoi forzare il processore di messaggi a utilizzare il protocollo TLSv1.0 per comunicare con il server di backend seguendo questa procedura:
    1. Se non hai specificato un server di destinazione nella definizione di 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.

Mancata corrispondenza della crittografia

Puoi visualizzare un errore di handshake TLS/SSL se l'algoritmo della suite di crittografia utilizzato dal client non è supportato dal server alla connessione in entrata (northbound) o in uscita (southbound) in Apigee Edge. Vedi anche Informazioni sui collegamenti in direzione nord e sud.

Diagnostica

  1. Determina se l'errore si è verificato alla connessione northbound o southbound. Per ulteriori indicazioni su come effettuare questa determinazione, consulta la pagina Determinazione dell'origine del problema.
  2. Esegui l'utilità tcpdump per raccogliere ulteriori informazioni:
    • Se sei un utente Private Cloud, puoi raccogliere i dati di tcpdump presso il client o 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 il router perimetrale (per le connessioni in entrata o in direzione nord) o il server di backend (per le connessioni in uscita o in direzione sud) in base alla tua determinazione nel 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 direzione nord) o sul server di backend (per le connessioni in uscita o in direzione sud), poiché non hai accesso al router perimetrale o al processore di messaggi.
    tcpdump -i any -s 0 host IP address -w File name
    Consulta i dati di tcpdump per maggiori informazioni sull'utilizzo del comando tcpdump.
  3. Analizza i dati di tcpdump usando lo strumento Wireshark o qualsiasi altro strumento che conosci.
  4. Ecco un esempio di analisi dell'output di tcpdump mediante Wireshark:
    • In questo esempio, l'errore di handshake TLS/SSL si è verificato tra l'applicazione client e il router periferico (connessione nord). L'output tcpdump è stato raccolto sul router perimetrale.

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

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

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

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

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

    • L'elenco degli algoritmi della suite di crittografia supportati dal router Edge è elencato nel file /opt/nginx/conf.d/0-default.conf. In questo esempio, il router perimetrale supporta solo gli algoritmi del pacchetto di crittografia ad alta crittografia.
    • L'applicazione client non utilizza nessuno degli algoritmi del pacchetto di crittografia con crittografia elevata. Questa mancata corrispondenza è la causa dell'errore di handshake TLS/SSL.
    • Poiché il router Edge è abilitato per SNI, scorri verso il basso fino al messaggio 4 nell'output tcpdump e conferma che l'applicazione client stia inviando correttamente il nome del server, come mostrato nella figura seguente:


    • Se questo nome è valido, si può dedurre che l'errore di handshake TLS/SSL si è verificato perché gli algoritmi della 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 Diagnostica precedente, scarica e installa il pacchetto JCE (Java Cryptography Extension) e includilo nell'installazione Java per supportare gli algoritmi della suite di crittografia ad alta crittografia.

Certificato errato

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

Se il problema riguarda il northbound, potresti visualizzare messaggi di errore diversi a seconda della causa.

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

Messaggi di errore

Potresti visualizzare messaggi di errore diversi a seconda della causa dell'errore di handshake TLS/SSL. Di seguito è riportato 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:

Causa Descrizione Chi può eseguire la procedura di risoluzione dei problemi
Mancata corrispondenza del nome host Il nome host utilizzato nell'URL e il certificato nell'archivio chiavi del router non corrispondono. Ad esempio, si verifica una mancata corrispondenza se il nome host utilizzato nell'URL è myorg.domain.com, mentre il nome host del certificato nel suo CN è CN=something.domain.com.

 Utenti di cloud privato e pubblico Edge
Catena di certificati incompleta o errata La catena di certificati non è completa o non è corretta. Solo per utenti di cloud privato e pubblico Edge
Certificato scaduto o sconosciuto inviato dal server o dal client Un certificato scaduto o sconosciuto viene inviato dal server o dal client nella connessione in direzione nord o a sud. Utenti Edge Private Cloud e Edge Public Cloud

Nome host non corrispondente

Diagnostica

  1. Nota il nome host utilizzato nell'URL restituito dalla seguente chiamata API Edge Management: 
    curl -v https://myorg.domain.com/v1/getinfo
    Ad esempio: 
    curl -v https://api.enterprise.apigee.com/v1/getinfo
  2. Ottieni il nome di rete connessa utilizzato nel certificato archiviato nell'archivio chiavi specifico. Puoi utilizzare le seguenti API di gestione perimetrale per ottenere i dettagli del certificato:
    1. Ottieni il nome del certificato nell'archivio chiavi:

      Se sei un utente Private Cloud, 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 di 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. Ottieni i dettagli del certificato nell'archivio chiavi utilizzando l'API Edge Management.

      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 di Cloud pubblico:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name

      Esempio di certificato:

      "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 (fai riferimento al passaggio 1 sopra) e il nome dell'oggetto nel certificato non corrispondono, si verifica un errore di handshake TLS/SSL.

Risoluzione

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

  • Ottieni un certificato (se non ne hai già uno) in cui il CN dell'oggetto ha un certificato con caratteri jolly, 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 oggetto esistente, ma utilizza your-org.your-domain come nome alternativo dell'oggetto, quindi carica la catena di certificati completa nell'archivio chiavi.

Riferimenti

Keystore e truststore

Catena di certificati incompleta o errata

Diagnostica

  1. Ottieni il nome di rete connessa utilizzato nel certificato archiviato nell'archivio chiavi specifico. Puoi utilizzare le seguenti API di gestione perimetrale per ottenere i dettagli del certificato:
    1. Ottieni il 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 di 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 di 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 rispettino le linee guida fornite nell'articolo Come funzionano le catene di certificati per garantire che sia una catena di certificati valida e completa. Se la catena di certificati archiviata nell'archivio chiavi è incompleta o non valida, viene visualizzato un 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:

      5. Esempio di certificato intermedio e radice in cui emittente e oggetto 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 opensl 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 il server/client invia un certificato errato/scaduto alla connessione verso nord o verso sud, l'altra estremità (server/client) rifiuta il certificato, causando un errore nell'handshake TLS/SSL.

Diagnostica

  1. Determina se l'errore si è verificato alla connessione northbound o southbound. 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 Private Cloud, puoi raccogliere i dati di tcpdump presso il client o 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 il router perimetrale (per le connessioni in entrata o in direzione nord) o il server di backend (per le connessioni in uscita o in direzione sud) in base alla tua determinazione nel 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 direzione nord) o sul server di backend (per le connessioni in uscita o in direzione sud), poiché non hai accesso al router perimetrale o al processore di messaggi.
    tcpdump -i any -s 0 host IP address -w File name
    Consulta i dati di tcpdump per maggiori informazioni sull'utilizzo del comando tcpdump.
  3. Analizza i dati di tcpdump utilizzando Wireshark o uno strumento simile.
  4. Dall'output tcpdump, determina l'host (client o server) che rifiuta il certificato durante la fase di verifica.
  5. Puoi recuperare il certificato inviato dall'altra parte dall'output tcpdump, a condizione che i dati non siano criptati. Questa opzione sarà utile per verificare se il certificato corrisponde a quello disponibile nell'archivio attendibilità.
  6. Esamina l'esempio tcpdump per la comunicazione SSL tra il processore di messaggi e il server di backend.

    Esempio tcpdump di errore relativo al 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. che convalidano reciprocamente gli algoritmi di protocollo e della suite di crittografia utilizzati.
    4. Il server di backend invia il messaggio Certificato e Ciao server completato al processore di messaggi nel messaggio n. 68.
    5. Il processore di messaggi invia l'avviso irreversibile "Description: Certificate Unknown" nel messaggio n. 70.
    6. Analizzando ulteriormente il messaggio 70, non esistono dettagli aggiuntivi oltre al messaggio di avviso, come mostrato di seguito:


    7. Esamina il messaggio n. 68 per ottenere i dettagli sul certificato inviato dal server di backend, come mostrato nell'immagine seguente:

    8. Il certificato e la catena completa del server di backend sono disponibili sotto la sezione "Certificati", come mostrato nella figura precedente.
  7. Se il certificato risulta sconosciuto dal router (in direzione nord) o dal processore di messaggi (in direzione sud) come nell'esempio illustrato sopra, segui questi passaggi:
    1. Recupera il certificato e la relativa catena archiviati nell'archivio di attendibilità specifico. (Fai riferimento alla configurazione dell'host virtuale per la configurazione del router e dell'endpoint di destinazione per il processore di messaggi). Puoi utilizzare le API seguenti per ottenere i dettagli del certificato:
      1. Ottieni 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. Visualizza i dettagli del certificato nell'archivio attendibilità: 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name
    2. Verifica se il certificato archiviato nell'archivio attendibilità del router (in direzione nord) o del processore di messaggi (in direzione sud) corrisponde al certificato archiviato nell'archivio chiavi dell'applicazione client (in direzione nord) o del server di destinazione (in direzione a sud) oppure a quello ottenuto dall'output tcpdump. L'eventuale mancata corrispondenza è la causa dell'errore di handshake TLS/SSL.
  8. Se il certificato risulta sconosciuto dall'applicazione client (northbound) o dal server di destinazione (southbound), segui questi passaggi:
    1. Ottieni la catena di certificati completa utilizzata nel certificato archiviato nell'archivio chiavi specifico. Fai riferimento alla configurazione dell'host virtuale per la configurazione del router e dell'endpoint di destinazione per il processore di messaggi. Puoi utilizzare le API seguenti 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 se il certificato archiviato nell'archivio chiavi del router (in direzione nord) o del processore di messaggi (in direzione sud) corrisponde al certificato archiviato nell'archivio di attendibilità dell'applicazione client (in direzione nord) o del server di destinazione (in direzione sud), oppure a quello ottenuto dall'output tcpdump. L'eventuale mancata corrispondenza è questa è la causa dell'errore di handshake SSL.
  9. Se il certificato inviato da un server/client risulta scaduto, il client/server ricevente lo rifiuta e viene visualizzato il seguente messaggio di avviso in 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 certificato valido del server di backend nel trustore del processore di messaggi.

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

Causa Descrizione Risoluzione
Certificato scaduto NorthBound
  • Il certificato memorizzato nell'archivio chiavi del router è scaduto.
  • Il certificato memorizzato nell'archivio chiavi dell'applicazione client è scaduto (SSL bidirezionale).
 Carica un nuovo certificato e la relativa catena completa nell'archivio chiavi sull'host appropriato.
SouthBound
  • Il certificato archiviato nell'archivio chiavi del server di destinazione è scaduto.
  • Il certificato memorizzato nell'archivio chiavi del processore di messaggi è scaduto (SSL bidirezionale).
 Carica un nuovo certificato e la relativa catena completa nell'archivio chiavi sull'host appropriato.
Certificato sconosciuto NorthBound
  • Il certificato archiviato nell'archivio attendibilità dell'applicazione client non corrisponde al certificato del router.
  • Il certificato archiviato nell'archivio attendibilità del router non corrisponde al certificato dell'applicazione client (SSL a due vie).
 Carica il certificato valido nell'archivio attendibilità sull'host appropriato.
SouthBound
  • Il certificato archiviato nell'archivio attendibilità del server di destinazione non corrisponde al certificato del processore di messaggi.
  • Il certificato archiviato nell'archivio attendibilità del processore di messaggi non corrisponde al certificato del server di destinazione (SSL bidirezionale).
 Carica il certificato valido nell'archivio attendibilità sull'host appropriato.

Server abilitato SNI

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

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

Identificazione del server abilitato per SNI

  1. Esegui il comando openssl e prova a connetterti al nome host del server pertinente (router periferico 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 un errore di handshake nel comando hostssl, 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 al passaggio 1 o ricevi certificati diversi nei passaggi 1 e 2, significa che il server specificato è abilitato per SNI.

Una volta identificato il server SNI abilitato, segui i passaggi riportati di seguito per verificare se l'errore di handshake TLS/SSL è causato dall'impossibilità da parte del client di comunicare con il server SNI.

Diagnostica

  1. Determina se l'errore si è verificato alla connessione northbound o southbound. 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 Private Cloud, puoi raccogliere i dati di tcpdump presso il client o 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 il router perimetrale (per le connessioni in entrata o in direzione nord) o il server di backend (per le connessioni in uscita o in direzione sud) in base alla tua determinazione nel 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 direzione nord) o sul server di backend (per le connessioni in uscita o in direzione sud), poiché non hai accesso al router perimetrale o al processore di messaggi.
    tcpdump -i any -s 0 host IP address -w File name
    Consulta i dati di tcpdump per maggiori informazioni sull'utilizzo del comando tcpdump.
  3. Analizza l'output tcpdump utilizzando Wireshark o uno strumento simile.
  4. Ecco un esempio di analisi di tcpdump mediante Wireshark:
    1. In questo esempio, l'errore di handshake TLS/SSL si è verificato tra il processore di messaggi Edge e il server di backend (connessione a sud).
    2. Il messaggio 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. La selezione del messaggio "Client Hello" mostra che il processore di messaggi utilizza il protocollo TLSv1.2.

    4. Il messaggio 4 mostra che il server di backend riconosce il messaggio "Client Hello" dal processore di messaggi.
    5. Il server di backend invia immediatamente un avviso irreversibile : errore di handshake al 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 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 l'avviso irreversibile: errore di handshake 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 SNI, ma l'applicazione client non sta inviando il nome del server.
    8. Esamina in modo più dettagliato il messaggio 3 (Client Hello) nell'output tcpdump. Tieni presente che manca l'Estensione: server_name, come mostrato di seguito:

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

Risoluzione

Consenti ai processori di messaggi di comunicare con i server abilitati per SNI svolgendo i seguenti 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. Imposta il proprietario di questo file su 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 disponi di più processori di messaggi, ripeti i passaggi da 1 a 4 su tutti i processori di messaggi.

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