Renovar de forma controlada la Default CA de Sophos Firewall

La CA integrada Default de Sophos Firewall no es una entrada descriptiva cualquiera. En cuanto se guardan sus ajustes, SFOS regenera automáticamente la CA. Se genera una nueva clave y, por tanto, un nuevo trust anchor. Las relaciones de confianza anteriores no se adaptan automáticamente.

Por eso, una renovación controlada no comienza con Save, sino con una lista completa de dependencias. Incluye certificados firmados localmente, WebAdmin y portales, perfiles SSL VPN, peers IPsec basados en certificados y sistemas externos que confían en la CA anterior.

⚠️ Importante: La CA Default solo se debe renovar con un backup verificado, acceso de administración independiente, una ventana de mantenimiento y un plan para todos los servicios dependientes. Un cambio estético del país, la organización o el common name no justifica una regeneración no planificada.

Renovar la Default CA en diez pasos

1. Documentar el motivo técnico, el responsable del cambio, la ventana de mantenimiento y los criterios de éxito.
2. Identificar todos los certificados, servicios, perfiles VPN, peers y clientes que confían en la CA Default actual.
3. Comprobar si el objetivo real es únicamente el ApplianceCertificate o la CA separada SecurityAppliance_SSL_CA.
4. Probar correctamente el backup de configuración actual, SSMK, acceso de administrador local y vía de recuperación.
5. Descargar la antigua CA Default y registrar su fingerprint SHA-256, subject, número de serie y validez.
6. Aprobar por escrito los nuevos datos de la CA, el tipo de clave y la compatibilidad con todos los peers.
7. En Certificates > Certificate authorities > Default, introducir los valores preparados y guardarlos solo durante la ventana de mantenimiento.
8. Descargar la nueva CA pública y distribuirla de forma controlada a peers, clientes y trust stores.
9. Probar por separado WebAdmin, portales, SSL VPN, IPsec y cada servicio dependiente adicional.
10. Documentar el fingerprint, los logs, los resultados de las pruebas y los perfiles antiguos restantes. Utilizar la vía de recuperación preparada si aparece un error crítico.

Distinguir Default CA, ApplianceCertificate e Inspection CA

Sophos Firewall contiene varios objetos con funciones distintas:

• Default: CA interna para certificados firmados localmente.
• ApplianceCertificate: certificado de servidor integrado que se usa de forma predeterminada para WebAdmin, el portal de usuario y el portal cautivo. Está firmado por la CA Default y se puede regenerar por separado.
• SecurityAppliance_SSL_CA: CA integrada independiente para HTTPS Inspection y Re-Signing cuando está seleccionada en la configuración de TLS Inspection.

Estos objetos no deben tratarse como si fueran iguales. Un problema con un único ApplianceCertificate no demuestra que la CA Default esté defectuosa. Del mismo modo, cambiar la CA Default no realiza automáticamente una rotación planificada de SecurityAppliance_SSL_CA.

Importar y asignar certificados en Sophos Firewall explica el trabajo general con certificados, claves privadas, CSR y cadenas de CA. La Inspection CA tiene su propio procedimiento en Distribuir el certificado CA para HTTPS Scanning.

Cuándo está justificada una regeneración

Puede ser necesario un cambio planificado cuando:

• se sabe o se sospecha razonablemente que la clave anterior de la CA está comprometida,
• la CA está a punto de caducar y aún se utiliza de forma productiva,
• la identidad, el tipo de clave o los requisitos criptográficos se migran de forma controlada,
• Sophos Support exige la regeneración para un problema confirmado.

Una descarga VPN fallida de forma aislada, una advertencia del navegador sin análisis de la cadena, un cambio estético del subject o un comando antiguo de la comunidad no son motivos suficientes. Para un problema con .ovpn y ApplianceCertificate, primero diagnosticar sistemáticamente la descarga de la configuración SSL VPN.

Inventariar las dependencias antes del cambio

Certificados y servicios asignados

En Certificates > Certificates, registrar como mínimo el nombre, subject, issuer, validez y asignación real de cada certificado firmado localmente. Según el entorno, esto incluye:

• WebAdmin, el portal de usuario y el portal cautivo,
• el certificado de servidor SSL VPN,
• IPsec site-to-site y de acceso remoto con Digital certificate,
• WAF, SMTP, API u otros servicios TLS,
• certificados de cliente o servidor generados localmente fuera del firewall.

Un certificado visible no es automáticamente una dependencia. Lo decisivo es si lo usa un servicio productivo y si el peer confía en la CA Default emisora.

Sistemas de confianza y vías de distribución

También se debe documentar:

• navegadores y sistemas operativos con la CA antigua importada,
• MDM, GPO o distribución de software para la nueva CA,
• peers IPsec con un Default.pem, Remote CA o asignación DN importados,
• usuarios SSL VPN y la vía de distribución de nuevos perfiles .ovpn,
• monitorización, clientes API o integraciones con certificate pinning,
• acceso de administración HA, de emergencia y externo.

Si no está claro quién distribuyó la CA anterior o qué peers confían en ella, se detiene el cambio.

Conservar el estado inicial y la vía de recuperación

Antes de la ventana de mantenimiento, descargar la CA Default en Certificates > Certificate authorities. El archivo contiene la parte pública, no automáticamente una exportación independiente y utilizable de su clave privada.

Los datos PEM se pueden comprobar en modo de solo lectura en un equipo de administración:

openssl x509 -in Default.pem -noout -subject -issuer -serial -dates -fingerprint -sha256

Para un archivo DER se especifica el formato de entrada:

openssl x509 -inform DER -in Default.der -noout -subject -issuer -serial -dates -fingerprint -sha256

El fingerprint y la salida se guardan en el estado previo junto con el nombre del firewall, número de serie, build de SFOS y ticket del cambio. Los archivos de certificado y los datos PKI internos no se adjuntan sin protección a tickets públicos.

Guardar también externamente un backup actual de Sophos Firewall con su contraseña y SSMK. Una restauración sustituye toda la configuración, reinicia el firewall y puede revertir cambios posteriores. Es una última vía de recuperación planificada, no una función de deshacer rápida para la CA.

Preparar la ventana de mantenimiento

Antes de Save, todos los puntos siguientes deben estar en verde:

• cuenta admin local o segundo administrador probado desde la red de gestión,
• consola u otra vía de recuperación independiente disponible,
• nuevos valores de CA y criptografía compatibles con todos los sistemas peer,
• responsables de peers VPN, MDM/GPO y portales disponibles,
• nuevos perfiles, distribución a trust stores y cuentas de prueba preparados,
• tiempo suficiente para una restauración completa del backup si fuera necesaria.

En un clúster HA, el cambio compatible de WebAdmin se realiza en el primary actual. SFOS no documenta continuidad ininterrumpida de la CA ni de las sesiones para este cambio. Por eso, después de un failover planificado se vuelven a probar inicios de sesión nuevos y todos los servicios críticos. La CA no se edita de forma independiente en ambos nodes.

Actualizar la Default CA en SFOS

1. Abrir Certificates > Certificate authorities.
2. Hacer clic en Default. El nombre no se puede cambiar.
3. Comprobar Country, State, Locality, Organization, Organizational unit, Common name y dirección de correo electrónico.
4. En Private key settings, seleccionar de forma consciente RSA o Elliptic curve, la longitud de clave o curva correspondiente y el Secure hash.
5. Comprobar los valores con el ticket del cambio y la lista de compatibilidad.
6. Hacer clic en Save solo durante la ventana de mantenimiento.

Valores de ejemplo como CH, Zurich, Example AG, IT Security, fw01.example.com y pki@example.com son únicamente datos de documentación. Se sustituyen por la organización, la referencia real del firewall y la convención de nombres PKI aprobada.

⚠️ Save es el punto de cambio. SFOS regenera automáticamente la CA Default. Volver a introducir más tarde los valores anteriores del subject no restaura la clave ni el fingerprint anteriores.

Inmediatamente después, descargar la nueva CA Default y ejecutar la misma comprobación OpenSSL. Se espera un nuevo fingerprint SHA-256 después de la regeneración. Campos inesperados, un error de descarga o un estado que no se pueda documentar son condiciones para detenerse.

Migrar los servicios dependientes de forma controlada

WebAdmin y portales

Comprobar qué certificado está seleccionado para WebAdmin, el portal de usuario y el portal cautivo en Administration > Admin and user settings. Si se usa un certificado firmado localmente con la nueva CA, los clientes que acceden a él deben confiar en la nueva CA.

Mantener abierta una sesión Full Admin existente durante la prueba. Nuevas ventanas privadas del navegador prueban el FQDN, la cadena del certificado y el inicio de sesión desde el origen de gestión previsto. El comando CLI que restablece el certificado de WebAdmin al certificado predeterminado del dispositivo no es un rollback de la clave anterior de la CA.

SSL VPN

Si SSL VPN usa ApplianceCertificate u otro certificado de servidor firmado localmente, los usuarios deben descargar e importar un nuevo archivo .ovpn después del cambio de los ajustes de la CA Default. Un nombre de archivo existente o un túnel en verde con un perfil antiguo no bastan como validación.

Al menos un usuario piloto descarga el nuevo perfil mediante la vía de portal prevista, establece una conexión nueva y prueba DNS, rutas y tráfico real de aplicaciones. Los perfiles antiguos solo se retiran de la distribución cuando todos los usuarios han migrado correctamente.

Peers IPsec basados en certificados

Con Digital certificate, los peers de Sophos Firewall intercambian sus certificados CA. Si antes se importó el Default.pem remoto en el peer, la nueva CA pública se sustituye o se añade de forma controlada en el peer y se vuelve a comprobar la asignación.

La configuración completa de la conexión permanece en Configurar IPsec site-to-site en Sophos Firewall. Para el cambio de CA se prueban como mínimo el establecimiento IKE, la Child SA, ambas direcciones del tráfico y las aplicaciones reales. Un túnel en verde no demuestra por sí solo la ruta de retorno.

HTTPS Inspection y otras vías de firma

Para HTTPS Inspection, primero identificar la Signing CA realmente seleccionada en Web > General settings. Si es SecurityAppliance_SSL_CA o una CA externa, no se redistribuye solo porque se haya regenerado la CA Default.

Una vía de firma solo se incluye en el cambio cuando se ha demostrado que utiliza la CA Default modificada o un certificado dependiente. Así, los cambios de trust store quedan limitados a los endpoints realmente afectados.

Comprobar el resultado y los logs

La validación separa configuración y funcionamiento:

1. Descargar la nueva CA y documentar subject, issuer, número de serie, validez y fingerprint SHA-256.
2. En Certificates > Certificates, comprobar issuer, Trusted y los objetos de certificado afectados.
3. Probar individualmente WebAdmin, portales, SSL VPN, IPsec y otros servicios asignados.
4. Comprobar en vpncertificate.log la operación de CA y certificado en el momento del cambio.
5. Comprobar en configuration-audit.log el administrador, la hora y los datos anteriores y posteriores compatibles.
6. Correlacionar en los logs de servicio correspondientes únicamente los errores y éxitos de la prueba.

Rastrear cambios de configuración con configuration-audit.log explica el audit trail. No todos los servicios escriben el mismo nivel de detalle en configuration-audit.log, por lo que la validación funcional sigue siendo obligatoria.

Rollback y condiciones de parada

Una CA regenerada no tiene un control Undo sencillo. Volver a guardar el texto anterior no restaura la antigua clave privada.

Por eso se define de antemano la vía de recuperación para cada servicio:

• mantener acceso de administración independiente y la sesión de administrador existente,
• volver a asignar a los portales un certificado externo independiente y ya validado, si está disponible y se puede asignar con seguridad,
• revertir la confianza de los peers y los perfiles de cliente solo según el estado anterior documentado,
• usar una restauración completa del backup únicamente cuando sean aceptables los efectos, el reinicio, SSMK y la pérdida de cambios posteriores,
• escalar a Sophos Support con evidencias cuando se desconozca una dependencia o no se pueda reproducir el estado del certificado.

No realizar cambios de base de datos desde shell, eliminación masiva de certificados, reinicios de servicios ni una segunda regeneración de la CA por sospecha. El cambio se detiene cuando no se puede coordinar un peer crítico, no se ha distribuido el nuevo trust anchor o no se ha probado correctamente la vía de recuperación.

Errores habituales después de la regeneración

El navegador indica una conexión no fiable

Comprobar la cadena de certificados que se entrega realmente para el FQDN. Si el certificado de servidor está firmado por la nueva CA Default, esa CA exacta debe estar en el trust store. No importar SecurityAppliance_SSL_CA de forma indiscriminada.

SSL VPN ya no conecta con el perfil antiguo

Correlacionar el certificado de servidor SSL seleccionado, la nueva CA, la descarga del portal y sslvpn.log. Descargar un nuevo archivo .ovpn e importarlo como un perfil nuevo. Distinguir los perfiles antiguos y nuevos por el certificado y la conexión correcta, no por el nombre de archivo.

IPsec permanece down después del cambio de CA

En ambos lados, comprobar la importación de CA, el estado Trusted, Local/Remote certificate, ID y strongswan.log. Con DER ASN1 DN, un cambio del subject de la CA también puede afectar a la identidad. No relajar perfiles ni IDs por sospecha.

HTTPS Inspection muestra errores de certificado

Primero comprobar la Signing CA realmente seleccionada. Si SecurityAppliance_SSL_CA sigue en uso y no ha cambiado, el error no se debe automáticamente a la nueva CA Default. Investigar por separado la cadena de certificados, la Decryption Rule y la confianza del endpoint.

Lista de comprobación

• El motivo y alcance de la regeneración de la CA están documentados.
• Se han conservado la CA antigua, el fingerprint, el backup, la contraseña y SSMK.
• Se han inventariado todos los certificados, servicios, peers, clientes y vías de distribución.
• Default, ApplianceCertificate y SecurityAppliance_SSL_CA se han evaluado por separado.
• La ventana de mantenimiento, la vía de recuperación de administración y los responsables están preparados.
• Los nuevos valores de CA y la criptografía son compatibles con todos los peers.
• La CA solo se ha guardado durante la ventana aprobada y se ha descargado después.
• WebAdmin, portales, SSL VPN, IPsec y otros servicios se han probado por separado.
• Se han guardado vpncertificate.log, configuration-audit.log y los logs de servicio.
• Es posible realizar un rollback o escalar a soporte sin cambios incontrolados desde shell.

Preguntas frecuentes