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.

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.

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. Descargar el certificado de la CA subordinada emitido.
8. Descargar también el certificado de la CA raíz que ha firmado la CA subordinada.

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. Abrir Certificates > Certificate authorities y localizar la CA importada.

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; volver a cargar el archivo en otro lugar no restablece la asociación de clave que falta.

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

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. Según la ruta de inspección, la selección se encuentra en lugares distintos:

• DPI: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings
• Decryption Profile: Profiles > Decryption profiles
• Web Proxy: Web > General settings > HTTPS decryption and scanning

Solo una CA con la finalidad Signing and validation y una clave privada disponible puede utilizarse como CA de re-firma. Una CA de firma en uso no se cambia a Validation only, porque la ruta activa de re-firma perdería su clave.

Para el piloto:

1. Documentar la selección actual y las reglas afectadas.
2. Seleccionar la nueva CA en la ruta de inspección prevista.
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.

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.

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:

1. Desactivar la regla piloto o volver a seleccionar la CA de re-firma anterior.
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

Si el certificado no se ha importado a través de la CSR correspondiente, SFOS no puede asociarlo con la clave creada en el firewall. Deben comprobarse la ruta de asociación de la CSR y el certificado emitido. No se importan 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