Part 2 · Certificate Types Intermediate 9 min read

Certificats d'authentification client

Les mots de passe peuvent être volés, hameçonnés ou cassés par force brute. Les certificats d'authentification client remplacent les secrets partagés par une preuve cryptographique d'identité, permettant une authentification plus robuste et sans mot de passe pour les utilisateurs, les appareils et les services dans les environnements d'entreprise.

En bref

Type
Educational
Niveau
Intermediate
Chapitre
8 sur 25
Suivant
Certificats IoT et appareils

Vue d'ensemble

Depuis des décennies, le couple identifiant et mot de passe constitue la manière par défaut de prouver son identité en ligne. Mais les mots de passe sont fondamentalement défectueux : ils peuvent être devinés, interceptés, réutilisés d'un service à l'autre ou récoltés par hameçonnage. Même avec des politiques de mots de passe robustes, le vol d'identifiants reste la principale cause de fuites de données année après année.

Les certificats d'authentification client offrent une approche radicalement différente. Au lieu de prouver qui vous êtes par quelque chose que vous savez (un mot de passe), vous le prouvez par quelque chose que vous possédez : un certificat numérique lié à une clé privée stockée de manière sécurisée sur votre appareil. Le serveur ne se contente pas de vérifier un secret partagé : il vérifie une signature cryptographique que seule votre clé privée pouvait produire.

Ce modèle est au cœur du TLS mutuel (mTLS), où le client et le serveur présentent tous deux des certificats et vérifient mutuellement leur identité. Alors que le TLS standard garantit que vous communiquez avec le bon serveur, le mTLS ajoute l'autre moitié : le serveur confirme également que vous êtes bien celui que vous prétendez être. C'est le socle des architectures zero-trust modernes, où aucune connexion n'est approuvée par défaut, qu'elle provienne de l'intérieur ou de l'extérieur du réseau d'entreprise.

Étapes clés

1

Début de la poignée de main TLS

Le client initie une connexion avec le serveur. Le serveur répond avec son propre certificat TLS, que le client valide auprès des autorités de certification approuvées. Jusque-là, c'est identique à une connexion HTTPS classique.

2

Requête de certificat client

Le serveur envoie un message CertificateRequest, en précisant quelles autorités de certification il approuve pour les certificats clients. Cela revient à dire au client : « Je dois aussi vérifier votre identité. »

3

Le client présente son certificat

Le client sélectionne un certificat correspondant dans son magasin local et l'envoie, accompagné d'un message CertificateVerify : une signature numérique des données de la poignée de main, créée avec la clé privée du client.

4

Le serveur valide et autorise

Le serveur vérifie la chaîne de confiance du certificat client, contrôle qu'il n'a pas été révoqué et valide la signature. Si tout est correct, la connexion est établie et le serveur sait précisément qui (ou quoi) se trouve à l'autre bout.

Composants clés

vs. les mots de passe

Les mots de passe sont un secret partagé : si l'une des parties est compromise, l'identifiant devient inutile. Les certificats clients utilisent la cryptographie asymétrique : la clé privée ne quitte jamais l'appareil, il n'y a donc rien à voler côté serveur. Ils sont immunisés contre l'hameçonnage, le credential stuffing et les attaques par réutilisation de mots de passe.

vs. l'authentification multifacteur

La MFA ajoute un deuxième facteur (code SMS, TOTP, notification push) par-dessus un mot de passe. Les certificats clients peuvent servir de facteur unique et robuste qui combine la possession (l'appareil portant la clé) et, souvent, une étape d'authentification locale (code PIN ou biométrie pour déverrouiller le keystore). Dans de nombreux cadres réglementaires, un certificat lié au matériel est considéré comme multifacteur à lui seul.

vs. FIDO2/WebAuthn

Les passkeys FIDO2 utilisent également la cryptographie asymétrique et résistent à l'hameçonnage. Cependant, FIDO2 est conçu pour l'authentification web orientée utilisateur, tandis que les certificats clients opèrent au niveau de la couche TLS, ce qui les rend adaptés aux communications machine-à-machine, VPN, Wi-Fi et aux scénarios où les flux navigateur ne sont pas disponibles.

vs. clés d'API et tokens

Les clés d'API et les tokens porteurs sont simples à mettre en œuvre mais ce sont des secrets statiques qui peuvent fuiter. Les certificats clients offrent une expiration intégrée, une révocation et un lien d'identité. Ils authentifient également au niveau de la couche transport, avant l'exécution de toute logique applicative, réduisant significativement la surface d'attaque.

Comment nous aidons

Evertrust & Certificats d'authentification client

Émission de certificats clients à grande échelleEvertrust PKI agit comme votre autorité de certification interne, émettant des certificats clients via SCEP, EST, CMP et ACME. Que vous enrôliez 100 utilisateurs ou 100 000 appareils, la plateforme gère le provisionnement automatiquement.

Visibilité complète sur le cycle de vieEvertrust CLM vous offre un inventaire en temps réel de chaque certificat client de votre environnement : qui le détient, quand il expire et s'il respecte vos politiques de certificats.

Intégration MDM transparenteDes connecteurs natifs pour les principales plateformes MDM permettent de déployer les certificats clients sur les appareils gérés sans développement spécifique. Les certificats sont enrôlés, renouvelés et révoqués via vos workflows existants de gestion d'appareils.

Révocation instantanéeLorsqu'un appareil est perdu ou qu'un collaborateur quitte l'entreprise, révoquez son certificat client immédiatement depuis le tableau de bord Evertrust ou l'API. La diffusion OCSP et CRL garantit que les parties relèvent sont notifiées en temps réel.