400 Solicitud incorrecta: error de certificado SSL

Estás viendo la documentación de Apigee Edge.
Ve a la Documentación de Apigee X. información

Síntoma

La aplicación cliente recibe una respuesta de HTTP 400: Solicitud incorrecta con el mensaje "The SSL Certificate error" (error del certificado SSL). Por lo general, el router perimetral envía este error en una configuración TLS bidireccional habilitada para la conexión entrante a Apigee Edge.

Mensaje de error

La aplicación cliente obtiene el siguiente código de respuesta:

HTTP/1.1 400 Bad Request

A continuación, se muestra la siguiente página de error de 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>

Causas posibles

Las posibles causas de este problema son las siguientes:

Causa Descripción Instrucciones de solución de problemas aplicables a
Certificado de cliente vencido El certificado que envió el cliente está vencido. Usuarios perimetrales de nubes privadas y públicas
El cliente envió el certificado incorrecto Este error se produce si el certificado enviado por la aplicación cliente no coincide. con el certificado almacenado en el almacén de confianza del router de Edge. Usuarios perimetrales de nubes privadas y públicas
Falta el certificado raíz del cliente en el almacén de confianza Se produce este error si falta el certificado raíz firmado por la AC del cliente en el almacén de confianza del router de Edge. Usuarios perimetrales de nubes privadas y públicas
Los certificados de cliente no se cargaron en el router perimetral Se produce este error si no se cargan los certificados de cliente subidos al almacén de confianza en el router. Usuarios de la nube privada perimetral

Causa: certificado de cliente vencido

Por lo general, este problema ocurre con una TLS de 2 vías, Cuando caduque el certificado que envió el cliente. En una TLS bidireccional, el intercambio de clientes y servidores sus certificados públicos para lograr el protocolo de enlace. El cliente valida el certificado del servidor y el servidor valida el certificado de cliente.

En Edge, la TLS bidireccional se implementa en hosts virtuales. donde el certificado de servidor se agrega al almacén de claves y el certificado de cliente a los almacenes de confianza.

Durante el protocolo de enlace TLS, si se descubre que el certificado de cliente caducó, entonces el servidor enviará el mensaje 400 - Bad request con el mensaje “The SSL Certificate error”.

Diagnóstico

  1. Acceder a la IU de Edge y ver la configuración específica del host virtual (Administrador > Hosts virtuales) para los que se realiza la solicitud a la API. o usa Obtener la API de host virtual Management de Google para obtener la definición del host virtual específico.

    Por lo general, un host virtual para la comunicación TLS bidireccional tiene el siguiente aspecto:

    <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>

  2. Determinar la referencia del almacén de confianza usada en el host virtual En el ejemplo anterior, El nombre de referencia del almacén de confianza es myTruststoreRef.

  3. Determina el almacén de confianza al que hace referencia la referencia.
    1. En la IU de Edge, navega a Administrador > Entornos > Referencias y busca el nombre de referencia del almacén de confianza.

    2. Anota el nombre en la columna Referencia de la referencia específica del almacén de confianza. Este será el nombre del almacén de confianza.

      La IU de Edge muestra una lista de referencias
      Figura 1

      En el ejemplo anterior, observa que myTruststoreRef tiene la referencia a myTruststore. Por lo tanto, el nombre del almacén de confianza es myTruststore.

  4. En Administrador > Entornos > Almacenes de claves TLS en la IU de Edge, navega a TLS Keystores y busca el Truststore que se encuentra en el paso 3.

  5. Selecciona el certificado en el almacén de confianza específico (determinado en el paso 3, anterior) como se muestra a continuación:

    Figura 2

    El certificado con el alias client-cert-markw del ejemplo anterior muestra que es y que ya venció.

  6. Verifica si el certificado del alias del certificado de tu almacén de confianza venció.
  7. Si el certificado no está vencido, continúa con los Pasos comunes del diagnóstico para las otras causas.

Solución

Obtén un certificado nuevo y súbelo:

  1. Crea un almacén de confianza nuevo, por ejemplo, myNewTruststore.
  2. Sube el certificado nuevo al almacén de confianza recién creado.

  3. Modificar la referencia de trustore utilizada en el host virtual específico para que apunte al nuevo host. de confianza con los pasos que se indican en Modifica una referencia.

    En el ejemplo descrito anteriormente, apunta la referencia myTruststoreRef a myNewTruststore.

Pasos comunes de diagnóstico para las otras causas

  1. Para investigar este problema, deberás capturar paquetes TCP/IP con el tcpdump.
    1. Si eres un usuario de una nube privada, puedes capturar los paquetes TCP/IP en la una aplicación cliente, o un router.
    2. Si eres usuario de una nube pública, captura los paquetes de TCP/IP en la aplicación cliente.

    3. Una vez que hayas decidido dónde te gustaría capturar los paquetes TCP/IP, usa el siguiente tcpdump para capturar paquetes TCP/IP:

      tcpdump -i any -s 0 host <IP address> -w <File name>

      Nota: Si toma los paquetes TCP/IP en el router, utilice el dirección IP pública de la aplicación cliente en el comando tcpdump.

      Si tomas los paquetes TCP/IP en la aplicación cliente, usa la IP pública. dirección del nombre de host que se usa en el host virtual en el comando tcpdump.

      Consulta tcpdump. para obtener más información sobre esta herramienta y otras variantes de este comando.

  2. Analiza los paquetes TCP/IP recopilados con el Herramienta Wireshark o una herramienta similar con la que estés familiarizado.

Este es el análisis de datos de muestra de paquetes TCP/IP con la herramienta Wireshark:

  1. El paquete 30 de tcpdump (imagen a continuación) muestra que la aplicación cliente (fuente) envió un mensaje de bienvenida "Client Hello" al router (destino).
  2. El paquete 34 muestra que el router confirma la recepción del mensaje de saludo del cliente desde la aplicación cliente.
  3. El router envía el mensaje “Server Hello” en el paquete 35 y, luego, envía su certificado y, además, solicita a la aplicación cliente que envíe su certificado en el paquete 38.
  4. En el paquete 38, en el que el router envía el paquete "Certificate Request", verifica el "Nombres distinguidos" que brinda detalles sobre el certificado de cliente, su cadena y las autoridades certificadoras que acepta el router (servidor).
    5. Figura 3

  5. La aplicación cliente envía su certificado en el paquete n.o 41. Consulta el Certificado Verificar del paquete 41 y determinar el certificado que envía la aplicación cliente.

    Figura 4
  6. Verifica si el asunto y el emisor del certificado y su cadena enviados por el cliente (paquete n.o 41) coincide con el certificado aceptado y su cadena del router (paquete n.o 38). Si hay una discrepancia, esa es la causa del error. Por lo tanto, el router (Servidor) envía la Encrypted Alert (paquete n.o 57) seguida de FIN, ACK (paquete 58) al cliente y, finalmente, la conexión finaliza.
  7. La discrepancia entre el certificado y su cadena puede deberse a las situaciones descritas en las siguientes secciones.

Causa: Certificado incorrecto que envió el cliente

Esto suele ocurrir si el sujeto o emisor del certificado o su cadena que envía el la aplicación cliente no coincide con el certificado o la cadena almacenada en el almacén de confianza del router (servidor).

Diagnóstico

  1. Acceder a la IU de Edge y ver la configuración específica del host virtual (Administrador > Hosts virtuales) para los que se realiza la solicitud a la API. o usa la API de Get virtual host Management de Google para obtener la definición del host virtual específico.

    Por lo general, un host virtual para la comunicación TLS bidireccional tiene el siguiente aspecto:

        <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>
  2. Determinar la referencia del almacén de confianza usada en el host virtual

    En el ejemplo anterior, el nombre de referencia del almacén de confianza es myCompanyTruststoreRef.

  3. Determina el almacén de confianza al que apunta la referencia del almacén de confianza.
    1. En la IU de Edge, navega a Administrador > Referencias de entornos y busca el nombre de referencia del almacén de confianza.

    2. Anota el nombre en la columna Referencia de la referencia específica del almacén de confianza. Este será el nombre del almacén de confianza.

      Visualización de la IU de Edge referencia del almacén de confianza.
      Figura 5

      En el ejemplo anterior, observa que myCompanyTruststoreRef tiene la a myCompanyTruststore. Por lo tanto, el nombre del almacén de confianza es myCompanyTruststore.

  4. Obtén los certificados almacenados en el almacén de confianza (determinado en el paso anterior) con las siguientes APIs:

    1. Enumera certificados para un almacén de claves o una API de almacén de confianza.

      Esta API enumera todos los certificados del almacén de confianza específico.

    2. Obtén detalles del certificado desde un almacén de claves o una API de almacén de confianza.

      Esta API muestra información sobre un certificado específico en el Truststore específico.

  5. Verifica si la entidad emisora y el sujeto de cada certificado y su cadena almacenados en myCompanyTruststore coincide con el del certificado y su cadena como ve en los paquetes TCP/IP (consulta el paquete 38) anterior. Si hay una discrepancia, entonces indica que los certificados subidos al almacén de confianza no se cargan en el router perimetral. Ve a la sección Causa: Los certificados de cliente no se cargaron en el router perimetral.
  6. Si no se encontró ninguna discrepancia en el paso 5, eso indica que la aplicación cliente no enviar el certificado correcto y su cadena.

Solución

Asegúrate de que la aplicación cliente envíe el certificado correcto y su cadena a Edge.

Causa: falta el certificado raíz de cliente en el almacén de confianza

Se produce este error si falta el certificado raíz firmado por la AC del cliente en el almacén de confianza del router de Edge.

Diagnóstico

  1. Acceder a la IU de Edge y ver la configuración específica del host virtual para la que la API se realiza la solicitud (Administrador > Hosts virtuales > virtual_host), o utiliza la Obtén la API de host virtual para obtener la definición del host virtual específico.

    Por lo general, un host virtual para la comunicación TLS bidireccional tiene el siguiente aspecto:

        <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>
  2. Determina la referencia del almacén de confianza que se usa en el host virtual. En el ejemplo anterior, el nombre de referencia del almacén de confianza es myCompanyTruststoreRef.
  3. Determina el almacén de confianza real que usa la referencia del almacén de confianza.
  4. En la IU de Edge, navega a Administrador > Entornos > Referencias y búsqueda para el nombre de referencia del almacén de confianza.

  5. El nombre del almacén de confianza para la referencia específica del almacén de confianza se encuentra en Reference.

    Figura 6

    En este ejemplo, observa que myCompanyTruststoreRef tiene myCompanyTruststore en la columna Referencia. Por lo tanto, el almacén de confianza el nombre es myCompanyTruststore.

  6. Obtén los certificados almacenados en el almacén de confianza (determinado en el paso anterior) con las siguientes APIs:
    1. Muestra una lista de certificados para un almacén de claves o una API de almacén de confianza. Esta API enumera todos los en el almacén de confianza.
    2. Obtén detalles del certificado desde un almacén de claves o una API de almacén de confianza. Esta API devuelve información sobre un certificado específico en el almacén de confianza.

  7. Comprueba si el certificado incluye una cadena completa, incluido el certificado raíz enviados por el cliente específico, como se ve en los paquetes de TCP/IP (consulta la figura 4). El almacén de confianza debe incluir el certificado raíz, así como el certificado de entidad final o la hoja del cliente certificado intermedio. Si el certificado raíz válido del cliente no está en el almacén de confianza, esa es la causa del error.

    Sin embargo, si toda la cadena de certificados del cliente, incluido el certificado raíz, en el almacén de confianza, indica que los certificados subidos al es posible que los almacenes de confianza no estén cargados en el router perimetral. Si ese es el caso, consulta Causa: Los certificados de cliente no se cargaron en el router perimetral.

Solución

Asegúrate de que esté disponible el certificado de cliente correcto, incluido el certificado raíz en el almacén de confianza del router de Apigee Edge.

Causa: Los certificados de cliente no se cargaron en el router perimetral

  1. Si eres usuario de la nube pública, comunícate con el equipo de asistencia de Apigee Edge.
  2. Si eres usuario de la nube privada, sigue las instrucciones a continuación en cada router:
    1. Verifica si el archivo /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem existe para el host virtual específico. Si el archivo no existe, dirígete a Resolución a continuación.
    2. Si el archivo existe, usa el siguiente comando openssl para obtener los detalles del certificados disponibles en el router perimetral: 
      openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
    3. Verifica la entidad emisora, el asunto y la fecha de vencimiento del certificado. Si alguno de estos no coincide con lo que se observó en Truststore en la IU de Edge o con las APIs de administración, eso es la causa del error.
    4. Es posible que el router no haya vuelto a cargar los certificados subidos.

Solución

Reinicia el router para asegurarte de que se carguen los certificados más recientes. Para ello, sigue el siguiente paso:

apigee-service edge-router restart

Vuelve a ejecutar las APIs y verifica los resultados. Si el problema persiste, ve a Recopila información de diagnóstico.

Recopile 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. Comunícate con el equipo de asistencia de Apigee Edge y compártela con esta información:

  1. Si eres usuario de la nube pública, proporciona la siguiente información:
    1. Nombre de la organización
    2. Nombre del entorno
    3. Nombre del proxy de la API
    4. Nombre del host virtual
    5. Nombre del alias de host
    6. Completar el comando curl para reproducir el error
    7. Paquetes TCP/IP capturados en la aplicación cliente
  2. Si eres usuario de la nube privada, proporciona la siguiente información:
    1. Nombre del host virtual y su definición con la API de Get virtual host
    2. Nombre del alias de host
    3. Se observó un mensaje de error completo
    4. Paquetes de TCP/IP capturados en la aplicación cliente o el router.
    5. Resultado de List thecertificates from the keystore API (Enumera los certificados de la API del almacén de claves). y también los detalles de cada certificado obtenido con la API de Get cert details.
  3. Detalles sobre las secciones de esta guía que probaste y cualquier otra conclusión que nos ayudan a resolver rápidamente este problema.