GH GambleHub

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'.

acme. sh (DNS-01, wildcard):
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).
Alertas (niveles de ejemplo):
  • 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.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.