Automatizar la renovación de la PKI interna: integrar ACME, HashiCorp Vault y systemd-timers

Introducción: Automatizar la renovación de una PKI interna es esencial para operadores y administradores cuando se gestionan numerosos certificados TLS internos —por ejemplo para servicios internos, gateways IoT, VPNs o autenticación de clientes. En este artículo muestro de forma práctica cómo enlazar ACME (Automated Certificate Management Environment — protocolo para la emisión automatizada de certificados) con HashiCorp Vault (Vault — gestión de secretos y motor opcional de firma PKI) y utilizar systemd‑timers (systemd‑Timers — planificador moderno en Linux con integración con Journald), de modo que las renovaciones se programen, ejecuten y distribuyan de forma fiable.

Por qué es necesaria la automatización del PKI‑Renewal

Los certificados suelen expirar de forma simultánea en cientos de hosts. Reemplazarlos manualmente es propenso a errores, provoca interrupciones y deja huecos en las auditorías. La automatización reduce esfuerzo, disminuye riesgos de indisponibilidad y garantiza procesos de seguridad consistentes. Aún así, la gobernanza sigue siendo central: la duración de validez, los roles, los registros de auditoría y los conceptos de acceso de mínimo privilegio deben definirse antes de pasar a producción.

Automatizar la renovación de la PKI interna: vista arquitectónica

La separación recomendada consta de tres capas:

• Capa de firma: Vault como CA/firmante interna. El motor PKI de Vault firma los CSR; la clave raíz debería permanecer idealmente offline.
• Capa de protocolo/integración: un proxy ACME o un servicio frontend compatible con ACME recibe las peticiones ACME y las traduce a llamadas de firma hacia Vault.
• Capa de operaciones: systemd‑timers en los hosts o en runners centrales programan y ejecutan los jobs de renovación, además de distribuir y validar los certificados.

Esta separación mejora la seguridad, la auditabilidad y la flexibilidad operativa: la firma, la autenticación y el programación tienen responsabilidades independientes.

Decisiones de diseño y prerrequisitos

Preguntas importantes antes de empezar:

• Root vs. Intermediate: utilice Vault como intermedio, firmado por una root mantenida offline. Esto minimiza la exposición de la root.
• Duración: duraciones más cortas (p. ej. 90 días) aumentan la seguridad, pero incrementan la frecuencia de renovaciones y la carga.
• Distribución de confianza: asegúrese de que los clientes reciban el bundle de CA (vía CM‑Tooling, paquete, MDM).
• Autenticación de máquinas: mTLS (p. ej. con certificados de máquina de producción) o Vault AppRole son patrones habituales —ambos tienen ventajas e inconvenientes respecto al manejo de secretos y su duración.
• Observabilidad y auditoría: active los Vault Audit Devices y recoja los logs del proxy/hosts.

Patrones de implementación: petición directa del cliente vs. ACME‑Proxy

Dos patrones comunes:

Cliente ACME directo en los hosts

Los clientes (p. ej. acme.sh, certbot) solicitan los certificados por sí mismos. Ventaja: descentralizado y robusto; desventaja: mayor trabajo de configuración y autenticación más compleja frente a Vault.

Proxy ACME central

Un proxy central valida las peticiones, autentica los hosts (mTLS, OAuth) y se comunica con Vault. Ventaja: control centralizado y auditoría simplificada; desventaja: camino de red adicional y requisitos de disponibilidad.

Configuración concreta: Vault PKI, ACME‑Proxy, systemd‑timers

Los pasos centrales son:

1. Configurar el motor Vault PKI y preparar el intermedio.
2. Implementar el ACME‑Proxy (p. ej. con lego o un componente ligero en Go) que autentique las peticiones y las mapee a Vault.
3. Crear unidades systemd‑timer que ejecuten periódicamente scripts de renovación, verifiquen certificados y recarguen servicios.

Vault PKI: comandos de ejemplo

vault secrets enable pki
vault secrets tune -max-lease-ttl=87600h pki
vault write pki/root/generate/internal common_name="Company Internal Root" ttl=87600h
vault write pki/intermediate/generate/internal common_name="Company Intermediate" | tee csr.json
vault write pki/root/sign-intermediate csr=@csr.json format=pem_bundle ttl=43800h > signed_intermediate.pem
vault write pki/intermediate/set-signed certificate=@signed_intermediate.pem

Vault separa así Root e Intermediate, lo que permite una gestión segura de claves. Si las firmas fallan: compruebe los permisos del token de Vault, los registros de auditoría y la configuración de TTL.

ACME‑Proxy: Aufgaben und Mapping

El proxy debe:

• Autenticar hosts (mTLS o token).
• Comprobar valores como CN/SAN frente a patrones permitidos.
• Asignar las solicitudes a una role de Vault y hacer que se firmen.
• Aplicar limitación de tasa y generar registros de auditoría.

Ejemplo de mapeo YAML:

acme:
  auth_method: mTLS
  allowed_roles:
    - name: webserver
      allowed_sans:
        - '*.svc.internal'
      vault_role: webserver-role
    - name: dbserver
      allowed_sans:
        - 'db-*.internal'
      vault_role: dbserver-role
rate_limit:
  requests_per_minute: 60

systemd‑timers: zuverlässiges Scheduling

Los systemd‑timers ofrecen RandomizedDelaySec, integración con Journald, Persistent=true (ejecuta los trabajos tras una caída del sistema) y mejor control que cron. Ejemplo Service+Timer:

# /etc/systemd/system/pki-renew.service
[Unit]
Description=Run PKI renewal script
After=network-online.target

[Service]
Type=oneshot
User=root
ExecStart=/usr/local/bin/pki-renew.sh

# /etc/systemd/system/pki-renew.timer
[Unit]
Description=Timer for PKI renewal

[Timer]
OnCalendar=*-*-* 02:00:00
RandomizedDelaySec=3600
Persistent=true

[Install]
WantedBy=timers.target

El script en sí debería operar de forma atómica: archivo de bloqueo, directorio temporal y códigos de error claros. Ejemplo de esqueleto:

#!/bin/bash
set -euo pipefail
LOCKDIR=/var/lock/pki-renew.lock
if ! mkdir "$LOCKDIR" 2>/dev/null; then
  echo "Another run in progress" >&2
  exit 0
fi
trap 'rm -rf "$LOCKDIR"' EXIT

# Anfrage an ACME-Proxy und lokale Installation
/usr/local/bin/acme-request --cn "$(hostname -f)" --out /etc/ssl/private/host.pem
systemctl reload nginx || systemctl RESTart nginx

Praxisbeispiel: Vault‑Policy und ACME‑Role

Policies begrenzen, welche Rollen welche SANs/CNs signieren dürfen. Beispiel Vault‑Policy (HCL):

# webserver-policy.hcl
path "pki/issue/webserver-role" {
  capabilities = ["create", "update"]
}

# Allow read of CA bundle
path "pki/cert/ca" {
  capabilities = ["read"]
}

La role define patrones de SAN y TTL:

vault write pki/roles/webserver-role  
  allowed_domains="svc.internal"  
  allow_subdomains=true  
  max_ttl="72h"

Si la Policy es demasiado permisiva, existe riesgo de abuso; si es demasiado RESTrictiva, la automatización se rompe. Pruebe de forma iterativa en Staging.

Deployment und atomare Installation von Zertifikaten

Un error operativo frecuente es una instalación de certificados inconsistente, en la que los archivos quedan medio escritos y los servicios se reinician con ficheros incompletos. Utilice patrones atómicos: escriba los nuevos artefactos en una ruta temporal, valide el archivo y sustituya mediante un enlace simbólico (symlink). De este modo se consigue una imagen consistente del sistema de ficheros y el rollback es sencillo.

# atomare Installation
TMPDIR=/tmp/new-cert-$$
mkdir -m 700 "$TMPDIR"
cp cert.pem "$TMPDIR/"
cp key.pem "$TMPDIR/"
# Validieren
openssl x509 -noout -text -in "$TMPDIR/cert.pem" >/dev/null
# Atomisch tauschen
mv /etc/ssl/current /etc/ssl/old-$(date +%s) || true
ln -sfn "$TMPDIR" /etc/ssl/current
systemctl reload myservice

En Windows o en entornos containerizados, recurra a mecanismos adecuados: p. ej. PKCS#12‑Bundles para IIS/Windows o Mount‑Overlays para contenedores.

HSM, TPM y Vault Transit: no exportar las claves

Para claves especialmente sensibles, utilice HSMs (Hardware Security Module — almacenes de claves dedicados y certificados) o TPM (Trusted Platform Module — Root of Trust vinculado a la placa base). El Transit Engine de Vault permite firmar/verificar sin exportar las claves privadas. Flujo operativo: Root en el HSM, Vault configura Transit como firmante, se generan y firman los certificados intermedios mediante Transit, los clientes reciben únicamente certificados.

Contenedores y Kubernetes: particularidades

En entornos cloud y de contenedores existen RESTricciones adicionales: los sistemas de archivos son efímeros, los Init‑Containers pueden proporcionar certificados antes del arranque. Los clústeres de Kubernetes suelen usar Secrets; aquí debería cifrar los Secrets (p. ej. Sealed Secrets) y controlar los rollouts mediante Deployments con readiness‑probes. PRESTe atención a los permisos de los kubelets: no deberían tener acceso ilimitado a las rutas de firma.

Detalles de monitorización y métricas

Diseñe métricas de forma granular: pki_renew_requests_total, pki_renew_success_total, pki_renew_failures_total, pki_cert_age_seconds así como gauges por parte del exporter para los días RESTantes hasta el vencimiento. Las alertas deberían vigilar no solo las tasas de error, sino también incrementos en la latencia de renovación — un indicador de problemas de rendimiento en el proxy.

Pruebas de caos, comprobaciones en staging y validación

Pruebe la resiliencia: simule fallos de Vault, particiones de red y golpes de rate‑limit. Ejecute canaries antes de un cambio global: un pequeño grupo de hosts recibe el nuevo CA‑Bundle, p. ej. mediante un Ansible‑Playbook. Use pruebas sintéticas end‑to‑end que verifiquen un TLS‑handshake antes y después de la renovación.

Runbook operativo: procedimiento paso a paso ante errores de renovación

1. Compruebe la hora del sistema: timedatectl status — el drift del reloj rompe TLS.
2. Estado de Vault y auditoría: vault status y revisar los logs de auditoría.
3. Logs del proxy: compruebe 401/403 (auth), 429 (rate limit) y 5xx (errores de servidor).
4. Compruebe el script del host: lockfiles, SELinux‑contexto, binarios faltantes, permisos.
5. Ejecute una petición manual vía Staging‑ACME para identificar problemas de ruta.

Ejemplo: script de renovación robusto con flock y logging

#!/usr/bin/env bash
set -euo pipefail
exec 3>&1
LOG=/var/log/pki-renew.log
flock -n /var/lock/pki-renew.lock -c "bash -c '
  echo "$(date -Iseconds) START" | tee -a $LOG
  /usr/local/bin/acme-request --cn "$(hostname -f)" --out /etc/ssl/private/host.pem || { echo "request failed" | tee -a $LOG; exit 2; }
  chown root:ssl-cert /etc/ssl/private/host.pem && chmod 640 /etc/ssl/private/host.pem
  systemctl try-reload-or-RESTart myservice || { echo "reload failed" | tee -a $LOG; exit 3; }
  echo "$(date -Iseconds) OK" | tee -a $LOG
'"

Los códigos de salida ayudan a las herramientas de alertas a asignar causas concretas. No olvide la rotación de logs.

Errores típicos y medidas de precaución

• Hora/Zona horaria: TLS depende del tiempo; diferencias en la hora del sistema provocan errores de validación.

Conclusión

Automatizar la renovación interna de PKI reduce la carga operativa y los riesgos de indisponibilidad, pero exige una arquitectura limpia, políticas RBAC, observabilidad y vías de emergencia definidas. La combinación de HashiCorp Vault como firmador, un ACME‑proxy como puente de protocolo y systemd‑timers como planificador está probada en la práctica: separa responsabilidades, facilita la auditoría y escala, siempre que tenga en cuenta los límites de tasa y el escalonamiento. Pruebe en staging, realice pruebas de caos y documente los runbooks: así su sistema de renovación seguirá siendo controlable y resistente a fallos.

Seguridad operativa, recuperación y escalado — complementos prácticos

En la operación productiva de una pila de renovación de PKI automatizada no sólo las configuraciones determinan el éxito, sino también los procesos operativos y los escenarios de fallo. A continuación encontrará indicaciones concretas sobre backup/recuperación, alta disponibilidad, procesos de rollover y protección frente al abuso — todo con enfoque en admins y decisores de TI.

Backup de Vault, Unseal y estrategias de Auto‑Unseal

No haga copias sólo de la base de datos: asegure sobre todo los materiales de Unseal: Shamir‑Shares, claves HSM o configuraciones de Cloud‑KMS. Si usa Shamir, debe definir recovery‑shops y roles (quién tiene acceso a cuántos shares). El Auto‑Unseal mediante Cloud‑KMS o HSM reduce el trabajo manual en reinicios, pero crea nuevas dependencias: segregue estrictamente los derechos de acceso al KMS y mantenga registros de acceso (audit) para los eventos de Unseal.

HA, replicación y fallo regional

Vault en modo HA (Integrated Storage o backends consistentes como Consul) permite replicación Read/Write. Decida si necesita replicación activa‑activa o activa‑pasiva. Para el ACME‑Proxy se recomienda escalado horizontal con sticky‑sessions o una persistencia centralizada para los contadores de Rate‑Limit, de modo que un failover no genere solicitudes duplicadas. Pruebe el failover entre centros de datos: apague una región, valide las latencias de firmado y si el Auto‑Unseal funciona correctamente.

Rotación de claves/CA y compatibilidad

Un rollover planificado de la CA intermedia es un procedimiento normal pero crítico. Ejecútelo de forma gradual: prepare la nueva intermedia, fírmela con la Root correspondiente, distribuya los nuevos bundles de CA en paralelo y establezca periodos de solapamiento prolongados para que los clientes acepten ambas cadenas. Documente los escenarios de retroceso: cómo volver a la intermedia anterior si hay incompatibilidades con clientes.

Revocación, CRL y diseño OCSP

Decida con antelación si va a usar CRLs, OCSP o ambos. Las CRL son fáciles de implementar, pero no escalan bien; OCSP funciona en línea, pero requiere un responder de baja latencia y alta disponibilidad. Para redes internas puede servir un OCSP‑Responder ligero delante de la PKI de Vault; asegúrese de que los clientes reciben las URLs correctas de CRL/OCSP y pruebe escenarios offline para cuando los responders no estén disponibles.

Notfallprozesse und minimaler Zugriff

Defina claramente: ¿Quién está autorizado a firmar/anular firmas manualmente en caso de emergencia? Establezca un proceso con aprobación de cambios, auditoría a corto plazo y escalados RBAC temporales. Automatice la exportación de auditorías para un análisis forense rápido. Proteja los puntos de firma con autenticación adicional (por ejemplo, mTLS + Vault AppRole) y limite las tasas de firma por rol.

Escalado del proxy ACME y comprobaciones de monitorización

Escale instancias de proxy detrás de un balanceador de carga; mantenga un Redis/DB central para límites de tasa y el estado de las solicitudes. Mida latencia y tasas de error por separado: una latencia elevada al firmar indica cuellos de botella en el backend (CPU de Vault/HSM). Las alertas deberían, además de errores, notificar también un aumento en la densidad de renovaciones —un indicador temprano de fallos del sistema o de planificación.

En resumen: invierta tiempo en procedimientos de recuperación, planes de rollback claros, pruebas de rollover y líneas base de monitorización. Solo así su automatización de PKI será no solo cómoda, sino también segura en operación, auditable y escalable.

Para este tema también son importantes los temporizadores de systemd y la gestión de certificados. El artículo ordena estos aspectos de forma comprensible y muestra en qué hay que centrarse en el día a día.