Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Errori di handshake SSL - Certificato client non valido

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

Sintomo

L'applicazione client riceve un codice di stato HTTP 503 con il messaggio "Service Unavailable" in risposta a una richiesta API. Nella traccia dell'interfaccia utente, noterai che error.cause è Received fatal alert: bad_certificate nel flusso di richieste target per la richiesta API non riuscita.

Se hai accesso ai log del processore di messaggi, noterai il messaggio di errore come Received fatal alert: bad_certificate per la richiesta API non riuscita. Questo errore si verifica durante il processo di handshake SSL tra il processore di messaggi e il server di backend in una configurazione TLS bidirezionale.

Messaggio di errore

L'applicazione client riceve il seguente codice di risposta:

HTTP/1.1 503 Service Unavailable

Inoltre, potresti visualizzare il seguente messaggio di errore:

{
 "fault": {
    "faultstring":"The Service is temporarily unavailable",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.ServiceUnavailable"
    }
 }
}

Gli utenti di Private Cloud vedranno il seguente errore per la richiesta API specifica nei log del processore di messaggi /opt/apigee/var/log/edge-message-processor/system.log:

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1 bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate

Possibili cause

Le possibili cause di questo problema sono le seguenti:

Causa	Descrizione	Istruzioni per la risoluzione dei problemi applicabili a
Nessun certificato client	L'archivio chiavi utilizzato nell'endpoint target del server target non contiene alcun certificato client.	Utenti di Edge Private e Public Cloud
Mancata corrispondenza dell'autorità di certificazione	L'autorità di certificazione del certificato foglia (il primo certificato nella catena di certificati) nell'archivio chiavi del processore di messaggi non corrisponde a nessuna delle autorità di certificazione accettate dal server di backend.	Utenti di Edge Private e Public Cloud

Passaggi comuni per la diagnosi

Abilita la traccia nell'interfaccia utente di Edge, effettua la chiamata API e riproduci il problema.
Nei risultati della traccia dell'interfaccia utente, scorri ogni fase e determina dove si è verificato l' errore. L'errore si è verificato nel flusso di richieste target.
Esamina il flusso che mostra l'errore. Dovresti vedere l'errore come mostrato nella traccia di esempio di seguito:
Come puoi vedere nello screenshot sopra, error.cause è "Received fatal alert: bad_certificate".

Se sei un utente di Private Cloud, segui le istruzioni riportate di seguito:

Puoi ottenere l'ID messaggio per la richiesta API non riuscita determinando il valore dell'intestazione di errore "X-Apigee.Message-ID" nella fase indicata da AX nella traccia.

Cerca questo ID messaggio nel log del processore di messaggi /opt/apigee/var/log/edge-message-processor/system.log e determina se riesci a trovare ulteriori informazioni sull'errore:

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1
bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate
2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLInfo:
KeyStore:java.security.KeyStore@52de60d9 KeyAlias:KeyAlias TrustStore:java.security.KeyStore@6ec45759
2017-10-23 05:28:57,814 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
RequestWriteListener.onException(HTTPRequest@6071a73d)
javax.net.ssl.SSLException: Received fatal alert: bad_certificate
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800) ~[na:1.8.0_101]
at com.apigee.nio.NIOSelector$SelectedIterator.findNext(NIOSelector.java:496) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:312) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:302) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:59) [nio-1.0.0.jar:na]

Il log del processore di messaggi conteneva un'analisi dello stack per l'errore Received fatal alert: bad_certificate, ma non contiene ulteriori informazioni che indicano la causa di questo problema.

Per esaminare ulteriormente questo problema, dovrai acquisire i pacchetti TCP/IP utilizzando lo strumento tcpdump.
1. Se sei un utente di Private Cloud, puoi acquisire i pacchetti TCP/IP sul server di backend o sul processore di messaggi. È preferibile acquisirli sul server di backend, poiché i pacchetti vengono decriptati sul server di backend.
2. Se sei un utente di Public Cloud, acquisisci i pacchetti TCP/IP sul server di backend.
3. Una volta deciso dove acquisire i pacchetti TCP/IP, utilizza il seguente tcpdump per acquisirli.
Analizza i pacchetti TCP/IP utilizzando lo strumento Wireshark o uno strumento simile che conosci.

Ecco l'analisi dei dati di esempio dei pacchetti TCP/IP utilizzando lo strumento Wireshark:

alt_text

Il messaggio n. 4 nel tcpdump sopra mostra che il processore di messaggi (origine) ha inviato un messaggio "Client Hello" al server di backend (destinazione).
Il messaggio n. 5 mostra che il server di backend riconosce il messaggio Client Hello dal processore di messaggi.
Il server di backend invia il messaggio "Server Hello" insieme al suo certificato, e quindi richiede al client di inviare il suo certificato nel messaggio n. 7.
Il processore di messaggi completa la verifica del certificato e riconosce il messaggio ServerHello del server di backend nel messaggio n. 8.
Il processore di messaggi invia il suo certificato al server di backend nel messaggio n. 9.
Il server di backend riconosce la ricezione del certificato del processore di messaggi nel messaggio n. 11.
Tuttavia, invia immediatamente un avviso irreversibile: certificato non valido al processore di messaggi (messaggio n. 12). Ciò indica che il certificato inviato dal processore di messaggi non è valido e pertanto la verifica del certificato non è riuscita sul server di backend. Di conseguenza, l'handshake SSL non è riuscito e la connessione verrà chiusa.
Ora esaminiamo il messaggio n. 9 per controllare i contenuti del certificato inviato dal processore di messaggi:
Come puoi notare, il server di backend non ha ricevuto alcun certificato dal client (Lunghezza certificato: 0). Di conseguenza, il server di backend invia l'avviso irreversibile: certificato non valido.
In genere, questo accade quando il client, ovvero il processore di messaggi (un processo basato su Java):
1. Non ha alcun certificato client nel suo archivio chiavi oppure
2. Non è in grado di inviare un certificato client. Questo può accadere se non riesce a trovare un certificato rilasciato da una delle autorità di certificazione accettabili del server di backend. Ciò significa che, se l'autorità di certificazione del certificato foglia del client (ovvero il primo certificato nella catena) non corrisponde a nessuna delle autorità di certificazione accettabili del server di backend, il processore di messaggi non invierà il certificato.

Esaminiamo separatamente ciascuna di queste cause come segue.

Causa: nessun certificato client

Diagnosi

Se non è presente alcun certificato nell'archivio chiavi specificato nella sezione Informazioni SSL dell'endpoint target o del server target utilizzato nell'endpoint target, questa è la causa dell'errore.

Segui i passaggi riportati di seguito per determinare se questa è la causa:

Determina l'archivio chiavi utilizzato nell'endpoint target o nel server target per il proxy API specifico seguendo questi passaggi:
1. Ottieni il nome di riferimento dell'archivio chiavi dall'elemento Keystore nella sezione SSLInfo nell'endpoint target o nel server target.
  Esaminiamo una sezione SSLInfo di esempio in una configurazione dell'endpoint target:
```
<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>true</ClientAuthEnabled>
  <KeyStore>ref://myKeystoreRef</KeyStore>
  <KeyAlias>myKey</KeyAlias>
  <TrustStore>ref://myTrustStoreRef</TrustStore>
</SSLInfo>
```
2. Nell'esempio precedente, il nome di riferimento dell'archivio chiavi è "myKeystoreRef".
3. Vai all'interfaccia utente di Edge e seleziona Proxy API -> Configurazioni ambiente.
  Seleziona la scheda Riferimenti e cerca il nome di riferimento dell'archivio chiavi. Prendi nota del nome nella colonna Riferimento per il riferimento dell'archivio chiavi specifico. Questo sarà il nome dell'archivio chiavi.
4. Nell'esempio precedente, puoi notare che myKeystoreRef ha il riferimento a "myKeystore". Pertanto, il nome dell'archivio chiavi è myKeystore.
Verifica se questo archivio chiavi contiene il certificato utilizzando l'interfaccia utente di Edge o la List certs for keystore API.
Se l'archivio chiavi contiene certificati, passa a Causa: mancata corrispondenza dell'autorità di certificazione.
Se l'archivio chiavi non contiene alcun certificato, questo è il motivo per cui il certificato client non viene inviato dal processore di messaggi.

Risoluzione

Assicurati che la catena di certificati client corretta e completa sia caricata nell'archivio chiavi specifico nel processore di messaggi.

Causa: mancata corrispondenza dell'autorità di certificazione

In genere, quando il server richiede al client di inviare il suo certificato, lo indica l'insieme di emittenti o autorità di certificazione accettati. Se l'emittente/l'autorità di certificazione del certificato foglia (ovvero il primo certificato nella catena di certificati) nell'archivio chiavi del processore di messaggi non corrisponde a nessuna delle autorità di certificazione accettate dal server di backend, il processore di messaggi (che è un processo basato su Java) non invierà il certificato al server di backend.

Segui questi passaggi per verificare se è questo il caso:

API List certs for keystore.
Ottieni i dettagli di ogni certificato ottenuto nel passaggio 1 utilizzando l' API Get cert for keystore.

Prendi nota dell'emittente del certificato foglia (ovvero il primo certificato nella catena di certificati) memorizzato nell'archivio chiavi.

Certificato foglia di esempio

{
  "certInfo" : [ {
    "basicConstraints" : "CA:FALSE",
    "expiryDate" : 1578889324000,
    "isValid" : "Yes",
    "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com",
    "publicKey" : "RSA Public Key, 2048 bits",
    "serialNumber" : "65:00:00:00:d2:3e:12:d8:56:fa:e2:a9:69:00:06:00:00:00:d2",
    "sigAlgName" : "SHA256withRSA",
    "subject" : "CN=nonprod-api.mycompany.com, OU=ITS, O=MyCompany, L=MELBOURNE, ST=VIC, C=AU",
    "subjectAlternativeNames" : [ ],
    "validFrom" : 1484281324000,
    "version" : 3
  } ],
  "certName" : "nonprod-api.mycompany.com.key.pem-cert"
}

Nell'esempio precedente, l'emittente/l'autorità di certificazione è "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com"

Determina l'elenco di emittenti o autorità di certificazione accettati dal server di backend utilizzando una delle seguenti tecniche:
Tecnica n. 1: utilizza il seguente comando openssl:
```
openssl s_client -host <backend server host name> -port <Backend port#> -cert <Client Certificate> -key <Client Private Key>
```
Fai riferimento alla sezione intitolata "Acceptable Client Certificate CA names" nell'output di questo comando, come mostrato di seguito:
```
Acceptable client certificate CA names
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
```
Tecnica n. 2: controlla il pacchetto Certificate Request nei pacchetti TCP/IP, in cui il server di backend richiede al client di inviare il suo certificato:

Nei pacchetti TCP/IP di esempio mostrati sopra, Certificate Request pacchetto è il messaggio n. 7. Fai riferimento alla sezione "Nomi distinti", che contiene le autorità di certificazione accettabili del server di backend.

Nota: l'elenco delle "autorità di certificazione accettabili" del server di backend viene compilato aggiungendo gli emittenti di tutti i certificati memorizzati nell'archivio attendibilità del server di backend.
Verifica se l'autorità di certificazione ottenuta nel passaggio 3 corrisponde all'elenco di emittenti o autorità di certificazione accettati dal server di backend ottenuti nel passaggio 4. In caso di mancata corrispondenza, il processore di messaggi non invierà il certificato client al server di backend.

Nell'esempio precedente, puoi notare che l'emittente del certificato foglia del client nell'archivio chiavi del processore di messaggi non corrisponde a nessuna delle autorità di certificazione accettate del server di backend. Di conseguenza, il processore di messaggi non invia il certificato client al server di backend. In questo modo, l'handshake SSL non riesce e il server di backend invia il messaggio "Fatal alert: bad_certificate".

Risoluzione

Assicurati che il certificato con l'emittente/l'autorità di certificazione che corrisponde l'emittente/l'autorità di certificazione del certificato foglia del client (il primo certificato nella catena) sia memorizzato nell'archivio attendibilità del server di backend.
Nell'esempio descritto in questa guida, il certificato con l'emittente "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com" è stato aggiunto all'archivio attendibilità del server di backend per risolvere il problema.

Se il problema persiste, vai a Raccogliere le informazioni di diagnostica necessarie.

Raccogliere le informazioni di diagnostica necessarie

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni di diagnostica. Contatta l'assistenza Apigee Edge e condividile a :

Se sei un utente di Public Cloud, fornisci le seguenti informazioni:
1. Nome dell'organizzazione
2. Nome ambiente
3. Nome del proxy API
4. Comando curl completo per riprodurre l'errore
5. File di traccia che mostra l'errore
6. Pacchetti TCP/IP acquisiti sul server di backend
Se sei un utente di Private Cloud, fornisci le seguenti informazioni:
1. Messaggio di errore completo osservato
2. Bundle del proxy API
3. File di traccia che mostra l'errore
4. Log del processore di messaggi /opt/apigee/var/log/edge-message-processor/logs/system.log
5. Pacchetti TCP/IP acquisiti sul server di backend o sul processore di messaggi.
6. Output dell'API Get cert for keystore.
Dettagli sulle sezioni di questa guida che hai provato e su eventuali altre informazioni che ci aiuteranno ad accelerare la risoluzione del problema.