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.

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. Existe el artículo existente Crear certificado comodín Let’s Encrypt.

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.

Programar nombres de certificadosAntes 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.
• 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.

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.
• 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.
• 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