502 Bad Gateway - Certificato autofirmato nella catena

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

Sintomo

L'applicazione client riceve un codice di risposta HTTP 502 con il messaggio Bad Gateway come risposta alle chiamate API in Edge Microgateway.

In alternativa, l'amministratore riceverà un errore self signed certificate in certificate chain quando esegue il edgemicro configure comando.

Messaggio di errore

Il client visualizzerà il seguente messaggio di risposta:

HTTP/1.1 502 Bad Gateway

Di seguito sono riportati due esempi comuni di risposte di errore:

{"message":"self signed certificate in certificate chain","code":"SELF_SIGNED_CERT_IN_CHAIN"}

{"message":"self signed certificate","code":"DEPTH_ZERO_SELF_SIGNED_CERT"}

In alternativa, questo errore può verificarsi durante l'esecuzione di edgemicro configure:

{ Error: self signed certificate in certificate chain
at TLSSocket.onConnectSecure (_tls_wrap.js:1051:34)
at TLSSocket.emit (events.js:189:13)
at TLSSocket._finishInit (_tls_wrap.js:633:8) code: 'SELF_SIGNED_CERT_IN_CHAIN' }

Possibili cause

Causa: il server di destinazione presenta un certificato autofirmato

Se il server di destinazione presenta un certificato autofirmato nella connessione in uscita, Edge Microgateway genererà questo errore per impostazione predefinita perché non considera attendibili i certificati autofirmati.

Diagnosi

Potresti visualizzare il seguente errore nei log (/var/tmp/edgemicro-`hostname`- *.log):

2021-05-18T10:52:46.425Z [error][0:8000][1][gsc][test][edgemicro_badtargethost][][][2db53f80-
b7c7-11eb-9abe-05b6297863f1][microgateway-core][][GET][502][self signed certificate in certificate
chain][SELF_SIGNED_CERT_IN_CHAIN][]

Il codice di errore SELF_SIGNED_CERT_IN_CHAIN indica che Edge Microgateway ha ricevuto molto probabilmente un certificato autofirmato dal server di destinazione. Per confermare, segui questi passaggi:

1. Esegui il seguente openssl comando per verificare la catena di certificati del server di destinazione:

   echo | openssl s_client -connect TARGET_SERVER_HOSTNAME:PORT -servername TARGET_SERVER_HOSTNAME | openssl x509 -noout
   

2. Se la catena di certificati del server di destinazione è effettivamente autofirmata, questa è la causa di problema.

   Nell'esempio seguente, tieni presente che il server di destinazione presenta un certificato autofirmato:

   echo | openssl s_client -connect untrusted-root.badssl.com:443 -servername untrusted-root.badssl.com | openssl x509 -noout
   

   depth=1 C = US, ST = California, L = San Francisco, O = BadSSL, CN = BadSSL Untrusted Root Certificate Authority
   verify error:num=19:self signed certificate in certificate chain
   verify return:0
   DONE

Risoluzione

1. Collabora con il team proprietario del server di destinazione per procurarti un certificato TLS appropriato firmato da un autorità di certificazione (CA) attendibile.

2. Se non è possibile, valuta una delle seguenti opzioni per consentire i certificati autofirmati in Edge Microgateway.

   Opzione 1: imposta una proprietà di sistema per consentire a Edge Microgateway di considerare attendibili tutti i certificati

   1. Se utilizzi Docker, consulta Utilizzo di una CA non considerata attendibile da Node.js

   2. In caso contrario, esporta una variabile di ambiente denominata NODE_EXTRA_CA_CERTS, che punta al file della CA radice.

      Questa procedura è documentata sul sito web ufficiale di Node.js.

   Opzione 2: configura il file di configurazione YAML di Edge Microgateway in modo che consideri attendibile il certificato specifico per il server di destinazione

   1. Assicurati di avere il certificato (o la catena) del server di destinazione in formato PEM. Per convertire altri formati di certificato in PEM, segui le istruzioni riportate in Conversione dei certificati in formato supportato.

   2. Se esiste una catena di certificati, assicurati che i certificati siano nell'ordine corretto Il certificato foglia deve essere sempre il primo, seguito dal certificato intermedio e poi dal certificato radice. Per ulteriori spiegazioni, consulta Convalida della catena di certificati.

      Nell'esempio seguente, abbiamo configurato il file della CA attendibile per untrusted-root.badssl.com.

      edgemicro:
      ...
      targets:
        - host: 'untrusted-root.badssl.com'
          ssl:
            client
              ca: /opt/apigee/certs/untrusted-root.pem

   Le istruzioni per la configurazione sono riportate anche nel video Modulo Edge Microgateway - Configura TLS in uscita unidirezionale e bidirezionale. Per ulteriori informazioni, consulta Configurazione di SSL sul server Edge Microgateway.

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

Causa: il server di gestione di Apigee Edge utilizza un certificato autofirmato

Quando configuri Edge Microgateway per la prima volta, uno dei comandi che dovrai eseguire è edgemicro configure o edgemicro private configure. Questo comando eseguirà il bootstrapping del cluster e contatterà Apigee Edge per scaricare le informazioni richieste.

Per Edge Private Cloud, l'URL del server di gestione è determinato dall'argomento -m. Se hai abilitato TLS per il server di gestione, Edge Microgateway tenterà di verificare il certificato presentato dal server di gestione.

Di seguito è riportato un esempio di comando edgemicro configure per Edge Private Cloud:

edgemicro private configure -u <username> -p <password> -o apigee -e dev -v secure -r https://apigee-dev.net -m https://management.apigee-dev.net:8443

Se il server di gestione è configurato con un certificato autofirmato, nell'output della console verrà visualizzato il seguente errore.

{ Error: self signed certificate in certificate chain
at TLSSocket.onConnectSecure (_tls_wrap.js:1051:34)
at TLSSocket.emit (events.js:189:13)
at TLSSocket._finishInit (_tls_wrap.js:633:8) code: 'SELF_SIGNED_CERT_IN_CHAIN' }

Diagnosi

1. In questo caso, il server di gestione (management.apigee-dev.net) potrebbe restituire un certificato TLS autofirmato.
2. È probabile che l'amministratore di sistema di Apigee Edge abbia fornito il certificato e ne abbia una copia.
3. In caso contrario, esegui il seguente comando per ottenere informazioni sul certificato:

   echo | openssl s_client -connect management.apigee-dev.net:8443 -servername management.apigee-dev.net | openssl x509 -noout
   

4. Se il server di gestione ha un certificato autofirmato, questa è la causa del problema.

Risoluzione

1. Collabora con il team proprietario del server di destinazione per procurarti un certificato TLS appropriato firmato da un autorità di certificazione (CA) attendibile.

2. Se non è possibile, segui questi passaggi per consentire i certificati autofirmati in Edge Microgateway.

3. Imposta una proprietà di sistema per consentire a Edge Microgateway di considerare attendibili tutti i certificati.
4. Se utilizzi Docker, consulta Utilizzo di una CA non considerata attendibile da Node.js.
5. In caso contrario, esporta una variabile di ambiente denominata NODE_EXTRA_CA_CERTS, che punta al file della CA radice.Questa procedura è documentata sul sito web ufficiale di Node.js.

Raccogliere le informazioni di diagnostica

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

• File di log: la cartella predefinita è /var/tmp, ma può essere sostituita nel file config.yaml principale (logging > dir parameter). Ti consigliamo di modificare log > level in info prima di fornire i file di log all'assistenza Apigee Edge.
• File di configurazione: la configurazione principale di Edge Microgateway si trova nel file YAML nella cartella predefinita di Edge Microgateway, $HOME/.edgemicro. Esiste un file di configurazione predefinito denominato default.yaml e uno per ogni ambiente ORG-ENV-config.yaml. Carica questo file per intero per l'organizzazione e l'ambiente interessati.

  Documenti di riferimento

  Configurare l'interfaccia utente Edge per utilizzare TLS per accedere all'API Edge