Certificats serveur TLS
Sécurisez le trafic web à grande échelle
Inventaire des certificats
Découvrez et suivez tous vos certificats
Certificats DevOps
Automatisez pour les pipelines CI/CD
Chiffrement d'e-mails
S/MIME pour la messagerie d'entreprise
Directive NIS2
Obligations européennes en cybersécurité
DORA
Résilience opérationnelle numérique
eIDAS 2.0
Identification électronique et services de confiance
RGPD
Protection des données et vie privée
Cyber Resilience Act
Règlement européen sur la sécurité des produits
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.
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.
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.
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é. »
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.
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.
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.
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.
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.
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.
Émission de certificats clients à grande échelle — Evertrust 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 vie — Evertrust 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 transparente — Des 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ée — Lorsqu'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.