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 la supervisión de API, haz lo siguiente:

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

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

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

5. Traza Código de error en Tiempo.

6. Seleccionar 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. Información sobre el código de falla messaging.adaptors.http.flow.SslHandshakeFailed se muestra como como se muestra a continuación:

   ( ver imagen más grande)

   

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

   ( ver imagen más grande)

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

Trace

Procedimiento 2: Usa la herramienta Trace

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

1. Habilita la sesión de seguimiento y haz lo siguiente:
   • Espera 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 hacerlo. 503 Service Unavailable

2. Asegúrate de que Show all FlowInfos esté habilitado:

   
3. Selecciona una de las solicitudes fallidas 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 Target Request Flow Started (Flujo de solicitud objetivo iniciado). como se muestra a continuación:

   ( ver imagen más grande)

   
6. Toma nota de los valores de lo siguiente del 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 el protocolo de enlace SSL falló. ya que el procesador de mensajes de Apigee Edge no pudo validar el estado certificado.
7. Navega a la fase AX (datos registrados de Analytics) en el seguimiento y haz clic en ella.

8. Desplázate hasta la sección Encabezados de error de detalles de la fase y determina el 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. Observa 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: Usa registros de acceso de NGINX

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

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

2. Verifica los registros de acceso de NGINX:

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

3. Realiza una búsqueda para ver si hay algún error 503 con el código de error messaging.adaptors.http.flow.SslHandshakeFailed durante un período específico (si el problema ocurrió en el anteriores) o si todavía hay solicitudes que fallan con 503.

4. Si encuentras algún error 503 con la coincidencia X-Apigee-fault-code el valor de messaging.adaptors.http.flow.SslHandshakeFailed y, luego, y determinar 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-source:

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

Registros del procesador de mensajes

Procedimiento 4: Usa los registros del procesador de mensajes

1. Determinar el ID de mensaje de una de las solicitudes fallidas con la supervisión de API, la herramienta Trace o NGINX Access Logs, como se explica en Pasos de diagnóstico comunes.

2. Busca el ID de 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 Message Processor y el servidor de backend.

   A continuación, verás 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 el protocolo de enlace SSL falló porque el procesador de mensajes de Apigee Edge se no puede 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 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 Almacén de confianza del procesador de mensajes

1. Determina la cadena de certificados del servidor de backend.
2. Determinar el certificado almacenado en el almacén de confianza del Procesador de mensajes utilizando sigue estos pasos:

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

      Observemos una sección SSLInfo de ejemplo en una TargetEndpoint. actual:

      <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 Anota el nombre en la La columna Reference para la referencia específica del almacén de confianza. Este será tu nombre del 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 un almacén 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 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 está configurado 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 Cómo usar curl

      Resultado de muestra:

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

      [
        "serverCert"
      ]
      

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

      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 está configurado 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 Cómo usar curl

      Resultado de muestra:

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

      Certificado Hoja o de 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 real del servidor que se obtuvo en el paso 1 y el certificado almacenada en el almacén de confianza obtenido en la coincidencia del paso 3. Si no coinciden, entonces esa es la 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 backend servidor.

   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 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 Message Processor. almacén de confianza.

   4. Dado que falta el certificado raíz en el almacén de confianza, el El procesador de mensajes 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 al cliente aplicaciones.

FQDN correcto

Actualiza el almacén de claves del servidor de backend con el FQDN correcto y un certificado válido y completo cadena:

1. Si no tienes un certificado de servidor backend con el FQDN correcto, luego, obtendrás el certificado correspondiente de una AC (autoridad certificadora) correspondiente.

2. Valide que dispone de 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 la hoja o un certificado de entidad idéntico al nombre de host especificados en el extremo de destino, actualiza el almacén de claves del backend con el 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 del host se especificó de forma incorrecta en el extremo de destino, actualiza el que el extremo de destino tenga el nombre de host correcto que coincida con el FQDN en el backend certificado de servidor de Google.

2. Guarda los cambios en el proxy de API.

   En el ejemplo anterior, si el nombre de host del servidor backend puedes corregirlo con el FQDN del certificado del servidor de backend que es 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>