Estás viendo la documentación de Apigee Edge.
Consulta la documentación de
Apigee X.
Síntoma
Una falla de protocolo de enlace TLS/SSL ocurre cuando un cliente y un servidor no pueden establecer 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 Service available. 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 un error de 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 TLS/SSL establezcan un conjunto de claves secretas con las que pueden comunicarse. Durante este proceso, el cliente y el servidor realizan las siguientes acciones:
- Acepta la versión del protocolo que usarás.
- Selecciona el algoritmo criptográfico que se usará.
- Intercambia y valida los certificados digitales para autenticarte mutuamente.
Si el protocolo de enlace TLS/SSL se ejecuta correctamente, el cliente TLS/SSL se transfieren entre sí de forma segura. De lo contrario, si se produce un error de protocolo de enlace TLS/SSL, la conexión finaliza y el cliente recibe un error 503 Service Unavailable
.
Las posibles causas de fallas de protocolo de enlace TLS/SSL son las siguientes:
Causa | Descripción | Quién puede seguir los pasos para solucionar problemas |
---|---|---|
Discrepancia de protocolo | El servidor no admite el protocolo que usa el cliente. | Usuarios de la nube privada y pública |
Discrepancia en Suite Suite | El servidor no admite el conjunto de algoritmos de cifrado que usa el cliente. | Usuarios de la nube privada y pública |
Certificado incorrecto | El nombre de host en la URL que usa el cliente no coincide con el nombre de host en el certificado almacenado en el extremo del servidor. | Usuarios de la nube privada y pública |
Una cadena de certificados incompleta o no válida se almacena en el cliente o en el extremo del servidor. | Usuarios de la nube privada y pública | |
El cliente envía un certificado incorrecto o vencido al servidor o desde el 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 |
Discrepancia en el protocolo
Una falla de protocolo de enlace TLS/SSL ocurre si el servidor no admite el protocolo que usa el servidor en la conexión entrante (límite del norte) o saliente (límite sur). También consulta Información sobre las conexiones con dirección norte y sur.
Diagnóstico
- Determina si el error ocurrió en la conexión northbound o southbound. Si deseas obtener más información para tomar esta determinación, consulta Cómo determinar la fuente del problema.
- Ejecuta la herramienta
tcpdump para recopilar más información:
- Si eres un usuario de nube privada, puedes recopilar los datos de
tcpdump
en el servidor o cliente relevante. Un cliente puede ser la app del cliente (para conexiones entrantes o hacia el norte) o el procesador de mensajes (para conexiones salientes o hacia el sur). Un servidor puede ser el router perimetral (para conexiones entrantes o salientes), o el servidor backend (para conexiones salientes o hacia el sur), según tu determinación del paso 1. - Si eres un usuario de Cloud público, puedes recopilar los datos de
tcpdump
solo en la app cliente (para conexiones entrantes o hacia el norte) o el servidor de backend (para conexiones salientes o 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 comandotcpdump
. - Si eres un usuario de nube privada, puedes recopilar los datos de
- Analiza los datos de
tcpdump
con la herramienta Wireshark o una herramienta similar. - Este es un análisis de muestra de
tcpdump con Wireshark:
- En este ejemplo, se produjo una falla en el protocolo de enlace TLS/SSL entre el procesador de mensajes y el servidor de backend (la conexión saliente o con dirección sur).
- El mensaje n.o 4 del resultado de
tcpdump
a continuación muestra que Message Processor (fuente) envió un mensaje de “Client Hello” al servidor de backend (destino).
Si seleccionas el mensaje
Client Hello
, se muestra que Message Processor usa el protocolo TLSv1.2, como se muestra a continuación:- En el mensaje 5, se muestra que el servidor de backend reconoce el mensaje “Client Hello” del Message Processor.
- El servidor de backend envía de inmediato la Alerta fatal : cerrar notificación al procesador de mensajes (mensaje n.o 6). Esto significa que falló el protocolo de enlace TLS/SSL y se cerrará la conexión.
Si observas con más detalle 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:
- Dado que el protocolo que usa Message Processor y el servidor de backend no coinciden, 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 realizar uno de los siguientes pasos para resolver el problema:
- 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.
- Si, por algún motivo, no puedes actualizar tu servidor de backend de inmediato, puedes hacer que el procesador de mensajes use el protocolo TLSv1.0 para comunicarse con él mediante los siguientes pasos:
- Si no especificaste un servidor de destino en la definición de TargetEndpoint del proxy, configura el elemento
Protocol
comoTLSv1.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>
- Si configuraste un servidor de destino para tu proxy, usa esta API de administración a fin de establecer el protocolo en TLSv1.0 en la configuración específica del servidor de destino.
- Si no especificaste un servidor de destino en la definición de TargetEndpoint del proxy, configura el elemento
No coincide con Ciipher
Puedes ver una falla del protocolo de enlace TLS/SSL si el servidor no admite el algoritmo de conjunto de algoritmos de cifrado que usa el cliente en la conexión entrante (límite norte) o saliente (límite sur) en Apigee Edge. También consulta Información sobre las conexiones con dirección norte y sur.
Diagnóstico
- Determina si el error ocurrió en la conexión northbound o southbound. Si deseas obtener más información para realizar esta determinación, consulta Cómo determinar la fuente del problema.
- Ejecuta la herramienta
tcpdump para recopilar más información:
- Si eres un usuario de nube privada, puedes recopilar los datos de
tcpdump
en el servidor o cliente relevante. Un cliente puede ser la app del cliente (para conexiones entrantes o hacia el norte) o el procesador de mensajes (para conexiones salientes o hacia el sur). Un servidor puede ser el router perimetral (para conexiones entrantes o salientes), o el servidor backend (para conexiones salientes o hacia el sur), según tu determinación del paso 1. - Si eres un usuario de Cloud público, puedes recopilar los datos de
tcpdump
solo en la app cliente (para conexiones entrantes o hacia el norte) o el servidor de backend (para conexiones salientes o 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 comandotcpdump
. - Si eres un usuario de nube privada, puedes recopilar los datos de
- Analiza los datos de
tcpdump
con la herramienta Wireshark o cualquier otra herramienta que conozcas. - Este es el análisis del ejemplo del resultado
tcpdump
con Wireshark:- En este ejemplo, el error de protocolo de enlace TLS/SSL se produjo entre la aplicación cliente y el router perimetral (conexión norte). El resultado de
tcpdump
se recopiló en el router de Edge. El mensaje n.o 4 en el resultado de
tcpdump
a continuación muestra que la aplicación cliente (fuente) envió un mensaje “Client Hello” al router perimetral (destino).Si seleccionas el mensaje Hello Client, se muestra que la aplicación cliente usa el protocolo TLSv1.2.
- En el mensaje 5, se muestra que el router perimetral reconoce el mensaje “Client Hello” de la aplicación cliente.
- El router perimetral envía de inmediato una alerta irrecuperable : error de protocolo de enlace a la aplicación cliente (mensaje n.o 6). Esto significa que falló el protocolo de enlace TLS/SSL y se cerrará la conexión.
- Si buscas en el mensaje 6, se mostrará 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 envía la Alerta fatal: error de protocolo de enlace a la aplicación cliente como se muestra en la siguiente captura de pantalla:
- El error puede 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 el router perimetral.
- El router perimetral está habilitado para SNI, pero la aplicación cliente no envía el nombre del servidor.
- En el mensaje 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 de 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, el router perimetral solo admite los algoritmos del conjunto de algoritmos de cifrado de alta encriptación. - La aplicación cliente no utiliza ninguno de los algoritmos del paquete de encriptación alta. 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 envíe el nombre del servidor correctamente, como se muestra en la siguiente figura:
- Si este nombre es válido, puedes inferir que la falla de 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.
- En este ejemplo, el error de protocolo de enlace TLS/SSL se produjo entre la aplicación cliente y el router perimetral (conexión norte). El resultado de
Resolución
Debes asegurarte de que el cliente use los algoritmos del conjunto de algoritmos de cifrado compatibles con el servidor. Para resolver el problema descrito en la sección Diagnóstico anterior, descarga e instala el paquete 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
Una falla de protocolo de enlace TLS/SSL se produce 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 límite norte) o saliente (con dirección sur) en Apigee Edge. También consulta Información sobre las conexiones con dirección norte y sur.
Si el problema es northbound, es posible que veas diferentes mensajes de error según la causa subyacente.
En las siguientes secciones, se muestran mensajes de error de ejemplo 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 ejemplo que puedes 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 seguir los pasos para solucionar problemas |
El nombre de host no coincide |
El nombre de host que se usa en la URL y el certificado en el almacén de claves del router no coincide. Por ejemplo, se produce una discrepancia si el nombre de host que se usa 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 privada y pública 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 privada y pública de Edge |
Certificado desconocido o vencido que envió el servidor o el cliente | El servidor o el cliente envían un certificado vencido o desconocido en el límite norte o en la conexión sur. | Usuarios de la nube privada perimetral y de la nube pública perimetral |
El nombre de host no coincide
Diagnóstico
- Ten en cuenta el nombre de host que se usa en la URL que muestra 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
- Obtén la CN que se usa en el certificado almacenado en el almacén de claves específico. Puedes usar las siguientes API de administración de Edge para obtener los detalles del certificado:
-
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
-
Obtén los detalles del certificado en el almacén de claves con la API de administración de Edge.
Si eres un usuario de la nube privada:
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:
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 la CN como
something.domain.com.
.Debido a que el nombre de host que se usa en la URL de solicitud a la API (consulta el paso 1 más arriba) y el nombre del asunto en el certificado no coinciden, se mostrará la falla de protocolo de enlace TLS/SSL.
-
Obtén el nombre del certificado en el almacén de claves:
Resolución
Este problema se puede resolver de una de las siguientes maneras:
- Obtener un certificado (si aún no tienes uno) donde la CN en cuestión tenga un certificado comodín y, luego, subir 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) con un asunto de CN 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
- Obtén la CN que se usa en el certificado almacenado en el almacén de claves específico. Puedes usar las siguientes API de administración de Edge para obtener los detalles del certificado:
-
Obtén el nombre del certificado en el almacén de claves:
Si eres un usuario de la nube privada:
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:
curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
-
Obtén los detalles del certificado en el almacén de claves:
Si eres un usuario de la nube privada:
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:
curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
- Valida el certificado y su cadena, y confirma que cumpla con los lineamientos que se proporcionan en el artículo Cómo funcionan las cadenas de certificados para asegurarte de que sea una cadena de certificados completa y válida. Si la cadena de certificados almacenada en el almacén de claves está incompleta o no es válida, verás la falla de protocolo de enlace TLS/SSL.
- 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 de raíz de muestra en el que la entidad emisora y el asunto no coinciden
-
Obtén el nombre del certificado en el almacén de claves:
Resolución
- Obtén un certificado (si aún no tienes uno) que incluya una cadena de certificados completa y válida.
- 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
- Sube la cadena de certificados validada al almacén de claves.
El servidor o cliente envió un certificado vencido o desconocido
Si el servidor o el cliente envían un certificado incorrecto o vencido en el límite norte o en la conexión sur, el otro extremo (servidor/cliente) rechaza el certificado y genera una falla de protocolo de enlace TLS/SSL.
Diagnóstico
- Determina si el error ocurrió en la conexión northbound o southbound. Si deseas obtener más información para tomar esta determinación, consulta Cómo determinar la fuente del problema.
- Ejecuta la herramienta
tcpdump para recopilar más información:
- Si eres un usuario de nube privada, puedes recopilar los datos de
tcpdump
en el servidor o cliente relevante. Un cliente puede ser la app del cliente (para conexiones entrantes o hacia el norte) o el procesador de mensajes (para conexiones salientes o hacia el sur). Un servidor puede ser el router perimetral (para conexiones entrantes o salientes), o el servidor backend (para conexiones salientes o hacia el sur), según tu determinación del paso 1. - Si eres un usuario de Cloud público, puedes recopilar los datos de
tcpdump
solo en la app cliente (para conexiones entrantes o hacia el norte) o el servidor de backend (para conexiones salientes o 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 comandotcpdump
. - Si eres un usuario de nube privada, puedes recopilar los datos de
- Analiza los datos de
tcpdump
con Wireshark o una herramienta similar. - A partir del resultado de
tcpdump
, determina el host (cliente o servidor) que rechaza el certificado durante el paso de verificación. - Puedes recuperar el certificado enviado desde el otro extremo del resultado de
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 confianza. - Revisa la muestra
tcpdump
para la comunicación SSL entre el procesador de mensajes y el servidor de backend.Ejemplo
tcpdump
con error desconocido en el certificado
- El procesador de mensajes (cliente) envía “Client Hello” al cliente de backend (servidor) en el mensaje n.o 59.
- El servidor de backend envía "Server Hello" al procesador de mensajes en el mensaje n.o 61.
- Validan mutuamente el algoritmo y los algoritmos del conjunto de algoritmos de cifrado que se usan.
- El servidor de backend envía el certificado y el mensaje Hello Done del servidor al Message Processor en el mensaje #68.
- El Procesador de Mensajes envía la Alerta Fatal "Descripción: Certificado Desconocido" en el mensaje n.o 70.
- Si buscas en el mensaje 70, no hay detalles adicionales, además del mensaje de alerta, como se muestra a continuación:
- Revisa el mensaje n.o 68 para obtener los detalles del certificado que envió el servidor de backend, como se muestra en el siguiente gráfico:
- 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.
- Si el router (con el norte) o el procesador de mensajes (con dirección sur) desconocen el certificado, como se muestra en el ejemplo anterior, sigue estos pasos:
- Obtenga el certificado y su cadena que está almacenado en el almacén de confianza específico. (Consulta la configuración del host virtual para el router y la configuración del extremo de destino para el procesador de mensajes). Puedes usar las siguientes API para obtener los detalles del certificado:
-
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
-
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
-
Obtén el nombre del certificado en el almacén de confianza:
- Verifica si el certificado almacenado en el almacén de confianza del router (con el norte) o del procesador de mensajes (con dirección sur) coincide con el certificado almacenado en el almacén de claves de la aplicación cliente (con dirección norte) o con el servidor de destino (con dirección sur), o con el que se obtiene del resultado
tcpdump
. Si no hay coincidencia, esa es la causa de la falla del protocolo de enlace TLS/SSL.
- Obtenga el certificado y su cadena que está almacenado en el almacén de confianza específico. (Consulta la configuración del host virtual para el router y la configuración del extremo de destino para el procesador de mensajes). Puedes usar las siguientes API para obtener los detalles del certificado:
- Si la aplicación cliente (con el norte) o el servidor de destino (con dirección sur) desconocen el certificado, sigue estos pasos:
- 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 router y la configuración del extremo de destino para el procesador de mensajes). Puedes usar las siguientes API para obtener los detalles del certificado:
-
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
-
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
-
Obtén el nombre del certificado en el almacén de claves:
- Verifica si el certificado almacenado en el almacén de claves del router (con el norte) o del procesador de mensajes (con dirección sur) coincide con el certificado almacenado en el almacén de confianza de la aplicación del cliente (con dirección norte) o con el servidor de destino (con dirección 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.
- 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 router y la configuración del extremo de destino para el procesador de mensajes). Puedes usar las siguientes API para obtener los detalles del certificado:
- Si se determina que el certificado que envió un servidor o cliente está vencido, el cliente o servidor receptor lo rechaza y aparece el siguiente mensaje de alerta en
tcpdump
:Alerta (nivel: Fatal, Descripción: Certificado vencido)
- Verifica que el certificado del almacén de claves del host correspondiente esté vencido.
Resolución
Para resolver el problema identificado en el ejemplo anterior, sube el certificado válido del servidor de backend al trustore en Message Processor.
En la siguiente tabla, se resumen los pasos para resolverlo según la causa.
Causa | Descripción | Solución |
Certificado vencido |
NorthBound
|
Sube un certificado nuevo y su cadena completa al almacén de claves en el host correspondiente. |
SouthBound
|
Sube un certificado nuevo y su cadena completa al almacén de claves en el host correspondiente. | |
Certificado desconocido |
NorthBound
|
Sube el certificado válido al almacén de confianza en el host correspondiente. |
SouthBound
|
Sube el certificado válido al almacén de confianza en el host correspondiente. |
SNI Enabled
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 está habilitado. Esto puede ocurrir en el límite norte o en la conexión sur del perímetro.
Primero, debes identificar el nombre de host y el número de puerto del servidor que se usa y verificar si está habilitado o no.
Identificación del servidor habilitado para la SNI
- Ejecuta el comando
openssl
y, luego, intenta conectarte al nombre de host relevante del servidor (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 que, 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
- Ejecuta el comando
openssl
y trata de conectarte al nombre de host del servidor pertinente (router perimetral o servidor de backend). Para ello, pasa el nombre del servidor, como se muestra a continuación:openssl s_client -connect hostname:port -servername hostname
- Si se produce un error de protocolo de enlace en el paso 1 o se obtienen certificados diferentes en los pasos 1 y 2, entonces se indica que el servidor especificado está habilitado para SNI.
Una vez que hayas identificado que el servidor está habilitado para SNI, puedes seguir los pasos que se indican a continuación para verificar si el error de protocolo de enlace TLS/SSL se debe a que el cliente no puede comunicarse con el servidor de SNI.
Diagnóstico
- Determina si el error ocurrió en la conexión northbound o southbound. Si deseas obtener más información para tomar esta determinación, consulta Cómo determinar la fuente del problema.
- Ejecuta la herramienta
tcpdump para recopilar más información:
- Si eres un usuario de nube privada, puedes recopilar los datos de
tcpdump
en el servidor o cliente relevante. Un cliente puede ser la app del cliente (para conexiones entrantes o hacia el norte) o el procesador de mensajes (para conexiones salientes o hacia el sur). Un servidor puede ser el router perimetral (para conexiones entrantes o salientes), o el servidor backend (para conexiones salientes o hacia el sur), según tu determinación del paso 1. - Si eres un usuario de Cloud público, puedes recopilar los datos de
tcpdump
solo en la app cliente (para conexiones entrantes o hacia el norte) o el servidor de backend (para conexiones salientes o 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 comandotcpdump
. - Si eres un usuario de nube privada, puedes recopilar los datos de
- Analiza el resultado de
tcpdump
con Wireshark o una herramienta similar. - Este es el análisis de muestra de
tcpdump
con Wireshark:- En este ejemplo, se produjo una falla en el protocolo de enlace TLS/SSL entre el procesador de mensajes perimetrales y el servidor de backend (conexión hacia el sur).
- El mensaje n.o 4 del resultado de
tcpdump
a continuación muestra que Message Processor (fuente) envió un mensaje “Client Hello” al servidor de backend (destino). - Si seleccionas el mensaje "Client Hello", se muestra que Message Processor usa el protocolo TLSv1.2.
- El mensaje n.o 4 muestra que el servidor de backend reconoce el mensaje “Client Hello” de Message Processor.
- El servidor de backend envía de inmediato una Alerta fatal : error de protocolo de enlace al procesador de mensajes (mensaje n.o 5). Esto significa que falló el protocolo de enlace TLS/SSL y se cerrará la conexión.
- Revisa el mensaje 6 para descubrir la siguiente información:
- El servidor de backend admite el protocolo TLSv1.2. Esto significa que el protocolo coincidió entre Message Processor y el servidor de backend.
- Sin embargo, el servidor de backend todavía envía la Alerta fatal: Error de protocolo de enlace al procesador de mensajes como se muestra en la siguiente figura:
- Este error puede deberse a uno de los siguientes motivos:
- El procesador de mensajes no usa los algoritmos del conjunto de algoritmos de cifrado compatibles con el servidor backend.
- El servidor de backend tiene SNI habilitado, pero la aplicación cliente no envía el nombre del servidor.
- Revisa el mensaje 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: - Esto confirma que Message Processor no envió el server_name al servidor de backend con SNI habilitado.
- 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: error de protocolo de enlace al procesador de mensajes.
- Verifica que
jsse.enableSNIExtension property
ensystem.properties
esté configurado como falso en Message Processor a fin de confirmar que Message Processor no esté habilitado para comunicarse con el servidor habilitado para SNI.
Resolución
Habilita los Message Processor para comunicarse con los servidores habilitados para SNI. Para ello, sigue estos pasos:
- Crea el archivo
/opt/apigee/customer/application/message-processor.properties
(si todavía no existe). - Agrega la siguiente línea a este archivo:
conf_system_jsse.enableSNIExtension=true
- Se asignó el propietario de este archivo a
apigee:apigee
:chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
- Reinicia el procesador de mensajes.
/opt/apigee/apigee-service/bin/apigee-service message-processor restart
- Si tienes más de un procesador de mensajes, repite los pasos n.o 1 a n.o 4 en todos ellos.
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 sobre el problema junto con el resultado de tcpdump
.