Configurar una CA subordinada para la inspección TLS de Sophos Firewall

Para la inspección TLS, Sophos Firewall debe volver a firmar los certificados de los destinos HTTPS visitados. En lugar de utilizar la CA integrada SecurityAppliance_SSL_CA, se puede emplear una CA empresarial subordinada dedicada. Los clientes gestionados siguen confiando en la CA raíz propia de la organización, mientras que la clave privada de la CA subordinada permanece en el firewall.

El procedimiento seguro consta de seis pasos:

1. Generar en Sophos Firewall una CSR para la nueva CA subordinada.
2. Hacer que una Enterprise CA de Microsoft AD CS firme la CSR con la plantilla Subordinate Certification Authority.
3. Importar el certificado de CA emitido directamente en la CSR existente.
4. Añadir la CA raíz correspondiente al firewall como Validation only.
5. Seleccionar la CA subordinada como CA de re-firma y utilizarla inicialmente solo en una regla piloto.
6. Verificar la cadena de certificados, el tráfico HTTPS real, los registros y la reversión.

⚠️ Una CA de re-firma puede emitir certificados para dominios ajenos. Por eso su clave privada es especialmente sensible. La CA solo debe utilizarse para la ruta de inspección prevista y no debe exportarse ni compartirse en tickets. No debe activarse en producción sin una vía de recuperación probada.

Este procedimiento está descrito para AD CS en modo Enterprise CA. Sophos indica expresamente que el método documentado no se aplica a una Standalone CA. Otra PKI interna también puede emitir una CA subordinada, pero necesita su propio proceso revisado por el responsable de la PKI.

Como alternativa, se pueden generar la CSR y las CA con una herramienta externa como OpenSSL. Las CA subordinada y raíz generadas externamente se cargan en Certificates > Certificate authorities; una CA de firma sin una CSR coincidente en el firewall también requiere su clave privada a través del proceso PKI aprobado. La raíz permanece sin clave privada. Es una ruta distinta de transferencia de claves, no la importación de CSR descrita abajo. La CA subordinada también puede utilizarse para configuraciones TLS de correo electrónico; la activación y validación siguientes afectan solo al tráfico web y no activan ninguna configuración TLS de correo.

Cuándo resulta útil una CA subordinada

Una CA subordinada propia resulta especialmente adecuada en redes empresariales gestionadas donde los clientes ya confían en una CA raíz interna. Así no es necesario distribuir a cada dispositivo un trust anchor adicional e independiente de Sophos. La rotación, la revocación y la responsabilidad pueden incorporarse a la gobernanza de la PKI existente.

Sin embargo, la solución no es automáticamente más sencilla. El firewall recibe una clave con la que puede firmar certificados para la inspección TLS. Por tanto, la CA necesita una finalidad estrictamente definida, responsables documentados, una vigencia limitada y procedimientos probados de revocación y renovación.

En entornos más pequeños sin PKI propia, la CA integrada de Sophos suele ser el camino más sencillo. Distribuir el certificado de CA de Sophos Firewall para la inspección TLS explica su selección y distribución a los clientes. Introducir correctamente la inspección TLS de Sophos Firewall describe todo el proceso piloto y de excepciones.

Preparar el diseño de la CA y la vía de recuperación

Antes de generar la CSR se definen la finalidad, los nombres y las dependencias. Un ejemplo posible es:

• nombre del objeto SFOS: SFOS-TLS-Inspection-SubCA-2026
• Common Name: SFOS TLS Inspection SubCA 2026
• CA raíz emisora: Example Enterprise Root CA
• uso previsto: exclusivamente inspección TLS y descifrado HTTPS en FW01
• red piloto: 10.20.30.0/24

Estos valores son ejemplos de documentación y deben sustituirse por la convención de nombres, la PKI y el grupo piloto propios. Una CA separada por firewall o clúster de inspección claramente delimitado simplifica posteriormente la asignación, la revocación y la rotación.

Antes del cambio deben estar disponibles:

• una copia de seguridad actual de la configuración y un acceso de administración independiente que funcione,
• la documentación de la CA de re-firma actual y de su distribución a los clientes,
• acceso a una Enterprise CA de AD CS y la aprobación del responsable de la PKI,
• un pequeño grupo de prueba gestionado con una vía de recuperación funcional,
• un plan de revocación, renovación y retorno controlado a la CA anterior.

Crear y restaurar una copia de seguridad de Sophos Firewall explica el procedimiento de copia y restauración. Una copia de seguridad no sustituye la documentación de la CA de re-firma seleccionada actualmente ni de los clientes que confían en ella.

Generar la CSR en Sophos Firewall

La CSR se genera en el firewall para que la clave privada se cree allí y no tenga que transportarse entre AD CS, el equipo de administración y el firewall.

1. Abrir Certificates > Certificates.
2. Seleccionar Add.
3. En Action, seleccionar Generate certificate signing request (CSR).
4. Introducir un nombre inequívoco, por ejemplo SFOS-TLS-Inspection-SubCA-2026.
5. Elegir el tipo y la longitud de clave o la curva, así como el hash seguro, conforme a la política de PKI propia. En su ejemplo, Sophos muestra RSA, 2048 bits y SHA-256; se trata de valores de ejemplo del producto, no de una especificación universal.
6. Introducir los atributos de sujeto y los Subject Alternative Names aprobados por la PKI interna.
7. Guardar la CSR y abrirla mediante el icono de descarga.
8. Utilizar Copy to clipboard y entregar la CSR exclusivamente a través del proceso autorizado de AD CS.

La CSR no contiene la clave privada. Aun así, forma parte del proceso controlado de PKI porque define la identidad, la clave pública y la finalidad de CA solicitada.

En Subject name attributes, el formulario CSR contiene Country name, State, Locality name, Organization name, Organization unit name, Common name y Email address. Se introducen los datos de identidad aprobados por la PKI, no los de cualquier sitio web visitado. Subject Alternative Names admite nombres DNS o direcciones IP, por ejemplo web.exampleorg.com, fd12:3456:789a:1:: o 203.0.113.10. Estos valores del ejemplo del producto no son requisitos para una CA de inspección; los SAN se acuerdan con el responsable de la PKI.

Emitir la CA subordinada con AD CS

La CSR de Sophos se envía desde la página de inscripción web de la Enterprise CA de AD CS responsable:

1. Abrir Request a certificate.
2. Seleccionar Advanced certificate request.
3. Pegar la CSR completa.
4. En Certificate template, seleccionar Subordinate Certification Authority.
5. Revisar la solicitud conforme al proceso de aprobación interno y emitirla con Submit.
6. En Certificate Issued, elegir un formato adecuado, por ejemplo Base 64 encoded.
7. Seleccionar Download certificate para descargar el certificado de la CA subordinada emitido.
8. En la página inicial de AD CS, abrir Download a CA certificate, seleccionar la CA raíz que firmó la subordinada y elegir Download CA certificate y Save.

Límite importante de EKU: Si el certificado de CA emitido contiene una sección Extended Key Usage, debe incluir TLS Web Server Authentication para esta finalidad de firma. Si falta ese valor, el certificado no debe utilizarse como CA de re-firma en producción. El responsable de la PKI debe corregir la plantilla de CA y emitir un certificado nuevo.

Antes de la importación, se comprueban en el visor de certificados el emisor, el sujeto, la vigencia, Basic Constraints y, si existe, Extended Key Usage. Los archivos raíz y subordinado se nombran de forma inequívoca para no confundirlos con certificados de servidor.

Importar las CA subordinada y raíz

Importar la CA subordinada en la CSR existente

1. Abrir Certificates > Certificates.
2. Seleccionar la acción de importación de la CSR creada anteriormente.
3. Seleccionar el certificado de CA subordinada emitido por AD CS.
4. Seleccionar Certificate authority only. SFOS detecta el tipo de CA y muestra las opciones correspondientes.
5. Comprobar el nombre y seleccionar Import certificate.
6. En Certificates > Certificate authorities, abrir el filtro junto a Name, introducir el nombre de la CA y seleccionar Apply.

SFOS asocia automáticamente a la CA subordinada la clave privada correspondiente a la CSR. Por eso, el icono de clave privada debe aparecer para esta CA en la lista de CA. Si falta, la CA no está lista para firmar. La importación general en Certificates > Certificate authorities > Add también puede detectar una CSR existente coincidente. La importación directa desde la CSR descrita aquí permite seguir explícitamente la asociación, pero no es la única ruta documentada. Sin una CSR coincidente o una clave privada, volver a cargar el certificado no crea una clave de firma.

Añadir la CA raíz solo para validación

El ejemplo paso a paso de Sophos denomina la finalidad Validation, mientras que la referencia del campo CA la llama Validation only. Aquí se pretende la misma función segura: certificado raíz solo para validación, sin clave privada de la raíz; no seleccionar Signing and validation para la raíz. Para cargarlo, elegir el archivo en Certificate mediante Browse.

1. Abrir Certificates > Certificate authorities y seleccionar Add.
2. Cargar el certificado de la CA raíz que ha emitido la CA subordinada.
3. En Use certificate for, mantener Validation only.
4. Comparar el nombre y la huella con la documentación aprobada de la CA raíz.
5. Guardar y volver a comprobar la cadena de la CA subordinada.

El firewall no necesita la clave privada de la CA raíz. Signing and validation está previsto únicamente para la CA subordinada cuya clave privada ya reside en el firewall gracias a la CSR. Importar y asignar certificados en Sophos Firewall explica las diferencias generales entre certificado, CSR, clave privada y cadena de CA.

Seleccionar la CA para la inspección TLS

La importación por sí sola no cambia el tráfico. La nueva CA se activa primero en un piloto estrictamente limitado. DPI ofrece una selección global y una posible sustitución por regla; el Web Proxy tiene una selección independiente:

• DPI, global: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings
• DPI, por regla: el Decryption Profile asignado en Profiles > Decryption profiles puede heredar o sustituir la selección global.
• Web Proxy: Web > General settings > HTTPS decryption and scanning

Los ajustes de DPI incluyen los campos separados Re-sign RSA with y Re-sign EC with. Se refieren a si el certificado original del sitio web se firmó mediante RSA o EC. SFOS admite una CA RSA o EC en cualquiera de los dos campos. Por tanto, normalmente se puede seleccionar la misma CA subordinada en ambos. Una segunda CA EC resulta útil sobre todo cuando una aplicación solo acepta un tipo de certificado concreto; todos los endpoints afectados también deben confiar en ella.

Un Decryption Profile asignado a una Inspection Rule puede heredar expresamente la selección global mediante Use CAs defined in SSL/TLS settings. Si en el perfil se definen valores propios para Re-sign RSA with y Re-sign EC with, estos sustituyen los ajustes globales para esa regla. Antes del piloto se deben comprobar tanto la selección global de CA como el perfil realmente asignado a la regla.

Solo una CA con la finalidad Signing and validation y una clave privada disponible puede utilizarse como CA de re-firma. No cambiar una CA de firma en uso a Validation only; dejaría de ser utilizable para la re-firma activa. Esto no permite afirmar si SFOS elimina la clave almacenada.

Asegurar primero el alcance del piloto: Cambiar la CA global de DPI también afecta a las reglas existentes cuyos perfiles heredan la selección global. Para un piloto DPI aislado, utilizar un Decryption Profile exclusivo con valores de CA explícitos y asignarlo solo a la regla piloto ya limitada al grupo de prueba. No editar un perfil compartido con producción. Una nueva regla piloto no aísla la selección global de CA del Web Proxy; si el escaneo proxy ya está activo, se necesita un cambio aprobado por separado para todos los clientes afectados. Hasta entonces, mantener la CA global existente sin cambios.

Para el piloto:

1. Documentar la selección actual y las reglas afectadas.
2. Seleccionar la nueva CA para certificados RSA y EC en la ruta de inspección prevista y, para DPI, comprobar si el Decryption Profile asignado hereda o sustituye la selección global.
3. Limitar la regla al grupo de prueba o a la red piloto definidos.
4. Comprobar la cadena de CA en los clientes piloto. En un dominio AD, la CA raíz empresarial ya debería ser de confianza, pero aun así debe poder construirse correctamente toda la cadena hasta la nueva CA subordinada.
5. Generar una petición HTTPS real y comprobar conjuntamente los detalles del certificado, la Inspection Rule, el Decryption Profile y la entrada de registro.

El cambio general en producción solo se realiza cuando el piloto ha sido satisfactorio. La selección de la CA no activa automáticamente una Inspection Rule y la confianza del cliente no demuestra que el tráfico se esté descifrando realmente.

Verificación de la API: separar la selección de CA de los controles globales

Quien verifique o automatice la selección de CA mediante la API XML debe distinguir los campos del objeto SSLTLSInspectionSettings. Las referencias de SFOS 22.0 y 23.0 enumeran los mismos campos; esto no demuestra que un firewall concreto ya haya aplicado correctamente un cambio.

• RSACA y ECCA seleccionan las CA para volver a firmar los certificados de servidor RSA y EC, respectivamente, y corresponden a Re-sign RSA with y Re-sign EC with. El valor es el nombre del objeto de CA previsto, por ejemplo, SFOS-TLS-Inspection-SubCA-2026, no una ruta de archivo de certificado, una clave privada ni un valor de activación. La selección no crea ni importa una CA y no distribuye la confianza a los clientes. Siguen vigentes los requisitos descritos anteriormente relativos al propósito de firma, la clave privada, la cadena y las anulaciones de perfil; si se utilizan dos CA distintas, los clientes afectados deben poder verificar ambas cadenas.

• SSLTLSEngine activa o desactiva el motor TLS y SSLTLSInspection activa o desactiva la inspección SSL/TLS global; ambos aceptan Enabled o Disabled. Estos campos no representan ni la selección de CA ni el estado de la regla piloto individual. Una rotación de CA no justifica modificar estos controles globales. La referencia de la API indica Enabled como valor predeterminado para ambos; sin embargo, para el cambio cuenta el estado real leído, no un valor predeterminado de la documentación.

• TLS13Decryption establece el tratamiento global de las conexiones TLS 1.3: Decrypt as 1.3 o Downgrade to TLS 1.2 and decrypt, con el valor predeterminado documentado Decrypt as 1.3. El campo no selecciona una CA de firma ni una acción de una regla de inspección individual. Por tanto, una degradación de versión no es una solución para la ausencia de una cadena de CA o de una clave de firma; en un cambio exclusivamente de CA, la configuración aprobada de TLS 1.3 permanece sin cambios.

También SSLv2SSLv3, SSLCompression y SSLConnectionsExceeded son decisiones globales independientes para protocolos antiguos, compresión SSL y exceso de capacidad de conexiones SSL, respectivamente. Cada uno acepta Allow without decryption, Drop o Reject; la API indica Allow without decryption como valor predeterminado en cada caso, no como recomendación de seguridad. Estas decisiones no se restablecen incidentalmente a valores de ejemplo durante una rotación de CA.

Antes de efectuar un cambio mediante la API, guardar los valores globales realmente almacenados, los nombres de ambos objetos de CA, las anulaciones de perfil y las reglas afectadas, y definir el procedimiento exacto de reversión. La referencia identifica los campos mencionados como opcionales; esto no demuestra que los campos omitidos permanezcan sin cambios en todas las versiones de firmware. No ejecutar ninguna llamada de escritura automatizada sin haber confirmado, para la compilación concreta, el comportamiento de actualización y restauración. Una respuesta documentada de la API 200 significa que la operación se ha realizado correctamente, y 500, que la operación ha fallado; incluso un mensaje de éxito no sustituye la nueva lectura de los valores almacenados ni la prueba con nuevas conexiones HTTPS. Un valor inesperado o un estado incierto detiene la ampliación del piloto.

Validar el funcionamiento y la seguridad

Una prueba satisfactoria incluye varias evidencias:

1. En Certificates > Certificate authorities, la CA raíz está presente como Validation only.
2. La CA subordinada tiene asignado Signing and validation y muestra el icono de clave privada.
3. Un cliente piloto confía en la CA raíz y puede construir la cadena completa.
4. Un sitio HTTPS descifrado deliberadamente muestra un certificado de servidor firmado por la nueva CA subordinada.
5. El hostname, el destino original y el estado del navegador son correctos; no aparece ninguna advertencia de certificado inesperada.
6. Log Viewer muestra la SSL/TLS Inspection Rule y la acción esperadas para esta prueba concreta.
7. Una fuente ajena al piloto permanece en la ruta anterior.

También deben probarse por separado las aplicaciones con certificate pinning, almacenes de confianza propios o rutas de actualización sensibles. Una sola petición satisfactoria en el navegador no basta para aprobar todo el despliegue.

Para la validación, probar tanto un certificado de servidor RSA como uno EC en la ruta DPI prevista y comparar, en cada caso, el emisor presentado, la cadena completa de CA raíz y subordinadas, la confianza del cliente, el perfil realmente asignado y la acción registrada en los logs. Si se utilizan CA de firma distintas, verificar ambas cadenas de confianza por separado. Confirmar además que los controles globales, el tratamiento de TLS 1.3 y las demás decisiones globales coinciden con su estado previo documentado y que un origen ajeno al piloto permanece sin cambios. Se trata de una verificación que debe realizarse en el entorno propio, no de una prueba ejecutada aquí en un dispositivo.

Rotación y reversión

La CA subordinada debe renovarse antes de que caduque. Durante una transición controlada, las CA nueva y antigua deben distinguirse claramente. La nueva CA se emite, se importa y se valida primero en clientes piloto; solo después se selecciona gradualmente en la ruta de inspección.

Si una prueba falla, se utiliza la vía de recuperación preparada:

Para revertir la CA, es preferible restaurar la CA o el perfil anterior. Desactivar una regla piloto por sí solo no garantiza ni la CA ni el descifrado anteriores: puede actuar una regla posterior. Comprobar antes la ruta de continuidad real y volver a verificar después el certificado y los registros.

Una reversión de CA solo devuelve los cambios de CA y perfil realizados para el piloto al estado previo guardado. Establecer indiscriminadamente SSLTLSEngine o SSLTLSInspection en Disabled, o modificar TLS13Decryption, no restablece ni la CA anterior ni la ruta de protección anterior. Después, volver a leer la selección y las anulaciones almacenadas, y comprobar la cadena de certificados y los logs con nuevas conexiones. Si no existe un procedimiento de reversión demostrado, no continuar el despliegue.

1. Restablecer la CA anterior utilizada para volver a firmar o el perfil de descifrado anterior, según corresponda. Desactivar la regla piloto únicamente si la ruta resultante, verificada previamente, restablece el estado previo aprobado; no desactivar indiscriminadamente el motor global ni la inspección global.
2. Comprobar con un proceso de navegador nuevo que vuelve a utilizarse la ruta de certificados anterior.
3. No eliminar la CA nueva mientras existan reglas, Decryption Profiles o ajustes de Web Proxy que hagan referencia a ella.
4. Involucrar al responsable de la PKI si la EKU, la cadena, la plantilla o el estado de revocación no están claros.
5. No seguir utilizando claves comprometidas; revocar la CA, emitir una nueva y limpiar los almacenes de confianza de forma controlada.

Una CA solo se elimina cuando ninguna configuración hace referencia a ella, la ruta anterior ya no se necesita y se han cumplido los requisitos de conservación y auditoría.

Delimitar errores concretos

Falta el icono de clave privada

Comprobar la CSR existente, el certificado emitido para ella y la asociación automática de la clave. La importación en Certificates > Certificate authorities > Add también depende de que SFOS encuentre una CSR coincidente. Si falta la CSR correspondiente o el certificado no coincide con ella, la asociación no está demostrada. No importar claves privadas desde tickets, correos electrónicos o almacenamientos no controlados.

La CA no se puede seleccionar para volver a firmar

Comprobar la finalidad de la CA, el icono de clave privada y las extensiones del certificado. Si existe Extended Key Usage, debe incluir TLS Web Server Authentication. Una CA raíz con Validation only no está disponible deliberadamente para volver a firmar.

Un cliente informa de una cadena no confiable

Comprobar las CA raíz y subordinada, sus huellas y el almacén de confianza del cliente afectado. Después se compara el emisor realmente presentado en el navegador con la CA seleccionada en SFOS. La mera presencia de la CA raíz en el firewall o en el cliente no demuestra que esté activa la CA de re-firma correcta.

El navegador funciona, pero una aplicación no

La aplicación puede utilizar un almacén de confianza propio o certificate pinning. Primero se documentan el destino, el cliente, la Inspection Rule y la hora del error. No se crea una excepción global Don't decrypt; el problema se delimita en el piloto reducido y solo se aprueba la excepción necesaria con una justificación documentada.

FAQ