Certificados TLS y renovación automática
¿Por qué es necesario
TLS cifra el tráfico de «kliyent↔servis», confirma la autenticidad del servidor (y con el cliente mTLS) y protege contra la sustitución. Los principales riesgos son: caducidad de certificados, claves débiles, cadena de confianza incorrecta, procedimientos manuales. El objetivo del artículo es describir una arquitectura en la que los certificados son siempre relevantes y las rotaciones pasan desapercibidas para los usuarios.
Conceptos básicos
CA/Firmante: entidad de certificación (pública o interna).
Cadena (fullchain): certificado de hoja + intermedio + raíz (generalmente raíz en los almacenes cliente).
SAN (Subject Alternative Name): lista de dominios/IP para un único certificado (multi-SAN).
Wildcard: `.example. com '- conveniente para muchos subdominios, requiere la validación DNS.
OCSP stapling: el servidor aplica un estado de revocación fresco; reduce la latencia y la dependencia de OCSPs externos.
HPKP: obsoleto/no usar; en cambio, los registros CT y la higiene clave.
CT (Certificate Transparency): los registros públicos de emisión son importantes para controlar las emisiones falsas.
Cifrado y claves
Algoritmos:- ECDSA (P-256) - rápido y compacto; preferido para clientes modernos.
- RSA-2048/3072 - sigue siendo más compatible; puede sostener dual-cert (RSA + ECDSA).
- Generación de claves: solo en el lado objetivo (no transmitir privatizadores a través de la red), para proteger los derechos de acceso ('0600').
- HSM/KMS: para zonas críticas (pagos/PII), guarde las claves en HSM/KMS, active la auditoría de operaciones.
- Períodos de vida: los certificados cortos (90 días/30 días para los internos) fomentan la rotación frecuente y reducen el riesgo de compromiso.
Modelos de administración de arquitectura TLS
1. CA pública a través de ACME (Let's Encrypt/Buypass/etc.)
Validación: HTTP-01 (a través del servidor web/Ingress) o DNS-01 (para dominios wildcard/extracorriente).
Pros: libre/automatizado, confianza amplia. Contras: dependencias externas.
2. CA corporativa interna
Herramientas: HashiCorp Vault PKI, Smallstep (step-ca), Microsoft AD CS, CFSSL.
Pros: políticas personalizadas, mTLS, TTL cortas, liberación para dominios internos. Contras: distribución de raíz, gestión de confianza.
3. Híbrido
CA pública para usuarios externos; CA interno - para servicio-a-servicio (mTLS), canales interclúster y almirantes.
Patrones de renovación automática (renew)
Principios
Umbral de renovación: comenzar a los '≤ 30' días antes de la expiración; para servicios críticos - a '≤ 45' días.
Zero-downtime: emisión de un nuevo certificado, reemplazo atómico, reload suave sin rotura de compuestos.
Doble sujeción (azul/verde): almacenar el cert actual y siguiente; conmutación - a través de symlink o versionada secret.
Alerting: alertas para 45/30/14/7/3/1 día; alerta separada cuando ACME Challenge falla.
Clientes ACME y sus aplicaciones
certbot / acme. sh/lego: agentes ligeros en VM/bare-metal.
cert-manager (Kubernetes): operador que trabaja con Issuer/ClusterIssuer; automatiza release/renew y escribe en Secret.
step-ca/Vault Agent: liberación/rotación automática con TTL cortos, patrones sidecar para actualizar claves y cadenas.
Procesos para Kubernetes
cert-manager (ejemplo de Issuer para Let's Encrypt, HTTP-01 a través de Ingress):yaml apiVersion: cert-manager. io/v1 kind: ClusterIssuer metadata:
name: le-http01 spec:
acme:
email: devops@example. com server: https://acme-v02. api. letsencrypt. org/directory privateKeySecretRef:
name: le-account-key solvers:
- http01:
ingress:
class: nginx
Solicitud de certificado:
yaml apiVersion: cert-manager. io/v1 kind: Certificate metadata:
name: app-cert namespace: prod spec:
secretName: app-tls dnsNames:
- app. example. com issuerRef:
name: le-http01 kind: ClusterIssuer privateKey:
algorithm: ECDSA size: 256 renewBefore: 720h # 30 дней
La sustitución en caliente en NGINX-Ingress se produce automáticamente cuando se actualiza 'Secret'. Agregue 'ssl-ecdh-curve: secp256r1' y active OCSP stapling a través de anotaciones/ConfigMap.
Procesos para VM/Bare-metal
Certbot (HTTP-01):bash sudo certbot certonly --webroot -w /var/www/html -d example. com -d www.example. com \
--deploy-hook "systemctl reload nginx"
Periódico 'certbot renew' a través de systemd timer.
Para el comodín, utilice el DNS-01 (proveedor de plugin) y el similar '--deploy-hook'.
bash export CF_Token="" # example for Cloudflare acme. sh --issue --dns dns_cf -d example. com -d '.example. com' \
--keylength ec-256 --ecc \
--reloadcmd "systemctl reload nginx"
NGINX: reemplazo atómico
Almacena 'fullchain. pem` и `privkey. pem 'bajo rutas estables (symlink en archivos versionados), luego' nginx -s reload '.
PKI y mTLS internos
HashiCorp Vault PKI (rol de ejemplo):bash vault secrets enable pki vault secrets tune -max-lease-ttl=87600h pki vault write pki/root/generate/internal common_name="Corp Root CA" ttl=87600h vault write pki/roles/service \
allowed_domains="svc. cluster. local,internal. example" allow_subdomains=true \
max_ttl="720h" require_cn=false key_type="ec" key_bits=256
Salida de autobús: a través de Vault Agent Injector (K8s) o sidecar; la aplicación vuelve a leer cert desde el archivo/FS-watcher.
TTL corto: 24-720 horas, que estimula la rotación frecuente y reduce el valor de la llave robada.
mTLS: emita certificados de cliente para servicios/roles específicos; en la entrada - TLS mutual en ingress/sidecar-proxy.
Operación segura
La separación de secretos: claves privadas - sólo en host/pode, acceso por el principio de los privilegios más pequeños.
Derechos de archivo: '600' para clave; propietario - usuario del proceso.
Período de gracia: instale 'renewBefore' lo suficiente para tener en cuenta las fallas de DNS/ACME/proveedor.
OCSP Stapling: incluir en los frentes; seguir la frescura de la respuesta (generalmente 12-72 h).
HSTS: habilitar gradualmente (sin 'preload' en el inicio), asegurándose de que la entrega HTTPS de todo el contenido sea correcta.
Dual-cert (RSA + ECDSA): mejora la interoperabilidad y el rendimiento; dar ECDSA a los clientes modernos.
Monitoreo y SLO
Métricas y validaciones:- Días antes de la expiración (gauge) de cada dominio/secreto; SLO: «No cert desde <7 días hasta expirar».
- Validez de cadena (linting), cumplimiento de SAN con los dominios/IP requeridos.
- Stapling de OCSP (frescura de la respuesta).
- Porcentaje de desafíos ACME exitosos/fallidos.
- Leitensy TLS-apretón de manos, versiones de protocolo/cifrado (audit).
- Warn: 30 días antes de la expiración.
- Crit: 7 días/fracaso 'renew'.
- Page: 72 horas/cadena no válida en venta/falta OCSP stapling.
Incidentes y retrocesos
Caducidad del certificado: reiniciar temporalmente y aplastar manualmente, fijar el RCA (por qué no se activó el renew, bloqueos DNS/restricciones de API).
Compromiso clave: relanzamiento/revocación inmediata, rotación de secretos, auditoría de acceso, rotación de tokens de proveedor DNS/cuenta ASME.
Una cadena incorrecta: un déploma urgente de la correcta 'fullchain', un reload forzado de los frentes.
Lock-in al proveedor de DNS: mantenga la ruta de validación en espera (HTTP-01) o el DNS secundario.
Lista de comprobación de implementación de reproducción automática
1. Seleccione un modelo (CA público a través de ACME/PKI interno/híbrido).
2. Identificar criptoprofilo: ECDSA-P256, si es necesario, dual-cert con RSA-2048.
3. Configure el agente automático (cert-manager, certbot, acme. sh, Vault Agent).
4. Organice el reemplazo zero-downtime (patrón symlink, hot-reload ingress/NGINX/Envoy).
5. Habilite OCSP stapling y HSTS (por etapas).
6. Agregue una alerta de fechas y estados de desafío; recetar SLO.
7. Documente los procesos de break-glass y la liberación manual.
8. Realizar ejercicios «falsos»: DNS-01 roto, caída ACME, raíz vencida/intermedio.
9. Revisa los accesos a las claves privadas, rota los tokens del proveedor de DNS y las cuentas de ACME.
Características para iGaming/fintech
PCI DSS/PII: rigurosas Suites de Cipher, forzadas por TLS 1. 2+/1. 3, apague los cifrados/compresión débiles, resunción de sesión sin compromiso de seguridad.
Segmentación de dominios: certificados individuales para subdominios de pago y admiradores; para proveedores de contenido: cadenas aisladas.
Auditoría y lógica: confirmar la liberación/revocación/rotación; Firma los artefactos CI/CD.
Multirregional: Issuer locales por región para no depender de fallas cruzadas por región.
Ejemplos de configuración
NGINX (RSA+ECDSA, OCSP stapling)
nginx ssl_protocols TLSv1. 2 TLSv1. 3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_ecdh_curve secp256r1;
ssl_certificate /etc/nginx/certs/app_ecdsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_ecdsa/privkey. pem;
ssl_certificate /etc/nginx/certs/app_rsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_rsa/privkey. pem;
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=31536000" always;
OpenSSL: CSR (ECDSA-P256)
bash openssl ecparam -name prime256v1 -genkey -noout -out privkey. pem openssl req -new -key privkey. pem -out csr. pem -subj "/CN=app. example. com" \
-addext "subjectAltName=DNS:app. example. com,DNS:www.example. com"
CFSSL: perfil y emisión
json
{
"signing": {
"profiles": {
"server": {
"usages": ["digital signature","key encipherment","server auth"],
"expiry": "2160h"
}
}
}
}
bash cfssl gencert -profile=server ca. json csr. json cfssljson -bare server
FAQ
¿Necesitas un comodín?
Si a menudo aparecen subdominios nuevos - sí (a través de DNS-01). De lo contrario, utilice multi-SAN para dominios explícitos.
¿Qué elegir: cert-manager o certbot?
Kubernetes → cert-manager. VM/microservicios hacia fuera K8s → certbot/lego/acme. sh. PKI interno → Vault/step-ca.
¿Es posible reducir la TTL a un día?
Para los mTLS internos, sí, si la automatización/sidecar garantiza la rotación y las aplicaciones son calientes.
¿Cómo puedo mantener a la DNS-01 segura?
Token separado/acceso mínimo a la zona, rotación de claves, restringir el acceso IP API, auditar.
Resultado
La gestión confiable de TLS es una combinación de criptoprofilo correcto, liberación y extensión automatizadas, rotaciones cero-downtime, observabilidad y procedimientos claros de incidente-respuesta. Construya un transportador ACME/PXI, agregue alertas estrictas y entrene regularmente escenarios de «emergencia» - y los certificados caducados dejarán de ser la fuente de los buscapersonas nocturnos.