502 Bad Gateway: Certificado autofirmado en cadena

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

Síntoma

La aplicación cliente recibe un código de respuesta HTTP 502 con el mensaje Bad Gateway como respuesta para las llamadas a la API en Edge Microgateway.

Como alternativa, el administrador recibirá un error self signed certificate in certificate chain cuando ejecute el edgemicro configure comando.

Mensaje de error

El cliente verá el siguiente mensaje de respuesta:

HTTP/1.1 502 Bad Gateway

A continuación, se muestran dos ejemplos comunes de respuestas de error:

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

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

Como alternativa, este error puede ocurrir cuando se ejecuta 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' }

Causas posibles

Causa: El servidor de destino presenta un certificado autofirmado

Si el servidor de destino presenta un certificado autofirmado en la conexión de salida, Edge Microgateway generará este error de forma predeterminada porque no confía en los certificados autofirmados.

Diagnóstico

Es posible que observes el siguiente error en los registros (/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][]

El código de error SELF_SIGNED_CERT_IN_CHAIN indica que es muy probable que Edge Microgateway haya recibido un certificado autofirmado del servidor de destino. Para confirmar esto, sigue estos pasos:

1. Ejecuta el siguiente openssl comando para verificar la cadena de certificados del servidor de destino:

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

2. Si la cadena de certificados del servidor de destino está autofirmada, esta es la causa de el problema.

   En el siguiente ejemplo, observa que el servidor de destino presenta un certificado autofirmado:

   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

Solución

1. Trabaja con el equipo propietario del servidor de destino para obtener un certificado TLS adecuado firmado por una autoridad certificadora (AC) de confianza.

2. Si eso no es posible, considera una de las siguientes opciones para permitir certificados autofirmados en Edge Microgateway.

   Opción 1: Establece una propiedad del sistema para permitir que Edge Microgateway confíe en todos los certificados

   1. Si usas Docker, consulta Usa una AC en la que Node.js no confía.

   2. De lo contrario, exporta una variable de entorno llamada NODE_EXTRA_CA_CERTS, que apunte al archivo de AC raíz.

      Esto se documenta en el sitio web oficial Node.js de Node.js.

   Opción 2: Configura el archivo de configuración YAML de Edge Microgateway para que confíe en ese certificado específico para ese servidor de destino

   1. Asegúrate de tener el certificado (o la cadena) del servidor de destino en formato PEM. Para convertir otros formatos de certificado a PEM, sigue las instrucciones que se indican en Convierte certificados a un formato compatible.

   2. Si hay una cadena de certificados, asegúrate de que los certificados estén en el orden correcto orden. El certificado de hoja siempre debe ser el primero, seguido del certificado intermedio y, luego, el certificado raíz. Hay más explicaciones sobre esto en Valida la cadena de certificados.

      En el siguiente ejemplo, configuramos el archivo de AC de confianza para untrusted-root.badssl.com.

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

   Las instrucciones para configurar esto también se incluyen en el video Módulo de Edge Microgateway: Configura TLS de salida unidireccional y bidireccional. Consulta Configura SSL en el servidor de Edge Microgateway para obtener más información.

Si el problema persiste, consulta Se debe recopilar información de diagnóstico.

Causa: El servidor de administración de Apigee Edge usa un certificado autofirmado

Cuando se configura Edge Microgateway por primera vez, uno de los comandos que deberás ejecutar es edgemicro configure o edgemicro private configure. Este comando iniciará el clúster y se comunicará con Apigee Edge para descargar la información requerida.

En el caso de la nube privada de Edge, la URL del servidor de administración se determina mediante el argumento -m. Si habilitaste TLS para el servidor de administración, Edge Microgateway intentará verificar el certificado que presenta el servidor de administración.

A continuación, se muestra un ejemplo del comando edgemicro configure para la nube privada de Edge:

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

Si el servidor de administración está configurado con un certificado autofirmado, recibirás el siguiente error en el resultado de la consola.

{ 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' }

Diagnóstico

1. En este caso, es posible que el servidor de administración (management.apigee-dev.net) muestre un certificado TLS autofirmado.
2. Es probable que el administrador del sistema de Apigee Edge haya proporcionado el certificado y tenga una copia de él.
3. De lo contrario, ejecuta el siguiente comando para obtener información sobre el certificado:

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

4. Si el servidor de administración tiene un certificado autofirmado, esa es la causa de este problema.

Solución

1. Trabaja con el equipo propietario del servidor de destino para obtener un certificado TLS adecuado firmado por una autoridad certificadora (AC) de confianza.

2. Si eso no es posible, haz lo siguiente para permitir certificados autofirmados en Edge Microgateway.

3. Establece una propiedad del sistema para permitir que Edge Microgateway confíe en todos los certificados.
4. Si usas Docker, consulta Usa una AC en la que Node.js no confía.
5. De lo contrario, exporta una variable de entorno llamada NODE_EXTRA_CA_CERTS, que apunte al archivo de AC raíz.Esto se documenta en el sitio web oficial Node.js de.

Se debe recopilar información de diagnóstico

Si el problema persiste incluso después de seguir las instrucciones anteriores, recopila la siguiente información de diagnóstico y, luego, comunícate con Asistencia de Apigee Edge:

• Archivos de registro: La carpeta predeterminada es /var/tmp, pero se puede anular en el archivo config.yaml principal (logging > dir parameter). Se recomienda cambiar el log > level a info antes de proporcionar los archivos de registro a Asistencia de Apigee Edge.
• Archivo de configuración: La configuración principal de Edge Microgateway reside en el archivo YAML de la carpeta predeterminada de Edge Microgateway, $HOME/.edgemicro. Hay un archivo de configuración predeterminado llamado default.yaml y luego uno para cada entorno ORG-ENV-config.yaml. Sube este archivo completo para la organización y el entorno afectados.

  Documentos de referencia

  Configura la IU de Edge para usar TLS para acceder a la API de Edge