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:
- Accetta la versione del protocollo da utilizzare.
- Seleziona l'algoritmo crittografico da utilizzare.
- 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
- 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.
- 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 comandotcpdump
. - Se sei un utente Private Cloud, puoi raccogliere i dati di
- Analizza i dati di
tcpdump
con lo strumento Wireshark o uno strumento simile. - 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:
- Esegui l'upgrade del server di backend per supportare il protocollo TLSv1.2. Questa è una soluzione consigliata poiché il protocollo TLSv1.2 è più sicuro.
- 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:
- Se non hai specificato un server di destinazione nella definizione di TargetEndpoint del proxy, imposta
l'elemento
Protocol
suTLSv1.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>
- 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.
- Se non hai specificato un server di destinazione nella definizione di TargetEndpoint del proxy, imposta
l'elemento
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
- 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.
- 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 comandotcpdump
. - Se sei un utente Private Cloud, puoi raccogliere i dati di
- Analizza i dati di
tcpdump
usando lo strumento Wireshark o qualsiasi altro strumento che conosci. - 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.
- In questo esempio, l'errore di handshake TLS/SSL si è verificato tra l'applicazione client e il router periferico (connessione nord). L'output
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
- 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
- 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:
-
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
-
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.
-
Ottieni il nome del certificato nell'archivio chiavi:
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
Catena di certificati incompleta o errata
Diagnostica
- 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:
-
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
-
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
- 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.
- 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 emittente e oggetto non corrispondono
-
Ottieni il nome del certificato nell'archivio chiavi:
Risoluzione
- Ottieni un certificato (se non ne hai già uno) che includa una catena di certificati completa e valida.
- 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
- 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
- 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.
- 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 comandotcpdump
. - Se sei un utente Private Cloud, puoi raccogliere i dati di
- Analizza i dati di
tcpdump
utilizzando Wireshark o uno strumento simile. - Dall'output
tcpdump
, determina l'host (client o server) che rifiuta il certificato durante la fase di verifica. - 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à. - 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
- Il processore di messaggi (client) invia "Client Hello" al server di backend (server) nel messaggio n. 59.
- Il server di backend invia "Server Hello" al processore di messaggi nel messaggio n. 61.
- che convalidano reciprocamente gli algoritmi di protocollo e della suite di crittografia utilizzati.
- Il server di backend invia il messaggio Certificato e Ciao server completato al processore di messaggi nel messaggio n. 68.
- Il processore di messaggi invia l'avviso irreversibile "Description: Certificate Unknown" nel messaggio n. 70.
- Analizzando ulteriormente il messaggio 70, non esistono dettagli aggiuntivi oltre al messaggio di avviso, come mostrato di seguito:
- Esamina il messaggio n. 68 per ottenere i dettagli sul certificato inviato dal server di backend, come mostrato nell'immagine seguente:
- Il certificato e la catena completa del server di backend sono disponibili sotto la sezione "Certificati", come mostrato nella figura precedente.
- 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:
- 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:
-
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
-
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
-
Ottieni il nome del certificato nell'archivio attendibilità:
- 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.
- 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:
- Se il certificato risulta sconosciuto dall'applicazione client (northbound) o dal server di destinazione (southbound), segui questi passaggi:
- 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:
-
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
-
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
-
Ottieni il nome del certificato nell'archivio chiavi:
- 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.
- 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:
- 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)
- 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
|
Carica un nuovo certificato e la relativa catena completa nell'archivio chiavi sull'host appropriato. |
SouthBound
|
Carica un nuovo certificato e la relativa catena completa nell'archivio chiavi sull'host appropriato. | |
Certificato sconosciuto |
NorthBound
|
Carica il certificato valido nell'archivio attendibilità sull'host appropriato. |
SouthBound
|
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
- 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
- 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
- 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
- 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.
- 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 comandotcpdump
. - Se sei un utente Private Cloud, puoi raccogliere i dati di
- Analizza l'output
tcpdump
utilizzando Wireshark o uno strumento simile. - 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 Edge e il server di backend (connessione a sud).
- 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). - La selezione del messaggio "Client Hello" mostra che il processore di messaggi utilizza il protocollo TLSv1.2.
- Il messaggio 4 mostra che il server di backend riconosce il messaggio "Client Hello" dal processore di messaggi.
- 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.
- 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:
- 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.
- 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: - Questo conferma che il processore di messaggi non ha inviato server_name al server di backend abilitato per SNI.
- 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.
- Verifica che il criterio
jsse.enableSNIExtension property
insystem.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:
- Crea il file
/opt/apigee/customer/application/message-processor.properties
(se non esiste già). - Aggiungi la seguente riga a questo file:
conf_system_jsse.enableSNIExtension=true
- Imposta il proprietario di questo file su
apigee:apigee
:chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
- Riavvia il processore di messaggi.
/opt/apigee/apigee-service/bin/apigee-service message-processor restart
- 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
.