Questa pagina è stata tradotta dall'API Cloud Translation.

400 Richiesta non valida - Errore certificato SSL

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Sintomo

L'applicazione client riceve una risposta HTTP 400 - Richiesta errata con il messaggio "Errore del certificato SSL". Questo errore viene generalmente inviato dal router perimetrale 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

Seguita 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 sono le seguenti:

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

Causa: certificato client scaduto

In genere questo problema si verifica per una connessione TLS bidirezionale, quando il certificato inviato dal client è scaduto. In un TLS a due vie, scambio di client e server i propri certificati pubblici per eseguire l'handshake. Il client convalida il certificato del server e il server convalida il certificato client.

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

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

Diagnosi

Accedi alla UI Edge e visualizza la configurazione specifica dell'host virtuale (Amministrazione > Host virtuali) per cui è in corso la richiesta API. o utilizza l'API Virtual Host di Google Cloud 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 del Truststore è myTruststoreRef.
Determina l'archivio di attendibilità a cui punta il riferimento di archivio attendibilità.
1. Nella UI di Edge, vai su Amministratore > Ambienti > Riferimenti e cerca il nome di riferimento dell'archivio attendibilità.
2. Prendi nota del nome nella colonna Riferimento per il riferimento specifico dell'archivio attendibilità. 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 nella UI Edge, accedi a TLS archivi chiavi e cerca l'archivio di attendibilità indicato nel passaggio 3.
Seleziona il certificato nell'archivio di attendibilità specifico (determinato nel passaggio 3 sopra) come mostrato di seguito:

Figura 2

Il certificato con l'alias client-cert-markw nell'esempio riportato sopra, mostra che si tratta scaduto.
Controlla se il certificato è scaduto per l'alias del certificato del tuo archivio attendibilità.
Se il certificato non è scaduto, vai alla sezione Passaggi diagnostici comuni per le altre cause.

Risoluzione

Acquista un nuovo certificato e caricalo:

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

Nell'esempio sopra descritto, fai riferimento a myTruststoreRef a myNewTruststore.

Passaggi diagnostici comuni per altre cause

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

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

Il pacchetto 30 in tcpdump (immagine sotto) mostra che l'applicazione client (origine) ha inviato un "Client Hello" al router (destinazione).
Il pacchetto 34 mostra che il router conferma il messaggio Client Hello dall'applicazione client.
Il router invia il messaggio "Server Hello" nel pacchetto #35 e poi invia il relativo certificato e anche richiede all'applicazione client di inviare il proprio certificato nel pacchetto #38.
Nel pacchetto #38, in cui il router invia il pacchetto "Certificate Request", controlla la "Nomi distinti" che fornisce dettagli sul certificato client, sulla sua catena e le autorità di certificazione accettate dal router (server).

L'applicazione client invia il certificato nel pacchetto n. 41. Seleziona il certificato Verifica la sezione nel pacchetto 41 e determina il certificato inviato dall'applicazione client.

Figura 4
Verifica se il soggetto, l'emittente del certificato e la relativa catena sono stati inviati dal client (pacchetto 41) corrisponde al certificato accettato e alla relativa catena dal router (pacchetto 38). L'errore è causato da un'errata corrispondenza. Da qui il router (server) invia l’avviso criptato (pacchetto n. 57) seguito da FIN, ACK (pacchetto 58) al dell'applicazione client e alla fine la connessione viene terminata.
La mancata corrispondenza tra il certificato e la relativa catena può essere causata dagli scenari descritti in le sezioni seguenti.

Causa: inviato dal client un certificato errato

Ciò si verifica in genere se il soggetto/l'emittente del certificato e/o della sua catena inviati l'applicazione client non corrisponde al certificato e/o alla relativa catena archiviata nel truststore del router (server).

Diagnosi

Accedi alla UI di Edge e visualizza la configurazione specifica dell'host virtuale (Amministrazione > Host virtuali) per cui è in corso la richiesta API. o utilizza l'API Get virtual host di Google Cloud 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 di attendibilità su cui si basa il riferimento di archivio attendibilità.
1. Nella UI di Edge, vai su Amministratore > Riferimenti ambientali e cerca il nome di riferimento dell'archivio attendibilità.
2. Prendi nota del nome nella colonna Riferimento per il riferimento specifico dell'archivio attendibilità. Sarà il nome dell'archivio attendibilità.
  
  Figura 5
  
  Nell'esempio precedente, nota che myCompanyTruststoreRef ha la proprietà riferimento a myCompanyTruststore. Pertanto, il nome dell'archivio attendibilità è myCompanyTruststore.
Ottieni i certificati archiviati nell'archivio attendibilità (determinati nel passaggio precedente) utilizzando le seguenti API:
1. Elenco dei certificati per un archivio chiavi o un'API truststore.
  
  Questa API elenca tutti i certificati in un archivio attendibilità specifico.
2. Recupera i dettagli del certificato da un archivio chiavi o un'API Truststore.
  
  Questa API restituisce informazioni su un certificato specifico in un archivio attendibilità specifico.
Controlla se l'emittente e il soggetto di ciascun certificato e la relativa catena sono archiviati in myCompanyTruststore e quella del certificato e della relativa catena descritti nei pacchetti TCP/IP (fare riferimento al pacchetto #38) sopra. Un'eventuale mancata corrispondenza indica che i certificati caricati nell'archivio attendibili non vengano caricati nel router Edge. Passa a Causa: i certificati client non sono stati caricati nel router Edge.
Se non è stata rilevata alcuna corrispondenza errata nel passaggio 5, significa che l'applicazione client ha eseguito non inviare 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 in Truststore

Questo errore viene visualizzato se il certificato radice firmato CA del client non è presente nella il truststore del router Edge.

Diagnosi

Accedi alla UI Edge e visualizza la configurazione host virtuale specifica per la quale (Amministratore > Host virtuali > virtual_host), o utilizza Recupera l'API 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 dell'archivio attendibilità utilizzato nell'host virtuale. Nell'esempio precedente, il nome di riferimento del truststore è myCompanyTruststoreRef.
Determinare l'archivio di attendibilità effettivo utilizzato dal riferimento di archivio attendibilità.
Nella UI di Edge, vai su Amministratore > Ambienti > Riferimenti e ricerca per il nome di riferimento del truststore.
Il nome dell'archivio attendibilità per il riferimento specifico dell'archivio di attendibilità è in Colonna Riferimento.

Figura 6

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

Tuttavia, se la catena di certificati completa del client, incluso il certificato radice, esiste in un archivio attendibilità, significa che i certificati caricati nell'archivio L'archivio attendibili potrebbe non essere stato caricato nel router Edge. In questo caso, consulta Causa: i certificati client non sono stati caricati nel router Edge.

Risoluzione

Assicurati che sia disponibile il certificato corretto del client, incluso il certificato radice nel truststore del router Apigee Edge.

Causa: i certificati client non sono stati caricati nel router perimetrale

Se sei un utente Cloud pubblico, contatta l'assistenza Apigee Edge.
Se sei un utente Private Cloud, segui le istruzioni seguenti 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 al file Risoluzione di seguito.
2. Se il file esiste, usa il comando openssl riportato di seguito per ottenere i dettagli della 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 uno di questi non corrisponde con quanto osservato in Truststore nella UI Edge o tramite le API di gestione, la causa dell'errore.
4. È possibile che il router non abbia ricaricato i certificati caricati.

Risoluzione

Riavvia il router per assicurarti che siano caricati i certificati più recenti svolgendo il seguente passaggio:

apigee-service edge-router restart

Esegui di nuovo le API e controlla i risultati. Se il problema persiste, vai a Raccogli 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 che raccogli con l'assistenza Apigee Edge:

Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:
1. Nome dell'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 sull'applicazione client
Se sei un utente del cloud privato, fornisci le seguenti informazioni:
1. Virtual Host Name e relativa definizione mediante l'utilizzo dell'API Virtual Host
2. Nome alias host
3. Messaggio di errore completo osservato
4. Pacchetti TCP/IP acquisiti sull'applicazione client o sul router.
5. Output di Elenca i certificati dall'API dell'archivio chiavi e i dettagli di ogni certificato ottenuto utilizzando l'API Get cert details.
Dettagli sulle sezioni di questo Playbook che hai provato ed eventuali altri approfondimenti che ci aiutano a risolvere questo problema rapidamente.