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.

Además de la CA integrada, se puede importar una CA de firma generada externamente o crear una Certificate Signing Request (CSR) en el firewall y solicitar a una CA externa, como Active Directory Certificate Services, una CA de firma subordinada. En ese caso, hay que importar en el firewall tanto la CA de firma subordinada como su CA raíz. Los clientes necesitan el anclaje de confianza público correspondiente y la cadena pública necesaria, no la clave privada de firma. El procedimiento PKI enlazado explica la emisión; los pasos siguientes cubren selección, distribución y verificación.

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

Preparar la regla Web Proxy y la CA

Para un piloto Web Proxy, abrir Rules and policies > Firewall rules, elegir IPv4 o IPv6 y crear una regla mediante Add firewall rule > New firewall rule. Por ejemplo, usar el nombre libre TLS-CA-Pilot, establecer Source zones en LAN, Source networks and devices en la red piloto, Destination zones en WAN y Destination networks en los destinos previstos. Adaptar zonas, redes y destinos a la ruta real; no autorizar a todos los clientes indiscriminadamente para probar un certificado.

Antes de realizar cambios, documentar los valores anteriores de la regla y la CA para la reversión. Comprobar por separado HTTPS scanning certificate authority (CA) en Web > General settings > HTTPS decryption and scanning, distribuir primero su certificado público a todos los dispositivos piloto afectados y verificar la confianza mediante el fingerprint. La CA compartida de Web Proxy es global: cambiarla no es un piloto de CA por regla, afecta a todos los clientes de Web Proxy y requiere que confíen previamente en ella, además de una ventana de mantenimiento.

Solo después, en la regla de firewall seleccionada, elegir la política web adecuada en Security features > Web filtering, activar Scan HTTP and decrypted HTTPS, Use web proxy instead of DPI engine y expresamente Decrypt HTTPS during web proxy filtering, y guardar con Save. La opción de escaneo por sí sola no descifra; seleccionar la CA en Web > General settings no sustituye al control de descifrado de la regla de firewall.

En la configuración inicial, comprobar en Certificates > Certificate authorities > Default que todos los ajustes de la Default CA estén configurados. Es una comprobación, no una instrucción para regenerar la CA ni para distribuir Default en lugar de la SecurityAppliance_SSL_CA activa.

Descargar el certificado público de la CA

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.

Para un piloto manual, facilitar el archivo público verificado a través de la intranet corporativa o un envío controlado por correo electrónico. Los usuarios lo guardan localmente y comparan su identidad con los detalles del certificado documentados por separado antes de otorgarle confianza. Para grupos más grandes siguen siendo preferibles GPO o MDM.

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 a la OU de prueba prevista. Si es necesario, usar un grupo de seguridad mediante filtrado de seguridad, no como destino del vínculo de la GPO.
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.

Para un único usuario también se puede usar el llavero login: abrir el archivo descargado con doble clic en Keychain Access, verificar su identidad y seleccionar Always Trust. Safari también utiliza esta confianza de macOS. Para un despliegue gestionado en todo el dispositivo siguen siendo adecuados System o MDM; no confundir el ámbito de usuario con el del sistema.

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

⚠️ Android: instalar el certificado no autoriza el descifrado. Sophos documenta la importación de la CA, pero también recomienda excluir todos los dispositivos Android de la inspección SSL/TLS mediante DPI debido a errores de certificado. Por tanto, esta guía establece la exclusión de DPI para todos los dispositivos Android como opción predeterminada. Los siguientes pasos de importación y prueba HTTPS en Android solo se aplican a un piloto gestionado, de alcance restringido y aprobado por separado: una necesidad empresarial documentada debe justificar la desviación para dispositivos y aplicaciones concretos. Antes de aprobarlo, verificar el almacén de confianza real y todas las aplicaciones afectadas; si hay errores, revertir el piloto y restablecer la exclusión. La instalación mediante MDM no resuelve el Certificate Pinning ni la confianza de todas las apps. La recomendación de DPI no es una afirmación general sobre la compatibilidad de Web Proxy; esa ruta también requiere validar las aplicaciones por separado.

Piloto móvil manual

Si el dispositivo no acepta el archivo PEM, puede ser necesaria una conversión a un formato compatible como .der, .cer o .crt. La extensión por sí sola no determina la codificación; nunca usar un archivo de clave privada. Los nombres de los menús varían según la versión de Android y el fabricante. Un ejemplo Pixel utiliza Settings > Security & location > Advanced > Encryption & credentials:

1. En Credential storage, seleccionar Install from storage o Install from SD card.
2. En el selector de archivos, elegir la ubicación mediante Menu > Open from y abrir el certificado público.
3. Introducir el PIN del dispositivo, asignar un nombre reconocible al certificado y elegir VPN and apps para este piloto de aplicaciones; Wi-Fi es la otra categoría ofrecida. Confirmar con OK.
4. Comprobar identidad e importación en User credentials y probar una petición HTTPS descifrada. Una importación correcta no garantiza que todas las apps de Android confíen en el almacén de certificados del usuario.

Para un piloto iOS manual, facilitar e importar el archivo CA público en el dispositivo. En Settings > General > About > Certificate Trust Settings > Enable full trust for root certificates, otorgar confianza solo al certificado raíz identificado y probar HTTPS. No activar varias CA raíz desconocidas.

Distribuir mediante la política del dispositivo

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. Después, se conectan uno o varios dispositivos iOS al Mac para instalar el perfil que contiene el certificado de la CA.

Ejemplo para iOS y iPadOS en Sophos Mobile:

Los certificados raíz instalados en dispositivos iOS y iPadOS mediante MDM o Apple Configurator son de confianza automáticamente, a diferencia de la importación manual. La comprobación siguiente no pide cambiar una confianza ya activada.

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

Para un único perfil de prueba también se puede realizar una importación manual: abrir Settings > Privacy & Security > Certificates > View Certificates > Authorities > Import, seleccionar el archivo CA público y pulsar Open. En Downloading Certificate, activar únicamente Trust this CA to identify websites para la CA cuya identidad ya se ha comprobado y pulsar OK. Reiniciar Firefox y probar la ruta HTTPS descifrada. Esta importación en el perfil no sustituye a la distribución centralizada.

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

Copiar firefox.admx y mozilla.admx directamente en la carpeta PolicyDefinitions elegida. Los archivos correspondientes firefox.adml y mozilla.adml deben ir en su subcarpeta de idioma, no junto a los archivos ADMX.

Ruta local típica:

C:\Windows\PolicyDefinitions

Para el Central Store del dominio, utilizar en su lugar \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions. Sustituir ambas apariciones de <domain> por el nombre DNS del dominio de AD. Si existe un Central Store, desplegar allí las plantillas de Mozilla; una copia únicamente en la carpeta local no basta para editar las GPO del dominio.

Conservar las carpetas de idioma del paquete descargado y utilizar archivos ADMX y ADML de la misma versión de las plantillas. Por ejemplo, colocar los ADML en inglés en C:\Windows\PolicyDefinitions\en-US o, si se utiliza el Central Store, en \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\en-US. Copiar los demás idiomas necesarios en las subcarpetas correspondientes del paquete. en-US es un ejemplo de idioma de las plantillas, no una exigencia relacionada con el idioma de este artículo.

Volver a abrir el editor de directivas de grupo y comprobar que Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates aparece sin errores de recursos. Si falta, corregir la carpeta de destino, la subcarpeta de idioma y la correspondencia de versiones antes de continuar con la política del certificado.

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.

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. Correlacionar la nueva petición en el firewall por origen, destino y hora, identificar el modo de operación real y utilizar las comprobaciones correspondientes que se describen a continuación.
6. Probar aplicaciones empresariales importantes, servicios de actualización, herramientas de colaboración y proveedores de identidad.

DPI: En Rules and policies > SSL/TLS inspection rules, comprobar la regla de inspección que coincide, su acción, Decryption Profile y CA de re-firma. En Log Viewer > SSL/TLS inspection, correlacionar la misma petición nueva por origen, destino y hora y comprobar el descifrado y la regla o acción aplicada. Revisar también las exclusiones de DPI.

Web Proxy: Confirmar la regla de firewall que realmente coincide, su política web y Decrypt HTTPS during web proxy filtering. Comprobar la HTTPS scanning certificate authority (CA) compartida en Web > General settings y las excepciones aplicables en Web > Exceptions. En Log Viewer, correlacionar los registros pertinentes de filtrado web/proxy para la misma petición nueva por origen, destino y hora; el emisor y la cadena del certificado del navegador deben corresponder a la CA seleccionada. Las reglas de inspección SSL/TLS no controlan el descifrado de Web Proxy. Aquí no se garantiza ni se exige una entrada de descifrado DPI; una entrada de filtrado web por sí sola no demuestra el descifrado.

Si el navegador sigue mostrando el certificado público original del sitio, esa conexión no se ha descifrado. En DPI, comprobar la regla de inspección y sus exclusiones; en Web Proxy, la regla de firewall que coincide, el control de descifrado y las excepciones web. Otra ruta de tráfico o QUIC/HTTP/3 también puede evitar la ruta TCP esperada.

Si desaparece la advertencia del navegador pero las aplicaciones siguen mostrando errores, la causa a menudo no es el certificado. Puede tratarse de Certificate Pinning o de un almacén de confianza propio. En DPI, revisar también Decryption Profile, regla de inspección y exclusiones TLS; en Web Proxy, la regla de firewall y las excepciones web según las comprobaciones anteriores.

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: Es posible que la CA no esté 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: Puede haber Certificate Pinning o una verificación propia del certificado. En DPI, revisar registros SSL/TLS y exclusiones TLS; en Web Proxy, registros de filtrado web/proxy y Web > Exceptions, siempre para la misma petición.
• 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: Utilizar las comprobaciones anteriores para el modo real: regla de inspección, perfil y registros SSL/TLS en DPI; regla de firewall, control de descifrado, CA compartida, excepciones web y registros de filtrado web/proxy en Web Proxy.
• Después de regenerar la CA hay advertencias: Puede faltar la nueva CA activa en los clientes. Distribuir primero la nueva CA pública y verificar su fingerprint. Eliminar una CA antigua no comprometida solo cuando ninguna ruta activa la siga usando; si está comprometida, seguir el procedimiento de emergencia.
• 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: En DPI puede faltar una regla de inspección que coincida; en Web Proxy puede faltar el control de descifrado de la regla de firewall o aplicarse una excepción web. Utilizar las comprobaciones específicas del modo y confirmar la ruta real del tráfico.
• Solo aplicaciones móviles o clientes individuales fallan: Considerar almacenes de confianza propios, Certificate Pinning y validación específica de la aplicación. Excluir Android de DPI de forma predeterminada; un piloto Android aprobado por separado debe volver a la exclusión si falla. Evaluar otras excepciones de forma limitada, en lugar de desactivar toda la inspección.

Rotación de CA y emergencia

No se debe mantener una CA en uso durante años sin conocer su fecha de caducidad, su origen y dónde se ha distribuido. 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