Escenarios de uso

En muchos entornos, los certificados no se emiten directamente en el servidor final, sino en un nodo centralizado (por ejemplo, un cliente ACME en IIS o en un servidor de gestión).

Luego, estos certificados deben ser distribuidos hacia los sistemas que terminan conexiones TLS, como balanceadores (F5), firewalls (FortiGate) o servidores web.

Los scripts permiten automatizar esta distribución y evitar errores manuales en cada renovación.

• Servidores web (IIS, Apache, Nginx)
• Balanceadores (F5, HAProxy)
• Appliances de seguridad (FortiGate, etc.)

El certificado debe instalarse en todos los puntos donde se atienden conexiones HTTPS.

Formatos requeridos

Antes de realizar el deploy, es necesario contar con el certificado en el formato adecuado:

• PFX / PKCS#12 (IIS, F5, Windows) Cómo generar archivo .pfx
• PEM (CRT + KEY + CA) (Linux, Nginx, Apache) Cómo generar archivos PEM
• Bundle / Chain (compatibilidad completa) Cómo armar la cadena

La conversión y preparación de estos archivos es responsabilidad de cada cliente según su entorno.

Cambios en certificados raíz y cadena de confianza

Como parte de la modernización del ecosistema PKI, las autoridades certificantes han comenzado a emitir certificados bajo nuevas jerarquías de confianza, incorporando raíces modernas como Sectigo Public Server Authentication Root R46, orientadas a mejorar la seguridad y cumplimiento actual.

Ver explicación completa de jerarquía y certificados raíz

Scripts de referencia para deploy

A continuación se presentan ejemplos de comandos utilizados para la instalación de certificados en distintas plataformas (F5, FortiGate, Nginx, Apache, IIS).

Estos ejemplos están basados en documentación oficial de cada fabricante y representan procedimientos manuales de referencia.

Su objetivo es servir como guía para la construcción de scripts automatizados de deploy, los cuales deberán adaptarse según la infraestructura, arquitectura y políticas de cada entorno.

No constituyen soluciones completas listas para producción, sino fragmentos que deben integrarse dentro de procesos más amplios que contemplen validación, conversión de formatos y distribución de certificados.

tmsh install sys crypto cert midominio.crt from-local-file /config/ssl/midominio.crt
tmsh install sys crypto key midominio.key from-local-file /config/ssl/midominio.key

tmsh create ltm profile client-ssl mi_ssl_profile \
cert midominio.crt key midominio.key chain ca_bundle.crt

tmsh modify ltm virtual mi_virtual profiles add { mi_ssl_profile }

config vpn certificate local
edit "mi_certificado"
    set password "password_del_pfx"
    set file "midominio.pfx"
next
end

ssl_certificate /etc/ssl/midominio/fullchain.crt;
ssl_certificate_key /etc/ssl/midominio/private.key;

systemctl reload nginx

SSLCertificateFile /etc/ssl/midominio/cert.crt
SSLCertificateKeyFile /etc/ssl/midominio/private.key
SSLCertificateChainFile /etc/ssl/midominio/ca_bundle.crt

systemctl restart apache2

certutil -importpfx midominio.pfx

Lógica de automatización recomendada

Los scripts de deploy no deben limitarse únicamente a copiar certificados, sino que deben formar parte de un proceso automatizado que contemple el ciclo completo de renovación.

En un escenario típico, cada ejecución del script debería:

• Verificar si el certificado fue renovado o si existe una versión más reciente
• Generar o convertir el certificado al formato requerido (PFX, PEM, etc.)
• Construir correctamente la cadena de certificados (bundle)
• Distribuir los archivos hacia los sistemas destino (servidores, F5, FortiGate, etc.)
• Aplicar la configuración necesaria o recargar los servicios

Este flujo permite asegurar que todos los puntos de terminación TLS utilicen siempre certificados vigentes y correctamente instalados.

Ejecución periódica

• Programación mediante cron (Linux) o Task Scheduler (Windows)
• Frecuencia recomendada: diaria o cada pocos días
• Incluir validaciones para evitar reinstalaciones innecesarias

La frecuencia y lógica de ejecución deben ajustarse según la infraestructura y los procesos de cada entorno.

Buenas prácticas de seguridad

La gestión y despliegue de certificados debe cumplir con medidas de seguridad que protejan tanto las claves privadas como la integridad del entorno.

• Proteger la clave privada en todo momento. No debe ser expuesta, compartida ni almacenada en ubicaciones inseguras.
• Restringir el acceso a los certificados y claves únicamente a usuarios o procesos autorizados.
• Utilizar canales seguros (SCP, SFTP, HTTPS, APIs seguras) para la transferencia de certificados entre sistemas.
• Evitar almacenar contraseñas o credenciales en texto plano dentro de scripts.
• Limitar permisos sobre archivos de certificados y claves (por ejemplo, permisos mínimos en sistemas Linux).
• Mantener actualizados los trust stores de aplicaciones para evitar validaciones incorrectas o uso de raíces obsoletas.

Estas prácticas permiten reducir riesgos asociados a la exposición de claves, errores de validación y configuraciones inseguras en entornos productivos.

Consideraciones finales

Los ejemplos y lineamientos presentados en esta sección tienen como objetivo facilitar la implementación de procesos de deploy de certificados en distintos entornos.

Dado que cada infraestructura presenta características particulares, es necesario adaptar estos procesos según la arquitectura, políticas de seguridad y herramientas disponibles en cada organización.

Se recomienda validar cada implementación en entornos de prueba antes de su uso en producción, así como establecer mecanismos de monitoreo y control para asegurar la correcta renovación e instalación de los certificados.

Una correcta gestión del ciclo de vida de certificados es clave para garantizar la continuidad y seguridad de los servicios.