TLS et certificats : sécurisation des communications

TLS (Transport Layer Security) chiffre et authentifie les communications entre un client et un serveur. C'est lui qui protège HTTPS, mais aussi la messagerie (SMTP, IMAP), les annuaires (LDAPS), de nombreux VPN et API. Bien configuré, il est invisible ; mal configuré, il provoque des pannes (certificat expiré) ou une fausse impression de sécurité.

Objectif : comprendre la poignée de main TLS, le rôle des certificats et de la chaîne de confiance, configurer correctement un service et diagnostiquer les erreurs courantes.

Ce que garantit TLS

• Confidentialité : les données sont chiffrées.
• Intégrité : toute modification en transit est détectée.
• Authentification du serveur (et éventuellement du client) grâce aux certificats.

TLS ne protège que le transport. Les adresses IP et ports restent visibles, et le nom du serveur demandé est généralement visible dans le champ SNI de la poignée de main (l'extension ECH, Encrypted Client Hello, vise à le masquer mais n'est pas encore universellement déployée). TLS ne protège pas non plus les données une fois arrivées sur le serveur.

Les versions

La poignée de main TLS 1.3, simplifiée

1. ClientHello : le client propose les versions, les suites de chiffrement et envoie sa part d'échange de clés (Diffie-Hellman éphémère sur courbe elliptique, par exemple X25519).
2. ServerHello : le serveur choisit les paramètres et envoie sa propre part. Les deux calculent alors un secret partagé ; la suite de la poignée de main est déjà chiffrée.
3. Le serveur envoie son certificat et une signature prouvant qu'il possède la clé privée correspondante.
4. Les deux parties confirment l'intégrité de l'échange (Finished), puis échangent les données applicatives.

TLS 1.3 n'utilise que des échanges de clés éphémères, ce qui garantit la confidentialité persistante (forward secrecy) : la compromission ultérieure de la clé privée du serveur ne permet pas de déchiffrer les sessions passées. Il a aussi supprimé les algorithmes obsolètes et réduit la poignée de main à un aller-retour.

Les certificats X.509

Un certificat (format X.509, RFC 5280) lie une clé publique à une identité, et cette association est signée par une autorité de certification (AC). Il contient notamment :

• le sujet et surtout les noms alternatifs (Subject Alternative Name, SAN) : les noms DNS pour lesquels il est valable — c'est le champ SAN qui est vérifié par les navigateurs, pas le CN ;
• la période de validité (dates notBefore et notAfter) ;
• l'émetteur ;
• les usages autorisés (authentification serveur, client, signature de code…).

La chaîne de confiance

Le client fait confiance à un ensemble d'autorités racines préinstallées dans son système ou son navigateur. Les racines ne signent généralement pas directement les certificats de serveurs : elles signent des autorités intermédiaires, qui signent les certificats finaux.

AC racine (dans le magasin de confiance du client)
  └─ AC intermédiaire
       └─ Certificat de www.exemple.fr

Le serveur doit envoyer son certificat et la ou les intermédiaires (fullchain). Une chaîne incomplète fonctionne parfois dans un navigateur qui a mis l'intermédiaire en cache, mais échoue avec d'autres clients (applications, scripts, objets connectés). C'est l'une des erreurs les plus fréquentes.

Révocation

Un certificat compromis doit être révoqué avant son expiration. Les mécanismes historiques sont les listes de révocation (CRL) et OCSP. L'écosystème évolue : la réduction progressive de la durée de vie maximale des certificats publics, décidée par le CA/Browser Forum, rend le renouvellement automatique indispensable.

Obtenir et renouveler les certificats : ACME

Le protocole ACME (RFC 8555), popularisé par l'autorité Let's Encrypt, automatise la délivrance et le renouvellement des certificats. Le client prouve qu'il contrôle le domaine par un défi :

• HTTP-01 : publication d'un fichier sur http://domaine/.well-known/acme-challenge/ ;
• DNS-01 : création d'un enregistrement TXT, indispensable pour les certificats génériques (wildcard) et pour les serveurs non exposés.

Exemple avec Certbot :

sudo certbot certonly --webroot -w /var/www/exemple -d www.exemple.fr -d exemple.fr
sudo certbot renew --dry-run        # vérifier que le renouvellement automatique fonctionne

L'automatisation du renouvellement est la meilleure protection contre l'expiration, première cause de panne liée à TLS. Complétez-la par une supervision de la date d'expiration de chaque certificat exposé.

Configurer un service de manière sûre

Exemple pour Nginx, en s'inspirant des profils recommandés (comme le générateur de configuration de Mozilla) :

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_session_tickets off;
ssl_certificate     /etc/letsencrypt/live/www.exemple.fr/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.exemple.fr/privkey.pem;
add_header Strict-Transport-Security "max-age=31536000" always;

La liste ssl_ciphers ne concerne que TLS 1.2 ; les suites de TLS 1.3 sont gérées séparément par la bibliothèque. HSTS indique aux navigateurs de n'utiliser que HTTPS pour ce domaine : activez-le uniquement lorsque HTTPS fonctionne parfaitement sur tous les sous-domaines concernés, car il est difficile à annuler.

Protégez la clé privée : permissions restrictives (lisible uniquement par root ou le service), jamais dans un dépôt de code, jamais envoyée par messagerie.

Diagnostiquer avec openssl

# Afficher la chaîne présentée par un serveur
openssl s_client -connect www.exemple.fr:443 -servername www.exemple.fr -showcerts </dev/null

# Dates de validité et noms couverts
openssl s_client -connect www.exemple.fr:443 -servername www.exemple.fr </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -subject -ext subjectAltName

# Tester une version précise
openssl s_client -connect www.exemple.fr:443 -tls1_3 </dev/null

# Vérifier qu'une clé privée correspond au certificat
openssl x509 -noout -pubkey -in cert.pem | openssl sha256
openssl pkey -pubout -in privkey.pem | openssl sha256

N'oubliez pas l'option -servername : sans elle, un serveur qui héberge plusieurs sites peut présenter un autre certificat.

Certificats internes

Pour les services internes, une AC privée (par exemple les services de certificats Active Directory, ou une PKI dédiée) permet de délivrer des certificats pour des noms non publics. Il faut alors déployer la racine dans les magasins de confiance des postes, protéger soigneusement la clé de l'AC racine (idéalement hors ligne) et automatiser autant que possible le renouvellement. Évitez les certificats auto-signés que les utilisateurs apprennent à « accepter » : c'est exactement le réflexe qu'exploite une interception.

Erreurs courantes

• Laisser expirer un certificat faute d'automatisation et de supervision.
• Chaîne incomplète côté serveur.
• Garder TLS 1.0/1.1 activés « pour compatibilité ».
• Clé privée accessible ou copiée sur de nombreux serveurs.
• Activer HSTS avec includeSubDomains alors que certains sous-domaines ne sont pas en HTTPS.

Conclusion

TLS 1.3, des certificats délivrés et renouvelés automatiquement, une chaîne complète, une clé privée protégée et une supervision des expirations : voilà l'essentiel. Avec openssl s_client, vous diagnostiquez la plupart des problèmes en une commande. Pour l'intégration avec un proxy inverse, consultez Nginx et Apache : fonctionnement et implications réseau.

Références

• RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 8996 — Deprecating TLS 1.0 and TLS 1.1
• RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• RFC 8555 — Automatic Certificate Management Environment (ACME)
• Mozilla — SSL Configuration Generator
• ANSSI — Recommandations de sécurité relatives à TLS