Estás viendo la documentación de Apigee Edge.
Ve a la
Documentación de Apigee X. información
Síntoma
Una falla del protocolo de enlace TLS/SSL ocurre cuando un cliente y un servidor no pueden establecer comunicación usando el protocolo TLS/SSL. Cuando se produce este error en Apigee Edge, el cliente recibe el estado HTTP 503 con el mensaje Servicio no disponible. Tú verás este error después de cualquier llamada a la API en la que se produzca un error 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 del 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 aplicación Un protocolo de enlace es un proceso que permite que el cliente y el servidor TLS/SSL establezcan un conjunto de secretos con las que pueden comunicarse. Durante este proceso, el cliente y el servidor hacen lo siguiente:
- Acepta la versión del protocolo que usarás.
- Selecciona el algoritmo criptográfico que deseas usar.
- Se autentican mutuamente a través del intercambio y la validación de certificados digitales.
Si el protocolo de enlace TLS/SSL se ejecuta correctamente, el servidor y el cliente TLS/SSL transfieren los datos a cada uno de ellos.
de forma segura. De lo contrario, si se produce una falla del protocolo de enlace TLS/SSL, la conexión finaliza y el cliente
recibe un error 503 Service Unavailable
.
Estas son las posibles causas de fallas del protocolo de enlace TLS/SSL:
Causa | Descripción | Quién puede realizar los pasos para solucionar problemas |
---|---|---|
Inconsistencia de protocolo | El protocolo que usa el cliente no es compatible con el servidor. | Usuarios de nubes privadas y públicas |
Discrepancia en el paquete de cifrado | El conjunto de algoritmos de cifrado utilizado por el cliente no es compatible con el servidor. | Usuarios de nubes privadas y públicas |
Certificado incorrecto | El nombre de host en la URL que usa el cliente no coincide con el nombre de host en el certificado se almacenan en el extremo del servidor. | Usuarios de nubes privadas y públicas |
Una cadena de certificados incompleta o no válida se almacena en el extremo del cliente o del servidor. | Usuarios de nubes privadas y públicas | |
El cliente envía un certificado incorrecto o vencido al servidor o desde este. al cliente. | Usuarios de nubes privadas y públicas | |
Servidor con SNI habilitada | El servidor de backend tiene habilitada la indicación de nombre del servidor (SNI). Sin embargo, el cliente no puede comunicarse servidores SNI. | Solo usuarios de la nube privada |
Protocolo Discrepancias
Si el protocolo utilizado por el cliente no admite el protocolo de enlace TLS/SSL, se produce un fallo en el protocolo de enlace TLS/SSL. en la conexión entrante (límite norte) o saliente (dirección sur). Consulta también Comprender las conexiones hacia el norte y el sur.
Diagnóstico
- Determina si el error ocurrió en el límite norte o hacia el sur. Para obtener más orientación determinación, consulta Determinar el origen del problema.
- Ejecuta el
tcpdump para recopilar más información:
- Si eres un usuario de la nube privada, puedes recopilar los
tcpdump
en el cliente o servidor relevante. Un cliente puede ser la app cliente (para entradas, o conexiones con el norte), o el mensaje Procesador (para conexiones salientes o hacia el sur). Un servidor puede ser el router perimetral (para conexiones entrantes o hacia el norte) o el servidor de backend (para conexiones salientes o hacia el sur) según tu determinación del Paso 1. - Si eres usuario de la nube pública, puedes recopilar los
tcpdump
datos 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), porque acceso al router perimetral o al procesador de mensajes.
tcpdump -i any -s 0 host IP address -w File name
Consulta tcpdump para obtener más información sobre el uso detcpdump
kubectl. - Si eres un usuario de la nube privada, puedes recopilar los
- Analiza los datos de
tcpdump
con la herramienta Wireshark. o una herramienta similar. - Este es un ejemplo de análisis del
tcpdump con Wireshark:
- En este ejemplo, el fallo del protocolo de enlace TLS/SSL se produjo entre Message Processor y el servidor de backend (la conexión saliente o hacia el sur).
- El mensaje n.o 4 del resultado
tcpdump
a continuación muestra que el Message Processor (fuente) envió un "Hola del cliente" al servidor de backend (Destino).
Si seleccionas el mensaje
Client Hello
, se mostrará que Message Processor está usando el TLSv1.2, como se muestra a continuación:- El mensaje n.o 5 muestra que el servidor de backend confirma la recepción del "Cliente Hello" mensaje de Message Processor.
- El servidor de backend envía inmediatamente Fatal Alert : Close Notificar al Message Processor (mensaje no 6). Esto significa que el protocolo de enlace TLS/SSL falló y la conexión esté cerrado.
Si observamos en 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 y el servidor de backend solo admite el protocolo TLSv1.0, como se muestra a continuación:
- Debido a que existe una discrepancia entre el protocolo que usa el Message Processor y el servidor de backend, el servidor de backend envió el mensaje: Fatal Alert Message: Close Notificar.
Solución
Message Processor se ejecuta en Java 8 y usa el protocolo TLSv1.2 de forma predeterminada. Si el backend el servidor no admite el protocolo TLSv1.2, puedes realizar uno de estos pasos para resolver este problema:
- 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.
- Si, por algún motivo, no puedes actualizar tu servidor de backend de inmediato, puedes
obligar al procesador de mensajes a usar el protocolo TLSv1.0 para comunicarse
el servidor de backend siguiendo estos pasos:
- Si no especificó un servidor de destino en la definición de TargetEndpoint del proxy, establezca
el elemento
Protocol
enTLSv1.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 de destino para tu proxy, usa esta API de administración para establecer el protocolo en TLSv1.0 en la configuración del servidor de destino.
- Si no especificó un servidor de destino en la definición de TargetEndpoint del proxy, establezca
el elemento
Discrepancias en el disco
Puedes ver una falla del protocolo de enlace TLS/SSL si el algoritmo del conjunto de algoritmos de cifrado utilizado por el cliente no es que admite el servidor en la conexión entrante (límite norte) o saliente (dirección sur) en Apigee Edge. Consulta también Comprender las conexiones hacia el norte y el sur.
Diagnóstico
- 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 Determinación la fuente del problema.
- Ejecuta el
tcpdump para recopilar más información:
- Si eres un usuario de la nube privada, puedes recopilar los
tcpdump
en el cliente o servidor relevante. Un cliente puede ser la app cliente (para entradas, o conexiones con el norte), o el mensaje Procesador (para conexiones salientes o hacia el sur). Un servidor puede ser el router perimetral (para conexiones entrantes o hacia el norte) o el servidor de backend (para conexiones salientes o hacia el sur) según tu determinación del Paso 1. - Si eres usuario de la nube pública, puedes recopilar los
tcpdump
datos 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), porque acceso al router perimetral o al procesador de mensajes.
tcpdump -i any -s 0 host IP address -w File name
Consulta tcpdump para obtener más información sobre cómo usar el comandotcpdump
. - Si eres un usuario de la nube privada, puedes recopilar los
- Analiza los datos de
tcpdump
con la herramienta Wireshark. o cualquier otra herramienta que conozcas. - Este es un 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
Router perimetral (conexión hacia el norte). El resultado de
tcpdump
se recopiló en Edge router. El mensaje n.o 4 del resultado de
tcpdump
a continuación muestra que la aplicación cliente (origen) envió un "Hola del cliente" al router perimetral (destino).Si seleccionas el mensaje Client Hello, verás que la aplicación cliente está usando el TLSv1.2.
- El mensaje n.o 5 muestra que el router perimetral confirma la recepción del "Hola del cliente". mensaje de la aplicación cliente.
- El router perimetral envía de inmediato una Alerta fatal : Error de protocolo de enlace a la aplicación cliente (mensaje n.o 6). Esto significa que el protocolo de enlace TLS/SSL falló y la conexión se cerrará.
- Si observas con más detalle el mensaje 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 sigue enviando la Alerta fatal: Protocolo de enlace. Error en 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 está usando los algoritmos de conjuntos de algoritmos de cifrado admitidos por la Router perimetral.
- El router perimetral está habilitado para SNI, pero la aplicación cliente no está enviando el el nombre del servidor.
- El mensaje n.o 4 del resultado de
tcpdump
enumera los algoritmos del conjunto de algoritmos de cifrado compatibles con el cliente. de la aplicación, como se muestra a continuación: - La lista de algoritmos de conjuntos de algoritmos de cifrado que admite el router perimetral se encuentra en el
/opt/nginx/conf.d/0-default.conf
. En este ejemplo, el router perimetral solo admite algoritmos de conjuntos de cifrado de alta encriptación. - La aplicación cliente no utiliza ninguno de los algoritmos del conjunto de algoritmos de cifrado de alta encriptación. Esa 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 no 4 en el resultado de
tcpdump
y confirmar que la aplicación cliente está enviando el nombre del servidor correctamente, como se muestra en el figura a continuación:
- Si este nombre es válido, puedes inferir que falla 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.
- En este ejemplo, la falla del protocolo de enlace TLS/SSL se produjo entre la aplicación cliente y
Router perimetral (conexión hacia el norte). El resultado de
Solución
Debes asegurarte de que el cliente use los algoritmos del conjunto de algoritmos de cifrado que compatibles con el servidor. Para resolver el problema descrito en el Diagnóstico, descargue e instale la Java Cryptography Extension (JCE) y, luego, inclúyelo en Java para admitir algoritmos de cifrado de alta encriptación.
Certificado incorrecto
Si tienes certificados incorrectos en el almacén de claves o en el almacén de confianza, se produce una falla del protocolo de enlace TLS/SSL. ya sea en la conexión entrante (hacia el norte) o saliente (hacia el sur) en Apigee Edge. Consulta también Comprender las conexiones hacia el norte y el sur.
Si el problema está de dirección 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 diagnosticarlo y resolverlos 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 ejemplo de mensaje de error 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 realizar los pasos para solucionar problemas |
Discrepancia en el nombre de host |
El nombre de host que se usa en la URL y el certificado del almacén de claves del router no
la coincidencia. 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 perimetrales de nubes privadas y públicas |
Certificado incompleto o incorrecto cadena | La cadena de certificados no está completa o no es correcta. | Solo usuarios de nubes públicas y privadas del perímetro |
Certificado vencido o desconocido enviado por el servidor o cliente | El servidor o el cliente envía un certificado vencido o desconocido, ya sea en el sentido norte o en la conexión hacia el sur. | Usuarios de la nube privada perimetral y de la nube pública perimetral |
Nombre de host Discrepancias
Diagnóstico
- Ten en cuenta el 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
- Obtén el CN que se usa en el certificado almacenado en el almacén de claves específico. Puedes usar la
siguientes APIs 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 mediante la API de Edge Management.
Si eres un usuario de la nube privada, ten en cuenta 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:
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 asunto en el certificado principal tiene el CN como
something.domain.com.
Porque el nombre de host utilizado en la URL de solicitud de la API (consulta el paso 1 más arriba) y el asunto en el certificado no coinciden, se produce la falla del protocolo de enlace TLS/SSL.
-
Obtén el nombre del certificado en el almacén de claves:
Solución
Este problema se puede resolver de una de las dos maneras siguientes:
- Obtén un certificado (si aún no tienes uno) en el que el sujeto CN tenga un 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 existente de la materia, pero utiliza your-orgyour-domain como nombre alternativo del asunto y, luego, sube el archivo al almacén de claves.
Referencias
almacenes de claves y Truststores
Cadena de certificados incompleta o incorrecta
Diagnóstico
- Obtén el CN que se usa en el certificado almacenado en el almacén de claves específico. Puedes usar la
siguientes APIs 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 usuario de la nube pública, ten en cuenta lo siguiente:
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 usuario de la nube pública, ten en cuenta lo siguiente:
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 verifica que cumpla con los requisitos de las pautas proporcionadas en el artículo Cómo funcionan las cadenas de certificados para garantizar que sean válidas y estén completas de la cadena de certificados. Si la cadena de certificados almacenada en el almacén de claves incompleto o inválido, entonces ves el protocolo de enlace TLS/SSL. falla.
- El siguiente gráfico muestra un certificado de muestra con una cadena de certificados no válida, donde los certificados intermedios y raíz no coinciden:
Ejemplo de certificado intermedio y raíz en el que la entidad emisora y El asunto no coincide.
-
Obtén el nombre del certificado en el almacén de claves:
Solución
- Obtén un certificado (si aún no tienes uno) que incluya una versión completa y de la cadena de certificados.
- Ejecuta el siguiente comando openssl para verificar que la cadena de certificados sea correcta y
completa:
openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert
- Sube la cadena de certificados validada al almacén de claves.
Vencida o desconocida certificado enviado por el servidor o el cliente
Si el servidor o cliente envía un certificado incorrecto o vencido, ya sea en el sentido norte o en la conexión hacia el sur, el otro extremo (servidor o cliente) rechaza el certificado lo que provoca una falla del protocolo de enlace TLS/SSL.
Diagnóstico
- Determina si el error ocurrió en el límite norte o hacia el sur. Para obtener más orientación determinación, consulta Determinar el origen del problema.
- Ejecuta el
tcpdump para recopilar más información:
- Si eres un usuario de la nube privada, puedes recopilar los
tcpdump
en el cliente o servidor relevante. Un cliente puede ser la app cliente (para entradas, o conexiones con el norte), o el mensaje Procesador (para conexiones salientes o hacia el sur). Un servidor puede ser el router perimetral (para conexiones entrantes o hacia el norte) o el servidor de backend (para conexiones salientes o hacia el sur) según tu determinación del Paso 1. - Si eres usuario de la nube pública, puedes recopilar los
tcpdump
datos 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), porque acceso al router perimetral o al procesador de mensajes.
tcpdump -i any -s 0 host IP address -w File name
Consulta tcpdump para obtener más información sobre cómo usar el comandotcpdump
. - Si eres un usuario de la nube privada, puedes recopilar los
- Analiza los datos de
tcpdump
con Wireshark o un 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 desde el resultado
tcpdump
, siempre y cuando 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 el
tcpdump
de muestra para la comunicación SSL entre Message Processor y el servidor de backend.Ejemplo de
tcpdump
que muestra un error de certificado desconocido
- El Message Processor (cliente) envía un mensaje de bienvenida al cliente (Client Hello). al servidor de backend (servidor) en el mensaje n.o 59.
- El servidor de backend envía “Server Hello” al Message Processor en los mensajes N.o 61:
- Estos validan mutuamente los algoritmos del protocolo y del conjunto de cifrado que se usaron.
- El servidor backend envía el certificado y el mensaje “Hello Done” del servidor al Message Processor en el mensaje n.o 68.
- El procesador de mensajes envía la alerta fatal "Description: Certificate Desconocido" en el mensaje n.o 70.
- Si analizamos el mensaje n.o 70 y no hay detalles adicionales,
que un mensaje de alerta, como se muestra a continuación:
- Revisa el mensaje 68 para obtener los detalles sobre el certificado que envió el backend
como se muestra en el siguiente gráfico:
- El certificado del servidor de backend y su cadena completa están disponibles debajo de la sección “Certificados” como se muestra en la imagen anterior.
- Si el router determina que el certificado es desconocido (límite norte) o al
Message Processor (dirección sur) como en el ejemplo anterior y, luego, sigue estas
pasos:
- Obtén el certificado y su cadena que se almacenan en el almacén de confianza específico. (Consulta
a la configuración del host virtual para el router y la configuración del extremo de destino
el Message Processor). Puedes usar las siguientes APIs para obtener los detalles de la
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 (de destino norte) o
Message Processor (dirección sur) coincide con el certificado almacenado en la
de la aplicación cliente (límite norte), servidor de destino (dirección sur), o bien el
uno que se obtiene de la salida
tcpdump
. Si hay una discrepancia, esa es la causa de la falla del protocolo de enlace TLS/SSL.
- Obtén el certificado y su cadena que se almacenan en el almacén de confianza específico. (Consulta
a la configuración del host virtual para el router y la configuración del extremo de destino
el Message Processor). Puedes usar las siguientes APIs para obtener los detalles de la
certificado:
- Si la aplicación cliente descubre que el certificado es desconocido (límite norte)
o el servidor de destino (hacia el sur), luego sigue estos pasos:
- Obtén la cadena de certificados completa que se usa en el certificado almacenado en la
el almacén de claves. (Consulta la configuración del host virtual para el router y el extremo de destino
del procesador de mensajes). Puedes usar las siguientes APIs para obtener
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 (límite norte) o
Message Processor (southbound) coincide con el certificado almacenado en el almacén de confianza del
la aplicación cliente (hacia el norte) o el servidor de destino (hacia el sur), o el servidor que se
que se obtiene de la salida
tcpdump
Si no hay coincidencia, entonces esa es la causa del falla del protocolo de enlace.
- Obtén la cadena de certificados completa que se usa en el certificado almacenado en la
el almacén de claves. (Consulta la configuración del host virtual para el router y el extremo de destino
del procesador de mensajes). Puedes usar las siguientes APIs para obtener
detalles del certificado:
- Si se descubre que el certificado enviado por un servidor o cliente está vencido, el destinatario
cliente/servidor rechaza el certificado, y se muestra el siguiente mensaje de alerta en la
tcpdump
:Alerta (nivel: Fatal, descripción: certificado vencido)
- Verifica que el certificado del almacén de claves del host correspondiente haya vencido.
Solución
Para resolver el problema identificado en el ejemplo anterior, sube el ID del servidor de certificado a la trustore en el Message Processor.
En la siguiente tabla, se resumen los pasos para resolver el problema según la causa problema.
Causa | Descripción | Solución |
Certificado vencido |
NorthBound
|
Sube un nuevo certificado y su cadena completa al almacén de claves en el host. |
SouthBound
|
Sube un nuevo certificado y su cadena completa al almacén de claves en el host. | |
Certificado desconocido |
NorthBound
|
Sube el certificado válido al almacén de confianza en el host adecuado. |
SouthBound
|
Sube el certificado válido al almacén de confianza en el host adecuado. |
SNI habilitada Servidor
La falla del protocolo de enlace TLS/SSL puede ocurrir cuando el cliente se comunica con un servidor Indicación de nombre (SNI) habilitada Servidor, pero el cliente no tiene habilitada la SNI. Esto puede ocurrir ya sea en el sentido norte o en el conexión hacia el sur en Edge.
Primero, debes identificar el nombre de host y el número de puerto del servidor que se usa y verificar si está habilitada para SNI o no.
Identificación del servidor habilitado para SNI
- Ejecuta el comando
openssl
y, luego, intenta conectarte al nombre de host del servidor relevante (Edge) router o servidor de backend) sin pasar el nombre del servidor, como se muestra a continuación:openssl s_client -connect hostname:port
Puedes obtener los certificados y, a veces, observar 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, luego, intenta conectarte con el nombre de host del servidor correspondiente. (router perimetral o servidor de backend) 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 u se obtienen certificados diferentes en el paso 1 y paso 2, indicará que el servidor especificado está habilitado para SNI.
Cuando hayas identificado que el servidor está habilitado para SNI, puedes seguir los pasos que se indican a continuación para comprobar si la falla del protocolo de enlace TLS/SSL se debe a que el cliente no puede comunicarse el servidor de SNI.
Diagnóstico
- Determina si el error ocurrió en el límite norte o hacia el sur. Para obtener más orientación determinación, consulta Determinar el origen del problema.
- Ejecuta el
tcpdump para recopilar más información:
- Si eres un usuario de la nube privada, puedes recopilar los
tcpdump
en el cliente o servidor relevante. Un cliente puede ser la app cliente (para entradas, o conexiones con el norte), o el mensaje Procesador (para conexiones salientes o hacia el sur). Un servidor puede ser el router perimetral (para conexiones entrantes o hacia el norte) o el servidor de backend (para conexiones salientes o hacia el sur) según tu determinación del Paso 1. - Si eres usuario de la nube pública, puedes recopilar los
tcpdump
datos 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), porque acceso al router perimetral o al procesador de mensajes.
tcpdump -i any -s 0 host IP address -w File name
Consulta tcpdump para obtener más información sobre cómo usar el comandotcpdump
. - Si eres un usuario de la nube privada, puedes recopilar los
- Analiza el resultado de
tcpdump
con Wireshark o un herramienta similar. - Este es un análisis de muestra de
tcpdump
con Wireshark:- En este ejemplo, se produjo un error de protocolo de enlace TLS/SSL entre el mensaje perimetral Procesador y servidor de backend (conexión hacia el sur).
- En el mensaje n.o 4 del resultado
tcpdump
a continuación, se muestra que Message Processor (fuente) envió un mensaje de bienvenida para los clientes al servidor de backend (destino). - Selección del “Hola del cliente” muestra que el elemento Message
El procesador usa el protocolo TLSv1.2.
- El mensaje n.o 4 muestra que el servidor backend confirma la recepción del mensaje "Client Hello" mensaje de Message Processor.
- El servidor backend envía inmediatamente una Alerta fatal : Protocolo de enlace Error en el procesador de mensajes (mensaje n.o 5). Esto significa que el protocolo de enlace TLS/SSL falló y la conexión se cerrará.
- Revisa el mensaje 6 para descubrir la siguiente información
- El servidor de backend admite el protocolo TLSv1.2. Esto significa que el protocolo coincide entre el Message Processor y el servidor backend.
- Sin embargo, el servidor backend sigue enviando la Alerta fatal: Protocolo de enlace
Error en el Message Processor, como se muestra en la siguiente figura:
- Este error puede deberse a alguno de los siguientes motivos:
- Message Processor no está usando los algoritmos del conjunto de algoritmos de cifrado compatibles con servidor de backend.
- El servidor backend está habilitado para SNI, pero la aplicación cliente no está enviando el nombre del servidor.
- Revisa con más detalle el mensaje n.o 3 (Hola al cliente) en el resultado de
tcpdump
. Ten en cuenta que Falta la extensión: server_name, como se muestra a continuación: - Esto confirma que el Message Processor no envió el server_name al servidor de backend habilitado para SNI
- Esta es la causa del fallo del protocolo de enlace TLS/SSL y la razón por la que el backend el servidor envía la Alerta fatal: Error de protocolo de enlace al mensaje Procesador.
- Verifica que el
jsse.enableSNIExtension property
ensystem.properties
se configura como falso en el procesador de mensajes para confirmar que el El procesador de mensajes no está habilitado para comunicarse con el servidor habilitado para SNI.
Solución
Permite que los procesadores de mensajes se comuniquen con los servidores habilitados para SNI a través de la los siguientes pasos:
- Crea el
/opt/apigee/customer/application/message-processor.properties
(si aún no existe). - Agrega la siguiente línea a este archivo:
conf_system_jsse.enableSNIExtension=true
- Asigna 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 del 1 al 4 en todos los Procesadores de mensajes.
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
Asistencia de Apigee Edge. Comparte los detalles completos sobre el problema junto con
el resultado de tcpdump