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

400 Richiesta non valida - Errore certificato SSL

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

Sintomo

L'applicazione client riceve una risposta HTTP 400 - Richiesta non valida con il messaggio "The SSL certificate error". Questo errore viene in genere inviato dal router Edge in una configurazione TLS bidirezionale 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 pagina di errore HTML riportata di seguito:

<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

Di seguito sono riportate le possibili cause di questo problema:

Causa	Descrizione	Istruzioni per la risoluzione dei problemi applicabili a
Certificato client scaduto	Il certificato inviato dal client è scaduto.	Utenti di Edge Private Cloud e Public Cloud
Certificato errato inviato dal client	Questo errore viene generato se il certificato inviato dall'applicazione client non corrisponde al certificato memorizzato nell'archivio attendibilità del router di Edge.	Utenti di Edge Private Cloud e Public Cloud
Certificato radice del client mancante nell'archivio attendibilità	Questo errore viene generato se il certificato radice firmato dalla CA del client non è presente nell' archivio attendibilità del router di Edge.	Utenti di Edge Private Cloud e Public Cloud
Certificati client non caricati nel router Edge	Questo errore viene generato se i certificati client caricati nell'archivio attendibilità non vengono caricati sul router.	Utenti di Edge Private Cloud

Causa: certificato client scaduto

Questo problema si verifica in genere per un TLS bidirezionale, quando il certificato inviato dal client è scaduto. In un TLS bidirezionale, sia il client sia il server scambiano i rispettivi certificati pubblici per completare l'handshake. Il client convalida il certificato del server e il server convalida il certificato del client.

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

Durante l'handshake TLS, se viene rilevato che il certificato del client è scaduto, il server invierà 400 - Richiesta non valida con il messaggio "The SSL certificate error".

Diagnosi

Accedi all'interfaccia utente di Edge e visualizza la configurazione dell'host virtuale specifico (Amministrazione > Host virtuali) per il quale viene effettuata la richiesta API oppure utilizza l'API di gestione Get virtual host API 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 all'archivio attendibilità utilizzato nell'host virtuale. Nell'esempio precedente, il nome del riferimento all'archivio attendibilità è myTruststoreRef.
Determina l'archivio attendibilità a cui fa riferimento il riferimento all'archivio attendibilità.
1. Nell'interfaccia utente di Edge, vai ad Amministrazione > Ambienti > Riferimenti e cerca il nome del riferimento all'archivio attendibilità.
2. Prendi nota del nome nella colonna Riferimento per il riferimento all'archivio attendibilità specifico. Questo sarà il nome dell'archivio attendibilità.
  
  Figura 1
  
  Nell'esempio precedente, nota che myTruststoreRef ha il riferimento a myTruststore. Pertanto, il nome dell'archivio attendibilità è myTruststore.
In Amministrazione > Ambienti > Archivi chiavi TLS nell'interfaccia utente di Edge, vai ad Archivi chiavi TLS e cerca l'archivio attendibilità trovato nel passaggio 3.
Seleziona il certificato nell'archivio attendibilità specifico (determinato nel passaggio 3 sopra) come mostrato di seguito:

Figura 2

Il certificato con alias client-cert-markw nell'esempio precedente mostra che è scaduto.
Controlla se il certificato è scaduto per l'alias del certificato del tuo archivio attendibilità.
Se il certificato non è scaduto, passa a passaggi di diagnostica 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 all'archivio attendibilità utilizzato nell'host virtuale specifico in modo che punti al nuovo archivio attendibilità seguendo i passaggi indicati in Modificare un riferimento.

Nell'esempio descritto sopra, fai in modo che il riferimento myTruststoreRef punti a myNewTruststore.

Passaggi di diagnostica comuni per le altre cause

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

Di seguito è riportata l'analisi dei dati di esempio dei pacchetti TCP/IP utilizzando lo strumento Wireshark:

Il pacchetto n. 30 nel tcpdump (immagine sotto) mostra che l'applicazione client (origine) ha inviato un "Client Hello" messaggio al router (destinazione).
Il pacchetto n. 34 mostra che il router riconosce il messaggio Client Hello dall'applicazione client.
Il router invia il messaggio "Server Hello" nel pacchetto n. 35, quindi invia il suo certificato e anche richiede all'applicazione client di inviare il suo certificato nel pacchetto n. 38.
Nel pacchetto n. 38, in cui il router invia il pacchetto "Certificate Request", controlla la sezione "Distinguished Names" (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 suo certificato nel pacchetto n. 41. Controlla la sezione Certificate Verify (Verifica certificato) nel pacchetto n. 41 e determina il certificato inviato dall'applicazione client.

Figura 4
Verifica se il soggetto e l'emittente del certificato e della relativa catena inviati dall'applicazione client (pacchetto n. 41) corrispondono al certificato accettato e della relativa catena del router (pacchetto n. 38). Se c'è una mancata corrispondenza, questa è la causa dell'errore. Di conseguenza, il router (server) invia l'avviso criptato (pacchetto n. 57) seguito da FIN, ACK (pacchetto n. 58) all' applicazione client e alla fine la connessione viene terminata.
La mancata corrispondenza del certificato e della relativa catena può essere causata dagli scenari descritti in nelle sezioni seguenti.

Causa: certificato errato inviato dal client

In genere, questo accade se il soggetto/l'emittente del certificato e/o della relativa catena inviati dall' applicazione client non corrispondono al certificato e/o alla relativa catena memorizzati nell'archivio attendibilità del router (server).

Diagnosi

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 all'archivio attendibilità utilizzato nell'host virtuale.
Nell'esempio precedente, il nome del riferimento all'archivio attendibilità è myCompanyTruststoreRef.
Determina l'archivio attendibilità a cui fa riferimento il riferimento all'archivio attendibilità.
1. Nell'interfaccia utente di Edge, vai ad Amministrazione > Ambienti > Riferimenti e cerca il nome del riferimento all'archivio attendibilità.
2. Prendi nota del nome nella colonna Riferimento per il riferimento all'archivio attendibilità specifico. Questo sarà il nome dell'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 memorizzati nell'archivio attendibilità (determinato nel passaggio precedente) utilizzando le seguenti API:
1. API Elenca certificati per un archivio chiavi o un archivio attendibilità.
  
  Questa API elenca tutti i certificati nell'archivio attendibilità specifico.
2. API Recupera dettagli certificato da un archivio chiavi o un archivio attendibilità.
  
  Questa API restituisce informazioni su un certificato specifico nell'archivio attendibilità specifico.
Controlla se l'emittente e il soggetto di ogni certificato e della relativa catena memorizzati in myCompanyTruststore corrispondono a quelli del certificato e della relativa catena visualizzati nei pacchetti TCP/IP (vedi pacchetto n. 38) sopra. Se c'è una mancata corrispondenza, significa che i certificati caricati nell'archivio attendibilità non vengono caricati nel router Edge. Vai a Causa: i certificati client non vengono caricati nel router Edge.
Se non è stata rilevata alcuna mancata corrispondenza nel passaggio 5, significa che l'applicazione client non ha inviato il certificato corretto e la relativa catena.

Risoluzione

Assicurati che l'applicazione client invii a Edge il certificato corretto e la relativa catena.

Causa: certificato radice del client mancante nell'archivio attendibilità

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

Diagnosi

Accedi all'interfaccia utente di Edge e visualizza la configurazione dell'host virtuale specifico per il quale viene effettuata la richiesta API (Amministrazione > Host virtuali > virtual_host), oppure utilizza l' API Get virtual host 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 all'archivio attendibilità utilizzato nell'host virtuale. Nell'esempio precedente, il nome del riferimento all'archivio attendibilità è myCompanyTruststoreRef.
Determina l'archivio attendibilità effettivo utilizzato dal riferimento all'archivio attendibilità.
Nell'interfaccia utente di Edge, vai a Amministrazione > Ambienti > Riferimenti e cerca il nome del riferimento all'archivio attendibilità.
Il nome dell'archivio attendibilità per il riferimento all'archivio attendibilità specifico si trova nella Riferimento colonna.

Figura 6

In questo esempio, nota che myCompanyTruststoreRef ha myCompanyTruststore nella colonna Riferimento. Pertanto, il nome dell'archivio attendibilità è myCompanyTruststore.
Recupera i certificati memorizzati nell'archivio attendibilità (determinato nel passaggio precedente) utilizzando le seguenti API:
1. API Elenca certificati per un archivio chiavi o un archivio attendibilità. Questa API elenca tutti i certificati nell'archivio attendibilità.
2. API Recupera dettagli certificato da un archivio chiavi o un archivio attendibilità. Questa API restituisce informazioni su un certificato specifico nell'archivio attendibilità.
Controlla se il certificato include una catena completa, incluso 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 del client o il certificato foglia e intermedio. Se il certificato radice valido del client non è presente nell'archivio attendibilità, questa è la causa dell'errore.

Tuttavia, se la catena di certificati completa del client, incluso il certificato radice, esiste nell'archivio attendibilità, significa che i certificati caricati nell' archivio attendibilità potrebbero non essere caricati nel router Edge. In questo caso, vedi Causa: i certificati client non vengono caricati nel router Edge.

Risoluzione

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

Causa: i certificati client non vengono caricati nel router Edge

Se sei un utente di Public Cloud, contatta l'assistenza Apigee Edge.
Se sei un utente di Private Cloud, segui le istruzioni riportate di seguito su ogni router:
1. Controlla se il file /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem esiste per l'host virtuale specifico. Se il file non esiste, vai alla Risoluzione sezione di seguito.
2. Se il file esiste, utilizza il seguente comando openssl per ottenere i dettagli dei certificati disponibili sul router Edge:
```
openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
```
3. Controlla l'emittente, il soggetto e la data di scadenza del certificato. Se uno di questi non corrisponde a quanto osservato nell'archivio attendibilità nell'interfaccia utente di Edge o utilizzando le 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 i certificati più recenti vengano caricati seguendo il passaggio riportato di seguito:

apigee-service edge-router restart

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

Raccogliere informazioni di diagnostica

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

Se sei un utente di Public Cloud, fornisci le seguenti informazioni:
1. Nome dell'organizzazione
2. Nome ambiente
3. Nome proxy API
4. Nome host virtuale
5. Nome alias host
6. Comando curl completo per riprodurre l'errore
7. Pacchetti TCP/IP acquisiti nell'applicazione client
Se sei un utente di Private Cloud, fornisci le seguenti informazioni:
1. Nome dell'host virtuale e relativa definizione utilizzando l'API Get virtual host
2. Nome alias host
3. Messaggio di errore completo osservato
4. Pacchetti TCP/IP acquisiti nell'applicazione client o nel router.
5. Output dell'API Elenca i certificati dall'API dell'archivio chiavi e anche i dettagli di ogni certificato ottenuto utilizzando l'API Recupera dettagli certificato.
Dettagli sulle sezioni di questa guida che hai provato e su eventuali altre informazioni che ci aiuteranno ad accelerare la risoluzione del problema.