Mise à niveau et migration de certificats TLS : guide pratique d'implémentation

Intro

La mise à niveau et la migration de certificats TLS (Transport Layer Security) : protocole de sécurité de la couche de transport, peuvent provoquer des interruptions évitables si elles sont réalisées de manière improvisée. Un SAN (Subject Alternative Name) : nom alternatif du sujet manquant, un client incapable de négocier ECDSA (Elliptic Curve Digital Signature Algorithm) : algorithme de signature numérique à courbe elliptique, ou un changement de chaîne appliqué en période de pointe sont des causes fréquentes d'échec.

Ce guide propose un chemin concret et à faible risque : planifier le changement, le valider localement, le déployer avec un canary, vérifier le comportement et garder la possibilité de rollback à une commande près. Vous verrez des exemples fonctionnels pour Nginx et Kubernetes Ingress sous Linux afin de vous exercer avant la production.

Vue d'ensemble du workflow

Utilisez cette liste de contrôle pour maintenir le risque bas et la progression visible.

Inventorier la terminaison TLS

Reverse proxies : Nginx, Envoy, HAProxy
Kubernetes : contrôleurs Ingress et gateways
Load balancers gérés et tout listener TLS direct
Associer chacun à l'emplacement des certificats et clés et à leur mécanisme de rechargement
Exemple : exécuter openssl s_client -connect host:443 -servername host </dev/null pour capturer les détails du certificat actuel pour chaque point de terminaison.

Définir le périmètre de la mise à niveau

Algorithme de clé : RSA (Rivest–Shamir–Adleman) : algorithme de chiffrement asymétrique 2048 → RSA 3072, ou passer à ECDSA P-256
Signature et chaîne : nouvel intermédiaire ou racine, format du fichier de chaîne
Modifications SAN et noms d'hôte : ajouter ou supprimer des noms, wildcard vs SAN spécifiques
Durée de vie du certificat et flux de renouvellement
Compatibilité ascendante : envisager des certificats dual (ECDSA + RSA) pour couvrir les anciens clients

Préparer les artefacts

Générer clés et CSR (Certificate Signing Request) : demande de signature de certificat sur un hôte durci
Planifier le stockage : permissions des fichiers, audit et sauvegardes pour les clés privées
Pour la pile dual, produire les artefacts RSA et ECDSA

Mettre en scène en toute sécurité

Charger les nouveaux certificats dans un proxy non‑productif ou un hôte canary
Confirmer les protocoles supportés (TLS 1.2 et 1.3) et désactiver les plus anciens
Vérifier la chaîne complète et le comportement OCSP (Online Certificate Status Protocol) : protocole de statut de certificat en ligne si activé

Plan de déploiement

Privilégier les bascules atomiques : liens symboliques pour les fichiers, secrets versionnés pour Kubernetes
Utiliser un nom d'hôte ou un chemin canary pour exercer le nouveau certificat avec du trafic réel
Recharger gracieusement seulement après validation réussie

Valider rigoureusement

Nom d'hôte, SANs, algorithme de signature, ordre de la chaîne
Négociation de protocole : TLS 1.2 et 1.3
Négociation de chiffrements pour ECDSA et RSA le cas échéant
Comportement applicatif et taux d'erreurs

Observer

Surveiller les journaux du proxy et du contrôleur pour les erreurs de handshake ou de certificat
Suivre les taux 4xx/5xx et les signalements clients pendant la fenêtre

Prêt pour le rollback

Conserver le certificat et la clé précédents installés mais inactifs
Revenir en arrière en inversant un lien symbolique ou en changeant la référence de secret Kubernetes
Recharger le proxy et re‑valider

Nettoyer et documenter

Supprimer l'ancien matériel après une fenêtre de sécurité
Consigner commandes, chemins de fichiers et vérifications dans un runbook

Plan pilote local

Commencez par un seul nom d'hôte ou une seule route que vous pouvez tester en toute sécurité. Prouvez les points suivants avant la production :

Vous pouvez installer le nouveau certificat à côté de l'ancien
Vous pouvez valider localement la chaîne, les protocoles et les suites de chiffrement
Vous pouvez basculer et revenir en arrière en moins d'une minute

Générer clés et CSR (Linux, OpenSSL)

ECDSA P-256 :

openssl ecparam -name prime256v1 -genkey -noout -out server-ecdsa.key
openssl req -new -key server-ecdsa.key -out server-ecdsa.csr \
 -subj '/CN=example.com' \
 -addext 'subjectAltName=DNS:example.com, DNS:www.example.com'

RSA 3072 :

openssl genrsa -out server-rsa.key 3072
openssl req -new -key server-rsa.key -out server-rsa.csr \
 -subj '/CN=example.com' \
 -addext 'subjectAltName=DNS:example.com, DNS:www.example.com'

Une fois émis, vous devez disposer des clés privées et des fichiers de chaîne complète, par exemple :

server-ecdsa.key et example-ecdsa-fullchain.pem
server-rsa.key et example-rsa-fullchain.pem

Appliquez des permissions strictes sur les clés privées :

sudo chown root:root server-*.key
sudo chmod 600 server-*.key

Reverse proxy Nginx : canary dual certificat

Placez certificats et clés sous un chemin versionné et pointez des liens symboliques stables vers la version active :

sudo install -d -m 0750 /etc/nginx/certs/releases/2024-07-20
sudo cp example-ecdsa-fullchain.pem /etc/nginx/certs/releases/2024-07-20/
sudo cp server-ecdsa.key /etc/nginx/certs/releases/2024-07-20/
sudo cp example-rsa-fullchain.pem /etc/nginx/certs/releases/2024-07-20/
sudo cp server-rsa.key /etc/nginx/certs/releases/2024-07-20/

sudo ln -sfn /etc/nginx/certs/releases/2024-07-20/example-ecdsa-fullchain.pem /etc/nginx/certs/example-ecdsa-fullchain.pem
sudo ln -sfn /etc/nginx/certs/releases/2024-07-20/server-ecdsa.key /etc/nginx/certs/example-ecdsa.key
sudo ln -sfn /etc/nginx/certs/releases/2024-07-20/example-rsa-fullchain.pem /etc/nginx/certs/example-rsa-fullchain.pem
sudo ln -sfn /etc/nginx/certs/releases/2024-07-20/server-rsa.key /etc/nginx/certs/example-rsa.key

Configurez Nginx pour proposer à la fois ECDSA et RSA, et restreindre les protocoles :

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers off;
    ssl_ecdh_curve X25519:secp256r1;

    # Certificat ECDSA
    ssl_certificate /etc/nginx/certs/example-ecdsa-fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/example-ecdsa.key;

    # Certificat RSA
    ssl_certificate /etc/nginx/certs/example-rsa-fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/example-rsa.key;

    location / {
        proxy_pass http://app:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Testez et rechargez :

sudo nginx -t && sudo systemctl reload nginx

Validez la négociation et la chaîne localement :

# Vérifier TLS 1.3
openssl s_client -connect example.com:443 -servername example.com -tls1_3 -brief </dev/null

# Forcer un chiffrement ECDSA pour confirmer le chemin ECDSA
openssl s_client -connect example.com:443 -servername example.com \
 -cipher ECDHE-ECDSA-AES128-GCM-SHA256 </dev/null

# Forcer un chiffrement RSA pour confirmer le fallback RSA
openssl s_client -connect example.com:443 -servername example.com \
 -cipher ECDHE-RSA-AES128-GCM-SHA256 </dev/null

# Curl avec résolution hôte‑vers‑IP pour prévisualiser
curl -v --resolve example.com:443:203.0.113.10 https://example.com/

Plan de rollback pour Nginx :

Conserver les certificats précédents sous un chemin de version plus ancien
Inverser les liens symboliques et recharger si nécessaire

sudo ln -sfn /etc/nginx/certs/releases/2024-06-01/example-ecdsa-fullchain.pem /etc/nginx/certs/example-ecdsa-fullchain.pem
sudo ln -sfn /etc/nginx/certs/releases/2024-06-01/server-ecdsa.key /etc/nginx/certs/example-ecdsa.key
sudo ln -sfn /etc/nginx/certs/releases/2024-06-01/example-rsa-fullchain.pem /etc/nginx/certs/example-rsa-fullchain.pem
sudo ln -sfn /etc/nginx/certs/releases/2024-06-01/server-rsa.key /etc/nginx/certs/example-rsa.key
sudo nginx -t && sudo systemctl reload nginx

Kubernetes Ingress : canary puis bascule

Créez un nouveau secret pour le nom d'hôte canary :

kubectl -n web create secret tls web-tls-new \
 --cert=example-fullchain.pem --key=server.key

Créez un Ingress canary utilisant le nouveau secret et un hôte distinct :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-canary
  namespace: web
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - canary.example.com
    secretName: web-tls-new
  rules:
  - host: canary.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web
            port:
              number: 80

Appliquez et testez :

kubectl apply -f web-canary.yaml
curl -v https://canary.example.com/
openssl s_client -connect canary.example.com:443 -servername canary.example.com -brief </dev/null

Basculez l'Ingress de production vers le nouveau secret :

Assurez‑vous de conserver l'ancien secret, par exemple web-tls-old
Mettez à jour spec.tls.secretName de l'Ingress de production à web-tls-new

# extrait de l'Ingress de production
spec:
  tls:
  - hosts:
    - example.com
    - www.example.com
    secretName: web-tls-new

Appliquez et surveillez les journaux du contrôleur pour les mises à jour :

kubectl -n web apply -f web-ingress.yaml
kubectl -n ingress-nginx logs deploy/ingress-nginx-controller -f | grep -i tls

Plan de rollback pour Kubernetes :

Revenir secretName à web-tls-old et appliquer
Conserver les deux secrets pendant la fenêtre de rollback

Checklist de validation

Nom d'hôte et SANs correspondent à ce qu'utilisent les clients
Protocoles : TLS 1.2 et 1.3 activés, les plus anciens désactivés
Négociation de chiffrement : chemin ECDSA disponible, fallback RSA fonctionnel si nécessaire
Chaîne complète et ordonnée correctement
Aucune erreur de handshake ou de certificat dans les journaux
Trafic et taux d'erreurs normaux après la bascule

Observabilité et notes de sécurité

Nginx : suivre error.log pour les erreurs SSL_do_handshake pendant la fenêtre
Contrôleur Ingress : surveiller les journaux pour les mises à jour de secret et les problèmes de handshake
Maintenir une fenêtre de maintenance courte avec astreinte et déclencheurs de rollback clairs

Conclusion

Les mises à niveau TLS réussies suivent un schéma répétable : inventorier, préparer les artefacts, canaryer le changement, valider agressivement et garder le rollback à une commande près. Commencez par un pilote étroit que vous pouvez inspecter localement, prouvez la négociation et l'intégrité de la chaîne, puis étendez le motif à d'autres services. Documentez les commandes exactes, les chemins de fichiers et les vérifications, et planifiez les renouvellements bien avant l'expiration pour que les futures rotations deviennent routinières.