Les certificats TLS ne sont pas de simples fichiers à déposer sur un serveur. Ils encodent l'identité, l'usage des clés et les chemins de confiance que les clients doivent valider sous contraintes réelles. Ce guide explique les concepts avancés nécessaires pour exploiter un TLS de qualité production en toute confiance. Vous apprendrez comment les chaînes sont construites, quels champs comptent, comment déployer des certificats RSA+ECDSA doubles, activer l'agrafage OCSP et durcir Nginx et Kubernetes Ingress. Chaque section inclut des commandes et configurations pratiques applicables dès aujourd'hui.

## Vue d'ensemble du flux de travail

Un flux TLS fiable évite les surprises. Suivez cette séquence :

- Inventaire : listez les domaines, ports et types de clients (navigateurs, API, IoT) et notez les besoins en SNI et ALPN.

- Stratégie de clés : choisissez RSA ou ECDSA (ou les deux), tailles de clés et stockage (fichier, HSM, KMS).

- CSR et politique : définissez SAN, EKU, KU et infos d'organisation. Préférez SAN à CN. Exemple : -addext "subjectAltName=DNS:app.example.com,DNS:api.example.com" -addext "extendedKeyUsage=serverAuth" .

- Émission : demandez les certificats à votre CA, assurez-vous que la chaîne intermédiaire est fournie, et enregistrez les périodes de validité et fenêtres de renouvellement.

- Installation : déployez le certificat feuille, la clé privée et la chaîne complète sur les points de terminaison ; activez l'agrafage OCSP.

- Test : vérifiez la chaîne, le nom d'hôte, EKU, OCSP, versions TLS et suites de chiffrement.

- Observation : surveillez l'expiration, la santé OCSP et les erreurs ; faites tourner clés et certificats selon un calendrier.

- Amélioration : adoptez les certificats doubles, imposez HSTS prudemment et ajustez les politiques de chiffrement.

## Plongée dans les entrailles du TLS

Champs X.509 clés et leur importance :

- Subject Alternative Name (SAN) : l'endroit définitif pour les noms DNS et adresses IP. Les clients modernes valident les noms d'hôte via SAN, pas via CN.

- Key Usage (KU) : contraintes sur la clé. Pour les certificats serveur TLS, digitalSignature est requis. Pour RSA avec TLS 1.2, keyEncipherment est souvent utilisé. Avec TLS 1.3, digitalSignature suffit pour RSA-PSS et ECDSA.

- Extended Key Usage (EKU) : les certificats serveur typiques incluent serverAuth ; les certificats client pour mTLS incluent clientAuth .

- Basic Constraints : CA=false pour les certificats feuille ; CA=true pour les AC (avec pathLen si nécessaire).

- Authority Information Access (AIA) : URLs pour récupérer les certificats d'émetteur ou points de terminaison OCSP.

- CRL Distribution Points (CDP) : où récupérer les listes de révocation.

- Algorithme de signature : s'associe à votre clé (RSA-PSS, ECDSA avec P-256 ou P-384). Choisissez des algorithmes modernes supportés par vos clients.

- Validité : des durées de vie courtes réduisent le risque et imposent l'automatisation, mais surveillez les renouvellements.

Ces champs pilotent la façon dont les clients construisent les chemins de confiance et décident si un certificat est acceptable pour un usage donné.

## Construction et validation de la chaîne

Les clients tentent de construire un chemin de la feuille vers une racine de confiance :

- Fournissez la chaîne complète : certificat feuille en premier, puis intermédiaire(s). N'incluez pas la racine.

- Construction du chemin : les clients peuvent récupérer les intermédiaires via AIA s'ils manquent, mais ne comptez pas dessus. Fournissez les intermédiaires explicitement.

- Vérification du nom : le nom d'hôte doit correspondre à une entrée DNS SAN ou IP.

- Vérifications EKU/KU : serverAuth doit être présent pour les serveurs ; clientAuth pour les certificats client en mTLS.

- Contraintes de nom : certaines racines d'entreprise limitent les espaces de noms DNS autorisés (ex. une racine corporate limitée à *.corp.example.com ) ; les SAN feuille doivent s'y conformer.

- État de révocation : OCSP bon, CRL non listé, ou preuve agrafée acceptable selon la politique client.

- Validité temporelle : les fenêtres notBefore/notAfter doivent inclure l'heure courante.

- Agilité algorithmique : assurez-vous que la chaîne utilise des algorithmes supportés par votre base de clients.

## Clés, algorithmes, double pile

Choix algorithmiques :

- RSA : très compatible. Utilisez 2048 ou 3072 bits. Fonctionne avec signatures RSA-PSS dans les piles modernes.

- ECDSA : poignées de main plus rapides et certificats plus petits. Utilisez P-256 (prime256v1) ou P-384.

Déploiement double certificat :

- Servez un certificat ECDSA et un certificat RSA pour les mêmes noms. Les serveurs modernes sélectionnent ECDSA pour les clients qui l'annoncent et reviennent à RSA sinon.

- Générez des clés et CSR séparés. Émettez deux certificats feuille avec SAN identiques.

- Configurez les deux certificats sur l'écouteur ; voir l'exemple Nginx ci-dessous.

Exemple de génération de CSR pour certificats doubles :

openssl ecparam -name prime256v1 -genkey -noout -out app-ecdsa.key
openssl req -new -key app-ecdsa.key -out app-ecdsa.csr -subj "CN=app.example.com" -addext "subjectAltName=DNS:app.example.com" -addext "extendedKeyUsage=serverAuth"

openssl genrsa -out app-rsa.key 2048
openssl req -new -key app-rsa.key -out app-rsa.csr -subj "CN=app.example.com" -addext "subjectAltName=DNS:app.example.com" -addext "extendedKeyUsage=serverAuth" 

## OCSP, CRL et CT

 Révocation et transparence en pratique :

- OCSP : état en ligne d'un certificat. Activez l'agrafage sur votre serveur pour délivrer la réponse OCSP aux clients, réduisant la latence et évitant les problèmes de soft-fail.

- CRL : listes plus volumineuses récupérées périodiquement. Certains clients consomment encore les CRL ; maintenez l'accessibilité des URLs CDP.

- Certificate Transparency (CT) : journaux publics des certificats émis. Les navigateurs modernes exigent des SCT (embarqués ou via OCSP). De nombreuses AC publiques embarquent les SCT par défaut ; vérifiez leur présence.

Conseils opérationnels :

- Mettez en cache et rafraîchissez les réponses OCSP agrafées avant expiration.

- Surveillez l'accessibilité du répondeur OCSP et l'état d'agrafage en production.

- Vérifiez l'agrafage sur un serveur en direct : openssl s_client -connect app.example.com:443 -servername app.example.com -status </dev/null

## SNI, ALPN, poignée de main TLS 1.3

- SNI : permet plusieurs certificats sur une IP. Assurez-vous que vos clients envoient SNI ; sinon fournissez un certificat par défaut sensé.

- ALPN : négociation d'application (ex. http/1.1 ou h2 ). Configurez ALPN selon les attentes du backend et des clients.

- TLS 1.3 : poignée de main simplifiée, secret de transmission par défaut, et nomenclature de suites différente. Préférez TLS 1.3 avec une repli TLS 1.2 moderne pour les clients hérités.

## Types de certificats et usages

- Certificats SAN : listent des noms d'hôte spécifiques ; privilégiés pour la clarté.

- Wildcards : *.example.com couvre un niveau. Évitez pour les environnements multi-locataires où le partage de clés est risqué.

- UCC ou multi-SAN : un certificat avec plusieurs SAN pour des services liés.

- mTLS : utilisez des certificats clients avec EKU clientAuth ; le serveur valide l'identité du client, souvent mappée à une autorisation au niveau application.

## Exemples pratiques Nginx

Double RSA+ECDSA, TLS 1.3, agrafage, HSTS :

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

 # Fournir les deux chaînes de certificats ECDSA et RSA (feuille + intermédiaires)
 ssl_certificate /etc/nginx/certs/app-ecdsa-fullchain.pem;
 ssl_certificate_key /etc/nginx/certs/app-ecdsa.key;
 ssl_certificate /etc/nginx/certs/app-rsa-fullchain.pem;
 ssl_certificate_key /etc/nginx/certs/app-rsa.key;

 # Chaîne de confiance pour vérification de l'agrafage OCSP
 ssl_trusted_certificate /etc/nginx/certs/issuer-chain.pem;

 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_prefer_server_ciphers off; # Laisser les clients choisir en TLS 1.3

 # Suites TLS 1.2 raisonnables (suites TLS 1.3 implicites)
 ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:
 ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256;

 # Agrafage OCSP
 ssl_stapling on;
 ssl_stapling_verify on;
 resolver 1.1.1.1 8.8.8.8 valid=300s;
 resolver_timeout 5s;

 # HSTS (activer après confirmation que HTTPS fonctionne partout)
 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

 # ALPN actif par défaut avec http2
 location / {
 proxy_set_header Host $host;
 proxy_set_header X-Forwarded-For $remote_addr;
 proxy_pass http://backend;
 }
} 
 mTLS sur Nginx :

server {
 listen 443 ssl;
 server_name api.example.com;

 ssl_certificate /etc/nginx/certs/api-fullchain.pem;
 ssl_certificate_key /etc/nginx/certs/api.key;
 ssl_trusted_certificate /etc/nginx/certs/issuer-chain.pem;

 # Exiger un certificat client
 ssl_verify_client on; # ou optional
 ssl_client_certificate /etc/nginx/certs/clients-ca.pem; # AC qui a émis les certificats clients
 ssl_verify_depth 2;

 location / {
 # Transmettre les infos du certificat client à l'application si nécessaire
 proxy_set_header X-Client-Verify $ssl_client_verify;
 proxy_set_header X-Client-DN $ssl_client_s_dn;
 proxy_pass http://api-backend;
 }
} 

## Exemples Kubernetes Ingress

 TLS de base sur Ingress-NGINX :

apiVersion: v1
kind: Secret
metadata:
 name: web-tls
 namespace: web
type: kubernetes.io/tls
data:
 tls.crt: <base64 de fullchain.pem>
 tls.key: <base64 de privkey.pem>
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: web-ing
 namespace: web
 annotations:
 nginx.ingress.kubernetes.io/ssl-redirect: "true"
 nginx.ingress.kubernetes.io/ssl-ciphers: |
 ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:
 ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256
 nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
spec:
 ingressClassName: nginx
 tls:
 - hosts:
 - app.example.com
 secretName: web-tls
 rules:
 - host: app.example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: web-svc
 port:
 number: 8080 
 mTLS avec Ingress-NGINX :

apiVersion: v1
kind: Secret
metadata:
 name: client-ca
 namespace: web
data:
 ca.crt: <base64 de clients-ca.pem>
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: api-ing
 namespace: web
 annotations:
 nginx.ingress.kubernetes.io/auth-tls-secret: "web/client-ca"
 nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
 nginx.ingress.kubernetes.io/auth-tls-verify-depth: "2"
 nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"
spec:
 tls:
 - hosts:
 - api.example.com
 secretName: api-tls
 rules:
 - host: api.example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: api-svc
 port:
 number: 8080 

## Dépannage en ligne de commande Linux

 Inspecter un fichier certificat :

openssl x509 -in cert.pem -text -noout 
 Vérifier un serveur en direct avec SNI et statut OCSP :

openssl s_client -connect app.example.com:443 -servername app.example.com -status </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates 
 Afficher la chaîne complète servie :

openssl s_client -showcerts -connect app.example.com:443 -servername app.example.com </dev/null 
 Vérifier une chaîne contre un bundle d'AC :

openssl verify -CAfile /etc/ssl/certs/ca-bundle.crt fullchain.pem 
 Vérifier l'expiration en jours restants :

END=$(openssl x509 -enddate -noout -in cert.pem | cut -d= -f2)
EXP=$(date -d "$END" +%s)
NOW=$(date +%s)
echo $(( (EXP-NOW)/86400 )) 

## Liste de contrôle de durcissement de la sécurité

- Privilégiez TLS 1.3, conservez TLS 1.2 pour l'héritage, désactivez 1.0 et 1.1.

- Utilisez des certificats ECDSA P-256 avec repli RSA si vos clients l'exigent.

- Incluez des SAN pour tous les noms d'hôte ; ne comptez pas sur le CN.

- Assurez-vous de la présence de l'EKU serverAuth pour les serveurs ; clientAuth pour les clients mTLS.

- Déployez la chaîne complète (feuille + intermédiaires), pas la racine.

- Activez l'agrafage OCSP et vérifiez la santé de l'agrafage.

- Utilisez HSTS seulement après avoir confirmé que HTTPS est stable ; envisagez le préchargement plus tard.

- Automatisez le renouvellement, testez 2 semaines avant expiration, et surveillez les jours restants.

- Protégez les clés avec le moindre privilège et un stockage sécurisé.

- Pour les configurations multi-locataires, évitez les wildcards et utilisez des clés séparées par locataire.

- Journalisez la version TLS, la suite, le SNI et les détails du certificat client pour l'audit.

- Documentez les étapes de retour arrière et conservez les certificats précédents jusqu'à ce que les nouveaux soient validés en production.

## Plan pilote local

 Objectif : déployer un seul site sur un hôte Nginx avec double RSA+ECDSA, agrafage OCSP et un plan de test mesurable.

Périmètre : un nom d'hôte, une VM ou un conteneur, pas de modification d'équilibreur de charge.

Étapes :

- Clés et CSR

openssl ecparam -name prime256v1 -genkey -noout -out app-ecdsa.key
openssl req -new -key app-ecdsa.key -out app-ecdsa.csr -subj "CN=app.example.com" -addext "subjectAltName=DNS:app.example.com" -addext "extendedKeyUsage=serverAuth"

openssl genrsa -out app-rsa.key 2048
openssl req -new -key app-rsa.key -out app-rsa.csr -subj "CN=app.example.com" -addext "subjectAltName=DNS:app.example.com" -addext "extendedKeyUsage=serverAuth" 

- Émettre les certificats auprès de votre AC choisie, en obtenant les fichiers fullchain et la chaîne d'émetteur pour l'agrafage.

- Configurer Nginx avec les deux certificats et l'agrafage OCSP (voir l'exemple ci-dessus).

- Tests (mesurables) :

- Version de la poignée de main : confirmez que TLS 1.3 fonctionne et que le repli TLS 1.2 est présent.

- Sélection d'algorithme : vérifiez que ECDSA est servi aux clients modernes et RSA aux clients hérités.

- Correction de la chaîne : openssl s_client -showcerts montre la feuille et les intermédiaires.

- Agrafage OCSP : -status affiche une réponse bonne avec un Next Update futur.

- Validation du nom d'hôte : le SAN correspond à app.example.com .

- Garde-fous de déploiement :

- Conservez les certificats et configurations précédents pour pouvoir revenir en arrière.

- Surveillez les taux d'erreur et les échecs de poignée de main pendant 24 à 48 heures.

- Documenter les résultats et étendre à d'autres noms d'hôte une fois les métriques au vert.

 Ce pilote est étroit, mesurable et facile à inspecter localement avant un déploiement plus large.

## Conclusion

Les opérations TLS avancées reposent sur la justesse des détails : SAN et EKU pour l'usage prévu, assemblage correct de la chaîne, algorithmes modernes, révocation agrafée et configurations serveur durcies. Commencez petit avec un pilote ciblé, validez avec des commandes concrètes, puis étendez le motif à d'autres services. Revoyez votre politique de suites, automatisez renouvellements et surveillance, et adaptez les configurations à votre base de clients. Avec ces pratiques, vous livrerez plus vite, avec moins de surprises, et maintiendrez une posture de sécurité robuste dans le temps.