Distribuir el certificado CA de Sophos Firewall para la inspección TLS

Cuando un Sophos Firewall descifra conexiones HTTPS mediante inspección TLS o escaneo HTTPS, el firewall crea un nuevo certificado para la conexión inspeccionada y lo firma con una CA local. Los clientes deben confiar en esta CA, de lo contrario, aparecerán advertencias en el navegador o las aplicaciones interrumpirán la conexión.

En Sophos Firewall, la CA integrada SecurityAppliance_SSL_CA está disponible de forma predeterminada. Esta CA se puede descargar desde Certificates > Certificate authorities y distribuir a los clientes gestionados. Pero no basta con que cualquier CA de Sophos esté instalada en los clientes. La CA distribuida debe coincidir con la CA que se usa realmente para el Re-Signing en la configuración de TLS Inspection.

Un entorno con su propia PKI empresarial puede emitir en su lugar una CA subordinada dedicada para la inspección TLS de Sophos Firewall. Este camino mantiene la clave de firma en la firewall y vincula la confianza a la CA raíz empresarial existente, pero requiere un proceso controlado de PKI y piloto.

SecurityAppliance_SSL_CA no es la CA integrada Default para certificados firmados localmente. Si se debe rotar ese otro trust anchor, se aplica el procedimiento Renovar de forma controlada la Default CA de Sophos Firewall. Ambos objetos CA no se sustituyen juntos por sospecha.

Según el modo de operación, esta selección se comprueba en lugares diferentes: en SSL/TLS Inspection Rules basadas en DPI, la CA relevante está en Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings. Un Decryption Profile asignado a la SSL/TLS Inspection Rule puede sobrescribir estos valores globales. En Web Proxy, la CA de HTTPS Scanning se encuentra en Web > General settings > HTTPS decryption and scanning. Si la ruta activa selecciona una CA distinta de aquella en la que confían los clientes, aparecen errores de certificado aunque se haya distribuido una CA de Sophos.

El artículo Implementar correctamente la inspección TLS de Sophos Firewall describe todo el proceso de implementación. Esta guía se centra en la distribución del certificado CA a Windows, macOS y Firefox.

Qué hace este certificado

El certificado CA de Sophos Firewall no es un certificado de servidor para WebAdmin, WAF o el portal VPN. Es la base de confianza con la que los clientes aceptan las conexiones HTTPS recién firmadas por el firewall.

Es importante la separación:

• CA del firewall: firma certificados generados nuevamente durante la inspección TLS.
• Re-Signing CA o HTTPS Scanning CA: la CA seleccionada concretamente que el firewall utiliza en modo DPI o Web Proxy.
• Almacén de confianza del cliente: decide si los navegadores y aplicaciones confían en esta CA.
• Regla de inspección SSL/TLS: decide qué tráfico se descifra.
• Perfil de descifrado: establece cuán estrictamente se manejan los certificados, versiones TLS y errores.
• Lista de exclusión: evita el descifrado para destinos problemáticos o intencionalmente excluidos.

La distribución de la CA por sí sola no activa la inspección TLS. La distribución solo evita que los clientes gestionados muestren advertencias de certificados cuando el tráfico HTTPS está descifrado. Si el tráfico se descifra realmente depende de las reglas del firewall, la política web, las reglas de inspección SSL/TLS, los perfiles de descifrado y las excepciones.

Además, la distribución de la CA no sustituye un control limpio de protocolos. SSL/TLS Inspection Rules actúan sobre tráfico TCP. Si el tráfico web usa QUIC o HTTP/3 sobre UDP 443, la inspección se comporta de otra forma y debe tratarse por separado.

Antes de la implementación

Antes de la distribución, debe estar claro qué clientes utilizarán la inspección TLS. Un certificado CA no debe colocarse sin control en cada dispositivo, sino específicamente en clientes corporativos gestionados.

Preparación:

• Definir un grupo de prueba o una OU de prueba.
• Aclarar el modo de operación: modo DPI, Web Proxy o ambas variantes.
• Documentar la CA elegida en SSL/TLS inspection settings, los Decryption Profiles utilizados y Web General settings.
• Documentar el proceso de reversión y excepciones.
• Descargar el certificado CA solo desde el propio firewall.
• Probar la distribución primero en unos pocos dispositivos.
• Verificar navegadores, aplicaciones empresariales y actualizaciones después de la distribución.
• Evaluar por separado los dispositivos móviles y las apps con almacén de confianza propio o Certificate Pinning.
• Eliminar certificados CA antiguos o no utilizados del almacén de confianza del cliente.

⚠️ Atención: Si la CA o la clave privada se han visto comprometidas, una nueva distribución no es suficiente. En ese caso, la CA debe regenerarse en el firewall, redistribuirse y eliminar la antigua CA de los clientes.

Elegir el método de distribución

El método de distribución adecuado depende de cómo se gestionan los dispositivos.

• Clientes Windows de dominio: usar GPO en Trusted Root Certification Authorities. Es la vía más limpia para entornos clásicos de Active Directory.
• Windows sin dominio: usar MDM, Intune o importación local. La importación local encaja más bien para pruebas o dispositivos individuales.
• macOS: usar perfil MDM o llavero System. La instalación manual encaja más bien para pruebas o entornos pequeños.
• Firefox: usar Windows Trust Store o desplegar Mozilla Enterprise Policies. El comportamiento de Firefox debe verificarse por separado.
• BYOD o dispositivos privados: normalmente no distribuir. TLS Inspection corresponde a dispositivos corporativos gestionados.
• Servidores: distribuir solo en workloads de servidor revisados conscientemente. El tráfico saliente de servidores puede tener otros riesgos y excepciones.

Para la operación productiva, es crucial que la misma implementación pueda revertirse más tarde. Quien distribuya la CA mediante GPO, MDM o políticas, también debe probar la eliminación de la antigua CA.

Descargar la CA de Sophos Firewall

En el Sophos Firewall, el certificado se descarga desde la interfaz web:

1. Iniciar sesión como administrador en el Sophos Firewall.
2. Abrir Certificates > Certificate authorities.
3. Buscar la CA SecurityAppliance_SSL_CA o la CA propia utilizada conscientemente.
4. Descargar el certificado mediante el icono de descarga.
5. Comprobar después si la misma CA está seleccionada en la configuración activa de TLS Inspection.

El certificado generalmente se presenta como SecurityAppliance_SSL_CA.pem. Este archivo contiene la parte pública de la CA y se puede distribuir a los clientes. La clave privada no debe distribuirse a los clientes.

En SFOS 22 también se puede descargar la CA realmente seleccionada directamente donde se utiliza. En la ruta DPI, el icono de descarga aparece junto a Re-sign RSA with y Re-sign EC with. Si se seleccionan dos CA diferentes, los clientes afectados deben confiar en ambas. En la ruta Web Proxy, el icono aparece junto a HTTPS scanning certificate authority (CA). La descarga en el punto de uso reduce el riesgo de distribuir un objeto CA de nombre similar que no esté activo.

El archivo debe tratarse como un elemento de configuración relevante para la seguridad. La parte pública no es una contraseña, pero define en qué CA confiarán los clientes. Por lo tanto, debe proceder del firewall de producción, estar versionado o al menos almacenado de forma rastreable y no reutilizarse de proyectos antiguos. Antes de distribuirlo, documente Subject, Issuer, número de serie, periodo de validez y fingerprint que aparecen en los detalles del certificado. Después de importarlo, compare estos valores en al menos un cliente piloto; el nombre mostrado por sí solo no acredita de forma fiable la identidad.

Para controlar la CA activa hay dos rutas adicionales:

• Modo DPI: abrir Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings y comparar la CA seleccionada allí con el archivo descargado. Si la SSL/TLS Inspection Rule activa usa un Decryption Profile, comprobar también su Re-Signing CA.
• Web Proxy: abrir Web > General settings > HTTPS decryption and scanning y comprobar la HTTPS-Scanning-CA.

Esta comprobación evita un error frecuente de rollout: en los clientes se distribuye la CA estándar mientras el firewall ya usa otra CA en un Decryption Profile o en Web Proxy.

Distribuir el certificado en Windows mediante GPO

En entornos de Active Directory, una política de grupo es el método más limpio. Edge, Chrome y muchas aplicaciones de Windows confían en el almacén de certificados de Windows.

Ruta recomendada en la administración de políticas de grupo:

Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities > Certificates

Procedimiento:

1. Abrir la administración de políticas de grupo en un controlador de dominio o cliente administrador.
2. Usar una GPO existente para la línea base del cliente o crear una nueva GPO para el grupo de prueba de inspección TLS.
3. Cambiar a la ruta Trusted Root Certification Authorities > Certificates.
4. Hacer clic derecho en la lista de certificados.
5. Seleccionar All Tasks > Import.
6. Importar SecurityAppliance_SSL_CA.pem.
7. Vincular la GPO solo con la OU o grupo de seguridad deseado.
8. Ejecutar gpupdate /force en un cliente de prueba o esperar la actualización regular.

Para entornos productivos, la GPO no debe aplicarse directamente a todas las computadoras. Una OU de prueba reduce el riesgo si un certificado se importa incorrectamente o una aplicación reacciona inesperadamente.

Instalar el certificado localmente en Windows

Para dispositivos de prueba individuales, el certificado se puede importar localmente. Hay dos variantes razonables:

• Almacén de computadora local: se aplica a todos los usuarios en el dispositivo y generalmente es correcto para clientes gestionados.
• Almacén de usuario actual: se aplica solo al usuario conectado y a veces es suficiente para pruebas.

Para la computadora local:

1. Iniciar sesión como administrador local.
2. Iniciar certlm.msc.
3. Abrir Trusted Root Certification Authorities > Certificates.
4. Hacer clic derecho en la lista de certificados.
5. Seleccionar All Tasks > Import.
6. Importar SecurityAppliance_SSL_CA.pem.

Para el usuario actual, se puede usar alternativamente certmgr.msc.

Después de la importación, los navegadores y aplicaciones deben reiniciarse. En algunas aplicaciones, es recomendable cerrar sesión o reiniciar el cliente.

Confiar en el certificado en el llavero de macOS

En macOS, el certificado se importa a través de la administración del llavero.

Procedimiento:

1. Copiar SecurityAppliance_SSL_CA.pem al Mac.
2. Abrir el certificado con doble clic.
3. Proporcionarlo en el llavero System o en un perfil MDM gestionado.
4. Abrir el certificado y en Trust establecer la opción Always Trust.
5. Confirmar el cambio con una cuenta de administrador.
6. Reiniciar navegadores y aplicaciones afectadas.

En entornos macOS más grandes, la distribución debe realizarse a través de MDM. La instalación manual es más adecuada para pruebas o dispositivos individuales.

Dispositivos móviles con Sophos Mobile

Para un número elevado de dispositivos Android, iOS y iPadOS gestionados, la CA debe distribuirse mediante una política MDM. Sophos Mobile puede añadir el certificado raíz directamente a la política de dispositivos ya asignada. Apple recomienda MDM o Apple Configurator; con Apple Configurator se crea primero un perfil de configuración en macOS.

Ejemplo para iOS y iPadOS en Sophos Mobile:

1. Abrir Policies > iOS & iPadOS.
2. Seleccionar la política ya asignada a los dispositivos previstos.
3. En la página Edit policy, seleccionar Add > Root certificate.
4. En Root certificate, utilizar Upload a file para cargar únicamente el certificado público de la CA en la que deben confiar los dispositivos según la cadena planificada. Para SecurityAppliance_SSL_CA, es la parte pública de la CA descargada de SFOS.
5. Guardar con Apply y después Save.
6. En la lista de políticas, utilizar la flecha y seleccionar Update devices. Si esta opción no está disponible, el cambio se distribuye durante la siguiente sincronización automática.

Para Android, el certificado raíz se añade de forma equivalente a una política de Android. Después no debe comprobarse solo el estado de la política. En iOS, la verificación está en Settings > General > About > Certificate Trust Settings; en Android, en Settings > Security > Advanced > Encryption & credentials > User credentials. Una petición HTTPS realmente descifrada sigue siendo la prueba final.

En iOS, compruebe allí el estado de confianza del certificado raíz previsto, después de verificar su identidad mediante el fingerprint documentado. Si la confianza sigue desactivada, actívela en Enable full trust for root certificates únicamente para ese certificado raíz. Si ya es de confianza, deje la configuración sin cambios; después, repita la petición HTTPS descifrada para verificar el resultado.

La clave privada de la CA de re-firma nunca debe guardarse en Sophos Mobile ni en un endpoint. Solo se distribuye el certificado público de la CA. Se comienza con un grupo piloto pequeño y también se prueba la retirada de la CA.

Verificar el certificado en dispositivos gestionados

Después de la distribución, se debe verificar en al menos un dispositivo de prueba por plataforma si la CA realmente se encuentra en el almacén de confianza correcto.

• Almacén de computadora Windows: Abrir certlm.msc y buscar en Trusted Root Certification Authorities > Certificates.
• Almacén de usuario actual de Windows: Abrir certmgr.msc y verificar el almacén de confianza del usuario.
• macOS: Abrir la administración del llavero y verificar el estado de confianza en el llavero System.
• Firefox: Abrir Settings > Privacy & Security > Certificates > View Certificates.

Si un certificado solo está en el almacén del usuario, pero una aplicación espera el almacén de la computadora, el navegador puede funcionar y otra aplicación aún mostrar errores de certificado. Por el contrario, los navegadores con su propio almacén de confianza pueden ignorar la distribución de Windows o macOS si no están configurados adecuadamente.

Firefox en Windows

Las versiones actuales de Firefox en Windows buscan de forma predeterminada en el almacén de certificados del sistema operativo las CA raíz instaladas adicionalmente. Si la CA de Sophos Firewall se distribuye mediante GPO al almacén del equipo Windows, normalmente no es necesario importarla de nuevo en una base de datos independiente de Firefox. Este comportamiento se controla en Firefox mediante Allow Firefox to automatically trust third-party root certificates you install, la preferencia security.enterprise_roots.enabled o la política empresarial ImportEnterpriseRoots.

Por tanto, en entornos Windows gestionados existen dos métodos adecuados:

• Usar el almacén de confianza de Windows: es el método estándar recomendado cuando la CA ya se distribuye mediante una GPO de equipo. El uso automático de las CA del sistema operativo debe seguir activo en la configuración gestionada de Firefox.
• Importar el certificado directamente mediante una política empresarial de Mozilla: es una alternativa cuando la confianza de Firefox se gestiona deliberadamente por separado o no debe usarse el almacén de confianza del sistema operativo.

Con el primer método, la CA heredada de Windows puede funcionar sin aparecer como una entrada importada por separado en la administración de certificados de Firefox. En ese caso, son determinantes el almacén del equipo Windows y una prueba HTTPS real. Las siguientes instrucciones de GPO describen el segundo método con Install Certificates.

Descargar plantillas GPO de Firefox

Mozilla proporciona las plantillas de políticas en GitHub. Se necesitan, entre otros:

• firefox.admx
• mozilla.admx
• firefox.adml
• mozilla.adml

Los archivos se pueden descargar del Repositorio de plantillas de políticas de Mozilla o como policy_templates.zip.

Importar plantillas

Los archivos ADMX y ADML se copian en la ruta central de PolicyDefinitions.

Ruta local típica:

C:\Windows\PolicyDefinitions

En un almacén central en el dominio, se utiliza en su lugar la carpeta PolicyDefinitions bajo SYSVOL.

Configurar política de Firefox

En la política de grupo, el certificado se ingresa bajo las políticas de Firefox:

Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates

Procedimiento:

1. Activar la política Install Certificates.
2. Ingresar el nombre del archivo del certificado, por ejemplo, SecurityAppliance_SSL_CA.pem.
3. Copiar el archivo de certificado mediante GPO o distribución de software en el directorio de perfil de usuario esperado.

Dependiendo de la versión de Firefox y la configuración de políticas, los certificados se leen de estos directorios:

%USERPROFILE%\AppData\Local\Mozilla\Certificates
%USERPROFILE%\AppData\Roaming\Mozilla\Certificates

Después de la próxima sesión de Firefox, el certificado debería ser visible en la administración de certificados de Firefox.

Mozilla describe el uso recomendado de la confianza del sistema operativo y la importación mediante políticas en Set up Certificate Authorities (CAs) in Firefox. El Wiki documenta rutas y variantes adicionales: Agregar certificado raíz a Firefox.

Verificar funcionamiento

Después de la distribución, no solo se debe verificar si el certificado está presente. Lo crucial es si la inspección TLS funciona correctamente.

Pruebas recomendadas:

1. Reiniciar el cliente de prueba o volver a iniciar sesión como usuario.
2. Abrir un navegador y acceder a una página HTTPS que sea descifrada por el Sophos Firewall.
3. Mostrar el certificado del sitio web en el navegador.
4. Verificar si la cadena de certificados pasa por SecurityAppliance_SSL_CA o exactamente la CA de Sophos elegida.
5. En el firewall, verificar en Log Viewer > SSL/TLS inspection si el tráfico se muestra como descifrado y qué rule o acción se ha aplicado.
6. Probar aplicaciones empresariales importantes, servicios de actualización, herramientas de colaboración y proveedores de identidad.

Si el navegador sigue mostrando el certificado público original del sitio web, esa conexión no se ha descifrado. Entonces no aplica una SSL/TLS Inspection Rule adecuada, una excepción tiene prioridad, el tráfico sigue otro camino o QUIC/HTTP/3 evita la ruta TCP esperada.

Si la advertencia del navegador desaparece, pero las aplicaciones aún muestran errores, el problema a menudo no está en el certificado en sí. A menudo, el pinning de certificados, la falta de excepciones TLS, un perfil de descifrado incorrecto o una regla de inspección SSL/TLS inadecuada son la causa.

Para el tráfico web, también se debe verificar si QUIC o HTTP/3 evitan la inspección esperada. El artículo Bloquear correctamente QUIC y HTTP/3 en Sophos Firewall explica por qué Block QUIC protocol sigue siendo relevante para el filtrado web, el escaneo de malware y la inspección TLS.

Errores comunes

• El navegador sigue mostrando advertencias de certificado: CA no en el almacén de confianza correcto. Verificar almacén de certificados de Windows/macOS/Firefox.
• Chrome funciona, Firefox no: comprobar si Firefox puede usar las CA raíz instaladas adicionalmente en el sistema operativo o si se aplica una política empresarial de Mozilla independiente. Después, reiniciar Firefox y probar la ruta HTTPS real.
• Aplicaciones individuales fallan: Pinning de certificados o verificación de certificados propia. Verificar Log Viewer de inspección TLS y excepciones.
• Solo algunos clientes funcionan: GPO no se aplica o OU incorrecta. Verificar gpresult y vinculación de GPO.
• La CA está instalada, pero la advertencia permanece: La CA distribuida quizá no coincide con la CA en Decryption Profile, en SSL/TLS inspection settings o en Web General settings.
• DPI funciona, Web Proxy no, o al revés: Ambas rutas pueden estar configuradas de forma diferente. Comprobar CA elegida, ruta de reglas y Log Viewer por modo de operación.
• Después de regenerar la CA hay advertencias: CA antigua aún en clientes o falta la nueva CA. Eliminar CA antigua, distribuir nueva CA.
• Feeds de URL o filtro web no funcionan como se espera: Ruta HTTPS no descifrada. Verificar inspección TLS y política web.
• Certificado presente, pero tráfico no descifrado: No hay regla de inspección SSL/TLS adecuada o ruta DPI/proxy web incorrecta. Verificar implementación TLS, regla de firewall y Log Viewer.
• Solo aplicaciones móviles o clientes individuales fallan: Almacén de confianza propio, Certificate Pinning o comprobación específica de la aplicación es probable. Especialmente el tráfico de Android y apps móviles debe probarse de forma dirigida y excluirse si hace falta, en lugar de distribuir la CA de forma amplia y ciega.

Rotación de CA y emergencia

Una CA no debe operar sin ser notada durante años sin que se conozcan la fecha de vencimiento, el origen y la distribución. Para entornos productivos, debe haber un pequeño proceso de ciclo de vida.

La CA integrada SecurityAppliance_SSL_CA se puede regenerar. Sin embargo, no es un paso preparatorio exento de riesgos: la CA anterior y la nueva no pasan a ser de confianza en paralelo automáticamente en todos los clientes. Para una transición DPI planificada con solapamiento, utilice una CA de firma preparada por separado y pruébela mediante un Decryption Profile de alcance restringido. En cambio, Web Proxy solo dispone de la HTTPS scanning certificate authority (CA) global. Cambiarla afecta a toda la ruta de Web Proxy y, por tanto, requiere una ventana de mantenimiento; antes, todos los clientes afectados deben confiar en la nueva CA pública. En ambos casos, la clave privada permanece en el firewall.

Cambio planificado:

1. Documentar la selección de CA activa, los fingerprints y todas las referencias. Preparar una CA de firma independiente sin regenerar la CA integrada como primer paso.
2. Distribuir únicamente el certificado público o la cadena de CA pública necesaria: primero al grupo piloto de DPI, o a todos los clientes afectados antes de un cambio global de Web Proxy.
3. En modo DPI, activar la nueva CA mediante un Decryption Profile de alcance restringido y comprobar el Issuer, la entrada de registro y las aplicaciones del grupo piloto.
4. Tras superar el piloto de DPI, distribuir el certificado público a todos los dispositivos gestionados afectados y confirmar la importación mediante el fingerprint.
5. Cambiar los campos DPI restantes o la CA global de Web Proxy. Comprobar con conexiones nuevas que firma la nueva CA y que se aplica la regla esperada.
6. Eliminar la CA antigua de los almacenes de confianza de los clientes solo cuando ninguna ruta de inspección haga referencia a ella y todos los dispositivos afectados hayan recibido la nueva CA.

Emergencia por compromiso:

1. Restringir o desactivar temporalmente la inspección TLS si es necesario.
2. Reemplazar la CA afectada en el firewall.
3. Implementar la nueva CA a través del método de distribución definido.
4. Eliminar la CA antigua de todos los almacenes de confianza.
5. Verificar excepciones, Log Viewer y aplicaciones afectadas.
6. Documentar el cambio en el sistema de incidentes o cambios.

Importante: Una CA comprometida no es un problema de certificado normal. Si un atacante controla la clave privada, los clientes pueden confiar en certificados falsificados. Entonces, la CA antigua debe eliminarse de manera consistente.

En un rollback normal, primero restaure en la ruta de inspección la CA documentada anteriormente o desactive la regla piloto. Solo después de que una conexión nueva vuelva a mostrar el Issuer anterior o la ruta original sin descifrar se debe eliminar la CA distribuida únicamente para el piloto. Retirar primero la confianza de los clientes mientras el firewall sigue firmando con esa CA provoca errores de certificado. No elimine CA compartidas o aún referenciadas.

Operación y mantenimiento

El certificado CA debe ser parte del proceso operativo:

• Documentar la fecha de vencimiento y los responsables.
• Realizar la regeneración de la CA solo de manera planificada.
• Eliminar la CA antigua de los clientes después de la migración.
• Verificar regularmente la distribución mediante GPO o MDM.
• Documentar excepciones TLS y revisarlas periódicamente.
• Iniciar el proceso de incidente y cambio de CA si se sospecha que la clave privada de firma o el firewall están comprometidos. La pérdida de un cliente que solo contiene el certificado CA público no compromete la clave de firma.

Al realizar un cambio en la inspección TLS, también se deben verificar las reglas de firewall afectadas, los perfiles de descifrado y las listas de exclusión. De lo contrario, el cliente puede confiar en la CA, pero el firewall aún no descifra el tráfico deseado.

FAQ