Configurar certificados Let's Encrypt de Sophos Firewall

Con certificados Let’s Encrypt en Sophos Firewall se pueden crear certificados HTTPS públicos directamente en el firewall y renovarlos automáticamente. Esto resulta especialmente práctico para publicaciones WAF, WebAdmin, User Portal, VPN Portal como interfaz web, Captive Portal, SPX Portal, páginas de inicio de sesión de hotspot y configuraciones SMTP TLS.

La función reduce el trabajo de certificación manual, pero no reemplaza la planificación adecuada. DNS, accesibilidad pública, puerto 80, nombres de certificados, reglas WAF, acceso al portal y monitoreo deben coincidir. Si la validación o renovación falla sin que nadie se dé cuenta, un portal o una aplicación web publicada puede fallar repentinamente con una advertencia de certificado a pesar de que la regla WAF sea realmente correcta.

Es importante separar el certificado del portal del certificado VPN: un certificado Let’s Encrypt puede proteger correctamente un VPN Portal en el navegador. Para Remote Access VPN, Site-to-Site VPN y Chromebook SSO, Sophos menciona limitaciones. Estos casos deben planificarse por separado.

La ruta de red también tiene un límite claro: la función integrada de Let’s Encrypt no es compatible con IPv6 en la matriz actual de SFOS 22. Por eso, la emisión y la renovación necesitan una ruta IPv4 funcional. Compatibilidad y límites de IPv6 en Sophos Firewall con SFOS 22 clasifica los demás límites del producto.

Para la publicación real de un servidor web, Sophos Firewall WAF: publique servidores web de forma segura encaja primero. Este artículo se centra en el lado del certificado y el funcionamiento de Let’s Encrypt en el firewall.

Cuándo Let’s Encrypt tiene sentido en el firewall

El método incorporado Let’s Encrypt tiene sentido si el propio Sophos Firewall proporciona el servicio público o se encuentra frente a él como un proxy inverso.

• WAF/Protección de servidor web: aplicaciones HTTPS de acceso público con su propio FQDN.
• Administrador web: acceso administrativo con un certificado limpio si WebAdmin se usa externamente o internamente a través de FQDN.
• User Portal / VPN Portal: los usuarios inician sesión en un portal HTTPS o descargan configuraciones; esto no es lo mismo que el certificado del túnel VPN propiamente dicho.
• Portal cautivo/punto de acceso: Los usuarios ven una página de inicio de sesión HTTPS sin advertencia de certificado.
• SMTP TLS: Configuración de Mail Protection o SMTP TLS con certificado público.

No todos los servicios se ajustan a este camino. Para certificados comodín o certificados que se van a utilizar en varios sistemas fuera del firewall, suele ser mejor un certificado generado externamente. La emisión se explica en Crear certificado comodín Let’s Encrypt; la posterior importación y asignación del certificado en Sophos Firewall se describen por separado.

Límites y diferencias importantes

Sophos Firewall crea certificados Let’s Encrypt para FQDN específicos. La integración no es la misma que la de un cliente ACME administrado libremente en un servidor Linux.

Puntos importantes:

• El dominio debe especificarse como un FQDN completo.
• Los dominios comodín no son la forma correcta para el proceso de firewall integrado.
• Las direcciones IP no son nombres de certificado válidos para la validación HTTP-01.
• La validación de dominio HTTP debe poder llegar al firewall por el puerto 80 e IPv4.
• Para la validación, el firewall crea temporalmente una regla WAF y la elimina de nuevo tras una validación correcta.
• Durante esta validación, las aplicaciones web existentes protegidas mediante reglas WAF pueden dejar de estar accesibles brevemente a través del firewall.
• Remote Access VPN, Site-to-Site VPN y Chromebook SSO no deberían planificarse con este flujo de certificados.
• Los certificados son válidos durante 90 días; el firewall intenta renovarlos automáticamente cuando quedan menos de 30 días de validez.
• Si se cancela el registro Let’s Encrypt en el firewall, los certificados existentes dejan de renovarse.

Sophos introdujo la función con SFOS 21. La clasificación de Avanet de las innovaciones en ese momento se puede encontrar en la publicación del blog Sophos Firewall v21: las innovaciones más importantes. En las notas de la versión recientes se enumeran varias correcciones de WAF y Let’s Encrypt. Para entornos productivos, esto significa que el estado del firmware, el estado del certificado y el funcionamiento del WAF deben comprobarse juntos, no de forma aislada.

Requisitos

Antes de crear un certificado conviene aclarar estos puntos:

• El firewall se ejecuta en una versión SFOS compatible con Let’s Encrypt.
• Cada nombre DNS del certificado se resuelve públicamente.
• Las respuestas DNS públicas apuntan de forma consistente en todo el mundo a la dirección WAN o a una IP que enruta el puerto 80 hacia el firewall.
• DNS no debería entregar destinos distintos según la región. Los comprobadores DNS públicos desde varias regiones ayudan a detectar problemas de split-brain o GeoDNS antes de solicitar el certificado.
• Por nombre normalmente debería responder una sola IP pública relevante. Varios A records solo son limpios si todos los destinos implicados reenvían de forma fiable el tráfico HTTP del puerto 80 hacia el firewall.
• Se puede acceder al puerto 80 externamente para la validación HTTP.
• No hay ninguna regla DNAT, WAF u otra regla activa en la IP pública afectada y puerto 80 que intercepte la solicitud de validación hacia otro sistema.
• GeoIP filters, firewalls anteriores, filtros del proveedor y rutas SD-WAN no bloquean la validación.
• El firewall puede comunicarse a través de Internet.
• La fecha, hora y NTP del firewall son correctos.
• Para el servicio posterior queda claro si el certificado se utiliza en WAF, WebAdmin, Portal o SMTP TLS.
• Un propietario comprueba periódicamente la caducidad del certificado, el estado de renovación y los servicios afectados.

⚠️ Let’s Encrypt no es una solución alternativa para una accesibilidad pública mal planteada. Si el puerto 80 está bloqueado por una regla DNAT antigua, otra regla WAF, GeoIP, NAT anterior o un filtro del proveedor, la solicitud o renovación del certificado puede fallar.

Planificar los nombres de los certificados

Antes de la configuración técnica, se debe determinar qué nombres de host son realmente necesarios. Una buena planificación de certificados evita correcciones posteriores en las reglas, portales y DNS de WAF.

Ejemplos:

• portal.example.com: Portal de Usuario o Portal VPN.
• vpn.example.com: Portal VPN o ruta de descarga VPN SSL.
• admin.example.com: WebAdmin, si se usa externamente o mediante FQDN de administración.
• app.example.com: Solicitud publicada WAF.
• mail.example.com: SMTP TLS o Protección de Correo.

Si tiene varias aplicaciones, no debe apresurarse a empaquetarlas todas en un solo certificado. Un certificado con muchos nombres puede resultar práctico, pero también aumenta las dependencias. Cuando se renueva, reemplaza o revierte un certificado, todos los nombres de host que contiene se ven afectados.

Para las reglas WAF, también es importante que DNS, certificado, dominios en la regla WAF y SNI coincidan. Los conceptos básicos de WAF se describen en Sophos Firewall WAF: servidores públicos web de forma segura.

Crear cuenta y certificado de Let’s Encrypt

La configuración se realiza en WebAdmin en el área Certificados. Dependiendo de la versión de SFOS, la representación exacta puede variar ligeramente, pero el proceso sigue siendo similar.

Registrar cuenta

Primero se registra el firewall en Let’s Encrypt.

1. Abrir Certificates > Let’s Encrypt.
2. Revisar el Subscriber Agreement y las condiciones.
3. Hacer clic en Register account.
4. Comprobar que el registro quede activo sin advertencias.

Si Let’s Encrypt cambia las condiciones, el registro debe confirmarse de nuevo. De lo contrario, los certificados existentes no se renuevan y no se pueden crear certificados nuevos. En la práctica, este aviso debe formar parte de la revisión normal del firewall, no quedar como “mirarlo más tarde”.

Sophos Firewall muestra avisos sobre condiciones modificadas, entre otros lugares, por correo de administrador y en Control Center. Estos avisos no deben tratarse como una simple información: sin nueva confirmación, la operación automática de certificados se detiene.

Solicitar certificado

Después se crea el certificado propiamente dicho.

1. Abrir Certificates > Certificates.
2. Hacer clic en Add.
3. En Action, seleccionar Request Let’s Encrypt certificate.
4. Asignar un nombre claro, por ejemplo le-app-example-com.
5. En Domains, introducir los FQDN deseados, por ejemplo app.example.com.
6. En Hosted address, seleccionar la dirección WAN pública a la que apuntan esos dominios.
7. Comprobar que el puerto 80 apunta realmente al firewall desde fuera.
8. Hacer clic en Save.
9. Tras unos minutos, comprobar en Certificates > Certificates si el certificado aparece como confiable y tiene una fecha Valid until válida.

Durante la validación, el firewall utiliza el mecanismo de desafío-respuesta HTTP. Para hacer esto, los sistemas externos Let’s Encrypt deben poder alcanzar la ruta de validación. Si el firewall está detrás de un enrutador, balanceador de carga o proveedor NAT, la redirección debe apuntar al firewall.

Si el nombre de dominio no es válido o no existe, corregirlo no siempre es simplemente editar el CSR existente. A menudo es más limpio eliminar la solicitud incorrecta y crear una nueva con el FQDN corregido.

Usar certificado

Una vez emitido, el certificado sólo existe. Sólo protege un servicio una vez que ha sido seleccionado activamente allí.

Asignación típica:

• WAF: regla WAF afectada en Reglas y políticas > Reglas de firewall.
• Administrador web: Certificado para la consola WebAdmin en la configuración relacionada con el acceso al dispositivo/administrador.
• Portal de usuario / Portal VPN: Configuración del portal o portal VPN.
• Portal cautivo/punto de acceso: Página de inicio de sesión y certificado del portal.
• SMTP TLS: Configuración de correo electrónico o SMTP TLS.

Después de la tarea, no sólo debe guardar en WebAdmin, sino también probar el servicio externamente. Para las publicaciones WAF, una prueba desde fuera de su propia LAN es adecuada porque, de lo contrario, la vista DNS interna, el loopback NAT o la caché del navegador pueden proporcionar una seguridad falsa.

Prueba de puesta en marcha

Una prueba de puesta en marcha exitosa consta de DNS, TLS, funcionalidad del servicio y registro.

Lista de verificación:

• El FQDN se resuelve públicamente en la dirección esperada.
• El firewall puede acceder al puerto 80 durante la validación.
• El puerto 443 o el puerto HTTPS utilizado entrega el nuevo certificado.
• El navegador no muestra advertencia de certificado.
• El certificado contiene el nombre de host esperado.
• La fecha de caducidad coincide con la del certificado recién creado.
• El servicio entrega, además del certificado del servidor, los certificados intermedios necesarios.
• La regla WAF, el portal, WebAdmin o SMTP TLS realmente utilizan este certificado.
• Log Viewer no muestra ningún error notable de WAF, portal o certificado.
• Para las versiones WAF, reverseproxy.log coincide con el momento de la prueba.

Una simple prueba TLS externa también puede mostrar qué certificado se entrega realmente. Es importante realizar la prueba desde fuera de la red del cliente, no sólo desde el cliente interno.

Verificar cadena de certificados

Después de cambiar a un nuevo certificado Let’s Encrypt, no solo se debe verificar el nombre común o la entrada SAN. También es crucial si el cliente ve la cadena de certificados completa. Si un navegador, una aplicación o un sistema de monitoreo informa una cadena incompleta, la causa podría ser la selección del certificado, un certificado importado antiguo, una regla WAF incorrecta o un proxy inverso intermediario.

En la práctica, debes comprobar estos puntos:

• La prueba HTTPS externa muestra el FQDN esperado sin advertencia de certificado.
• El certificado entregado es realmente el nuevo certificado Let’s Encrypt de Sophos Firewall.
• La cadena de certificados está completa y no se reemplaza por un certificado de servidor o proxy antiguo.
• La regla WAF, el portal o el WebAdmin utilizan el mismo certificado que es visible en la prueba externa.
• Si se trata de un equilibrador de carga ascendente, un enrutador o un proxy inverso, no se entregará ningún otro certificado allí.

Esta verificación es particularmente importante si el mismo dominio se ejecutó anteriormente en una publicación diferente, o si varias reglas WAF, reglas DNAT o servidores proxy externos usan el mismo nombre de host. De lo contrario, verá un certificado válido en WebAdmin, mientras que los clientes externos seguirán recibiendo una cadena diferente o incompleta.

Comprobar las cadenas YE e YR después de una renovación

Los certificados de Let’s Encrypt emitidos recientemente pueden estar firmados mediante YE1, YE2, YR1 o YR2. SFOS 22.0 MR2 Build 546 añadió compatibilidad con estos nuevos certificados raíz e intermedios. Para la entrega incompleta de la cadena registrada como NC-181671, Sophos también ha confirmado el despliegue de un hotfix en todos los appliances, pero no ha indicado un único número de versión del hotfix. Por ello, lo decisivo sigue siendo comprobar la cadena que realmente se entrega desde el exterior: un certificado válido en WebAdmin no demuestra que WAF, el portal o WebAdmin envíen todos los certificados intermedios necesarios.

Un síntoma típico aparece justo después de una renovación: el navegador funciona, pero curl, una aplicación Go, un sistema de monitorización o un dispositivo móvil antiguo muestra unable to get local issuer certificate o certificate signed by unknown authority. Hay dos causas posibles:

• El firewall entrega una cadena incompleta. Falta al menos un certificado intermedio necesario entre el certificado del servidor y el ancla de confianza.
• El cliente no confía en el ancla de confianza. La cadena entregada está completa, pero el almacén de confianza del sistema operativo, el contenedor o la aplicación está obsoleto.

Desde un equipo de administración externo, este comando de solo lectura muestra qué certificados envía realmente el servicio. app.example.com debe sustituirse por el FQDN que se va a comprobar:

openssl s_client -connect app.example.com:443 -servername app.example.com -showcerts </dev/null

La salida debe contener el certificado de app.example.com y los certificados intermedios necesarios para su cadena. Normalmente, el servidor no envía el ancla de confianza raíz final; esta debe existir en el almacén de confianza del cliente. Si la salida solo contiene el certificado del servidor o falta un certificado intermedio, el problema está en el lado que entrega el servicio. Si la cadena está completa, pero solo fallan algunos clientes, deben comprobarse los paquetes de CA del sistema operativo, el entorno de ejecución o el contenedor correspondientes.

Además, curl prueba la misma URL con el almacén de confianza del equipo concreto:

curl -Iv https://app.example.com/

Que el navegador funcione no basta como comprobación, porque los navegadores pueden almacenar certificados intermedios en caché o validarlos de otra forma. Si la prueba externa devuelve un certificado distinto del esperado, primero deben comprobarse la asignación de certificados de la regla WAF o del portal, así como los proxies y balanceadores de carga situados delante.

Para correlacionar temporalmente los eventos, debe consultarse primero el registro de Let’s Encrypt en Advanced Shell. La salida se detiene con Ctrl+C:

tail -f /log/letsencrypt.log

letsencrypt.log muestra la emisión y la renovación. Para operaciones generales de certificados se utiliza tail -f /log/vpncertificate.log; para el funcionamiento de WAF, tail -f /log/reverseproxy.log. Los registros no sustituyen la prueba externa de la cadena, pero ayudan a relacionar temporalmente la renovación, el cambio de certificado y el primer acceso fallido.

Si la cadena sigue incompleta después de comprobar la asignación del servicio, el firmware actual y los hotfixes disponibles, debe contactarse con Sophos Support indicando la referencia NC-181671. Deben facilitarse la versión y el build de SFOS, el servicio afectado, el FQDN, el issuer, la hora, la salida de openssl y el mensaje de error exacto del cliente. No deben eliminarse archivos de CA por sospecha, importarse indiscriminadamente todos los certificados de Let’s Encrypt ni reiniciarse WAF sin una vía de reversión documentada.

Monitorear la renovación en la empresa.

Los certificados Let’s Encrypt son válidos durante 90 días. La ventaja de la integración es que el firewall puede renovar automáticamente un certificado cuando quedan menos de 30 días de validez. Sin embargo, no debe dejarse el proceso funcionando a ciegas.

Estos puntos deben comprobarse periódicamente en una auditoría de empresa:

• ¿El firewall se ejecuta en una versión SFOS actual y estable?
• ¿El certificado sigue siendo válido?
• ¿La renovación automática fue exitosa?
• ¿Aún se puede acceder al puerto 80 para su validación?
• ¿Existen nuevas reglas DNAT o WAF que podrían bloquear la validación?
• ¿Sigue activo el registro Let’s Encrypt y se han confirmado condiciones modificadas?
• ¿Los usuarios o el monitoreo muestran advertencias de certificados?
• ¿Hay errores de WAF o de portal en el visor de registros?

Esta verificación es particularmente importante después de actualizaciones de firewall, cambios de WAF, cambios de proveedor, cambios de DNS y cambios en enrutadores ascendentes o servidores proxy inversos.

Errores típicos

• El certificado no se crea: FQDN no apunta al firewall o el puerto 80 no es accesible. Verifique la resolución de DNS público y la prueba del puerto externo.
• La solicitud de certificado falla después del cambio de WAF: regla existente intercepta la validación HTTP. Verifique las reglas DNAT, WAF y Firewall en el puerto 80.
• La validación falla según el país de origen: GeoIP, filtros anteriores o SD-WAN pueden bloquear algunos destinos de validación. Para la emisión, el puerto 80 no debe ser accesible solo desde el propio país.
• DNS entrega IPs distintas según la región: Let’s Encrypt no valida necesariamente desde la región del administrador. Las respuestas DNS públicas deben apuntar globalmente a un camino que lleve el puerto 80 al firewall.
• Varios A records apuntan a sistemas distintos: la validación puede llegar aleatoriamente a un destino que no reenvía el challenge al firewall. Simplificar DNS o garantizar que todos los destinos enruten correctamente el HTTP challenge.
• La aplicación WAF no está accesible brevemente durante la emisión: el firewall utiliza mecanismos WAF temporales para la validación. Las publicaciones críticas no deberían modificarse durante una ventana productiva no planificada.
• Se crea el certificado, pero el navegador muestra el certificado antiguo: El servicio utiliza otro certificado. Verifique la selección de regla WAF, portal o certificado WebAdmin.
• El navegador o el seguimiento informan que la cadena de certificados está incompleta: Certificado incorrecto activo, la cadena no se entrega completamente o el proxy ascendente entrega un certificado diferente. Compare la prueba TLS externa, la regla WAF, el mapeo del portal y posibles proxies.
• El navegador funciona, pero curl, Go o la monitorización fallan después de la renovación: comprobar externamente si se entregan todos los certificados intermedios necesarios. Si la cadena del servidor está completa, actualizar el almacén de confianza del cliente afectado; si está incompleta, comprobar el estado del firmware y de los hotfixes y, si es necesario, indicar NC-181671 a Sophos Support.
• La aplicación WAF no funciona correctamente después del cambio de certificado: SNI, dominio, host backend o perfil de protección no coinciden. Verifique la regla WAF, los dominios, reverseproxy.log y los registros de backend.
• La renovación no funciona: La ruta de validación ha cambiado desde su creación. Verifique DNS, puerto 80, NAT ascendente y estado del firmware.
• La renovación se detiene tras cambios en las condiciones: si debe confirmarse de nuevo el Let’s Encrypt Subscriber Agreement, los certificados nuevos y las renovaciones quedan bloqueados hasta confirmar de nuevo Register account.
• Los certificados no se renuevan tras la deregistración: si la cuenta Let’s Encrypt del firewall fue deregistrada, no revise solo el certificado individual; compruebe primero el estado de la cuenta.
• El certificado debe usarse para Remote Access VPN o Site-to-Site VPN: este no es el caso de uso soportado por esta integración. Para certificados VPN debe planificarse un flujo de certificados propio.
• Centro de control muestra WAF o advertencia de certificado: antigua regla WAF, reinicio de WAF o estado del certificado problemático. Verifique el visor de registros, las reglas WAF y la lista de certificados.

Si el WAF y el certificado son visibles juntos, no deberías mirar sólo el certificado. La coincidencia de WAF, la dirección alojada, los dominios, el SNI y la accesibilidad del backend pertenecen a la misma cadena de errores.

Reversión del plan

Para portales públicos y aplicaciones WAF, debe quedar claro cómo retroceder antes de cambiar un certificado.

Preparación útil:

• no borre el certificado anterior inmediatamente
• Documentar la regla WAF afectada y la configuración del portal.
• Tener acceso a pruebas externas disponible
• Conozca DNS TTL si se cambian los nombres de host
• Seleccionar ventanas de mantenimiento para portales críticos.
• Preparar comunicaciones con los usuarios si algún portal se ve afectado

Si se ha creado el nuevo certificado, pero un servicio no funciona correctamente, normalmente puede volver a seleccionar el certificado anterior. Sin embargo, si la causa es una validación HTTP bloqueada, una reversión del certificado sólo ayudará a corto plazo. Luego se debe corregir la ruta de validación, de lo contrario la próxima renovación volverá a fallar.

Lista de verificación

• FQDN y servicios documentados.
• Resolución de DNS público marcada.
• Puerto 80 verificado para validación HTTP.
• Se comprobaron conflictos con DNAT, WAF, GeoIP, SD-WAN o NAT anterior.
• Cuenta Let’s Encrypt registrada y condiciones modificadas confirmadas.
• Certificado Let’s Encrypt creado.
• Certificado asignado al servicio correcto.
• Prueba HTTPS externa realizada con la cadena completa y más de un tipo de cliente.
• Visor de registros y WAF reverseproxy.log marcados.
• Responsabilidad y seguimiento de renovación definidos.
• El certificado antiguo sólo se elimina después de una operación exitosa.

Preguntas frecuentes