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