Servicio no disponible: Error de protocolo de enlace SSL

Supervisión de API

Procedimiento n.o 1: Usar la supervisión de APIs

Para diagnosticar el error con la supervisión de la API, sigue estos pasos:

1. Accede a la IU de Apigee Edge como un usuario con el rol adecuado.

2. Cambia a la organización en la que quieres investigar el problema.

   
3. Navega a la página Analyze > API Monitoring > Investigate.
4. Selecciona el período específico en el que observaste los errores.

5. Traza el código de falla en función del valor Time.

6. Selecciona una celda que tenga el código de falla messaging.adaptors.http.flow.SslHandshakeFailed, como se muestra a continuación:

   ( ver imagen más grande)

   

7. Se muestra información sobre el código de falla messaging.adaptors.http.flow.SslHandshakeFailed como se muestra a continuación:

   ( ver imagen más grande)

   

8. Haz clic en Ver registros y expande la fila de la solicitud fallida.

   ( ver imagen más grande)

   
9. En la ventana Registros, ten en cuenta los siguientes detalles:
   • ID de mensaje de solicitud
   • Código de estado: 503
   • Fuente de la falla: target
   • Código de falla: messaging.adaptors.http.flow.SslHandshakeFailed

Trace

Procedimiento n.o 2: Usa la herramienta de seguimiento

Para diagnosticar el error con la herramienta Trace, sigue estos pasos:

1. Habilita la sesión de seguimiento y realiza una de estas acciones:
   • Espera a que aparezca el error 503 Service Unavailable con el código de error messaging.adaptors.http.flow.SslHandshakeFailed.
   • Si puedes reproducir el problema, realiza la llamada a la API para reproducirlo 503 Service Unavailable

2. Asegúrate de que la opción Show all FlowInfos esté habilitada:

   
3. Selecciona una de las solicitudes con errores y examina el seguimiento.
4. Navega por las diferentes fases del seguimiento y localiza dónde ocurrió la falla.

5. Por lo general, encontrarás el error después de la fase Se inició el flujo de solicitud de destino, como se muestra a continuación:

   ( ver imagen más grande)

   
6. Toma nota de los valores de lo siguiente en el seguimiento:
   • error: SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.cause: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.class: com.apigee.errors.http.server.ServiceUnavailableException.
   • El valor del error SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target indica que falló el protocolo de enlace SSL, ya que el procesador de mensajes de Apigee Edge no pudo validar el certificado del servidor de backend.
7. Navega a la fase AX (datos de Analytics registrados) en el seguimiento y haz clic en ella.

8. Desplázate hacia abajo hasta la sección Encabezados de error de los detalles de la fase y determina los valores de X-Apigee-fault-code y X-Apigee-fault-source, y X-Apigee-Message-ID como se muestra a continuación:

   ( ver imagen más grande)

   
9. Ten en cuenta los valores de X-Apigee-fault-code, X-Apigee-fault-source y X-Apigee-Message-ID:

Encabezados de error	Valor
X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
X-Apigee-fault-source	target
X-Apigee-Message-ID	MESSAGE_ID

NGINX

Procedimiento n.o 3: Usa los registros de acceso de NGINX

Para diagnosticar el error con los registros de acceso de NGINX, sigue estos pasos:

1. Si eres un usuario de la nube privada, puedes usar los registros de acceso de NGINX para determinar la información clave de 503 Service Unavailable de HTTP.

2. Verifica los registros de acceso de NGINX:

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

3. Busca para ver si hay errores 503 con el código de error messaging.adaptors.http.flow.SslHandshakeFailed durante un período específico (si el problema ocurrió en el pasado) o si hay alguna solicitud que aún falla con 503.

4. Si encuentras algún error 503 con el X-Apigee-fault-code que coincide con el valor de messaging.adaptors.http.flow.SslHandshakeFailed, determina el valor de X-Apigee-fault-source.

   Ejemplo de error 503 del registro de acceso de NGINX:

   ( ver imagen más grande)

   

   La entrada de ejemplo anterior del registro de acceso de NGINX tiene los siguientes valores para X-Apigee-fault-code y X-Apigee-fault-code

   Encabezados	Valor
   X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-fault-source	target

Registros de Message Processor

Procedimiento n.o 4: Usa los registros del procesador de mensajes

1. Determina el ID del mensaje de una de las solicitudes con errores mediante la supervisión de la API, la herramienta Trace o los registros de acceso de NGINX, como se explica en Pasos comunes de diagnóstico.

2. Busca el ID del mensaje de solicitud específico en el registro de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log). Es posible que observes el siguiente error:

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
   SSLClientChannel[Connected: Remote:X.X.X.X:443
   Local:192.168.194.140:55102]@64596 useCount=1
   bytesRead=0 bytesWritten=0 age=233ms  lastIO=233ms
   isOpen=true handshake failed, message: General SSLEngine problem
   

   El error anterior indica que el protocolo de enlace SSL falló entre el Message Processor y el servidor de backend.

   A continuación, se producirá una excepción con un seguimiento de pila detallado, como se muestra a continuación:

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
   RequestWriteListener.onException(HTTPRequest@1522922c)
   javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478)
   	at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
   	... <snipped>
   Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Alerts.getSSLException(Alerts.java:203)
   	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
   	... <snipped>
   Caused by: sun.security.validator.ValidatorException: PKIX path building failed:
   sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
   certification path to requested target
   	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
   	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
   	... <snipped>
     

   Ten en cuenta que la falla del protocolo de enlace se debe a los siguientes motivos:

   Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

   Esto indica que el protocolo de enlace SSL falló porque el procesador de mensajes de Apigee Edge no pudo validar el certificado del servidor de backend.

Fase 1

Fase 1: Determinación de la cadena de certificados del servidor de backend

Usa uno de los siguientes métodos para determinar la cadena de certificados del servidor de backend:

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

Certificate chain
 0 s:/CN=mocktarget.apigee.net
   i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
 1 s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
 2 s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

Fase 2

Fase 2: Compara el certificado del servidor de backend y los certificados almacenados en el almacén de confianza del procesador de mensajes

1. Determina la cadena de certificados del servidor de backend.
2. Sigue estos pasos para determinar el certificado almacenado en el almacén de confianza de Message Processor:

   1. Obtén el nombre de referencia del almacén de confianza del elemento TrustStore en la sección SSLInfo de TargetEndpoint.

      Veamos una sección SSLInfo de muestra en una configuración TargetEndpoint:

      <TargetEndpoint name="default">
      ...
         <HTTPTargetConnection>
            <Properties />
            <SSLInfo>
               <Enabled>true</Enabled>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <KeyStore>ref://myKeystoreRef</KeyStore>
               <KeyAlias>myKey</KeyAlias>
               <TrustStore>
                  ref://myCompanyTrustStoreRef
               </TrustStore>
            </SSLInfo>
         </HTTPTargetConnection>
         ...
      </TargetEndpoint>
      

   2. En el ejemplo anterior, el nombre de referencia de TrustStore es myCompanyTruststoreRef.

   3. En la IU de Edge, selecciona Entornos > Referencias. Anota el nombre de la columna Reference para la referencia específica del almacén de confianza. Este será el nombre de tu almacén de confianza.

      ( ver imagen más grande)

      

   4. En el ejemplo anterior, el nombre del almacén de confianza es el siguiente:

      myCompanyTruststoreRef: myCompanyTruststore

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

   1. Obtén todos los certificados de un almacén de claves o almacén de confianza. Esta API enumera todos los certificados del almacén de confianza específico.

      Usuario de la nube pública:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      Usuario de la nube privada:

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      Dónde:

      • ORGANIZATION_NAME es el nombre de la organización
      • ENVIRONMENT_NAME es el nombre del entorno.
      • KEYSTORE_NAME es el nombre del almacén de claves.
      • $TOKEN se configura en tu token de acceso de OAuth 2.0 como se describe en Cómo obtener un token de acceso de OAuth 2.0.
      • Las opciones de curl que se usan en este ejemplo se describen en Cómo usar curl.

      Resultado de muestra:

      Los certificados del almacén de confianza de ejemplo myCompanyTruststore son los siguientes:

      [
        "serverCert"
      ]
      

   2. Obtén detalles del certificado específico de un almacén de claves o un almacén de confianza. Esta API muestra la información sobre un certificado específico en el almacén de confianza específico.

      Usuario de la nube pública:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      Usuario de la nube privada

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#>/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      Dónde:

      • ORGANIZATION_NAME es el nombre de la organización
      • ENVIRONMENT_NAME es el nombre del entorno.
      • KEYSTORE_NAME es el nombre del almacén de claves.
      • CERT_NAME es el nombre del certificado.
      • $TOKEN se configura en tu token de acceso de OAuth 2.0 como se describe en Cómo obtener un token de acceso de OAuth 2.0.
      • Las opciones de curl que se usan en este ejemplo se describen en Cómo usar curl.

      Resultado de muestra:

      En los detalles de serverCert, se muestra el sujeto y la entidad emisora de la siguiente manera:

      Certificado de hoja o entidad:

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      

      Certificado de nivel intermedio:

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",
      

4. Verifica que el certificado de servidor real obtenido en el paso 1 y el certificado almacenado en el almacén de confianza obtenido en el paso 3 coincidan. Si no coinciden, esa es la causa del problema.

   En el ejemplo anterior, veamos un certificado a la vez:

   1. Certificado de hoja:

      Desde el servidor de backend:

      s:/CN=mocktarget.apigee.net
      i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
      

      Desde el almacén de confianza (cliente) de Message Processor:

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      

      El certificado de hoja almacenado en el almacén de confianza coincide con el del servidor de backend.

   2. Certificado intermedio:

      Desde el servidor de backend:

      s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      

      Desde el almacén de confianza (cliente) de Message Processor:

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",
      

      El certificado intermedio almacenado en el almacén de confianza coincide con el del servidor de backend.

   3. Certificado raíz:

      Desde el servidor de backend:

      s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      

      Falta por completo el certificado raíz en el almacén de confianza de Message Processor.

   4. Como falta el certificado raíz en el almacén de confianza, Message Processor arroja la siguiente excepción:

      sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
      

      y muestra 503 Service Unavailable con el código de error messaging.adaptors.http.flow.SslHandshakeFailed a las aplicaciones cliente.

FQDN correcto

Actualiza el almacén de claves del servidor de backend con el FQDN correcto y la cadena de certificados completa y válida:

1. Si no tienes un certificado del servidor de backend con el FQDN correcto, obtén el certificado adecuado de una AC (autoridad certificada) adecuada.

2. Verifica que tengas una cadena de certificados del servidor de backend válida y completa.

3. Una vez que tengas la cadena de certificados válida y completa con el FQDN correcto del servidor de backend en el certificado de entidad o hoja que sea idéntico al nombre de host especificado en el extremo de destino, actualiza el almacén de claves del backend con la cadena de certificados completa.

Servidor de backend correcto

Actualiza el extremo de destino con el nombre de host del servidor de backend correcto:

1. Si el nombre de host se especificó de forma incorrecta en el extremo de destino, actualiza este extremo para que tenga el nombre de host correcto que coincida con el FQDN en el certificado del servidor de backend.

2. Guarda los cambios en el proxy de API.

   En el ejemplo anterior, si el nombre de host del servidor de backend se especificó de forma incorrecta, puedes corregirlo con el FQDN desde el certificado del servidor de backend, es decir, backend.apigee.net de la siguiente manera:

   <TargetEndpoint name="default">
      …
      <HTTPTargetConnection>
         <Properties />
         <SSLInfo>
            <Enabled>true</Enabled>
            <TrustStore>ref://myTrustStoreRef</TrustStore>
         </SSLInfo>
         <URL>https://backend.apigee.net/resource</URL>
      </HTTPTargetConnection>
   </TargetEndpoint>