Certificats TLS/SSL

Vue d'ensemble

Lorsque vous voyez un cadenas dans la barre d'adresse de votre navigateur, vous observez un certificat TLS en action. Transport Layer Security (TLS) est le protocole qui chiffre les communications entre votre navigateur et un serveur web, et les certificats TLS sont les certificats numériques qui le rendent possible.

Vous entendrez peut-être encore parler de « certificats SSL ». Secure Sockets Layer (SSL) est le protocole d'origine développé par Netscape au milieu des années 1990. SSL 3.0, publié en 1996, était la dernière version avant que le protocole ne soit renommé et reconçu en TLS 1.0 en 1999. Aujourd'hui, toutes les versions de SSL sont obsolètes et considérées comme non sécurisées. Les versions actuellement utilisées sont TLS 1.2 (2008) et TLS 1.3 (2018). Le terme « certificat SSL » persiste dans le marketing et les conversations, mais la technologie sous-jacente est bel et bien le TLS. Tout au long de ce guide, nous utilisons « certificat TLS » par souci de précision.

Les certificats TLS remplissent deux fonctions essentielles : ils authentifient le serveur (en prouvant que vous vous connectez au véritable site et non à un imposteur) et ils activent le chiffrement (en garantissant que les données échangées entre votre navigateur et le serveur ne peuvent être ni lues ni altérées par un tiers sur le réseau).

Étapes clés

Client Hello

Le navigateur envoie un message « Client Hello » au serveur, en indiquant les versions de TLS et les suites cryptographiques qu'il prend en charge, accompagnés d'une valeur aléatoire. En TLS 1.3, le client envoie également son key share dans ce premier message, réduisant la poignée de main à un seul aller-retour.

Server Hello et certificat

Le serveur répond avec la suite cryptographique choisie, sa propre valeur aléatoire, son key share et, point essentiel, son certificat TLS. Le certificat contient la clé publique du serveur et est signé par une autorité de certification approuvée.

Validation du certificat

Le navigateur vérifie le certificat : la CA est-elle approuvée ? Le certificat a-t-il expiré ? A-t-il été révoqué ? Le nom de domaine du certificat correspond-il à l'URL ? Si l'un de ces contrôles échoue, le navigateur affiche un avertissement de sécurité et la connexion est interrompue.

Échange de clés et session chiffrée

À partir des key shares échangés dans les messages hello, les deux parties dérivent les mêmes clés de session via un échange Diffie-Hellman. Ces clés symétriques chiffrent toute la communication ultérieure. Les clés privées ne sont jamais transmises : seules circulent les key shares nécessaires à la dérivation des clés de session.

Composants clés

Certificats wildcard

Un certificat wildcard sécurise un domaine et tous ses sous-domaines à un niveau. Par exemple, un certificat pour *.example.com couvre www.example.com, api.example.com et mail.example.com. Il ne couvre pas les sous-domaines multi-niveaux comme staging.api.example.com. Les wildcards simplifient la gestion mais demandent de la prudence : si la clé privée est compromise, tous les sous-domaines sont affectés.

Certificats SAN / multi-domaines

Les certificats Subject Alternative Name (SAN) peuvent inclure plusieurs noms de domaine distincts dans un seul certificat. Par exemple, un même certificat peut couvrir example.com, example.org et shop.example.net. Les certificats SAN sont courants dans les environnements cloud et les déploiements CDN où un serveur unique héberge de nombreux domaines différents.

Quand utiliser quoi

Utilisez des certificats wildcard lorsque vous avez de nombreux sous-domaines sous un même domaine et que vous souhaitez simplifier la gestion. Utilisez des certificats SAN pour sécuriser des domaines indépendants ou un mélange de domaines et de sous-domaines. Certains certificats combinent les deux en intégrant des entrées wildcard dans une liste SAN.

Considérations de sécurité

Les certificats wildcard et SAN augmentent tous deux le rayon d'impact d'une compromission de clé privée. Si la clé fuit, chaque domaine du certificat est exposé. Les organisations doivent peser la commodité face au risque, protéger fortement leurs clés et envisager des certificats à courte durée de vie pour limiter l'exposition.

Evertrust & Certificats TLS/SSL

Automatiser les renouvellements à grande échelle — Evertrust CLM automatise l'intégralité du cycle de vie des certificats TLS, de la demande à l'émission, puis au déploiement et au renouvellement, en s'appuyant sur ACME et des intégrations natives avec les serveurs web, les équilibreurs de charge et les plateformes cloud. Lorsque les durées de vie tomberont à 47 jours, vos renouvellements se feront automatiquement.

Découvrir chaque certificat TLS — Le scan réseau, la surveillance des journaux CT et la découverte côté endpoint constituent un inventaire complet de tous les certificats TLS de votre infrastructure, y compris ceux acquis en dehors du périmètre IT. Plus d'expirations imprévues.

Prévenir les interruptions — Une surveillance en temps réel avec alertes configurables garantit qu'aucun certificat n'expire à votre insu. Les tableaux de bord affichent les échéances d'expiration, le statut de conformité et les certificats à risque, offrant à votre équipe une visibilité complète et le temps d'agir.

Compatible avec n'importe quelle CA — Evertrust est agnostique vis-à-vis des CA. Que vos certificats TLS proviennent de Let's Encrypt, DigiCert, Sectigo ou de votre propre CA privée, CLM les gère tous depuis une plateforme unique.

PKI

CLM

Cas d'usage

Secteurs

Conformité

Apprendre

Outils & Analyses

Événements & Communauté

En bref