Chiffrement, certificats SSL/TLS et PKI

Un certificat SSL/TLS est un fichier signé par une autorité de certification qui associe une clé publique à une identité, par exemple le nom intranet.sorbier.lan : il permet à un navigateur de vérifier qu'il parle au bon serveur avant de chiffrer les échanges. Une PKI (infrastructure à clés publiques) est l'organisation qui émet, distribue et révoque ces certificats. Ce chapitre explique d'abord les trois outils de la cryptographie (chiffrement symétrique, asymétrique, hachage), puis les certificats, la chaîne de confiance, la création d'une autorité interne, les nouvelles durées de validité et la configuration de TLS.

Trois outils, trois garanties

Le chiffrement symétrique est très rapide mais pose un problème : comment partager la clé secrète sans qu'elle soit interceptée ? Le chiffrement asymétrique résout ce problème mais il est lent. On combine donc les deux (chiffrement hybride) : l'asymétrique sert à se mettre d'accord sur une clé de session, le symétrique chiffre ensuite les données. C'est ce que font TLS, les VPN et SSH.

La signature numérique combine hachage et asymétrique : on calcule l'empreinte du document, puis on la signe avec sa clé privée (avec RSA, cela revient à la chiffrer avec la clé privée). Le destinataire recalcule l'empreinte et vérifie, avec la clé publique de l'émetteur, que la signature correspond bien à cette empreinte. Si elles concordent, le document n'a pas été modifié (intégrité) et il vient bien du détenteur de la clé privée (authenticité, et non-répudiation : il ne peut pas nier l'avoir signé).

Les algorithmes à choisir en 2026

Ces tailles suivent le guide de sélection des algorithmes cryptographiques de l'ANSSI. Une évolution est en cours : l'arrivée possible d'ordinateurs quantiques menace RSA et les courbes elliptiques. Le NIST a normalisé en 2024 un premier mécanisme post-quantique d'échange de clés, ML-KEM (FIPS 203). Les navigateurs récents et OpenSSL 3.5 utilisent déjà un échange hybride (X25519 combiné à ML-KEM), l'approche que recommande l'ANSSI pour la transition.

Le certificat X.509

Une clé publique seule ne dit pas à qui elle appartient : un attaquant placé au milieu pourrait présenter la sienne. Le certificat règle ce problème : une autorité de certification (AC, ou CA en anglais) atteste, par sa signature, que telle clé publique appartient à tel nom. Les certificats suivent la norme X.509 version 3.

L'empreinte (fingerprint) d'un certificat est le hachage SHA-256 du certificat entier. Elle l'identifie de façon unique : vérifier l'empreinte, c'est vérifier qu'on a exactement le bon certificat. Dans le sujet 2026, le client de sauvegarde mémorise l'empreinte du certificat du serveur Proxmox Backup Server : si un autre serveur se fait passer pour lui, l'empreinte ne correspond pas et la connexion est refusée, ce qui empêche une interception de l'homme du milieu même avec un certificat auto-signé.

La chaîne de confiance

Un navigateur ne connaît pas les milliards de certificats de serveurs. Il connaît une centaine d'AC racines, enregistrées dans le magasin de certificats du système ou du navigateur. La confiance se transmet par une chaîne :

1. l'AC racine a un certificat auto-signé, gardé hors ligne, qui ne sert qu'à signer des AC intermédiaires ;
2. l'AC intermédiaire signe les certificats des serveurs au quotidien ; si elle est compromise, on la révoque sans toucher à la racine ;
3. le certificat du serveur (certificat feuille) est présenté au client, avec le certificat intermédiaire.

Le client vérifie chaque signature en remontant jusqu'à une racine de son magasin, puis contrôle la date de validité, le nom (le SAN doit correspondre au nom tapé dans la barre d'adresse) et la révocation.

AC publique ou AC interne ?

Un certificat auto-signé (signé par sa propre clé) n'est vérifiable par personne : il provoque un avertissement, et habitue les utilisateurs à cliquer sur « continuer quand même », exactement le réflexe qu'un attaquant exploite. Dans une entreprise, on le remplace par un certificat de l'AC interne.

Créer une AC interne et un certificat de serveur avec OpenSSL

En TP, OpenSSL 3 permet de monter une petite AC en quelques commandes. Sorbier crée son AC racine, puis le certificat de l'intranet :

# 1. Clé privée de l'AC (courbe P-256), à protéger absolument
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ac-sorbier.key

# 2. Certificat auto-signé de l'AC, valable 10 ans
openssl req -x509 -new -key ac-sorbier.key -sha256 -days 3650 \
  -subj "/O=Sorbier Logistique/CN=AC racine Sorbier" \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign" \
  -out ac-sorbier.crt

# 3. Sur le serveur : clé privée et demande de signature (CSR)
openssl req -new -newkey rsa:3072 -nodes -keyout intranet.key -out intranet.csr \
  -subj "/O=Sorbier Logistique/CN=intranet.sorbier.lan" \
  -addext "subjectAltName=DNS:intranet.sorbier.lan" \
  -addext "extendedKeyUsage=serverAuth" \
  -addext "basicConstraints=CA:FALSE"

# 4. L'AC signe la demande : certificat valable 397 jours
openssl x509 -req -in intranet.csr -CA ac-sorbier.crt -CAkey ac-sorbier.key \
  -CAcreateserial -days 397 -sha256 -copy_extensions copy -out intranet.crt

# 5. Vérifications
openssl x509 -in intranet.crt -noout -subject -issuer -dates -ext subjectAltName
openssl x509 -in intranet.crt -noout -fingerprint -sha256
openssl verify -CAfile ac-sorbier.crt intranet.crt

La dernière commande répond intranet.crt: OK si la signature est valide. Retiens la logique du CSR (Certificate Signing Request) : la clé privée du serveur ne quitte jamais le serveur. Seule la demande, qui contient la clé publique et les noms, part vers l'AC, qui renvoie le certificat signé. L'option -copy_extensions copy recopie dans le certificat les extensions que demande le CSR : l'AC doit donc vérifier ce que la demande contient (noms, usage, CA:FALSE) avant de signer. Il reste à installer la racine ac-sorbier.crt dans le magasin « Autorités de certification racines de confiance » des postes, par une stratégie de groupe.

En production, on ne garde pas la clé de l'AC racine sur un serveur en ligne : elle reste hors ligne, et une AC intermédiaire signe les certificats.

Durée de validité : ce qui a changé en 2026

Les règles des certificats publics sont fixées par le CA/Browser Forum, qui réunit les AC et les éditeurs de navigateurs. Son vote SC-081 réduit la durée maximale des certificats TLS publics par étapes :

Avec de telles durées, renouveler à la main n'est plus tenable : on automatise avec le protocole ACME, celui de Let's Encrypt (client certbot sous Linux, paquet ACME sur pfSense et OPNsense). Let's Encrypt délivre des certificats de 90 jours, renouvelés automatiquement vers les deux tiers de leur durée. Let's Encrypt passera à 64 jours le 10 février 2027 puis à 45 jours le 16 février 2028 : un renouvellement codé « tous les 60 jours » ne suffira plus.

La révocation

Un certificat dont la clé privée a fui doit être révoqué avant sa date d'expiration. Le client le découvre de deux façons :

• la liste de révocation (CRL) : un fichier publié par l'AC, qui liste les numéros de série révoqués ;
• OCSP : une interrogation en direct de l'AC sur un certificat précis.

Let's Encrypt a arrêté son service OCSP en 2025 et ne publie plus que des CRL ; les navigateurs, eux, s'appuient sur des listes de révocation compactes qu'ils téléchargent régulièrement. Les durées de validité courtes limitent d'ailleurs le problème : un certificat compromis expire vite.

TLS : chiffrer les échanges

TLS (Transport Layer Security), successeur de SSL, chiffre et authentifie les échanges au-dessus de TCP : HTTPS, mais aussi LDAPS, SMTP avec STARTTLS, IMAPS, syslog TLS. On dit encore « certificat SSL » par habitude, mais SSL 2.0 et 3.0, puis TLS 1.0 et 1.1, sont interdits (RFC 6176 pour SSL 2.0, RFC 7568 pour SSL 3.0, RFC 8996 en 2021 pour TLS 1.0 et 1.1). Seules TLS 1.2 et TLS 1.3 sont acceptables.

La négociation (handshake) de TLS 1.3 se déroule en un aller-retour :

1. le client envoie les versions et algorithmes qu'il accepte, et sa part d'échange de clés (ECDHE) ;
2. le serveur choisit, envoie sa part d'échange de clés, son certificat, et une signature qui prouve qu'il détient la clé privée correspondante ;
3. le client vérifie le certificat (chaîne, nom, dates, révocation) et la signature ; les deux côtés calculent la même clé de session ;
4. les données sont chiffrées en AES-GCM ou ChaCha20-Poly1305.

Parce que la clé de session vient d'un échange éphémère (ECDHE), une clé privée de serveur volée plus tard ne permet pas de déchiffrer les échanges passés : c'est la confidentialité persistante (forward secrecy), obligatoire en TLS 1.3.

Une configuration TLS correcte, par exemple pour nginx sur le serveur web de la DMZ :

server {
    listen 443 ssl;
    server_name suivi.sorbier-logistique.fr;
    ssl_certificate     /etc/letsencrypt/live/suivi.sorbier-logistique.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/suivi.sorbier-logistique.fr/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

L'en-tête HSTS (Strict-Transport-Security) dit au navigateur de n'utiliser que HTTPS pour ce site pendant un an : même si l'utilisateur tape http://, aucune requête ne part en clair. Pour vérifier un serveur, openssl s_client -connect suivi.sorbier-logistique.fr:443 -servername suivi.sorbier-logistique.fr affiche la chaîne présentée et la version négociée ; le test en ligne SSL Labs donne une note de A+ à F pour un site public.

Certificats et preuve électronique

Le référentiel demande de « déployer les moyens appropriés de preuve électronique ». Les mêmes outils servent à prouver :

• la signature électronique d'un document (règlement européen eIDAS) atteste son auteur et son intégrité ;
• l'horodatage par une autorité de confiance prouve qu'un document ou un journal existait à une date donnée, sans modification depuis ;
• l'empreinte d'un fichier, notée au moment d'une copie de preuve, permet de démontrer plus tard que la copie n'a pas changé (chapitre 14).

Pour aller plus loin. Le cours Cryptographie détaille le chiffrement asymétrique, les certificats et la PKI et la poignée de main TLS 1.3.

Exercices