Servicio no disponible: Error de protocolo de enlace SSL

Supervisión de API

Procedimiento 1: Usa la supervisión de API

Para diagnosticar el error con API Monitoring, haz lo siguiente:

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

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

   
3. Navega a la página Analizar > Supervisión de API > Investigar.
4. Selecciona el período específico en el que observaste los errores.

5. Representa gráficamente el código de falla en función del tiempo.

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

   ( aumentar el tamaño de la imagen)

   

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

   ( aumentar el tamaño de la imagen)

   

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

   ( aumentar el tamaño de la imagen)

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

Seguimiento

Procedimiento 2: Cómo usar la herramienta de Trace

Para diagnosticar el error con la herramienta Trace, haz lo siguiente:

1. Habilita la sesión de registro y una de las siguientes opciones:
   • Espera a que se produzca el error 503 Service Unavailable con el código de error messaging.adaptors.http.flow.SslHandshakeFailed, o
   • Si puedes reproducir el problema, realiza la llamada a la API para reproducirlo. 503 Service Unavailable

2. Asegúrate de que la opción Mostrar todos los FlowInfos esté habilitada:

   
3. Selecciona una de las solicitudes con errores y examina el registro.
4. Navega por las diferentes fases del registro y ubica dónde se produjo la falla.

5. Por lo general, encontrarás el error después de la fase Target Request Flow Started, como se muestra a continuación:

   ( aumentar el tamaño de la imagen)

   
6. Toma nota de los valores de los siguientes elementos del registro:
   • 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 Message Processor de Apigee Edge no pudo validar el certificado del servidor de backend.
7. Navega a la fase AX (datos de Analytics registrados) en el registro y haz clic en ella.

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

   ( aumentar el tamaño de la imagen)

   
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 3: Uso de registros de acceso de NGINX

Para diagnosticar el error con los registros de acceso de NGINX, haz lo siguiente:

1. Si eres usuario de Private Cloud, puedes usar los registros de acceso de NGINX para determinar la información clave sobre 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 si hay errores de 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 aún hay solicitudes que fallan con 503.

4. Si encuentras errores de 503 con el X-Apigee-fault-code que coincida 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:

   ( aumentar el tamaño de la imagen)

   

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

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

Registros de Message Processor

Procedimiento 4: Cómo usar los registros de Message Processor

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

2. Busca el ID del mensaje de solicitud específico en el registro del 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 falló el protocolo de enlace SSL entre el Message Processor y el servidor de backend.

   A continuación, se mostrará 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 lo siguiente:

   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 falló el protocolo de enlace SSL, ya que el Message Processor de Apigee Edge no pudo validar el certificado del servidor de backend.

Fase 1

Fase 1: Determina 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 certificados de confianza del procesador de mensajes

1. Determina la cadena de certificados del servidor de backend.
2. Para determinar el certificado almacenado en el almacén de certificados de confianza del procesador de mensajes, sigue estos pasos:

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

      Veamos una sección SSLInfo de ejemplo en una configuración de 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 TrustStore es myCompanyTruststoreRef.

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

      ( aumentar el tamaño de la imagen)

      

   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 certificados de confianza (determinado en el paso anterior) con las siguientes APIs:

   1. Obtén todos los certificados de un almacén de claves o de certificados de confianza. Esta API enumera todos los certificados 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 -H "Authorization: Bearer $TOKEN"
      

      Usuario de 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 Obtén un token de acceso de OAuth 2.0
      • Las opciones de curl que se usan en este ejemplo se describen en Usa curl

      Resultado de muestra:

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

      [
        "serverCert"
      ]

   2. Obtén los detalles del certificado específico de un almacén de claves o de confianza. Esta API devuelve 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 Private Cloud

      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 Obtén un token de acceso de OAuth 2.0
      • Las opciones de curl que se usan en este ejemplo se describen en Usa curl

      Resultado de muestra:

      Los detalles de serverCert muestran el asunto y el emisor 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 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 del servidor real que obtuviste en el paso 1 y el certificado almacenado en el almacén de certificados de confianza que obtuviste en el paso 3 coincidan. Si no coinciden, esa es la causa del problema.

   En el ejemplo anterior, analicemos 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 del procesador de mensajes (cliente):

      "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 certificados 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 del procesador de mensajes (cliente):

      "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 certificados 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 certificados de confianza del Message Processor.

   4. Dado que falta el certificado raíz en el almacén de certificados de confianza, el 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 devuelve 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 una cadena de certificados válida y completa:

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

2. Valida 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 hoja o de entidad 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 correcto del servidor de backend:

1. Si el nombre de host se especificó de forma incorrecta en el extremo de destino, actualiza el extremo de destino 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 usando el FQDN del 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>