Certificate pinning : risques et rotation des certificats

Le certificate pinning ajoute une contrainte locale à la validation TLS (Transport Layer Security) : le serveur doit présenter une identité cryptographique attendue, pas seulement une chaîne acceptable pour le système. Le gain est réel contre une autorité de certification compromise. Le prix l’est tout autant : une rotation mal orchestrée transforme un renouvellement banal en indisponibilité complète.

→ Lire l’explication complète de la marmotte

Ce que le certificate pinning ajoute à la validation TLS

La validation TLS classique vérifie plusieurs propriétés : la signature de la chaîne par une autorité de certification (AC) reconnue, la période de validité, le nom de domaine dans le certificat et, selon la pile, les informations de révocation. Cette confiance est déléguée à un magasin d’ancres de confiance contenant souvent des dizaines, voire des centaines d’AC.

Le pinning réduit ce périmètre. L’application conserve une valeur attendue et rejette toute connexion dont le certificat ou la clé publique ne correspond pas. Une AC publique parfaitement légitime, mais qui aurait émis un certificat frauduleux pour le domaine ciblé, ne suffit alors plus à convaincre le client.

Deux formes dominent :

Le pinning de certificat compare l’empreinte d’un certificat précis. Toute réémission, même avec la même clé publique, exige une mise à jour du pin.
Le pinning de SPKI (Subject Public Key Info) compare l’empreinte de la clé publique et de ses paramètres. Un nouveau certificat signé avec la même paire de clés reste accepté.

Le pinning SPKI est généralement le moins mauvais choix lorsqu’un pinning est réellement justifié. Épingler le certificat entier lie la disponibilité à des champs administratifs, à un émetteur, à une date et à une sérialisation. Bref, on fait dépendre le trafic de détails que la sécurité de l’identité ne demande pas de figer. C’est très zélé, donc très cassant.

Le pinning ne remplace pas la validation de chaîne. Désactiver la vérification du nom, de l’expiration ou de la chaîne sous prétexte qu’une clé est épinglée produit une authentification incomplète et augmente la surface d’erreur. La règle est stricte : valider TLS normalement, puis vérifier le pin. Une application qui ne fait que comparer une empreinte accepte potentiellement un certificat expiré ou présenté pour un autre nom si la bibliothèque le permet.

Les fondations de cette validation restent détaillées dans TLS expliqué et dans relier une clé à une identité avec une PKI. Le pinning n’est pas une PKI miniature. C’est une réduction explicite des identités acceptables par un client donné.

Le compromis central : moins d’AC, plus de responsabilité

Le bénéfice du pinning est limité à une menace précise : l’émission abusive d’un certificat par une AC de confiance, ou l’interception utilisant une chaîne installée localement sur le poste ou le terminal. C’est une défense utile quand le client distribué contrôle son propre comportement de vérification et que l’identité du serveur est stable.

La contrepartie est brutale : la disponibilité dépend désormais d’une synchronisation entre infrastructure serveur et clients. Si le serveur bascule vers une clé non épinglée avant que les clients connaissent cette clé, chaque connexion échoue. Ni redémarrage, ni renouvellement forcé, ni prière vers le portail de supervision ne corrige un binaire mobile déjà distribué.

Le scénario classique se répète avec une régularité presque artisanale :

une paire de clés est remplacée pendant un renouvellement de certificat ;
l’ancienne clé est détruite, rendue inaccessible ou retirée du répartiteur ;
l’application déployée ne contient que l’ancien pin ;
les clients refusent le nouveau serveur ;
la correction exige une version applicative ou une configuration distante déjà authentifiée.

Le point 5 décide de la gravité. Une configuration distante chargée uniquement après l’établissement de la connexion épinglée ne permet aucune récupération. C’est un verrou de coffre-fort dont la clé serait rangée dans le coffre. L’absurde est techniquement impeccable.

Le pinning impose aussi une gouvernance des clés plus stricte. Une clé privée de serveur épinglée ne peut pas être tournée au rythme normal des certificats sans plan de transition. Cela augmente sa durée de vie et donc l’exposition en cas de compromission. Une clé conservée plusieurs années pour éviter une mise à jour client n’est pas une stratégie cryptographique, c’est une dette d’exploitation déguisée en stabilité.

Pinset, rotation et reprise après échec

Un pinset doit contenir au minimum deux empreintes SPKI : la clé active et une clé de secours, générée et protégée avant tout incident. Le client accepte l’une ou l’autre, tout en conservant les contrôles TLS standards. Cette seconde clé permet de déployer un certificat de remplacement sans publier une application d’urgence.

La clé de secours ne doit pas être stockée sur le même hôte, dans le même secret de déploiement ni sous les mêmes habilitations que la clé active. Sinon, une compromission unique couvre les deux pins et le mécanisme perd son intérêt. Pour une clé privée à forte valeur, un HSM (Hardware Security Module) doit empêcher son export et journaliser les opérations de signature. Le HSM ne protège ni la logique de pinning ni la disponibilité de l’application. Il protège une clé, ce qui est déjà beaucoup, mais pas magique.

La rotation doit suivre une séquence contrôlée :

générer une nouvelle paire de clés et calculer son empreinte SPKI ;
distribuer le nouveau pin aux clients, avec l’ancien toujours accepté ;
mesurer l’adoption de la version ou de la configuration contenant les deux pins ;
déployer le certificat associé à la nouvelle clé côté serveur ;
attendre l’extinction vérifiée des anciens clients ;
retirer l’ancien pin seulement après la fenêtre de support définie.

La supervision doit exposer les erreurs de pinning séparément des échecs TLS génériques. Compter seulement les codes HTTP est insuffisant : une connexion rejetée avant la requête ne produit aucun code applicatif. Instrumenter le motif de rejet, l’identifiant de pin attendu et l’empreinte présentée, sans journaliser de secret ni de certificat client complet.

Une sauvegarde exploitable comprend les métadonnées du pinset, les clés publiques, les certificats, les dates de bascule, la procédure de retour arrière et les accès aux clés privées. Sauvegarder uniquement le certificat est inutile pour restaurer une identité épinglée si la clé correspondante a disparu. À l’inverse, restaurer une clé privée compromise pour sauver une disponibilité remplace une panne visible par une compromission silencieuse. Ce marché-là n’a jamais été favorable.

Exemple reproductible : calculer et vérifier un pin SPKI

La commande suivante récupère le certificat présenté par un serveur, extrait sa clé publique et calcule le pin SPKI encodé en Base64. La seconde commande demande à curl de n’accepter que cette clé publique, tout en conservant la validation TLS normale.

# Récupérer le certificat de www.example.com puis calculer son pin SPKI SHA-256.
PIN=$(
  openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
  | openssl x509 -pubkey -noout \
  | openssl pkey -pubin -outform der \
  | openssl dgst -sha256 -binary \
  | base64
)

# Vérifier que curl accepte uniquement la clé publique qui vient d'être calculée.
curl --fail --show-error \
  --pinnedpubkey "sha256//$PIN" \
  https://www.example.com/

Cet exemple ne constitue pas un déploiement de pinning : le pin est obtenu au moment même de la connexion, donc un attaquant déjà capable de substituer le certificat peut alimenter la variable avec sa propre clé. En production, l’empreinte doit provenir d’un artefact distribué et signé avant la connexion, par exemple le binaire mobile, un fichier de configuration signé ou une politique livrée par un canal distinct.

Une empreinte SHA-256 (Secure Hash Algorithm 256 bits) est une représentation de la clé publique, pas un secret. La publier dans l’application est attendu. Publier la clé privée, en revanche, reste une manière très efficace de transformer une architecture en communiqué d’incident.

Surface d’attaque et garanties absentes

Le pinning protège contre une chaîne de confiance inattendue. Il ne protège pas contre la compromission de la clé privée correspondant au pin. Un attaquant qui possède cette clé peut présenter un certificat valide ou frauduleux avec la bonne clé publique. La protection doit donc venir du stockage matériel, du contrôle d’accès, de la journalisation des signatures et de la rotation.

Il ne protège pas non plus contre un binaire client compromis. Un attaquant contrôlant l’application peut neutraliser le contrôle de pin, modifier le pinset ou intercepter les données après déchiffrement. L’obfuscation ralentit l’analyse, elle ne crée pas une frontière de confiance. Sur mobile, il faut combiner intégrité applicative, détection de compromission selon le modèle de menace et limitation des données accessibles au client.

Le pinning n’empêche pas une attaque sur le nom de domaine, le routage, le service DNS (Domain Name System) ou la disponibilité réseau. Il bloque l’authentification frauduleuse, pas le déni de service. Il ne corrige pas davantage les erreurs applicatives derrière TLS : une requête autorisée à tort reste autorisée à tort, même emballée dans une poignée de main irréprochable.

La révocation via OCSP (Online Certificate Status Protocol) ou liste de révocation ne révoque pas les sessions déjà établies. Un pinning n’y change rien. Les connexions persistantes, les tickets de reprise de session et les proxys doivent être traités selon leurs propres durées de vie et mécanismes de purge.

Certificate Transparency, HPKP et cas où pinner reste justifié

Certificate Transparency (CT) publie les certificats émis dans des journaux append-only audités publiquement. CT améliore la détection d’une émission abusive et permet de surveiller les certificats associés à un domaine. Ce n’est pas un refus local immédiat : un client peut accepter un mauvais certificat techniquement valide avant que la détection et la réponse opérationnelle aient lieu.

HPKP (HTTP Public Key Pinning) a tenté d’appliquer le pinning dans les navigateurs via des en-têtes HTTP. Le mécanisme a disparu car il permettait de verrouiller durablement un domaine sur un mauvais pin, avec des incidents de disponibilité difficiles à récupérer. Les navigateurs ont jugé, correctement, qu’offrir aux sites une télécommande pour s’auto-isoler était une idée dispensable.

Pour un site web grand public, le pinning applicatif ou navigateur est généralement à éviter. CT, surveillance de l’émission, gestion rigoureuse des comptes AC, DNSSEC (Domain Name System Security Extensions) quand le périmètre le justifie, et renouvellement automatisé réduisent le risque sans rendre chaque application dépendante d’une clé figée.

Le pinning reste défendable dans deux cas :

une application mobile manipulant des données à haute sensibilité, avec un cycle de distribution maîtrisé, un pinset de secours et une télémétrie de version ;
un échange M2M (machine-to-machine) dans un environnement fermé, où les deux extrémités sont inventoriées, les déploiements coordonnés et la reprise hors bande testée.

Pour les résolveurs internes, le profil strict de DNS over TLS peut aussi utiliser un pinset SPKI, comme décrit dans DNS over TLS. Dans ce cas, l’inventaire des clients et des serveurs est la condition préalable. Sans cet inventaire, le pinning n’est pas une mesure de sécurité, c’est une panne différée avec une empreinte SHA-256.

🐝 Ce qui arrive si on s’en passe

Sans pin ni pinset tenu à jour, une autorité de certification tierce ou une ancre installée sur le terminal suffit à présenter une identité acceptée par le client : l’interception est alors silencieuse côté serveur, qui voit une session normale et ne conserve aucune trace du détournement. Sans clé de secours préparée et sans télémétrie de version, la date de retrait d’un ancien pin devient une estimation, et le délai de publication d’un correctif applicatif (validation en magasin, adoption progressive) s’ajoute à la durée de l’indisponibilité. Sans canal de reprise indépendant de la connexion épinglée, aucune bascule à distance n’est possible. Sans distinction entre rejet de pin et échec TLS générique, un incident de rotation se lit comme une panne réseau, ce qui retarde le diagnostic et le retour arrière.

🦫 Explication de la marmotte 🍫

Lorsqu’une application contacte un serveur sécurisé, elle vérifie normalement un certificat. Ce document affirme que le serveur correspond bien à un nom de domaine et qu’une autorité reconnue a validé cette affirmation. L’application vérifie aussi que le certificat n’est pas expiré et que le nom demandé correspond.

Le pinning ajoute une vérification. L’application garde à l’avance la trace d’une clé publique attendue, ou parfois d’un certificat précis. Après les contrôles normaux, elle compare ce que présente le serveur avec cette trace. Si cela ne correspond pas, elle coupe la connexion, même si le certificat présenté semble valide.

Cette règle limite les dégâts si une autorité de certification délivre par erreur ou sous contrainte un faux certificat. Mais elle crée une dépendance : quand le serveur change de clé, l’application doit connaître la nouvelle trace avant ce changement. Sinon, elle refuse le vrai serveur et cesse de fonctionner.

Pour éviter ce blocage, l’application contient généralement deux traces : celle de la clé actuelle et celle d’une clé de remplacement préparée à l’avance. La nouvelle trace est distribuée avant le changement côté serveur. Il faut ensuite vérifier que les applications ont bien reçu cette mise à jour, puis remplacer la clé. Le pinning ne protège pas si la clé privée est volée, si l’application est modifiée par un attaquant ou si le réseau est coupé.

Pages voisines

La citent

Certificate pinning : risques et rotation des certificats

Elle cite

: les deux pages se citent l’une l’autre.

Certificate pinning : risques et rotation des certificats

Certificate pinning : risques et rotation des certificats

Ce que le certificate pinning ajoute à la validation TLS

Le compromis central : moins d’AC, plus de responsabilité

Pinset, rotation et reprise après échec

Exemple reproductible : calculer et vérifier un pin SPKI

Surface d’attaque et garanties absentes

Certificate Transparency, HPKP et cas où pinner reste justifié

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines