Certificats TLS et renouvellement automatique

Pourquoi est-ce nécessaire

TLS chiffre le trafic « kliyent↔servis », confirme l'authenticité du serveur (et avec mTLS - client) et protège contre la substitution. Les principaux risques sont : les certificats périmés, les clés faibles, la chaîne de confiance erronée, les procédures manuelles. Le but de l'article est de décrire l'architecture dans laquelle les certificats sont toujours à jour et les rotations sont invisibles pour les utilisateurs.

Notions de base

CA/Signataire : autorité de certification (publique ou interne).
Chain (fullchain) : certificat de feuille + intermédiaire + racine (généralement racine dans les référentiels clients).
SAN (Subject Alternative Name) : Liste des domaines/IP pour un seul certificat (multi-SAN).
Wildcard: `.example. com '- pratique pour de nombreux sous-domaines, nécessite une validation DNS.
Stapling OCSP : le serveur applique un nouveau statut de révocation ; réduit les retards et la dépendance vis-à-vis des OCSP externes.
HPKP : obsolète/ne pas utiliser ; au lieu de cela - les logs CT et l'hygiène clé.
CT (Certification Transparency) : Logs d'émission publics - important pour le contrôle des rejets frauduleux.

Cryptophile et clés

• ECDSA (P-256) - rapide et compact ; préféré pour les clients modernes.
• RSA-2048/3072 - toujours plus compatible ; il est possible de conserver un double cert (RSA + ECDSA).
• Génération de clés : uniquement sur le côté cible (ne pas transférer de privatismes sur le réseau), protéger les droits d'accès ('0600').
• HSM/KMS : pour les zones critiques (paiement/PII), stockez les clés dans HSM/KMS, activez l'audit des transactions.
• Durée de vie : les certificats courts (90 jours/30 jours pour l'intérieur) encouragent la rotation fréquente et réduisent le risque de compromission.

Modèles de gestion architecturale TLS

1. CA public via ACME (Let's Encrypt/Buypass/, etc.)

Validation : HTTP-01 (via le serveur Web/Ingress) ou DNS-01 (pour les domaines wildcard/extraterrestres).
Avantages : gratuit/automatisé, grande confiance. Inconvénients : dépendances extérieures.

2. Entreprise interne CA

Outils : HashiCorp Vault PKI, Smallstep (step-ca), Microsoft AD CS, CFSSL.
Avantages : politiques personnalisées, mTLS, TTL courts, sortie pour les domaines internes. Inconvénients : distribution racine, gestion de la confiance.

3. Hybride

CA public pour les utilisateurs externes ; CA interne - pour le service-k-service (mTLS), les canaux interclastres et les amiraux.

Modèles de renouvellement automatique (renew)

Principes généraux

Seuil de renouvellement : commencer à '≤ 30' jours avant l'expiration ; pour les services critiques - à « ≤ 45 » jours.
Zero-downtime : sortie d'un nouveau certificat, remplacement atomique, reload sans rupture de connexion.
Double maintien (bleu/vert) : stocker le cert actuel et suivant ; commutation - via symlink ou secret versionné.
Alerting : avertissements 45/30/14/7/3/1 jour ; un alert séparé lors de l'échec du challenge ACME.

Les clients ACME et leur application

certbot / acme. sh/lego : agents légers sur VM/bare-metal.
cert-manager (Kubernetes) : opérateur travaillant avec Issuer/ClusterIssuer ; automatise release/renew et enregistre dans Secret.
step-ca/Vault Agent : sortie/rotation automatique avec TTL courts, modèles sidecar pour mettre à jour les clés et les chaînes.

Processus pour Kubernetes

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

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 дней

Le remplacement à chaud dans NGINX-Ingress est automatique lorsque 'Secret' est mis à jour. Ajoutez 'ssl-ecdh-curve : secp256r1' et activez le stapling OCSP via annotations/BouMap.

Processus pour VM/Bare-metal

bash sudo certbot certonly --webroot -w /var/www/html -d example. com -d www.example. com \
--deploy-hook "systemctl reload nginx"

Périodique 'certbot renew' via systemd timer.
Pour la wildcard, utilisez un DNS-01 (plugin fournisseur) et un '--deploy-hook' similaire.

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 : Remplacement atomique

Gardez 'fullchain. pem` и `privkey. pem 'sous les chemins stables (symlink par fichiers versionnés), puis « nginx -s reload ».

PKI interne et mTLS

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

Autopartage : via Vault Agent Injector (K8s) ou sidecar ; l'application relit le cert du fichier/FS-watcher.
Court TTL : 24-720 heures, ce qui stimule la rotation fréquente et réduit la valeur de la clé volée.
mTLS : émettre des certificats client pour des services/rôles spécifiques ; à l'entrée, le mutual TLS dans ingress/sidecar-proxy.

Exploitation sécurisée

Séparation des secrets : clés privées - uniquement sur l'hôte/sous-sol, accès selon le principe des plus petits privilèges.
Autorisations de fichier : '600' pour la clé ; le propriétaire est l'utilisateur du processus.
Période Grace : installez 'renewBefore' suffisamment pour tenir compte des pannes DNS/ACME/fournisseur.
Stapling OCSP : inclure sur les fronts ; surveiller la fraîcheur de la réponse (habituellement 12-72 h).
HSTS : Activer progressivement (sans 'preload' au départ), en veillant à ce que tous les contenus soient correctement livrés par HTTPS.
Dual-cert (RSA + ECDSA) : améliore l'interopérabilité et les performances ; donnez ECDSA aux clients modernes.

Surveillance et SLO

• Jours avant l'expiration (gauge) pour chaque domaine/secret ; SLO : « pas de cert avec <7 jours avant expiry ».
• Validation de la chaîne (linting), conformité du SAN aux domaines/IP requis.
• Statut de stapling OCSP (fraîcheur de la réponse).
• Proportion de challenges ACME réussis/échoués.
• Poignée de main TLS, versions protocole/cryptage (audit).

• Warn : 30 jours avant l'expiration.
• Crit : 7 jours/échec « renew ».
• Page : 72 heures/chaîne non validée en vente/pas de stapling OCSP.

Incidents et retours

Certificat expiré : Transférez temporairement et mettez-le à la main, fixez RCA (pourquoi renew n'a pas fonctionné, verrouillage DNS/restriction API).
Compromis clé : transfert/retrait immédiat, rotation des secrets, audit d'accès, rotation des tokens du fournisseur DNS/compte ASME.
Chaîne incorrecte : Déplie urgente du « fullchain » correct, reload forcé des fronts.
Lock-in au fournisseur DNS : conservez le chemin de validation de secours (HTTP-01) ou le DNS secondaire.

Chèque de mise en œuvre de l'extension automatique

1. Sélectionnez le modèle (CA public via ACME/PKI interne/hybride).
2. Identifiez le cryptophile : ECDSA-P256, si nécessaire, double-cert avec le RSA-2048.
3. Configurez l'agent automatique (cert-manager, certbot, acme. sh, Vault Agent).
4. Organisez un remplacement zero-downtime (symlink-pattern, hot-reload ingress/NGINX/Envoy).
5. Activer le stapling OCSP et le HSTS (par étapes).
6. Ajouter une alerte sur les échéances et les statuts des challenges ; prescrire un SLO.
7. Documentez les processus de break-glass et de sortie manuelle.
8. Faites des exercices « fael » : un DNS-01 cassé, une chute ACME, une racine expirée/intermédiaire.
9. Révisez les accès aux clés privées, tournez les jetons du fournisseur DNS et les comptes ACME.

Caractéristiques pour iGaming/fintech

PCI DSS/PII : rigoureux Cipher Suites, force TLS 1. 2+/1. 3, désactiver les codes/compressions faibles, résumer session sans compromis de sécurité.
Segmentation des domaines : certificats distincts pour les sous-domaines de paiement et les amiraux ; pour les fournisseurs de contenu - chaînes isolées.
Audit et loging : enregistrer la sortie/rappel/rotation ; signer les artefacts CI/CD.
Multirégionalité : Issuers locaux par région, afin de ne pas dépendre des abandons croisés.

Exemples de configurations

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 : profil et délivrance

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

Ai-je besoin d'une wildcard ?
Si de nouveaux sous-domaines apparaissent souvent - oui (via DNS-01). Sinon, utilisez le multi-SAN pour les domaines explicites.

Que choisir : cert-manager ou certbot ?
Kubernetes → cert-manager. VM/microservices hors K8s → certbot/lego/acme. sh. PKI interne → Vault/step-ca.

La TTL peut-elle être réduite à 24 heures ?
Pour les mTLS internes, oui, si l'automatisation/sidecar garantit la rotation et que les applications savent se reload.

Comment sécuriser les DNS-01 ?
Token séparé/accès minimum à la zone, rotation des clés, limiter l'accès IP API, tenir un audit.

Résultat

La gestion fiable de TLS est une combinaison de cryptophiles corrects, de sortie et de renouvellement automatisés, de rotations zero-downtime, d'observabilité et de procédures claires d'incident-response. Construisez un pipeline ACME/PXI, ajoutez une alerte rigoureuse et entraînez régulièrement des scénarios « d'urgence » - et les certificats expirés ne seront plus la source des pagers de nuit.