502 Bad Gateway - Certificato autofirmato nella catena

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

Sintomo

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

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

Messaggio di errore

Il client vedrà il seguente messaggio di risposta:

HTTP/1.1 502 Bad Gateway

Due esempi comuni di risposte di errore sono:

{"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 certificato autofirmato viene presentato dal server di destinazione . verso sud, Edge Microgateway genererà, per impostazione predefinita, questo errore non considera attendibili i certificati autofirmati.

Diagnosi

Potresti osservare 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 il gateway Edge Microgateway ha molto probabilmente ha ricevuto un certificato autofirmato dal server di destinazione. Per verificarlo, esegui segui questi passaggi:

1. Esegui questo comando openssl per verificare la sicurezza del server catena di certificati:

   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, questo è il motivo risolvere il problema.

   Nell'esempio seguente, nota 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 ottenere un certificato TLS appropriato firmato da un un'autorità di certificazione (CA) attendibile.

2. Se questo non è possibile, prendi in considerazione una delle seguenti opzioni per consentire la firma in Edge Microgateway.

   Opzione 1: imposta una proprietà di sistema per consentire a Edge Microgateway di considerare attendibili tutti 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 rimanda al file CA radice.

      Questo documento è documentato sul Node.js sito web.

   di Gemini Advanced.

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

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

   2. Se esiste una catena di certificati, assicurati che siano corretti ordine. Il certificato foglia deve essere sempre il primo, seguito dall'intermedio e quindi il certificato radice. Trovi maggiori spiegazioni al riguardo nella Convalida della catena di certificati in corso...

      Nell'esempio seguente, abbiamo configurato il file 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 descritte anche nel Modulo Edge Microgateway - Video sulla configurazione del TLS unidirezionale e bidirezionale relativo al TLS. Consulta Configura SSL sul server Edge Microgateway per ulteriori informazioni.

Se il problema persiste, vai a Devi raccogliere dati diagnostici.

Causa: Apigee Edge Management Server utilizza un certificato autofirmato

Quando Edge Microgateway viene configurato per la prima volta, uno dei comandi che dovrai eseguire è edgemicro configure o edgemicro private configure. Questo comando avvia il bootstrap 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.

Ecco 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, verrà visualizzato il l'errore seguente nell'output della console.

{ 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 Apigee Edge abbia fornito il certificato e ne ha una copia.
3. In caso contrario, esegui questo 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, è questo il motivo problema.

Risoluzione

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

2. Se non è possibile, procedi nel seguente modo per consentire la firma 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 rimanda al file CA radice.Si tratta documentate sul Sito web Node.js.

Raccogliere dati diagnostici

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli i seguenti dati informazioni diagnostiche e contattare l'assistenza Apigee Edge:

• File di log: la cartella predefinita è /var/tmp, ma potrebbe essere ignorata in il file config.yaml principale (logging > dir parameter). È ti consigliamo di modificare log > level in info prima di fornire il di log all'Assistenza Apigee Edge.
• File di configurazione: la configurazione principale di Edge Microgateway risiede nel file YAML nella cartella predefinita di Edge Microgateway, $HOME/.edgemicro. C'è un il file di configurazione predefinito denominato default.yaml e uno per ogni ambiente ORG-ENV-config.yaml. Carica questo file per l'organizzazione e l'ambiente colpiti.

  Documenti di riferimento

  Configura la UI Edge per l'utilizzo di TLS per accedere all'API Edge