Fallas del protocolo de enlace TLS/SSL

Estás viendo la documentación de Apigee Edge.
Consulta la documentación de Apigee X. Más información

Síntoma

Una falla del protocolo de enlace TLS/SSL se produce cuando un cliente y un servidor no pueden establecer la comunicación mediante 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 de 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 de protocolo de enlace TLS/SSL:

Received fatal alert: handshake_failure

Causas posibles

TLS (seguridad de la capa de transporte, cuya antecesora es SSL) es la tecnología de seguridad estándar que permite 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 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. Acepta la versión del protocolo que usarás.
2. Selecciona el algoritmo criptográfico que se usará.
3. Intercambie y valide certificados digitales para autenticarse entre sí.

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

Las posibles causas de las fallas del protocolo de enlace TLS/SSL son las siguientes:

Causa	Descripción	Quién puede realizar los pasos para solucionar problemas
Discrepancia en el protocolo	El servidor no admite el protocolo que usa el cliente.	Usuarios de la nube privada y pública
Discrepancia en Ciipher Suite	El servidor no admite el conjunto de algoritmos de cifrado que utiliza el cliente.	Usuarios de la nube privada y pública
Certificado incorrecto	El nombre de host de la URL que usa el cliente no coincide con el del certificado almacenado en el extremo del servidor.	Usuarios de la nube privada y pública
	Se almacena una cadena de certificados incompleta o no válida en el extremo del cliente o del servidor.	Usuarios de la nube privada y pública
	El cliente envía un certificado incorrecto o vencido al servidor, o bien del servidor al cliente.	Usuarios de la nube privada y pública
Servidor habilitado para SNI	El servidor de backend tiene habilitada la indicación de nombre del servidor (SNI). Sin embargo, el cliente no puede comunicarse con los servidores SNI.	Solo usuarios de la nube privada

Discrepancias en el protocolo

Se produce una falla de protocolo de enlace TLS/SSL si el servidor no admite el protocolo que usa el cliente, ya sea en la conexión entrante (con el norte) o en la salida (hacia el sur). Consulta también Información sobre las conexiones con el norte y el sur.

Diagnóstico

1. Determina si el error ocurrió en la conexión hacia el norte o hacia el sur. Para obtener más información sobre cómo hacer esta determinación, consulta Cómo determinar la fuente del problema.
2. Ejecuta la utilidad tcpdump para recopilar más información:
   • Si eres un usuario de nube privada, puedes recopilar los datos de tcpdump en el cliente o servidor relevante. Un cliente puede ser la app cliente (para conexiones entrantes o con dirección norte) o el Procesador de mensajes (para conexiones salientes o con dirección sur). Un servidor puede ser el router perimetral (para conexiones entrantes o hacia el norte) o el servidor de backend (para conexiones salientes o con dirección sur) según la determinación del paso 1.
   • Si eres un usuario de la nube pública, puedes recopilar los datos de tcpdump solo en la app cliente (para conexiones entrantes o hacia el norte) o en el servidor de backend (para conexiones salientes o hacia el sur), ya que no tienes acceso al router perimetral o al procesador de mensajes.

   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. Este es un análisis de muestra de tcpdump con Wireshark:
   • En este ejemplo, se produjo la falla de protocolo de enlace TLS/SSL entre el procesador de mensajes y el servidor de backend (la conexión saliente o con el sur).
   • El mensaje n.o 4 del resultado de tcpdump que aparece a continuación muestra que el procesador de mensajes (fuente) envió un mensaje de “Hello del cliente” al servidor de backend (destino).
     

     

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

     

   • En el mensaje n.o 5, se muestra que el servidor de backend confirma el mensaje “Client Hello” del Message Processor.
   • El servidor de backend envía de inmediato el mensaje Alerta de cierre : Notificación de cierre al Procesador de mensajes (mensaje n.o 6). Esto significa que el protocolo de enlace TLS/SSL falló y se cerrará la conexión.

   • Si profundizamos en el mensaje n.o 6, se muestra 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 procesador de mensajes y el servidor de backend, el servidor de backend envió el mensaje Fatal Alert Message: Close Notify.

Resolución

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

1. Actualiza tu servidor de backend para que sea compatible con 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 a Message Processor a usar el protocolo TLSv1.0 a fin de comunicarse con el servidor de backend siguiendo estos pasos:
   1. Si no especificaste un servidor de destino en la definición de TargetEndpoint del proxy, configura 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 a fin de establecer el protocolo TLSv1.0 en la configuración específica del servidor de destino.

Cipher no coincide

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

Diagnóstico

1. Determina si el error ocurrió en la conexión hacia el norte o hacia el sur. Para obtener más orientación sobre cómo hacer esta determinación, consulta Cómo determinar la fuente del problema.
2. Ejecuta la utilidad tcpdump para recopilar más información:
   • Si eres un usuario de nube privada, puedes recopilar los datos de tcpdump en el cliente o servidor relevante. Un cliente puede ser la app cliente (para conexiones entrantes o con dirección norte) o el Procesador de mensajes (para conexiones salientes o con dirección sur). Un servidor puede ser el router perimetral (para conexiones entrantes o hacia el norte) o el servidor de backend (para conexiones salientes o con dirección sur) según la determinación del paso 1.
   • Si eres un usuario de la nube pública, puedes recopilar los datos de tcpdump solo en la app cliente (para conexiones entrantes o hacia el norte) o en el servidor de backend (para conexiones salientes o hacia el sur), ya que no tienes acceso al router perimetral o al procesador de mensajes.

   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 de la salida de tcpdump con Wireshark:
   • En este ejemplo, se produjo la falla de protocolo de enlace TLS/SSL entre la aplicación cliente y el router Edge (conexión norte). El resultado de tcpdump se recopiló en el router perimetral.

   • El mensaje n.o 4 del resultado de tcpdump que aparece a continuación muestra que la aplicación cliente (origen) envió un mensaje “Client Hello” al router perimetral (destino).

     

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

     

   • El mensaje n.o 5 muestra que el router perimetral reconoce el mensaje “Hello del cliente” de la aplicación cliente.
   • El router de Edge envía inmediatamente una Alerta irrecuperable : falla de protocolo de enlace a la aplicación cliente (mensaje n.o 6). Esto significa que el protocolo de enlace TLS/SSL falló y se cerrará la conexión.
   • Si observas con más detalle el mensaje n.o 6, verás la siguiente información:
     • El router perimetral es compatible con el protocolo TLSv1.2. Esto significa que el protocolo coincide entre la aplicación cliente y el router perimetral.

     • Sin embargo, el router Edge aún envía la Alerta irrecuperable: error de protocolo de enlace a la aplicación cliente, como se muestra en la siguiente captura de pantalla:

       

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

     

   • La lista de algoritmos del conjunto de algoritmos de cifrado compatibles con el router perimetral se incluye en el archivo /opt/nginx/conf.d/0-default.conf. En este ejemplo, Edge Router 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 discrepancia es la causa de la falla del protocolo de enlace TLS/SSL.
   • Debido a que el router perimetral está habilitado para SNI, desplázate hacia abajo hasta el mensaje 4 en el resultado de tcpdump y confirma que la aplicación cliente esté enviando el nombre del servidor correctamente, como se muestra en la siguiente figura:
     
     
     
   • Si este nombre es válido, puedes inferir que el protocolo de enlace TLS/SSL se produjo porque los algoritmos del conjunto de algoritmos de cifrado que usa la aplicación cliente no son compatibles con el router perimetral.

Resolución

Debes asegurarte de que el cliente utilice 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 la extensión de criptografía de Java (JCE) y, luego, inclúyelo en la instalación de Java para que sea compatible con los algoritmos del conjunto de algoritmos de cifrado de alta encriptación.

Certificado incorrecto

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

Si el problema se limita al norte, 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. A continuación, se muestra 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:

Causa	Descripción	Quién puede realizar los pasos para solucionar problemas
El nombre de host no coincide	El nombre de host que se usa en la URL y el certificado del almacén de claves del router no coinciden. Por ejemplo, se produce una discrepancia si el nombre de host que se usó en la URL es myorg.domain.com mientras que el certificado tiene el nombre de host en su CN como CN=something.domain.com.	Usuarios de la nube pública y privada de Edge
Cadena de certificados incompleta o incorrecta	La cadena de certificados no está completa o no es correcta.	Solo para usuarios de la nube pública y privada de Edge
Certificado vencido o desconocido enviado por el servidor o el cliente	El servidor o el cliente envía un certificado vencido o desconocido, ya sea en el norte o en la conexión con el sur.	Usuarios de la nube privada de Edge y de la nube pública perimetral

El nombre de host no coincide

Diagnóstico

1. Toma nota del nombre de host que se usa en la URL que muestra la siguiente llamada a la API de Edge Management:

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

   Por ejemplo:

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

2. Obtén el CN usado en el certificado almacenado en el almacén de claves específico. Puedes usar las siguientes APIs de administración perimetral para obtener los detalles del certificado:
   1. Obtén el nombre del certificado en el almacén de claves:
      
      Si eres un usuario de la nube privada, 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 un 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 Edge Management.
      
      Si eres un 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 un usuario de la nube pública, haz lo siguiente:
      

      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 asunto 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 del certificado no coinciden, se produce la falla del protocolo de enlace TLS/SSL.

Resolución

Este problema puede resolverse de una de estas 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 tema 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 usado en el certificado almacenado en el almacén de claves específico. Puedes usar las siguientes APIs de administración perimetral para obtener los detalles del certificado:
   1. Obtén el nombre del certificado en el almacén de claves:
      
      Si eres un 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
      

      Si eres un usuario de la nube pública, haz lo siguiente:
      

      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 un 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 un usuario de la nube pública, haz lo siguiente:
      

      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 la falla del protocolo de enlace TLS/SSL.
   4. En el siguiente gráfico, se muestra un certificado de muestra con una cadena de certificados no válida, en la que los certificados intermedios y raíz no coinciden:

   Certificado intermedio y raíz de muestra en el que el emisor y el sujeto no coinciden

   
   

Resolució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 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 validados al almacén de claves.

Certificado vencido o desconocido que envió el servidor o el cliente

Si el servidor o cliente envía un certificado incorrecto o vencido, ya sea en la conexión con el norte o en el sur, el otro extremo (servidor/cliente) rechaza el certificado, lo que provoca una falla de protocolo de enlace TLS/SSL.

Diagnóstico

1. Determina si el error ocurrió en la conexión hacia el norte o hacia el sur. Para obtener más información sobre cómo hacer esta determinación, consulta Cómo determinar la fuente del problema.
2. Ejecuta la utilidad tcpdump para recopilar más información:
   • Si eres un usuario de nube privada, puedes recopilar los datos de tcpdump en el cliente o servidor relevante. Un cliente puede ser la app cliente (para conexiones entrantes o con dirección norte) o el Procesador de mensajes (para conexiones salientes o con dirección sur). Un servidor puede ser el router perimetral (para conexiones entrantes o hacia el norte) o el servidor de backend (para conexiones salientes o con dirección sur) según la determinación del paso 1.
   • Si eres un usuario de la nube pública, puedes recopilar los datos de tcpdump solo en la app cliente (para conexiones entrantes o hacia el norte) o en el servidor de backend (para conexiones salientes o hacia el sur), ya que no tienes acceso al router perimetral o al procesador de mensajes.

   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 rechazará el certificado durante el paso de verificación.
5. Puedes recuperar el certificado enviado desde el otro extremo desde el resultado de tcpdump, siempre que los datos no estén encriptados. Será útil para comparar si este certificado coincide con el certificado disponible en el almacén de confianza.
6. Revisa el tcpdump de muestra para la comunicación SSL entre el procesador de mensajes y el servidor de backend.

   Ejemplo tcpdump que muestra un error de certificado desconocido

   
   

   1. El Procesador de mensajes (cliente) envía el mensaje “Hello del cliente” al servidor de backend (servidor) en el mensaje n.o 59.
   2. El servidor de backend envía “Server Hello” al procesador de mensajes en el mensaje n.o 61.
   3. Validan mutuamente el protocolo y los algoritmos del conjunto de algoritmos de cifrado utilizados.
   4. El servidor de backend envía el certificado y el mensaje Hello Done al Procesador de mensajes en el mensaje n.o 68.
   5. Message Processor envía la alerta fatal "Description: Certificate Unknown" en el mensaje n.o 70.
   6. Si se observa en el mensaje n.o 70, no hay detalles adicionales aparte del mensaje de alerta, como se muestra a continuación:

      
      

   7. Revisa el mensaje n.o 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 "Certificados", como se muestra en la figura anterior.
7. Si se descubre que el router (extremo norte) o el procesador de mensajes (extremo sur) no reconoce el certificado, como en el ejemplo ilustrado más arriba, sigue estos pasos:
   1. Obtén el certificado y su cadena almacenada en el almacén de confianza específico. (Consulta la configuración del host virtual correspondiente al router y la configuración del extremo de destino para 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. Verifica si el certificado almacenado en el almacén de confianza del router (límite hacia el norte) o el procesador de mensajes (hacia el sur) coincide con el certificado almacenado en el almacén de claves de la aplicación cliente (norte) o el servidor de destino (hacia el sur), o con el que se obtiene de los resultados de tcpdump. Si no hay coincidencia, esa es la causa del error de protocolo de enlace TLS/SSL.
8. Si se descubre que el certificado es desconocido por la aplicación cliente (en el norte) o el servidor de destino (hacia el sur), sigue estos pasos:
   1. Obtén la cadena de certificados completa usada en el certificado almacenado en el almacén de claves específico. (Consulta la configuración del host virtual correspondiente al router y la configuración del extremo de destino para 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 (hacia el norte) o el procesador de mensajes (hacia el sur) coincide con el certificado almacenado en el almacén de confianza de la aplicación cliente (norte) o el servidor de destino (hacia el sur), o con el que se obtiene de la salida de tcpdump. Si no hay coincidencia, esa es la causa de la falla del protocolo de enlace SSL.
9. Si se descubre que el certificado enviado por un servidor o cliente está vencido, el cliente o servidor receptor rechaza el certificado y verás el siguiente mensaje de alerta en tcpdump:

   Alerta (Nivel: Fatal, Descripción: Certificado vencido)

10. Verifica que el certificado del almacén de claves del host correspondiente haya caducado.

Resolución

Para resolver el problema identificado en el ejemplo anterior, sube el certificado del servidor de backend válido a Trustore en el Procesador de mensajes.

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

Causa	Descripción	Resolución
Certificado vencido	NorthBound El certificado almacenado en el almacén de claves del router está vencido. El certificado almacenado en el almacén de claves de la aplicación cliente está vencido (SSL bidireccional).	Sube un certificado nuevo y su cadena completa al almacén de claves en el host adecuado.
	SouthBound El certificado almacenado en el almacén de claves del servidor de destino está vencido. El certificado almacenado en el almacén de claves de Message Processor está vencido (SSL bidireccional).	Sube un certificado nuevo y su cadena completa al almacén de claves en el host adecuado.
Certificado desconocido	NorthBound El certificado almacenado en el almacén de confianza de la aplicación cliente no coincide con el certificado del router. El certificado almacenado en el almacén de confianza del router no coincide con el certificado de la aplicación cliente (SSL 2 vías).	Sube el certificado válido al almacén de confianza en el host adecuado.
	SouthBound El certificado almacenado en el almacén de confianza del servidor de destino no coincide con el certificado de Message Processor. El certificado almacenado en el almacén de confianza de Message Processor no coincide con el certificado del servidor de destino (SSL bidireccional).	Sube el certificado válido al almacén de confianza en el host adecuado.

Servidor habilitado para la SNI

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

Primero, debes identificar el nombre de host y el número de puerto del servidor que se está utilizando y verificar si tiene SNI habilitada o no.

Identificación del servidor habilitado para SNI

1. Ejecuta el comando openssl y trata de conectarte al nombre de host del servidor relevante (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 protocolo de enlace 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, luego, intenta conectarte al nombre de host del servidor relevante (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 n.o 1 o obtienes diferentes certificados en los pasos n.o 1 y n.o 2, significa que el servidor especificado tiene habilitada la SNI.

Una vez que hayas identificado que el servidor está habilitado para la 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 ocurrió en la conexión hacia el norte o hacia el sur. Para obtener más información sobre cómo hacer esta determinación, consulta Cómo determinar la fuente del problema.
2. Ejecuta la utilidad tcpdump para recopilar más información:
   • Si eres un usuario de nube privada, puedes recopilar los datos de tcpdump en el cliente o servidor relevante. Un cliente puede ser la app cliente (para conexiones entrantes o con dirección norte) o el Procesador de mensajes (para conexiones salientes o con dirección sur). Un servidor puede ser el router perimetral (para conexiones entrantes o hacia el norte) o el servidor de backend (para conexiones salientes o con dirección sur) según la determinación del paso 1.
   • Si eres un usuario de la nube pública, puedes recopilar los datos de tcpdump solo en la app cliente (para conexiones entrantes o hacia el norte) o en el servidor de backend (para conexiones salientes o hacia el sur), ya que no tienes acceso al router perimetral o al procesador de mensajes.

   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, se produjo la falla del protocolo de enlace TLS/SSL entre el procesador de mensajes perimetrales y el servidor de backend (conexión con el extremo sur).
   2. El mensaje n.o 4 del resultado de tcpdump que aparece a continuación muestra que el Message Processor (fuente) envió un mensaje "Client Hello" al servidor de backend (destino).

      

   3. Si seleccionas el mensaje "Hola del cliente", se mostrará que el procesador de mensajes usa el protocolo TLSv1.2.

      

   4. El mensaje n.o 4 muestra que el servidor de backend confirma el mensaje “Client Hello” del Message Processor.
   5. El servidor de backend envía de inmediato una Alerta irrecuperable : falla de protocolo de enlace al Message Processor (mensaje n.o 5). Esto significa que el protocolo de enlace TLS/SSL falló y se cerrará la conexión.
   6. Revisa el mensaje n.o 6 para descubrir la siguiente información:
      • El servidor de backend es compatible con el protocolo TLSv1.2. Esto significa que el protocolo coincidió entre el procesador de mensajes y el servidor de backend.
      • Sin embargo, el servidor de backend aún envía la Alerta irrecuperable: error de protocolo de enlace al Message Processor, como se muestra en la siguiente figura:

        

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

      

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

Resolución

Habilita los procesadores de mensajes para que se comuniquen con los servidores habilitados para SNI mediante los siguientes 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. Elige al propietario de este archivo apigee:apigee:

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

4. Reinicia el Procesador de mensajes.

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

5. Si tienes más de un Message Processor, repite los pasos 1 a 4 en todos estos.

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