Questa pagina è stata tradotta dall'API Cloud Translation.

400 Richiesta non valida - Errore certificato SSL

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

Sintomo

L'applicazione client riceve una risposta HTTP 400 - Richiesta non valida con il messaggio "Errore del certificato SSL". Questo errore in genere viene inviato dal router Edge in una configurazione TLS a due vie abilitata per la connessione in entrata ad Apigee Edge.

Messaggio di errore

L'applicazione client riceve il seguente codice di risposta:

HTTP/1.1 400 Bad Request

Seguito dalla seguente pagina di errore HTML:

<html>
  <head>
    <title>400 The SSL certificate error</title>
  </head>
  <body bgcolor="white">
    <center> <h1>400 Bad Request</h1>
    </center>
    <center>The SSL certificate error</center>
    <hr>
    <center>nginx</center>
  </body>
</html>

Possibili cause

Le possibili cause di questo problema sono le seguenti:

Causa	Descrizione	Istruzioni per la risoluzione dei problemi applicabili a
Certificato client scaduto	Il certificato inviato dal client è scaduto.	Utenti di cloud privato e pubblico Edge
Certificato non corretto inviato dal client	Questo errore viene visualizzato se il certificato inviato dall'applicazione client non corrisponde al certificato archiviato nell'archivio attendibilità del router di Edge.	Utenti di cloud privato e pubblico Edge
Certificato radice client mancante nell'archivio attendibilità	Questo errore viene visualizzato se il certificato radice firmato dalla CA del client non è presente nell'archivio attendibilità del router Edge.	Utenti di cloud privato e pubblico Edge
Certificati client non caricati nel router perimetrale	Questo errore viene visualizzato se i certificati client caricati nel truststore non vengono caricati sul router.	Utenti del cloud privato perimetrale

Causa: certificato client scaduto

In genere questo problema si verifica per una TLS bidirezionale, quando il certificato inviato dal client è scaduto. Con TLS a due vie, sia il client che il server scambiano i certificati pubblici per compiere l'handshake. Il client convalida il certificato del server, mentre il server lo convalida.

In Edge, il protocollo TLS a due vie viene implementato nell'host virtuale, dove il certificato del server viene aggiunto all'archivio chiavi e il certificato client agli archivi attendibilità.

Se durante l'handshake TLS viene rilevato che il certificato client è scaduto, il server invia il messaggio 400 - Richiesta non valida con il messaggio "Errore del certificato SSL".

Diagnostica

Accedi all'interfaccia utente Edge e visualizza la configurazione dell'host virtuale specifica (Amministratore > Host virtuali) per cui viene effettuata la richiesta API oppure utilizza l'API di gestione Ottieni API host virtuale per ottenere la definizione dell'host virtuale specifico.

In genere un host virtuale per la comunicazione TLS bidirezionale ha il seguente aspetto:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>api.myCompany.com</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <TrustStore>ref://myTruststoreRef</TrustStore>
    </SSLInfo>
</VirtualHost>

Determina il riferimento dell'archivio attendibilità utilizzato nell'host virtuale. Nell'esempio precedente, il nome di riferimento dell'archivio attendibilità è myTruststoreRef.
Determina l'archivio attendibilità a cui punta il riferimento Truststore.
1. Nella UI di Edge, vai ad Amministrazione > Ambienti > Riferimenti e cerca il nome di riferimento dell'archivio attendibilità.
2. Prendi nota del nome nella colonna Riferimento per il riferimento specifico all'archivio attendibilità. Questo sarà il nome del tuo archivio attendibilità.
  
  Figura 1
  
  Nell'esempio precedente, tieni presente che myTruststoreRef ha il riferimento a myTruststore. Di conseguenza, il nome dell'archivio attendibilità è myTruststore.
In Amministrazione > Ambienti > Archivi chiavi TLS nell'interfaccia utente di Edge, vai agli archivi chiavi TLS e cerca l'archivio attendibilità trovato nel passaggio 3.
Seleziona il certificato nell'archivio attendibilità specifico (determinato nel passaggio 3 sopra riportato) come mostrato di seguito:

Figura 2

Il certificato con l'alias client-cert-markw nell'esempio precedente indica che è scaduto.
Controlla se il certificato per l'alias di certificati del tuo archivio attendibilità è scaduto.
Se il certificato non è scaduto, vai ai passaggi di diagnosi comuni per le altre cause.

Risoluzione

Procurati un nuovo certificato e caricalo:

Crea un nuovo archivio attendibilità, ad esempio myNewTruststore.
Carica il nuovo certificato nell'archivio attendibilità appena creato.
Modifica il riferimento trustore utilizzato nell'host virtuale specifico in modo che punti al nuovo archivio attendibilità seguendo i passaggi descritti nella sezione Modifica di un riferimento.

Nell'esempio descritto sopra, punta il riferimento myTruststoreRef a myNewTruststore.

Passaggi di diagnosi comuni per le altre cause

Per esaminare questo problema, devi acquisire i pacchetti TCP/IP utilizzando lo strumento tcpdump.
1. Se sei un utente Private Cloud, puoi acquisire i pacchetti TCP/IP sull'applicazione client o sul router.
2. Se sei un utente del cloud pubblico, acquisisci i pacchetti TCP/IP nell'applicazione client.
3. Una volta che hai deciso dove acquisire i pacchetti TCP/IP, utilizza il seguente comando tcpdump per acquisire i pacchetti TCP/IP:
```
tcpdump -i any -s 0 host <IP address> -w <File name>
```
  Nota: se acquisisci i pacchetti TCP/IP sul router, utilizza l'indirizzo IP pubblico dell'applicazione client nel comando tcpdump.
  
  Se prendi i pacchetti TCP/IP nell'applicazione client, utilizza l'indirizzo IP pubblico del nome host utilizzato nell'host virtuale nel comando tcpdump.
  
  Fai riferimento a tcpdump per ulteriori informazioni su questo strumento e per altre varianti di questo comando.
Analizza i pacchetti TCP/IP raccolti utilizzando lo strumento Wireshark o uno strumento simile che conosci.

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

Il pacchetto n. 30 in tcpdump (immagine sotto) mostra che l'applicazione client (origine) ha inviato un messaggio "Client Hello" al router (destinazione).
Il pacchetto n. 34 mostra che il router riconosce il messaggio Client Hello dall'applicazione client.
Il router invia "Server Hello" nel pacchetto n. 35, quindi invia il certificato e richiede all'applicazione client di inviare il certificato nel pacchetto n. 38.
Nel pacchetto n. 38, in cui il router invia il pacchetto "Richiesta di certificato", controlla la sezione "Nomi distinti", che fornisce dettagli sul certificato client, sulla relativa catena e sulle autorità di certificazione accettate dal router (server).

L'applicazione client invia il certificato nel pacchetto n. 41. Controlla la sezione Certificate Verification (Verifica certificato) nel pacchetto n. 41 e determina il certificato inviato dall'applicazione client.

Figura 4
Verifica se il soggetto, l'emittente del certificato e la relativa catena inviata dall'applicazione client (pacchetto n. 41) corrispondono al certificato accettato e alla relativa catena del router (pacchetto n. 38). L'eventuale mancata corrispondenza è la causa dell'errore. Quindi il router (server) invia l'avviso criptato (pacchetto 57) seguito da FIN e ACK (pacchetto 58) all'applicazione client e alla fine la connessione viene interrotta.
La mancata corrispondenza tra il certificato e la relativa catena può essere causata dagli scenari descritti nelle sezioni seguenti.

Causa: certificato inviato dal client errato

In genere questo accade se l'oggetto/l'emittente del certificato e/o della catena inviata dall'applicazione client non corrisponde al certificato e/o alla catena archiviata nell'archivio attendibilità del router (server).

Diagnostica

Accedi all'interfaccia utente Edge e visualizza la configurazione dell'host virtuale specifica (Amministratore > Host virtuali) per cui viene effettuata la richiesta API oppure utilizza l'API di gestione Ottieni l'API host virtuale per ottenere la definizione dell'host virtuale specifico.

In genere un host virtuale per la comunicazione TLS bidirezionale ha il seguente aspetto:

    <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
                <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>

Determina il riferimento dell'archivio attendibilità utilizzato nell'host virtuale.
Nell'esempio precedente, il nome di riferimento dell'archivio attendibilità è myCompanyTruststoreRef.
Determina l'archivio attendibilità a cui punta il riferimento Truststore.
1. Nella UI di Edge, vai ad Amministrazione > Riferimenti degli ambienti e cerca il nome di riferimento dell'archivio attendibilità.
2. Prendi nota del nome nella colonna Riferimento per il riferimento specifico all'archivio attendibilità. Questo sarà il nome del tuo archivio attendibilità.
  
  Figura 5
  
  Nell'esempio precedente, nota che myCompanyTruststoreRef ha il riferimento a myCompanyTruststore. Pertanto, il nome dell'archivio attendibilità è myCompanyTruststore.
Recupera i certificati archiviati nel Truststore (determinati nel passaggio precedente) utilizzando le seguenti API:
1. Elenca i certificati per un'API keystore o truststore.
  
  Questa API elenca tutti i certificati nello specifico archivio di attendibilità.
2. Recupera i dettagli del certificato da un archivio chiavi o da un'API Truststore.
  
  Questa API restituisce informazioni su un certificato specifico nell'archivio attendibilità specifico.
Verifica se l'emittente e il soggetto di ciascuno dei certificati e della relativa catena archiviata in myCompanyTruststore corrispondono a quelli del certificato e della relativa catena, come indicato nei pacchetti TCP/IP (fai riferimento al pacchetto n. 38) qui sopra. Se viene rilevata una mancata corrispondenza, significa che i certificati caricati nell'archivio attendibilità non vengono caricati nel router perimetrale. Passa a Causa: certificati client non caricati nel router perimetrale.
Se nel passaggio 5 non è stata rilevata alcuna mancata corrispondenza, significa che l'applicazione client non ha inviato il certificato corretto e la relativa catena.

Risoluzione

Assicurati che il certificato corretto e la relativa catena vengano inviati dall'applicazione client a Edge.

Causa: certificato radice client mancante nell'archivio attendibilità

Questo errore viene visualizzato se il certificato radice firmato dalla CA del client non è presente nell'archivio attendibilità del router Edge.

Diagnostica

Accedi all'interfaccia utente Edge e visualizza la configurazione dell'host virtuale specifica per cui viene effettuata la richiesta API (Amministratore > Host virtuali > virtual_host) oppure utilizza Ottieni l'API host virtuale per ottenere la definizione dell'host virtuale specifico.

In genere un host virtuale per la comunicazione TLS bidirezionale ha il seguente aspetto:

    <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
            <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>

Determina il riferimento dell'archivio attendibilità utilizzato nell'host virtuale. Nell'esempio precedente, il nome di riferimento dell'archivio attendibilità è myCompanyTruststoreRef.
Determina l'archivio attendibilità effettivo utilizzato dal riferimento per l'archivio attendibilità.
Nella UI di Edge, vai ad Amministrazione > Ambienti > Riferimenti e cerca il nome di riferimento dell'archivio attendibilità.
Il nome dell'archivio attendibilità per il riferimento specifico all'archivio attendibilità si trova nella colonna Riferimento.

Figura 6

In questo esempio, nota che myCompanyTruststoreRef ha myCompanyTruststore, nella colonna Riferimento. Pertanto, il nome dell'archivio attendibilità è myCompanyTruststore.
Recupera i certificati archiviati nell'archivio attendibilità (determinato nel passaggio precedente) utilizzando le seguenti API:
1. Elenca i certificati per un'API keystore o truststore. Questa API elenca tutti i certificati nell'archivio attendibilità.
2. Ottieni i dettagli del certificato da un archivio chiavi o da un'API Truststore. Questa API restituisce informazioni su un certificato specifico nell'archivio attendibilità.
Verifica se il certificato include una catena completa, compreso il certificato radice inviato dal client specifico, come mostrato nei pacchetti TCP/IP (vedi Figura 4). L'archivio attendibilità deve includere il certificato radice, nonché il certificato foglia o quello secondario e intermedio del client. Se nell'archivio attendibilità manca un certificato radice valido del client, questa è la causa dell'errore.

Tuttavia, se nell'archivio attendibilità esiste la catena di certificati completa del client, incluso il certificato radice, è possibile che i certificati caricati nell'archivio attendibilità non siano stati caricati nel router perimetrale. In questo caso, vedi Causa: certificati client non caricati nel router Edge.

Risoluzione

Assicurati che nell'archivio attendibilità del router Apigee Edge sia disponibile il certificato del client corretto, incluso il certificato radice.

Causa: certificati client non caricati nel router Edge

Se sei un utente del cloud pubblico, contatta l'assistenza Apigee Edge.
Se sei un utente Private Cloud, segui le istruzioni riportate di seguito su ciascun router:
1. Verifica se il file /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem esiste per l'host virtuale specifico. Se il file non esiste, passa alla sezione Risoluzione di seguito.
2. Se il file esiste, utilizza il comando openssl seguente per ottenere i dettagli dei certificati disponibili sul router perimetrale:
```
openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
```
3. Controlla l'emittente, l'oggetto e la data di scadenza del certificato. Se una di queste non corrisponde a quanto osservato nell'archivio attendibilità nella UI Edge o nell'utilizzo delle API di gestione, è questa la causa dell'errore.
4. È possibile che il router non abbia ricaricato i certificati caricati.

Risoluzione

Riavvia il router per assicurarti che vengano caricati i certificati più recenti utilizzando il passaggio seguente:

apigee-service edge-router restart

Esegui di nuovo le API e controlla i risultati. Se il problema persiste, vai a Raccogliere informazioni diagnostiche.

Raccogliere informazioni diagnostiche

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche. Contatta e condividi le informazioni raccolte con l'assistenza Apigee Edge:

Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:
1. Nome organizzazione
2. Nome ambiente
3. Nome proxy API
4. Nome host virtuale
5. Nome alias host
6. Completa il comando curl per riprodurre l'errore
7. Pacchetti TCP/IP acquisiti nell'applicazione client
Se sei un utente del cloud privato, fornisci le seguenti informazioni:
1. Nome host virtuale e relativa definizione utilizzando Ottieni API host virtuale
2. Nome alias host
3. Rilevato messaggio di errore completo
4. Pacchetti TCP/IP acquisiti sull'applicazione client o sul router.
5. Output dell'API Elenca i certificati dall'API Keystore e i dettagli di ogni certificato ottenuto utilizzando l'API Ottieni dettagli certificato.
Dettagli sulle sezioni di questo playbook che hai provato e su eventuali altri insight che ci aiuteranno a risolvere il problema in tempi rapidi.