Fallas del protocolo de enlace TLS/SSL

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

Síntoma

Se produce un error de protocolo de enlace TLS/SSL cuando un cliente y un servidor no pueden establecer comunicación con el protocolo TLS/SSL. Cuando se produce este error en Apigee Edge, la aplicación cliente recibe un estado HTTP 503 con el mensaje Servicio no disponible. Verás este error después de cualquier llamada a la API en la que se produzca una falla en el protocolo de enlace TLS/SSL.

Mensajes de error

HTTP/1.1 503 Service Unavailable

También puedes ver este mensaje de error cuando se produce una falla en el protocolo de enlace TLS/SSL:

Received fatal alert: handshake_failure

Causas posibles

TLS (seguridad de la capa de transporte, cuyo predecesor es SSL) es la tecnología de seguridad estándar para establecer un vínculo encriptado entre un servidor web y un cliente web, como un navegador o una app. Un protocolo de enlace es un proceso que permite que el cliente y el servidor de TLS/SSL establezcan un conjunto de claves secretas con las que pueden comunicarse. Durante este proceso, el cliente y el servidor hacen lo siguiente:

1. Acuerda la versión del protocolo que se usará.
2. Selecciona el algoritmo criptográfico que se usará.
3. Se autentican mutuamente intercambiando y validando certificados digitales.

Si el protocolo de enlace TLS/SSL se realiza correctamente, el cliente y el servidor TLS/SSL se transfieren datos de forma segura. De lo contrario, si se produce una falla en el protocolo de enlace TLS/SSL, se finaliza la conexión y el cliente recibe un error 503 Service Unavailable.

Las posibles causas de los errores de protocolo de enlace de TLS/SSL son las siguientes:

Protocol Mismatch

Se produce una falla del protocolo de enlace TLS/SSL si el servidor no admite el protocolo que usa el cliente en la conexión entrante (norte) o saliente (sur). Consulta también Información sobre las conexiones ascendentes y descendentes.

Diagnóstico

1. Determina si el error se produjo en la conexión de norte a sur o de sur a norte. Para obtener más orientación sobre cómo realizar esta determinación, consulta Cómo determinar la fuente del problema.
2. Ejecuta la utilidad tcpdump para recopilar más información:
   • Si eres usuario de la nube privada, puedes recopilar los datos de tcpdump en el cliente o servidor correspondiente. Un cliente puede ser la app cliente (para conexiones entrantes o ascendentes) o el procesador de mensajes (para conexiones salientes o descendentes). Un servidor puede ser el router perimetral (para conexiones entrantes o ascendentes) o el servidor de backend (para conexiones salientes o descendentes) según tu determinación del paso 1.
   • Si eres usuario de la nube pública, solo puedes recopilar los datos de tcpdump en la app cliente (para las conexiones entrantes o de norte a sur) o en el servidor de backend (para las conexiones salientes o de sur a norte), ya que no tienes acceso al router perimetral ni al Message Processor.

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

   Consulta los datos de tcpdump para obtener más información sobre el uso del comando tcpdump.
3. Analiza los datos de tcpdump con la herramienta Wireshark o una herramienta similar.
4. A continuación, se muestra un análisis de ejemplo de tcpdump con Wireshark:
   • En este ejemplo, la falla del protocolo de enlace TLS/SSL ocurrió entre el Message Processor y el servidor de backend (la conexión saliente o de salida).
   • El mensaje núm. 4 del resultado de tcpdump que se muestra a continuación indica que el Message Processor (fuente) envió un mensaje "Client Hello" al servidor de backend (destino).
     

     

   • Si seleccionas el mensaje Client Hello, se muestra que el Message Processor usa el protocolo TLSv1.2, como se muestra a continuación:

     

   • El mensaje núm. 5 muestra que el servidor de backend confirma la recepción del mensaje "Client Hello" del Message Processor.
   • El servidor de backend envía de inmediato Fatal Alert : Close Notify al procesador de mensajes (mensaje núm. 6). Esto significa que falló el protocolo de enlace TLS/SSL y se cerrará la conexión.

   • Si analizamos más el mensaje núm. 6, se observa que la causa de la falla del protocolo de enlace TLS/SSL es que el servidor de backend solo admite el protocolo TLSv1.0, como se muestra a continuación:

     

   • Debido a que hay una discrepancia entre el protocolo que usa el Message Processor y el servidor de backend, este último envió el mensaje Fatal Alert Message: Close Notify.

Solución

El Message Processor se ejecuta en Java 8 y usa el protocolo TLSv1.2 de forma predeterminada. Si el servidor de backend no admite el protocolo TLSv1.2, puedes seguir uno de los siguientes pasos para resolver este problema:

1. Actualiza tu servidor de backend para que admita el protocolo TLSv1.2. Esta es una solución recomendada, ya que el protocolo TLSv1.2 es más seguro.
2. Si, por algún motivo, no puedes actualizar tu servidor de backend de inmediato, puedes forzar al Message Processor a usar el protocolo TLSv1.0 para comunicarse con el servidor de backend. Para ello, sigue estos pasos:
   1. Si no especificaste un servidor de destino en la definición de TargetEndpoint del proxy, establece el elemento Protocol en TLSv1.0, como se muestra a continuación:

      <TargetEndpoint name="default">
       …
       <HTTPTargetConnection>
         <SSLInfo>
             <Enabled>true</Enabled>
             <Protocols>
                 <Protocol>TLSv1.0</Protocol>
             </Protocols>
         </SSLInfo>
         <URL>https://myservice.com</URL>
       </HTTPTargetConnection>
       …
      </TargetEndpoint>

   2. Si configuraste un servidor de destino para tu proxy, usa esta API de administración para establecer el protocolo en TLSv1.0 en la configuración específica del servidor de destino.

Cipher Mismatch

Puedes ver una falla del protocolo de enlace TLS/SSL si el servidor no admite el algoritmo del conjunto de algoritmos de cifrado que usa el cliente en la conexión entrante (norte) o saliente (sur) en Apigee Edge. Consulta también Información sobre las conexiones ascendentes y descendentes.

Diagnóstico

1. Determina si el error se produjo en la conexión de norte a sur o de sur a norte. Para obtener más orientación sobre cómo tomar esta determinación, consulta Cómo determinar la fuente del problema.
2. Ejecuta la utilidad tcpdump para recopilar más información:
   • Si eres usuario de la nube privada, puedes recopilar los datos de tcpdump en el cliente o servidor correspondiente. Un cliente puede ser la app cliente (para conexiones entrantes o ascendentes) o el procesador de mensajes (para conexiones salientes o descendentes). Un servidor puede ser el router perimetral (para conexiones entrantes o ascendentes) o el servidor de backend (para conexiones salientes o descendentes) según tu determinación del paso 1.
   • Si eres usuario de la nube pública, solo puedes recopilar los datos de tcpdump en la app cliente (para las conexiones entrantes o de norte a sur) o en el servidor de backend (para las conexiones salientes o de sur a norte), ya que no tienes acceso al router perimetral ni al Message Processor.

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

   Consulta los datos de tcpdump para obtener más información sobre el uso del comando tcpdump.
3. Analiza los datos de tcpdump con la herramienta Wireshark o cualquier otra herramienta que conozcas.
4. Este es el análisis de muestra del resultado de tcpdump con Wireshark:
   • En este ejemplo, la falla del protocolo de enlace TLS/SSL se produjo entre la aplicación cliente y el router perimetral (conexión de salida). El resultado de tcpdump se recopiló en el router de borde.

   • El mensaje núm. 4 en el resultado de tcpdump que se muestra a continuación indica que la aplicación cliente (fuente) envió un mensaje "Client Hello" al enrutador perimetral (destino).

     

   • Si seleccionas el mensaje Client Hello, se muestra que la aplicación cliente usa el protocolo TLSv1.2.

     

   • El mensaje núm. 5 muestra que el router perimetral confirma la recepción del mensaje "Client Hello" de la aplicación cliente.
   • El router perimetral envía de inmediato una Alerta Fatal : Fallo en el Protocolo de Enlace a la aplicación cliente (mensaje núm. 6). Esto significa que falló el protocolo de enlace TLS/SSL y se cerrará la conexión.
   • Si analizamos más a fondo el mensaje #6, se muestra la siguiente información:
     • El router perimetral admite el protocolo TLSv1.2. Esto significa que el protocolo coincide entre la aplicación cliente y el router perimetral.

     • Sin embargo, el router perimetral aún envía la Alerta Fatal: Error de Negociación a la aplicación cliente, como se muestra en la siguiente captura de pantalla:

       

   • El error podría deberse a uno de los siguientes problemas:
     • La aplicación cliente no usa los algoritmos de conjunto de algoritmos de cifrado compatibles con el router perimetral.
     • El router perimetral está habilitado para SNI, pero la aplicación cliente no envía el nombre del servidor.
   • El mensaje núm. 4 del resultado de tcpdump enumera los algoritmos de conjuntos de cifrado compatibles con la aplicación cliente, como se muestra a continuación:

     

   • La lista de algoritmos de conjuntos de algoritmos de cifrado compatibles con el enrutador perimetral se encuentra en el archivo /opt/nginx/conf.d/0-default.conf. En este ejemplo, el router perimetral solo admite los algoritmos del conjunto de algoritmos de cifrado de alta encriptación.
   • La aplicación cliente no usa ninguno de los algoritmos del conjunto de algoritmos de cifrado de alta encriptación. Esta falta de coincidencia es la causa del error del protocolo de enlace TLS/SSL.
   • Como el router perimetral tiene habilitado el SNI, desplázate hacia abajo hasta el mensaje núm. 4 en el resultado de tcpdump y confirma que la aplicación cliente envía el nombre del servidor correctamente, como se muestra en la siguiente figura:
     
     
     
   • Si este nombre es válido, puedes inferir que el error de handshake de TLS/SSL se produjo porque los algoritmos de conjuntos de cifrado que usa la aplicación cliente no son compatibles con el router perimetral.

Solución

Debes asegurarte de que el cliente use los algoritmos del conjunto de algoritmos de cifrado que admite el servidor. Para resolver el problema descrito en la sección Diagnóstico anterior, descarga e instala el paquete de Java Cryptography Extension (JCE) y, luego, inclúyelo en la instalación de Java para admitir los algoritmos de conjuntos de algoritmos de cifrado de alta encriptación.

Certificado incorrecto

Se produce una falla del protocolo de enlace TLS/SSL si tienes certificados incorrectos en el almacén de claves o el almacén de certificados de confianza, ya sea en la conexión entrante (norte) o saliente (sur) en Apigee Edge. Consulta también Información sobre las conexiones ascendentes y descendentes.

Si el problema es de entrada, es posible que veas diferentes mensajes de error según la causa subyacente.

En las siguientes secciones, se enumeran ejemplos de mensajes de error y los pasos para diagnosticar y resolver este problema.

Mensajes de error

Es posible que veas diferentes mensajes de error según la causa de la falla del protocolo de enlace TLS/SSL. Este es un mensaje de error de muestra que podrías ver cuando llamas a un proxy de API:

* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

Causas posibles

Las causas típicas de este problema son las siguientes:

Discrepancia en el nombre de host

Diagnóstico

1. Ten en cuenta el nombre de host que se usa en la URL que devuelve la siguiente llamada a la API de administración de Edge:

   curl -v https://myorg.domain.com/v1/getinfo

   Por ejemplo:

   curl -v https://api.enterprise.apigee.com/v1/getinfo

2. Obtén el CN que se usa en el certificado almacenado en el almacén de claves específico. Puedes usar las siguientes APIs de administración de Edge para obtener los detalles del certificado:
   1. Obtén el nombre del certificado en el almacén de claves:
      
      Si eres usuario de Private Cloud, usa la API de Management de la siguiente manera:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      Si eres usuario de la nube pública, usa la API de Management de la siguiente manera:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Obtén los detalles del certificado en el almacén de claves con la API de administración de Edge.
      
      Si eres usuario de la nube privada, haz lo siguiente:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Si eres usuario de la nube pública:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Certificado de muestra::

      "certInfo": [
          {
            "basicConstraints": "CA:FALSE",
            "expiryDate": 1456258950000,
            "isValid": "No",
            "issuer": "SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=\"GoDaddy.com, Inc.\", L=Scottsdale, ST=Arizona, C=US",
            "publicKey": "RSA Public Key, 2048 bits",
            "serialNumber": "07:bc:a7:39:03:f1:56",
            "sigAlgName": "SHA1withRSA",
            "subject": "CN=something.domain.com, OU=Domain Control Validated, O=something.domain.com",
            "validFrom": 1358287055000,
            "version": 3
          },

      El nombre del sujeto en el certificado principal tiene el CN como something.domain.com.

      Debido a que el nombre de host que se usa en la URL de la solicitud a la API (consulta el paso 1 anterior) y el nombre del asunto en el certificado no coinciden, se produce la falla del protocolo de enlace TLS/SSL.

Solución

Este problema se puede resolver de una de las siguientes dos maneras:

• Obtén un certificado (si aún no tienes uno) en el que el CN del sujeto tenga un certificado comodín y, luego, sube la nueva cadena de certificados completa al almacén de claves. Por ejemplo:

  "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",

• Obtén un certificado (si aún no tienes uno) con un CN de asunto existente, pero usa your-org.your-domain como nombre alternativo del sujeto y, luego, sube la cadena de certificados completa al almacén de claves.

Referencias

Almacenes de claves y almacenes de confianza

Cadena de certificados incompleta o incorrecta

Diagnóstico

1. Obtén el CN que se usa en el certificado almacenado en el almacén de claves específico. Puedes usar las siguientes APIs de administración de Edge para obtener los detalles del certificado:
   1. Obtén el nombre del certificado en el almacén de claves:
      
      Si eres usuario de Private Cloud:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

      Si eres usuario de la nube pública:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Obtén los detalles del certificado en el almacén de claves:
      
      Si eres usuario de Private Cloud:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Si eres usuario de la nube pública:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

   3. Valida el certificado y su cadena, y verifica que cumpla con los lineamientos proporcionados en el artículo Cómo funcionan las cadenas de certificados para asegurarte de que sea una cadena de certificados válida y completa. Si la cadena de certificados almacenada en el almacén de claves está incompleta o no es válida, verás el error de protocolo de enlace TLS/SSL.
   4. En el siguiente gráfico, se muestra un certificado de ejemplo con una cadena de certificados no válida, en la que no coinciden los certificados intermedio y raíz:

   Ejemplo de certificado intermedio y certificado raíz en el que no coinciden el emisor y el sujeto

   
   

Solución

1. Obtén un certificado (si aún no tienes uno) que incluya una cadena de certificados completa y válida.
2. Ejecuta el siguiente comando de openssl para verificar que la cadena de certificados sea correcta y esté completa:

   openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert

3. Sube la cadena de certificados validada al almacén de claves.

Certificado vencido o desconocido enviado por el servidor o el cliente

Si el servidor o el cliente envían un certificado incorrecto o vencido en la conexión de salida o de entrada, el otro extremo (servidor o cliente) rechaza el certificado, lo que provoca una falla en el protocolo de enlace TLS/SSL.

Diagnóstico

1. Determina si el error se produjo en la conexión de norte a sur o de sur a norte. Para obtener más orientación sobre cómo realizar esta determinación, consulta Cómo determinar la fuente del problema.
2. Ejecuta la utilidad tcpdump para recopilar más información:
   • Si eres usuario de la nube privada, puedes recopilar los datos de tcpdump en el cliente o servidor correspondiente. Un cliente puede ser la app cliente (para conexiones entrantes o ascendentes) o el procesador de mensajes (para conexiones salientes o descendentes). Un servidor puede ser el router perimetral (para conexiones entrantes o ascendentes) o el servidor de backend (para conexiones salientes o descendentes) según tu determinación del paso 1.
   • Si eres usuario de la nube pública, solo puedes recopilar los datos de tcpdump en la app cliente (para las conexiones entrantes o de norte a sur) o en el servidor de backend (para las conexiones salientes o de sur a norte), ya que no tienes acceso al router perimetral ni al Message Processor.

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

   Consulta los datos de tcpdump para obtener más información sobre el uso del comando tcpdump.
3. Analiza los datos de tcpdump con Wireshark o una herramienta similar.
4. En el resultado de tcpdump, determina el host (cliente o servidor) que rechaza el certificado durante el paso de verificación.
5. Puedes recuperar el certificado enviado desde el otro extremo de la salida tcpdump, siempre que los datos no estén encriptados. Esto será útil para comparar si este certificado coincide con el certificado disponible en el almacén de certificados de confianza.
6. Revisa el ejemplo de tcpdump para la comunicación SSL entre el Message Processor y el servidor de backend.

   Ejemplo de tcpdump que muestra el error Certificate Unknown

   
   

   1. El Message Processor (cliente) envía "Client Hello" al servidor de backend (servidor) en el mensaje núm. 59.
   2. El servidor de backend envía "Server Hello" al Message Processor en el mensaje #61.
   3. Validan mutuamente los algoritmos del protocolo y del conjunto de algoritmos de cifrado que se usan.
   4. El servidor de backend envía el certificado y el mensaje Server Hello Done al Message Processor en el mensaje núm. 68.
   5. El Message Processor envía la alerta fatal "Description: Certificate Unknown" en el mensaje núm. 70.
   6. Si analizamos más a fondo el mensaje #70, no hay detalles adicionales más allá del mensaje de alerta, como se muestra a continuación:

      
      

   7. Revisa el mensaje núm. 68 para obtener los detalles sobre el certificado que envió el servidor de backend, como se muestra en el siguiente gráfico:

      

   8. El certificado del servidor de backend y su cadena completa están disponibles en la sección "Certificates", como se muestra en la figura anterior.
7. Si el Router (norte) o el Message Processor (sur) consideran que el certificado es desconocido, como se muestra en el ejemplo anterior, sigue estos pasos:
   1. Obtén el certificado y su cadena que se almacenan en el almacén de certificados de confianza específico. (Consulta la configuración del host virtual para el enrutador y la configuración del extremo de destino para el Message Processor). Puedes usar las siguientes APIs para obtener los detalles del certificado:
      1. Obtén el nombre del certificado en el almacén de confianza:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs

      2. Obtén los detalles del certificado en el almacén de confianza:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name

   2. Comprueba si el certificado almacenado en el almacén de certificados de confianza del router (norte) o del Message Processor (sur) coincide con el certificado almacenado en el almacén de claves de la aplicación cliente (norte) o del servidor de destino (sur), o con el que se obtiene del resultado de tcpdump. Si hay una discrepancia, esa es la causa de la falla del protocolo de enlace TLS/SSL.
8. Si la aplicación cliente (norte) o el servidor de destino (sur) detectan que el certificado es desconocido, sigue estos pasos:
   1. Obtén la cadena de certificados completa que se usa en el certificado almacenado en el almacén de claves específico. (Consulta la configuración del host virtual para el enrutador y la configuración del extremo de destino para el Message Processor). Puedes usar las siguientes APIs para obtener los detalles del certificado:
      1. Obtén el nombre del certificado en el almacén de claves:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      2. Obtén los detalles del certificado en el almacén de claves:
         

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
         

   2. Verifica si el certificado almacenado en el almacén de claves del router (norte) o del Message Processor (sur) coincide con el certificado almacenado en el almacén de certificados de confianza de la aplicación cliente (norte) o del servidor de destino (sur), o con el que se obtiene del resultado de tcpdump. Si hay una discrepancia, esa es la causa de la falla del protocolo de enlace SSL.
9. Si se detecta que el certificado enviado por un servidor o cliente venció, el cliente o servidor receptor lo rechaza y verás el siguiente mensaje de alerta en tcpdump:

   Alerta (nivel: fatal, descripción: El certificado venció)

10. Verifica que el certificado del almacén de claves del host adecuado haya vencido.

Solución

Para resolver el problema identificado en el ejemplo anterior, sube el certificado válido del servidor de backend al almacén de confianza en el Message Processor.

En la siguiente tabla, se resumen los pasos para resolver el problema según su causa.

Servidor con SNI habilitado

La falla del protocolo de enlace TLS/SSL puede ocurrir cuando el cliente se comunica con un servidor habilitado para la indicación del nombre del servidor (SNI), pero el cliente no está habilitado para la SNI. Esto podría ocurrir en la conexión de norte a sur o de sur a norte en Edge.

Primero, debes identificar el nombre de host y el número de puerto del servidor que se usa, y verificar si está habilitado para SNI.

Identificación del servidor habilitado para SNI

1. Ejecuta el comando openssl y trata de conectarte al nombre de host del servidor pertinente (router perimetral o servidor de backend) sin pasar el nombre del servidor, como se muestra a continuación:

   openssl s_client -connect hostname:port

   Es posible que obtengas los certificados y, a veces, observes la falla del handshake en el comando openssl, como se muestra a continuación:
   

   CONNECTED(00000003)
   9362:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_clnt.c:593

2. Ejecuta el comando openssl y trata de conectarte al nombre de host del servidor pertinente (router perimetral o servidor de backend) pasando el nombre del servidor como se muestra a continuación:

   openssl s_client -connect hostname:port -servername hostname

3. Si se produce un error de protocolo de enlace en el paso 1 o si obtienes certificados diferentes en los pasos 1 y 2, significa que el servidor especificado tiene habilitado el SNI.

Una vez que identifiques que el servidor tiene habilitado SNI, puedes seguir los pasos que se indican a continuación para verificar si la falla del protocolo de enlace TLS/SSL se debe a que el cliente no puede comunicarse con el servidor SNI.

Diagnóstico

1. Determina si el error se produjo en la conexión de norte a sur o de sur a norte. Para obtener más orientación sobre cómo realizar esta determinación, consulta Cómo determinar la fuente del problema.
2. Ejecuta la utilidad tcpdump para recopilar más información:
   • Si eres usuario de la nube privada, puedes recopilar los datos de tcpdump en el cliente o servidor correspondiente. Un cliente puede ser la app cliente (para conexiones entrantes o ascendentes) o el procesador de mensajes (para conexiones salientes o descendentes). Un servidor puede ser el router perimetral (para conexiones entrantes o ascendentes) o el servidor de backend (para conexiones salientes o descendentes) según tu determinación del paso 1.
   • Si eres usuario de la nube pública, solo puedes recopilar los datos de tcpdump en la app cliente (para las conexiones entrantes o de norte a sur) o en el servidor de backend (para las conexiones salientes o de sur a norte), ya que no tienes acceso al router perimetral ni al Message Processor.

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

   Consulta los datos de tcpdump para obtener más información sobre el uso del comando tcpdump.
3. Analiza el resultado de tcpdump con Wireshark o una herramienta similar.
4. Este es el análisis de muestra de tcpdump con Wireshark:
   1. En este ejemplo, la falla del protocolo de enlace de TLS/SSL ocurrió entre el procesador de mensajes de Edge y el servidor de backend (conexión de salida).
   2. El mensaje #4 en el resultado de tcpdump que se muestra a continuación indica que el Message Processor (fuente) envió un mensaje "Client Hello" al servidor de backend (destino).

      

   3. Si seleccionas el mensaje "Client Hello", se muestra que el Message Processor usa el protocolo TLSv1.2.

      

   4. El mensaje núm. 4 muestra que el servidor de backend confirma la recepción del mensaje "Client Hello" del Message Processor.
   5. El servidor de backend envía de inmediato una Alerta Fatal : Error de Protocolo de Enlace al Message Processor (mensaje núm. 5). Esto significa que falló el protocolo de enlace TLS/SSL y se cerrará la conexión.
   6. Revisa el mensaje núm. 6 para descubrir la siguiente información:
      • El servidor de backend admite el protocolo TLSv1.2. Esto significa que el protocolo coincidió entre el Message Processor y el servidor de backend.
      • Sin embargo, el servidor de backend aún envía la Alerta Fatal: Error de Protocolo de Enlace al Message Processor, como se muestra en la siguiente figura:

        

   7. Este error puede ocurrir por uno de los siguientes motivos:
      • El Message Processor no usa los algoritmos de conjuntos de algoritmos de cifrado compatibles con el servidor de backend.
      • El servidor de backend tiene habilitada la SNI, pero la aplicación cliente no envía el nombre del servidor.
   8. Revisa el mensaje núm. 3 (Client Hello) en el resultado de tcpdump con más detalle. Ten en cuenta que falta la extensión: server_name, como se muestra a continuación:

      

   9. Esto confirma que el Message Processor no envió el server_name al servidor de backend habilitado para SNI.
   10. Esta es la causa de la falla del protocolo de enlace TLS/SSL y el motivo por el que el servidor de backend envía la Alerta fatal: Falla del protocolo de enlace al procesador de mensajes.
5. Verifica que jsse.enableSNIExtension property en system.properties esté configurado como falso en el Message Processor para confirmar que el Message Processor no esté habilitado para comunicarse con el servidor habilitado para SNI.

Solución

Para habilitar la comunicación de los Message Processor con los servidores habilitados para SNI, sigue estos pasos:

1. Crea el archivo/opt/apigee/customer/application/message-processor.properties (si aún no existe).
2. Agrega la siguiente línea a este archivo: conf_system_jsse.enableSNIExtension=true
3. Cambia el propietario de este archivo a apigee:apigee con el comando chown:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Reinicia el Message Processor.

   /opt/apigee/apigee-service/bin/apigee-service message-processor restart

5. Si tienes más de un Message Processor, repite los pasos del 1 al 4 en todos los Message Processors.

Si no puedes determinar la causa de la falla del protocolo de enlace TLS/SSL y solucionar el problema, o si necesitas más ayuda, comunícate con el equipo de asistencia de Apigee Edge. Comparte los detalles completos del problema junto con el resultado de tcpdump.