Solucionar un error de protocolo de enlace SSL de Kopano en un puerto personalizado

Defina cómo se ve una solución exitosa.

Un error de protocolo de enlace SSL de Kopano indica que el cliente y el servidor no pudieron establecer o completar la conexión TLS. El puerto personalizado puede ser correcto para una parte de la configuración, pero incorrecto para otra. Antes de modificar los certificados o la configuración del protocolo, identifique qué servicio es el propietario del puerto y si se espera TLS en él.

Para una configuración funcional, el puerto previsto acepta una conexión TLS, presenta un certificado válido para el nombre de host que utilizan los clientes y permite que se complete el siguiente paso del protocolo. Un navegador debería acceder a la página de inicio de sesión de la aplicación web sin ninguna advertencia de certificado. Un cliente de Kopano Core debería conectarse utilizando el puerto TLS correspondiente y, si está configurado, su certificado de cliente de confianza. Una comprobación TLS exitosa por sí sola no demuestra que el inicio de sesión en la aplicación web, la autenticación de Kopano o la entrega de correo electrónico funcionen correctamente.

Primero, separe las dos configuraciones de puerto comunes.

Verificado para Kopano Core: El manual del administrador de Kopano Core 8.0 describe un oyente TLS nativo controlado por server_listen_tls. Su ejemplo usa el puerto 237, dice que el puerto se puede cambiar y configura los archivos de certificado y CA en /etc/kopano/server.cfg. El manual también muestra a los clientes usando un https://socket de servidor con el puerto y certificado de cliente coincidentes. Consulte Kopano Core: Conexiones y certificados SSL y Configuraciones especiales de Kopano Core .

Por separado, para el acceso a WebApp: los usuarios normalmente abren una URL del navegador servida por Apache, Nginx o Kopano Web. TLS puede terminar en ese servidor front-end mientras reenvía las solicitudes a los servicios de Kopano. El manual de Kopano documenta el proxy HTTP al oyente Core en el puerto 236, mientras que su guía de Kopano Web documenta la configuración del certificado TLS en /etc/kopano/kwebd.cfg. Ese puerto HTTPS front-end no es automáticamente el mismo que el puerto TLS Core. Consulte el ejemplo de proxy inverso Core y la guía de instalación de Kopano Web .

Acción: Anote la URL del cliente, el puerto personalizado, el proceso que se espera que escuche allí y si TLS finaliza en el proxy o en Kopano Core. No modifique ambos oyentes a la vez.

1. Compruebe qué está escuchando en el puerto personalizado.

En el host de Kopano, reemplace 8443lo siguiente con el puerto que está fallando:

sudo ss -ltnp | grep ':8443'

Una fila coincidente debería mostrar un socket de escucha. Si no hay ninguna fila, el servicio no está vinculado a ese puerto o está vinculado a una dirección diferente. Si el puerto pertenece a un proxy inverso local, inspeccione el host virtual del proxy. Si debería ser el puerto TLS nativo de Kopano Core, inspeccione server_listen_tlsen /etc/kopano/server.cfg. Un proceso que solo escucha en 127.0.0.1no puede aceptar conexiones remotas directamente; esto puede ser intencional cuando un proxy se encuentra delante.

Compruebe también el firewall del host, el firewall de la nube y cualquier regla de balanceo de carga o NAT. El puerto público debe llegar al receptor interno previsto. Un tiempo de espera agotado o un rechazo de conexión indican problemas de accesibilidad o de configuración del receptor; por sí solo, no indica un certificado incorrecto.

2. Sondear TLS en el nombre de host y puerto exactos.

Desde una máquina cliente, pruebe el punto final público con OpenSSL. Utilice el nombre DNS que aparece en el certificado, no una dirección IP no relacionada:

openssl s_client -connect mail.example.com:8443 -servername mail.example.com -showcerts

Busque el certificado presentado, el protocolo y el cifrado negociados, y cualquier error de verificación. Esta -servernameopción envía el nombre de host TLS SNI; esto es importante cuando un servidor aloja más de un sitio TLS. OpenSSL documenta estas opciones en su manual s_client . Pulse Ctrl+C para salir de la exploración interactiva.

Si el certificado no está presente, es posible que el punto final esté utilizando HTTP simple, que el puerto esté siendo utilizado por un servicio incorrecto o que un proxy esté reenviando el tráfico a un servidor de origen erróneo. Si aparece un certificado, pero su nombre, emisor o fecha de caducidad son incorrectos, corrija la selección o la cadena de certificados en el punto final TLS. Un error de coincidencia de nombre de host no se soluciona cambiando el puerto de escucha de Kopano Core.

Para un punto final accesible desde el navegador, continúe con:

curl -v https://mail.example.com:8443/webapp/

La salida detallada ayuda a distinguir la verificación TLS de una respuesta HTTP como una redirección, un error 404 o un error 502. Un error 404 después de que se haya completado el protocolo de enlace indica un problema de ruta o enrutamiento, no un fallo en la negociación TLS. Para un diagnóstico puntual, curl -vkpuede mostrar si omitir la verificación del certificado modifica el resultado. No deje las comprobaciones de certificados desactivadas en un navegador, cliente o proxy.

Límite importante: Kopano Core utiliza TLS nativo con certificados de cliente. Una s_clientprueba básica sin certificado de cliente puede ser rechazada incluso si el receptor TLS funciona correctamente. Si el servidor solicita autenticación de cliente, repita la prueba con el certificado y la clave de cliente autorizados, o bien, realice la prueba con el cliente de servicio Kopano configurado. Nunca exponga una clave privada en una transcripción de comandos ni en un ticket de soporte.

3. Adaptar el protocolo al receptor.

Un error común al configurar puertos personalizados es configurar un cliente HTTPS para que se comunique con un receptor HTTP simple, o reenviar tráfico HTTPS a un servidor que espera HTTP. El esquema y el puerto deben describir el mismo punto final.

• https://mail.example.com:8443/webapp/significa que el navegador espera TLS en el puerto 8443.
• El ejemplo documentado de Kopano Core envía HTTP a través de un proxy 127.0.0.1:236. Si su implementación utiliza ese patrón, el proxy ascendente debe usar http://, aunque la conexión pública del navegador utilice HTTPS.
• Para Kopano Core TLS nativo, el ejemplo del manual utiliza server_listen_tls = *:237y una URL de cliente que comienza con https://. Si cambia 237 por un puerto personalizado, actualice cada cliente o proxy dependiente con ese mismo valor.

Compruebe si hay líneas de configuración copiadas que presenten discrepancias en cuanto al puerto o el esquema. En una configuración de varios servidores, revise también la URL del servidor o proxy publicada: un cliente puede establecer una conexión inicial y luego fallar después de que Kopano lo redirija a un nombre de host o puerto antiguo.

4. Reparar la configuración del Listener y del Certificado.

Si se trata del oyente TLS nativo de Kopano Core, edite la configuración existente en lugar de añadir directivas duplicadas. A continuación, se muestra un ejemplo simplificado para un puerto personalizado; mantenga las rutas de los certificados y la CA adecuadas para su instalación:

server_listen_tls = *:1237
server_ssl_ca_file = /etc/kopano/ssl/ca.pem
server_ssl_key_file = /etc/kopano/ssl/server.pem
server_ssl_key_pass = your-key-passphrase

El manual de Kopano especifica la configuración del listener, la CA, la clave del servidor y la contraseña, y requiere reiniciar el sistema kopano-servertras este cambio en el listener nativo. Confirme que la versión instalada admite las opciones mostradas; la estructura de los paquetes y las directivas pueden variar. Proteja el directorio de claves y asegúrese de que la cuenta de servicio de Kopano tenga permisos de lectura para los archivos necesarios.

Verifique que el certificado corresponda al nombre de host que utilizan los clientes, que esté vigente y que incluya los certificados intermedios necesarios. El manual de Kopano indica que sus componentes comprueban el nombre común del certificado y los nombres alternativos del sujeto. En una configuración TLS multiservidor, el servidor también debe confiar en la CA que firmó los certificados de cliente, y se deben configurar los certificados de cliente autorizados. No reemplace un certificado por uno autofirmado como atajo para un servicio de navegador público.

Si TLS finaliza en Apache, Nginx o Kopano Web, configure el certificado y listenel puerto personalizado en ese servidor. Luego, configure el esquema y el puerto de origen según el servidor backend. No habilite TLS de origen solo porque el servidor público use HTTPS; primero confirme que el puerto del servidor backend también admite TLS.

5. Validar y recargar el servicio correcto.

Antes de reiniciar un servidor web, ejecute su comprobación de configuración, por ejemplo, sudo nginx -tpara Nginx o sudo apachectl configtestApache. Si la prueba informa de un error, corríjalo antes de reiniciar. Utilice el nombre del servicio instalado en su distribución; por ejemplo:

sudo systemctl restart kopano-server
sudo systemctl status kopano-server --no-pager

Reinicia Kopano Core solo si has modificado su configuración. Si el cambio de puerto o certificado afecta únicamente al front-end, valida y recarga el servicio front-end. Revisa el registro de eventos o de errores inmediatamente después del cambio y repite la comprobación OpenSSL desde la red del cliente. El protocolo de enlace debería mostrar el certificado esperado. A continuación, prueba la URL de la aplicación web o la conexión del cliente Kopano, ya que el éxito de TLS por sí solo no valida la ruta de la aplicación ni la autenticación.

Lea el resultado antes de cambiar más.

• No hay ningún socket de escucha: compruebe el oyente configurado, el estado del servicio y la dirección de enlace.
• Conexión rechazada o tiempo de espera agotado: compruebe el cortafuegos, la NAT, el balanceador de carga y si el puerto de destino es accesible.
• Certificado incorrecto: inspeccione el certificado configurado en el punto final que responde a ese puerto, incluida la selección SNI y la cadena de certificados.
• TLS funciona localmente pero no de forma remota: compare la ruta del proxy público o del balanceador de carga con el oyente local y revise los valores de host y puerto reenviados.
• El protocolo de enlace se establece correctamente, pero la aplicación web falla: inspeccione el estado HTTP, la ruta del proxy, los registros de PHP/WebApp y la conectividad de Kopano Core. Continúe en la capa de aplicación.
• Solo fallan los clientes Core: verifique su server_socketconfiguración de puerto personalizado, CA de confianza y certificado de cliente. La ruta TLS de Core puede requerir autenticación mutua de certificados.

Una solución fiable solo modifica el punto final responsable del error en el protocolo de enlace. El Manual del Administrador de Kopano Core disponible para este procedimiento es la versión 8.0.0, y sus ejemplos deben compararse con los paquetes instalados y las páginas del manual local. Si su implementación utiliza una versión diferente de Kopano, un contenedor o un proxy inverso gestionado, confirme la configuración actual de dicho componente antes de aplicar las directivas de ejemplo.