Renovar el certificado de Sophos Firewall mediante la API XML y comprobar los servicios

La reducción de la vigencia de los certificados TLS de confianza pública aumenta el trabajo que requieren las renovaciones manuales. Por eso, el certificado se emite en un sistema externo, se importa desde un host de automatización protegido, se asigna al servicio previsto y, a continuación, se comprueba en el listener real. Que la emisión se haya completado correctamente no confirma que la importación haya tenido éxito; que exista un objeto de certificado tampoco confirma qué certificado presentan WebAdmin, Portal, WAF o SMTP.

Los campos XML para add y update siempre se obtienen de la API help de la compilación de SFOS utilizada. El campo de identificación de un objeto existente, la conservación de las referencias y el comportamiento después de los errores se determinan en una prueba. Por este motivo, el artículo no muestra una carga útil de actualización supuestamente universal.

El proceso en cuatro fases

Preparar: aclarar las autorizaciones de la CA, las validaciones, el host de automatización, el acceso a la API y el procedimiento de reversión.
Probar: con un nombre prescindible, convertir el ejemplo local de adición/actualización en una solicitud multipart vinculada a la versión y aprobarla.
Renovar: comprobar el certificado y la clave, cargarlos y asignar el certificado a los servicios previstos.
Validar: comprobar el archivo del objeto y el listener real, supervisar el funcionamiento y no eliminar el certificado antiguo hasta más adelante.

Por qué la duración exige una automatización robusta

La vigencia máxima permitida de los certificados TLS de confianza pública se reduce de forma gradual. Según los Baseline Requirements del CA/Browser Forum, se aplican los siguientes límites máximos a los certificados recién emitidos:

antes del 15 de marzo de 2026: 398 días como máximo;
del 15 de marzo de 2026 al 14 de marzo de 2027: 200 días como máximo;
del 15 de marzo de 2027 al 14 de marzo de 2029: 100 días como máximo;
a partir del 15 de marzo de 2029: 47 días como máximo.

El periodo permitido para reutilizar validaciones de dominio o IP completadas también se reduce en las mismas etapas: de 398 a 200, 100 y, finalmente, 10 días. Por tanto, el certificado y la validación subyacente tienen plazos distintos.

Según su aviso actual sobre la reducción de la vigencia, desde el 24 de febrero de 2026 DigiCert emite certificados TLS públicos con una vigencia máxima de 199 días. Los límites operativos de 99 y 46 días no están previstos hasta principios de 2027 y principios de 2029, respectivamente; las fechas exactas de la transición aún pueden cambiar. Por eso, la automatización supervisa el valor notAfter realmente emitido en lugar de asumir una vigencia anual fija.

Separar la función Let’s Encrypt integrada de una CA externa

La función Let’s Encrypt integrada en SFOS es un proceso propio administrado por el firewall. No es un cliente ACME genérico para DigiCert y no puede reconfigurarse sin más para usar una URL ACME de DigiCert. Para el proceso integrado, consulte Configurar certificados Let’s Encrypt en Sophos Firewall.

Cuando se utiliza una CA pública externa, la emisión se realiza en un sistema apropiado para ello. Solo el certificado terminado se transfiere después a SFOS mediante la API XML.

Identificar los requisitos independientes de la CA

Antes de la configuración, deben aclararse estos puntos con la CA elegida:

la autorización para el producto y los tipos de certificado permitidos;
el pedido, la suscripción u otra forma de pago;
la creación, vigencia y rotación de las credenciales ACME o API;
el método DCV admitido para cada nombre solicitado;
en el caso de OV/EV, la validación de la organización necesaria;
los plazos del certificado y de las validaciones de dominio y organización.

Las denominaciones y los pasos de aprobación varían según el proveedor. Por tanto, los siguientes datos de cuenta constituyen un ejemplo concreto de DigiCert, no un requisito general de las CA.

Ejemplo de DigiCert: preparar la cuenta y ACME

En CertCentral, la función de automatización debe estar activada para la cuenta correspondiente. A continuación, la configuración y la aprobación varían según el modelo de cuenta:

En las cuentas Enterprise, Partner y cuentas antiguas sin suscripción, solo un administrador de CertCentral puede crear la ACME Directory URL. Después puede entregar las credenciales creadas a una cuenta de servicio con permisos mínimos para la operación habitual.
En las cuentas Enterprise y otras cuentas sin suscripción debe estar activada la aprobación automática de solicitudes de certificado; sin ella, las solicitudes ACME fallan de forma predeterminada.
Las Subscription Accounts no necesitan este ajuste para la aprobación automática de solicitudes. No obstante, los productos disponibles y el estado de la suscripción deben ser adecuados.

De este modo, los permisos amplios necesarios para crear las credenciales quedan separados de la cuenta de automatización que se utilizará posteriormente. Antes del primer pedido, compruebe también la autorización para el producto, el método de pago y la asociación de la ACME Directory URL y el External Account Binding con la cuenta y el producto correctos. Una persona claramente responsable administra la creación, la rotación y la sustitución de emergencia de las credenciales.

Las credenciales ACME deben almacenarse en un gestor de secretos protegido. No deben escribirse en un repositorio, script de shell, ticket, ejemplo de wiki ni exportación de Postman.

Ejemplo de DigiCert: DCV para DV, OV y EV

En los certificados DV, DigiCert realiza de nuevo la Domain Control Validation en cada pedido ACME; las DCV anteriores no se validan previamente ni se reutilizan. El host de automatización debe poder completar el desafío elegido en cada renovación.

En los certificados OV y EV, la emisión ACME desatendida requiere que la organización se haya validado previamente. Además, el estado del dominio debe ser válido. Actualmente, DigiCert utiliza una validación de dominio OV/EV reutilizable durante 199 días; la validación de organización para certificados OV públicos puede reutilizarse actualmente durante 397 días. Ambos plazos se supervisan por separado del vencimiento del certificado.

Para un certificado wildcard como *.example.com, DNS-01 es el método de validación habitual. El acceso a la API de DNS solo debe permitir modificar la zona o el registro necesarios.

Configurar un host de automatización seguro

El host de automatización procesa temporalmente la clave privada, las credenciales de la CA y una contraseña de SFOS con permisos de escritura. Debe situarse en un entorno de administración protegido, no en un portátil de administración de uso general ni en cualquier entorno de ejecución de CI.

Los requisitos mínimos son:

sistema operativo reforzado y actualizado, con una persona claramente responsable;
IP de origen fija o red de administración estrictamente delimitada;
acceso saliente limitado a la CA, la API de DNS y los firewalls previstos;
credenciales separadas para la CA, DNS y cada firewall, o para grupos de firewalls claramente delimitados;
gestor de secretos en lugar de variables de entorno, salidas de diagnóstico, parámetros de línea de comandos o archivos de texto sin formato;
permisos de archivo restrictivos y directorio de trabajo temporal en almacenamiento cifrado;
ningún registro de claves privadas, contraseñas ni solicitudes XML completas;
ID de pedido, firewall de destino, nombre del certificado y resultado trazables, sin contenido secreto;
sincronización horaria y alertas en caso de errores repetidos o de una vigencia restante insuficiente.

Si la clave privada se transfiere cifrada a SFOS, la contraseña de importación no debería superar los 30 caracteres por motivos de compatibilidad. La ayuda de la GUI de SFOS indica este límite máximo, mientras que la ayuda de la API describe, según la compilación, entre 4 y 128 caracteres. El límite de 30 caracteres se utiliza únicamente por compatibilidad y no constituye una recomendación general sobre la longitud de las contraseñas. La contraseña aleatoria solo es válida para esta clave y se transporta de forma protegida.

La protección del origen, la cuenta de servicio, Device Access y los permisos de la API se describe en Proteger el acceso a la API XML de Sophos Firewall. En SFOS 22, en Administration > API access, solo se autoriza el IP Host del sistema de automatización en Allowed IP hosts. En versiones anteriores, la configuración de la API se encuentra en otra ruta del menú.

Prueba antes de la renovación en producción

La prueba utiliza un nombre prescindible como test-fw.example.com, un objeto de certificado independiente y un listener cuya interrupción sea aceptable. Se repite después de actualizaciones relevantes de SFOS o de la automatización.

Determinar el comportamiento de la compilación utilizada

Las pruebas determinan el comportamiento de la compilación concreta; no sustituyen ninguna garantía del fabricante. Deben comprobarse y registrarse los siguientes puntos:

la compilación exacta de SFOS y la API help local utilizada;
los campos exactos de add y update, así como el campo de identificación del objeto existente;
el resultado al volver a enviar la misma solicitud y después de una carga interrumpida;
el procesamiento de un archivo de certificado con certificados leaf e intermedios, así como los objetos de CA resultantes;
la cadena presentada realmente;
la conservación o pérdida de las referencias de WebAdmin, Portal, WAF y SMTP;
la activación necesaria del listener o cualquier reinicio del servicio;
en HA, la transferencia del certificado, la clave privada y la asignación, así como la presentación después de un failover.

No debe darse por supuesto que un archivo fullchain sea compatible sin haberlo comprobado. La automatización tampoco debe presuponer la idempotencia, la conservación de referencias ni que sea seguro repetir automáticamente una operación después de un error.

Del ejemplo local de adición/actualización a la solicitud

Así se crea una solicitud concreta para la compilación instalada, sin presentarla erróneamente como universal:

En la API help local del firewall de destino, vaya a System > Certificates > Certificate > Add Certificate / Update Certificate. Guarde la configuración de ejemplo y la descripción de los parámetros correspondientes exactamente a esa compilación.
Para el primer caso, utilice el wrapper add documentado. Para el segundo, adopte el update que se muestra allí y su campo de identificación. No copie el atributo de operación ni el identificador del objeto de otra compilación.
Sustituya únicamente los valores específicos del entorno en el ejemplo: inicio de sesión de la API procedente del gestor de secretos, nombre del objeto test-public-cert, acción para cargar el certificado, formato del certificado, nombre del archivo de certificado, nombre del archivo de la clave privada y, si procede, la contraseña de importación. Elimine las ramas del ejemplo que no sean necesarias, pero no modifique los nombres de los elementos ni su anidamiento.
Genere localmente la solicitud XML resultante como un reqxml efímero. Los dos nombres de archivo del XML deben coincidir exactamente con los archivos cargados.
En Postman o en la biblioteca HTTP utilizada, seleccione POST al siguiente endpoint y multipart/form-data:
```
https://<Firewall-FQDN>:<Admin-Port>/webconsole/APIController
```
Cree exactamente tres partes multipart: la parte de archivo indicada en la ayuda local para el certificado, la parte de archivo indicada allí para la clave privada y el campo de texto reqxml. No adivine los nombres de las dos primeras partes; tome sus nombres actuales y los nombres de archivo del ejemplo de la compilación de destino.
Ejecute primero add y después update con un certificado de prueba recién emitido. Envíe también una solicitud no válida en el entorno de prueba y vuelva a consultar el estado antes de repetirla.
La solicitud solo se aprueba cuando <Response> y <Status> indican el éxito esperado, se ha modificado exactamente el objeto previsto, no se han creado objetos de CA inesperados, la referencia del servicio se ha comportado según lo registrado y, tras la asignación, el listener externo presenta el nuevo certificado con una cadena válida. En HA, esto incluye un failover controlado.

A partir de los resultados, la solicitud se crea, prueba y aprueba internamente para esa compilación concreta. Los tres nombres de las partes, la plantilla XML, los valores de estado esperados y las condiciones de cancelación se versionan conjuntamente, sin guardar credenciales ni claves.

Comprobar el certificado antes de cargarlo

Los siguientes ejemplos utilizan estos valores de sustitución:

FQDN del servicio: vpn.example.com
nombre del objeto de SFOS: public-vpn-example-com
certificado leaf: vpn.example.com.pem
clave privada: vpn.example.com.key
bundle intermedio: intermediates.pem
bundle de raíces de confianza: trust-roots.pem
puerto HTTPS externo: 443

Primero, lea los datos del certificado:

openssl x509 -in vpn.example.com.pem -noout -subject -issuer -serial -dates -ext subjectAltName -fingerprint -sha256

El emisor, el periodo de validez, los SAN y la huella SHA-256 deben coincidir con el pedido. A continuación, compruebe que el certificado y la clave privada pertenecen al mismo par de claves sin mostrar la clave:

(
  tmpdir=$(mktemp -d)
  trap 'rm -rf -- "$tmpdir"' EXIT
  openssl x509 -in vpn.example.com.pem -pubkey -noout > "$tmpdir/cert-public-key.pem" &&
    openssl pkey -in vpn.example.com.key -pubout > "$tmpdir/key-public-key.pem" &&
    cmp "$tmpdir/cert-public-key.pem" "$tmpdir/key-public-key.pem"
)

cmp no produce ninguna salida si las claves públicas son idénticas. Si no coinciden, el proceso se cancela. Una clave privada cifrada solicita la contraseña de forma interactiva; en la automatización, esta procede del gestor de secretos y no aparece ni en la invocación del proceso ni en el registro.

La cadena prevista se comprueba con el almacén de confianza propio:

openssl verify -CAfile trust-roots.pem -untrusted intermediates.pem vpn.example.com.pem

trust-roots.pem contiene las CA raíz de confianza del entorno propio y intermediates.pem, las CA intermedias correspondientes a la emisión. La comprobación solo se considera correcta si devuelve vpn.example.com.pem: OK; cualquier otra salida detiene la carga.

Transferir el certificado mediante la API XML

Comprobaciones antes de la carga

Antes de escribir, compare el firewall de destino, la compilación de SFOS, el nombre del objeto y los servicios con el cambio aprobado. Deben estar disponibles una copia de seguridad actual de Sophos Firewall, el acceso de administración alternativo y el objeto de certificado anterior. Ejecute primero una consulta de lectura inocua con el mismo host y la misma cuenta de servicio. Los permisos de los archivos y las comprobaciones locales del certificado no deben mostrar errores.

Enviar la solicitud y evaluar la respuesta

La automatización envía la solicitud multipart aprobada durante la prueba. El certificado y la clave privada se transfieren como archivos; reqxml se genera en tiempo de ejecución y después se descarta. El cliente utiliza el FQDN correspondiente al certificado del firewall, valida su CA y cancela el proceso en caso de errores de nombre de host o de certificado. No se permite usar curl -k ni ninguna desactivación equivalente de la comprobación TLS.

Un estado HTTP 200 o Send successful solo confirma el transporte. La automatización evalúa en el XML, como mínimo, el elemento <Response> correspondiente a la operación y su <Status> utilizando los valores aprobados durante la prueba. En caso de timeout, respuesta incompleta o estado negativo, primero vuelve a consultar el estado del objeto o se detiene para una aclaración manual; no repite la solicitud de escritura sin comprobarla.

Comprobar el objeto y el archivo descargado

En Certificates > Certificates, busque el objeto de destino. En la GUI, compruebe los datos que allí se ofrecen realmente, en particular el nombre del objeto, el estado de la clave privada, Trusted, los valores Subject, Issuer y Purpose visibles al pasar el cursor, así como cualquier objeto de certificado o CA adicional inesperado.

No se presupone que el número de serie, los SAN, la fecha de vencimiento y la huella SHA-256 sean campos garantizados de la GUI. Exporte el certificado de destino mediante la acción de descarga de SFOS y compruebe el archivo descargado:

openssl x509 -in downloaded-vpn.example.com.pem -noout -serial -dates -issuer -subject -ext subjectAltName -fingerprint -sha256

Estos valores deben coincidir con los del archivo comprobado antes de la carga. El estado verde Trusted por sí solo no demuestra que la asignación al servicio sea correcta ni que la cadena del listener esté completa. Los formatos, la cadena y la importación mediante la GUI se explican en Importar y asignar certificados en Sophos Firewall.

Asignar el certificado al servicio

La importación y la asignación son cambios independientes. Un objeto nuevo debe asignarse expresamente al servicio deseado. En una actualización, se utiliza el procedimiento confirmado durante la prueba y, después de la ejecución, se comprueba si las referencias se han conservado realmente.

WebAdmin y portales

En Administration > Admin and user settings > Admin console and end-user interaction, el campo Certificate se aplica conjuntamente a WebAdmin Console, User Portal, VPN Portal, Captive Portal, SPX Registration y Reply Portal. El certificado debe incluir como SAN todos los nombres utilizados realmente. Después de pulsar Apply, compruebe por separado cada FQDN y puerto; mantenga abiertas una sesión de administración existente y una vía alternativa de administración local.

WAF

En una publicación WAF, el certificado se selecciona en la regla correspondiente, en Rules and policies > Firewall, mediante el campo HTTPS certificate. El dominio, SNI, Listen Port y SAN deben coincidir. Al guardar, se reinician las reglas de Web Server Protection y pueden interrumpirse las conexiones existentes. Durante la prueba con la compilación utilizada debe comprobarse si la sustitución de un certificado ya referenciado también provoca una recarga.

SMTP TLS

En el modo MTA, la selección se encuentra en Email > General settings > SMTP TLS configuration, en el campo TLS certificate. Después de pulsar Apply, compruebe por separado STARTTLS y, si procede, TLS implícito. Las VPN y otros usos de certificados pueden tener sus propias asignaciones; que el nombre sea idéntico no significa que cambien automáticamente.

Validar externamente con SNI y el puerto correcto

Primero, compruebe la cadena y el nombre de host desde un host de comprobación externo realista:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts -verify_hostname vpn.example.com -verify_return_error </dev/null

Deben aparecer los certificados intermedios necesarios y Verification: OK. -servername envía SNI; sustituya el FQDN y el puerto por los del servicio real.

La huella, el número de serie y otros datos del certificado leaf pueden leerse con un segundo paso ejecutable a partir de la misma configuración del listener:

(
  set -o pipefail
  tmpdir=$(mktemp -d)
  trap 'rm -rf -- "$tmpdir"' EXIT
  openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts \
    -verify_hostname vpn.example.com -verify_return_error </dev/null 2>"$tmpdir/s_client.log" |
    openssl x509 -out "$tmpdir/leaf.pem" &&
  openssl x509 -in "$tmpdir/leaf.pem" -noout -serial -fingerprint -sha256 -dates -issuer -subject -ext subjectAltName
)

El número de serie, la huella SHA-256, la vigencia, el emisor y los SAN deben coincidir con el certificado aprobado. A continuación, compruebe la propia aplicación, por ejemplo, iniciando sesión en el portal, realizando un health check de WAF u otra función end-to-end inocua. Un balanceador de carga, CDN o proxy inverso situado delante puede terminar TLS con otro certificado; por tanto, el punto de comprobación debe corresponder a la función de SFOS prevista.

SMTP con STARTTLS requiere una invocación propia:

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -verify_hostname mail.example.com -verify_return_error </dev/null

Para TLS implícito en el puerto 465, se omite -starttls smtp. También en este caso, la cadena y el nombre de host se confirman con Verification: OK; los datos del certificado leaf pueden leerse con el patrón de extracción anterior y las opciones de conexión adaptadas. Después, compruebe el flujo de correo real.

Ventana de mantenimiento, rollback y HA

Preparar la ventana de mantenimiento

La primera ejecución en producción y cualquier cambio en la solicitud, la compilación de SFOS, el producto de CA o la composición de la cadena se realizan durante una ventana de mantenimiento. El objeto anterior permanece disponible; se conocen las asignaciones afectadas, el acceso de administración alternativo y las personas responsables de la reversión y la comprobación externa.

Elegir la estrategia de rollback

Cuando se trata de un objeto nuevo, la vía de reversión más clara consiste en volver a seleccionar el certificado antiguo en el servicio afectado y probar de nuevo el listener externamente. Por este motivo, el objeto antiguo no se elimina en la misma ejecución.

Cuando se actualiza el objeto existente, solo se utiliza la vía de reversión confirmada durante la prueba. Si no se ha demostrado que sea seguro volver a importar el contenido anterior, se opta por un enfoque conservador: se crea un objeto nuevo independiente y después se asigna expresamente.

Probar HA por separado

En principio, SFOS sincroniza la configuración del Primary al Auxiliary en un clúster HA. Aun así, el certificado, la clave privada y la asignación al servicio deben comprobarse en ambos nodos o en el servicio compartido. A continuación, se realiza un failover controlado con una comprobación externa del listener. El proceso solo se aprueba para HA cuando esta prueba se supera.

Supervisión y operación recurrente

La automatización debe notificar con suficiente antelación los errores y las renovaciones que no se hayan producido. Deben supervisarse continuamente:

los días de vigencia restantes del certificado en el listener externo y la próxima ventana de renovación de la CA;
el estado de DCV y, en OV/EV, también la validación de la organización;
el último pedido a la CA y la última carga a SFOS completados correctamente;
la huella esperada y la presentada realmente;
los errores de la API, las respuestas ambiguas y las ejecuciones interrumpidas;
los nuevos objetos de certificado o CA no planificados;
el vencimiento y la rotación de las credenciales;
en HA, la última prueba de failover superada.

La alerta debe dejar tiempo suficiente para los tiempos de tramitación de la CA y de la DCV, la reacción interna, la ventana de mantenimiento y la reversión. Después de un cambio correcto, el certificado antiguo se conserva durante el periodo de observación definido. Los archivos temporales de certificados, claves y XML se eliminan de forma controlada; los datos probatorios almacenados de forma permanente solo contienen metadatos no secretos.

Solución de problemas por síntoma

La CA no emite un certificado nuevo

Compruebe con el proveedor correspondiente la autorización para el producto, el estado de la cuenta, el método de pago y la DCV. En el ejemplo de DigiCert, compruebe además la automatización y la aprobación automática de solicitudes específica del modelo de cuenta. En OV/EV, la organización y el dominio deben ser válidos. Compruebe los errores de DNS-01 en el DNS público autoritativo, no solo en el resolver local.

No se puede acceder a la API XML

Compruebe la IP de origen desde la perspectiva del firewall, Allowed IP hosts, Device Access, el enrutamiento, el puerto de administración y el certificado del firewall. La prueba debe realizarse desde el host de automatización real.

La solicitud HTTP se completa, pero el certificado no se actualiza

Compruebe <Response> y <Status>, no solo el código HTTP. Después, compare el nombre del objeto, el formato del archivo, la longitud de contraseña permitida y los campos específicos de la compilación con la ayuda local de la API. En Diagnostics > Troubleshooting logs pueden resultar útiles apiparser.log, validation.log y validationError.log; elimine todas las credenciales antes de compartirlos. Si el estado no está claro, descargue y compruebe primero el objeto de certificado en lugar de repetir la solicitud de escritura sin verificarla.

El objeto es nuevo, pero el servicio muestra el certificado antiguo

Compruebe la asignación al servicio, la regla WAF, la selección de certificado compartida por WebAdmin y los portales o la configuración de SMTP. Después, realice la prueba con SNI en el puerto correcto y descarte que haya un endpoint TLS situado delante.

El certificado no aparece como `Trusted` o la cadena está incompleta

Compare el emisor del certificado leaf con las CA intermedias instaladas. Utilice el procedimiento de importación confirmado durante la prueba y compruebe con -showcerts la cadena enviada por el listener.

Después de una actualización o un failover vuelve a aparecer el certificado antiguo

Determine qué nodo y listener están respondiendo. A continuación, compare la huella del objeto descargado, la referencia del servicio y el estado de HA. Si hay una discrepancia, ejecute la vía de reversión confirmada y detenga la automatización.

Lista de comprobación para la aceptación

La renovación en producción solo se aprueba cuando se cumplen todos los puntos:

La autorización de la CA, el pago, la DCV y, si procede, la validación de la organización son válidos.
La compilación, la ayuda local de la API y la solicitud multipart corresponden a la prueba superada.
Las comprobaciones locales del certificado, la clave y la cadena se completaron correctamente.
<Response> y <Status> indican el éxito esperado; se modificó exactamente el objeto de destino.
El archivo del objeto descargado tiene el número de serie, los SAN, la vigencia y la huella SHA-256 esperados; la clave privada y el estado Trusted son correctos y no se crearon objetos inesperados.
Cada FQDN y puerto real presenta con SNI el certificado nuevo, la cadena esperada y Verification: OK; el servicio correspondiente funciona.
En HA, se ha superado el failover controlado junto con la comprobación externa.
La supervisión detecta la nueva fecha de vencimiento y el resultado correcto; el certificado antiguo se conserva como vía de reversión hasta que finalice el periodo de observación.