SSL vs TLS : différences, sécurité et versions en 2026

SSL et TLS ne sont pas deux protections modernes entre lesquelles il faudrait encore choisir. SSL est l’ancien protocole, désormais abandonné, tandis que TLS est son successeur utilisé pour sécuriser les connexions HTTPS, les API, la messagerie et de nombreux autres échanges réseau.

En 2026, un serveur web doit privilégier TLS 1.3 et conserver TLS 1.2 uniquement lorsque la compatibilité avec certains clients l’exige. SSL 2.0, SSL 3.0, TLS 1.0 et TLS 1.1 ne doivent plus être activés.

La confusion persiste parce que les expressions « certificat SSL », « hébergement avec SSL » ou « SSL gratuit » restent très employées. Dans la plupart des offres actuelles, le certificat présenté comme SSL sert en réalité à établir une connexion TLS. Le certificat ne chiffre d’ailleurs pas seul toute la session : il permet notamment d’authentifier le serveur et de participer à l’établissement sécurisé des clés utilisées ensuite pour protéger les données.

Comprendre cette distinction évite des erreurs concrètes. Acheter un nouveau « certificat SSL » ne corrigera pas un serveur qui accepte encore un ancien protocole. À l’inverse, activer TLS 1.3 ne réparera pas un certificat expiré, un nom de domaine non couvert ou une chaîne de certification incomplète. La sécurité dépend du certificat, du protocole, des suites cryptographiques, de la configuration du serveur et du comportement du client.

Table de matières

SSL vs TLS : quelle est la différence en une phrase ?

SSL est une ancienne famille de protocoles de sécurisation des communications ; TLS est la famille qui l’a remplacée et qui protège les connexions modernes. SSL signifie Secure Sockets Layer. TLS signifie Transport Layer Security. Les deux poursuivent des objectifs semblables — confidentialité, intégrité et authentification — mais leurs versions, leurs mécanismes et leur niveau de sécurité diffèrent.

TLS n’est pas simplement un nouveau nom commercial. Il résulte d’une normalisation distincte et a évolué au fil de plusieurs versions. TLS 1.0 a succédé à SSL 3.0 en 1999. TLS 1.2, défini en 2008, reste présent pour la compatibilité. TLS 1.3 a d’abord été normalisé par la RFC 8446 en 2018.

Depuis juillet 2026, la RFC 9846 constitue sa spécification de référence et remplace les RFC 8446 et 5246. Cette version simplifie la négociation, retire plusieurs algorithmes anciens et réduit la latence.

Quand un hébergeur annonce un « certificat SSL », il utilise généralement une expression devenue générique. La connexion établie par Chrome, Firefox, Safari ou Edge repose normalement sur TLS. Il est donc acceptable de reprendre « SSL/TLS » pour être compris du public, mais une documentation technique précise doit expliquer que SSL n’est plus le protocole à déployer.

Cette nuance est importante lorsqu’une erreur apparaît. Le guide CritiquePlus consacré à ERR_SSL_VERSION_OR_CIPHER_MISMATCH montre par exemple qu’un message contenant « SSL » peut en réalité signaler une incompatibilité de version TLS ou de suite cryptographique.

Tableau comparatif SSL et TLS

Critère	SSL	TLS
Signification	Secure Sockets Layer	Transport Layer Security
Statut en 2026	Obsolète et à désactiver	Protocole moderne à utiliser
Versions principales	SSL 2.0 et SSL 3.0	TLS 1.0, 1.1, 1.2 et 1.3
Versions recommandées	Aucune	TLS 1.3, avec TLS 1.2 si nécessaire
Normalisation	Technologie historique développée par Netscape	Standards publiés par l’IETF
Sécurité	Vulnérabilités structurelles et algorithmes anciens	Conception améliorée, surtout avec TLS 1.3
Handshake	Plus ancien et moins robuste	Simplifié et plus rapide dans TLS 1.3
Suites de chiffrement	Mécanismes aujourd’hui insuffisants	Suites modernes AEAD dans TLS 1.3
Utilisation sur le Web	Ne doit plus être proposée	Protège HTTPS
Terme commercial	« SSL » reste utilisé par habitude	Nom technique exact du protocole moderne

Le tableau ne signifie pas que toute connexion annoncée comme « SSL » utilise réellement SSL. Les interfaces d’hébergement, les plugins WordPress et les autorités de certification conservent souvent ce mot pour des raisons historiques. Il faut regarder la version négociée, et non l’étiquette commerciale.

Une configuration moderne permet idéalement TLS 1.3 et TLS 1.2. Le serveur et le client choisissent ensuite la meilleure version qu’ils prennent tous les deux en charge. Maintenir une ancienne version « au cas où » augmente la surface d’attaque et peut faire échouer les audits de conformité.

Comment SSL a-t-il été remplacé par TLS ?

SSL 2.0 a été publié dans les années 1990, puis SSL 3.0 a corrigé plusieurs défauts. Ces protocoles ont joué un rôle fondateur, mais l’évolution des attaques et de la cryptographie a révélé des faiblesses incompatibles avec les exigences modernes. TLS 1.0 a repris l’architecture générale de SSL 3.0 tout en introduisant des modifications suffisamment importantes pour porter un nouveau nom.

La succession des versions peut être résumée ainsi :

Version	Situation actuelle	Décision pratique
SSL 2.0	Interdit par la RFC 6176	Désactiver dans tous les cas
SSL 3.0	Vulnérable, notamment à POODLE	Désactiver dans tous les cas
TLS 1.0	Déprécié par la RFC 8996	Désactiver
TLS 1.1	Déprécié par la RFC 8996	Désactiver
TLS 1.2	Encore utilisable avec une configuration moderne	Conserver pour la compatibilité nécessaire
TLS 1.3	Version moderne de référence	Activer et privilégier

La dépréciation de TLS 1.0 et 1.1 ne signifie pas que tous les appareils anciens ont disparu. Certains équipements industriels, terminaux, logiciels métiers ou systèmes embarqués peuvent encore en dépendre. Cependant, exposer un site public à d’anciens protocoles pour quelques clients non maintenus reporte le risque sur tous les utilisateurs. Une entreprise doit plutôt isoler ces dépendances, documenter l’exception et planifier leur remplacement.

TLS 1.3 n’est pas une simple hausse de numéro. L’IETF a retiré des options devenues dangereuses ou difficiles à configurer, imposé des mécanismes de chiffrement authentifié et réduit le nombre d’allers-retours nécessaires au handshake. Ce nettoyage diminue les possibilités de mauvaise configuration.

Comment fonctionne une connexion TLS ?

Une connexion TLS commence par une négociation appelée handshake. Le navigateur et le serveur doivent s’accorder sur une version du protocole, sélectionner des paramètres cryptographiques, authentifier le serveur et dériver des clés de session. Une fois cette étape terminée, les données applicatives peuvent circuler dans un canal chiffré.

Dans une connexion TLS 1.3 classique, le client envoie notamment les versions et groupes cryptographiques qu’il accepte ainsi qu’un matériau de clé. Le serveur choisit les paramètres compatibles, présente son certificat et prouve qu’il possède la clé privée associée. Le client vérifie le certificat : domaine couvert, période de validité, signature, chaîne de confiance et autorité reconnue.

Après authentification, les deux parties disposent de secrets partagés dont sont dérivées des clés symétriques. Le chiffrement symétrique est utilisé pour la session parce qu’il est plus rapide que la cryptographie asymétrique. Les clés publiques et privées restent essentielles pour l’authentification et l’établissement sécurisé du secret, mais elles ne chiffrent pas chaque octet de la page pendant toute la visite.

TLS protège trois propriétés :

– la confidentialité, afin qu’un intermédiaire ne lise pas le contenu échangé ;

– l’intégrité, afin qu’une modification des données soit détectée ;

– l’authentification, afin que le client puisse vérifier l’identité du serveur à travers le certificat.

TLS ne garantit cependant pas qu’un site est honnête. Un site frauduleux peut posséder un certificat valide pour son propre domaine. Le cadenas indique que la communication vers ce domaine est protégée, pas que le contenu ou le commerçant mérite automatiquement votre confiance.

Pour approfondir les échecs de négociation, consultez le guide SSL Handshake Failed et erreur 525, qui sépare les causes liées au navigateur, au certificat, au serveur d’origine et à Cloudflare.

Certificat SSL, certificat TLS et HTTPS : que désignent ces termes ?

Un certificat TLS, couramment appelé certificat SSL, est un document numérique conforme au modèle X.509. Il associe une identité — le plus souvent un nom de domaine — à une clé publique et porte la signature d’une autorité de certification. Le protocole TLS utilise ce certificat pendant l’authentification du serveur.

HTTPS désigne HTTP transporté dans un canal TLS. HTTP définit les requêtes et réponses du Web ; TLS ajoute la protection du transport. Un site peut donc avoir un certificat valide mais rester mal configuré si certaines ressources sont chargées en HTTP, si les redirections ne forcent pas HTTPS ou si l’origine derrière un CDN utilise une protection insuffisante.

Trois éléments doivent être distingués :

– le certificat contient l’identité, la clé publique, la période de validité et la signature de l’émetteur ;

– le protocole TLS organise la négociation, l’authentification et la protection des échanges ;

– HTTPS est l’usage de HTTP au-dessus de TLS.

Les certificats DV, OV et EV n’emploient pas des niveaux de chiffrement différents par nature. Ils correspondent surtout à des procédures de validation distinctes. Un certificat DV vérifie le contrôle du domaine. Les certificats OV et EV ajoutent des vérifications organisationnelles, mais les navigateurs modernes n’affichent plus toujours de différence visuelle marquée.

Un certificat gratuit émis automatiquement peut offrir une protection cryptographique solide. Le prix ne détermine pas à lui seul la sécurité de la connexion. La gestion des renouvellements, la protection de la clé privée, la couverture des noms de domaine et la configuration TLS comptent davantage.

Si le navigateur ne reconnaît pas l’émetteur, le guide sur NET::ERR_CERT_AUTHORITY_INVALID détaille les causes liées à la chaîne de confiance et les vérifications adaptées.

TLS 1.2 vs TLS 1.3 : quelles différences concrètes ?

TLS 1.2 reste acceptable lorsqu’il est correctement configuré, mais il offre beaucoup plus de choix historiques. Cette souplesse peut devenir un problème : un administrateur peut conserver des échanges de clés ou des suites cryptographiques qui ne répondent plus aux attentes modernes. TLS 1.3 réduit volontairement ces choix.

Point comparé	TLS 1.2	TLS 1.3
Handshake complet	Généralement deux allers-retours TLS	Généralement un aller-retour TLS
Reprise de session	Mécanismes plus anciens	Possibilité de 0-RTT, à encadrer
Suites cryptographiques	Nombreuses combinaisons, dont certaines anciennes	Ensemble simplifié de suites AEAD
Échange de clés	Peut autoriser RSA statique selon la configuration	Échanges assurant la confidentialité persistante
Chiffrement du handshake	Une partie reste visible plus longtemps	Davantage de messages sont chiffrés
Compatibilité	Très large, y compris clients plus anciens	Excellente sur les clients modernes
Réglage conseillé	Solution de repli contrôlée	Version prioritaire

Le gain d’un aller-retour est particulièrement visible lorsque la latence réseau est élevée. Pour un visiteur proche du serveur, quelques millisecondes peuvent passer inaperçues. Pour un utilisateur mobile éloigné de l’origine, les étapes réseau s’additionnent. TLS 1.3 participe ainsi à une connexion plus rapide, même si le poids des images, le JavaScript et le temps de réponse du serveur restent souvent plus déterminants pour l’affichage complet.

Le mode 0-RTT permet à un client revenant sur un serveur d’envoyer certaines données très tôt. Il n’est pas adapté sans précaution aux opérations qui ne doivent pas être répétées, par exemple un achat ou une modification d’état, car des données précoces peuvent faire l’objet d’une attaque par rejeu. Le serveur ou l’application doit limiter les requêtes acceptées en 0-RTT.

En pratique, il ne faut pas désactiver TLS 1.2 sans avoir étudié les clients réellement utilisés. La RFC 9325 encadre encore son emploi sécurisé dans les déploiements existants, tandis que la RFC 9852 demande aux nouveaux protocoles utilisant TLS d’exiger TLS 1.3.

Un service destiné au grand public peut donc privilégier TLS 1.3 avec TLS 1.2 en repli lorsque cette compatibilité reste nécessaire. Un système B2B connecté à de vieux équipements doit mesurer la compatibilité avant la migration, puis traiter les dépendances comme une dette technique.

Quelles attaques et faiblesses distinguent SSL de TLS ?

SSL et les premières versions de TLS ont accumulé des vulnérabilités qui expliquent leur retrait. POODLE a notamment démontré une faiblesse de l’utilisation du chiffrement par blocs dans SSL 3.0. D’autres familles d’attaques ont exploité des choix cryptographiques anciens, des mécanismes de compression, des implémentations défectueuses ou la possibilité de forcer une négociation vers une version moins sûre.

TLS 1.3 réduit cette surface en supprimant RC4, DES, 3DES, les échanges de clés RSA statiques, les suites CBC et plusieurs fonctions héritées. Les suites autorisées utilisent le chiffrement authentifié avec données associées, ou AEAD. Le protocole impose également la confidentialité persistante pour les handshakes standards : la compromission future de la clé privée du certificat ne suffit pas, à elle seule, à déchiffrer les anciennes sessions enregistrées.

Une version moderne ne protège toutefois pas d’une mauvaise mise en œuvre. Les risques subsistent si la clé privée est exposée, si le certificat couvre le mauvais domaine, si un proxy intercepte le trafic sans politique maîtrisée, si les bibliothèques ne sont pas corrigées ou si l’application envoie des données sensibles dans des URL et journaux.

Le downgrade constitue un scénario important. Un attaquant tente de pousser les parties vers une version ou un mécanisme plus faible. Les navigateurs et serveurs modernes disposent de protections contre plusieurs formes de rétrogradation, mais la meilleure défense reste de ne pas proposer de protocoles obsolètes.

Enfin, TLS ne remplace ni l’authentification de l’utilisateur, ni les contrôles d’accès, ni la protection contre les injections, le hameçonnage ou les logiciels malveillants. Il protège le transport entre deux points ; la sécurité globale exige d’autres couches.

TLS améliore-t-il les performances et le référencement naturel ?

TLS 1.3 réduit la latence de négociation par rapport à TLS 1.2 et simplifie plusieurs opérations. Cette amélioration peut contribuer à une expérience plus rapide, surtout sur les réseaux mobiles ou internationaux. Elle ne doit cependant pas être présentée comme une accélération automatique de toutes les pages : un serveur lent restera lent après le handshake.

HTTPS est important pour la confiance, l’intégrité et l’accès à des fonctions modernes du navigateur. Google utilise HTTPS comme signal de classement léger depuis plusieurs années, mais le passage à HTTPS ne suffit pas à faire monter une page mal structurée ou peu utile. Pour le SEO, l’essentiel est de migrer proprement : redirections permanentes cohérentes, canonicals en HTTPS, sitemap à jour, absence de contenu mixte et une seule version indexable de chaque URL.

Une migration mal préparée peut créer des chaînes de redirections, des doublons HTTP/HTTPS, des ressources bloquées ou des erreurs de certificat. Ces problèmes affectent l’exploration et l’expérience utilisateur. Il faut tester toutes les variantes de domaine, y compris avec et sans www, et contrôler les sous-domaines réellement utilisés.

HTTP/2 et HTTP/3 sont généralement associés à des connexions sécurisées dans les navigateurs. TLS 1.3 est intégré à QUIC, le protocole de transport utilisé par HTTP/3. Une erreur n’implique toutefois pas toujours TLS : le guide CritiquePlus sur ERR_HTTP2_PROTOCOL_ERROR aide à distinguer certificat, HTTP/2, proxy, CDN et serveur.

Comment vérifier la version TLS utilisée par un site ?

Le premier contrôle consiste à ouvrir les informations de sécurité du navigateur. Dans Chrome ou Edge, cliquez sur l’icône située à gauche de l’adresse, ouvrez les informations de connexion, puis les détails du certificat. Les outils de développement, dans l’onglet Sécurité, peuvent indiquer le protocole et la suite cryptographique négociés. L’emplacement exact évolue selon la version du navigateur.

Firefox affiche également les informations techniques de la connexion depuis le cadenas, puis « Connexion sécurisée » et « Plus d’informations ». Pour une analyse publique plus complète, Qualys SSL Labs Server Test examine les versions proposées, les suites, la chaîne de certificats et plusieurs vulnérabilités connues.

En ligne de commande, OpenSSL permet de tester explicitement une version :

`openssl s_client -connect exemple.com:443 -servername exemple.com -tls1_3`

Pour TLS 1.2, remplacez l’option par `-tls1_2`. Une connexion réussie ne prouve pas que toute la configuration est parfaite, mais elle confirme que le serveur accepte la version testée. L’option `-servername` est importante pour les serveurs qui utilisent SNI et hébergent plusieurs domaines sur la même adresse IP.

Un audit doit vérifier au minimum :

– les versions TLS acceptées ;

– la date d’expiration et les noms couverts ;

– la chaîne intermédiaire ;

– les suites cryptographiques ;

– la redirection HTTP vers HTTPS ;

– HSTS, si son déploiement est maîtrisé ;

– la cohérence entre CDN, proxy et serveur d’origine ;

– l’absence de contenu mixte.

Si le test renvoie une version obsolète, le guide ERR_SSL_OBSOLETE_VERSION présente les causes côté navigateur, système et serveur.

Comment configurer TLS 1.2 et TLS 1.3 sans casser la compatibilité ?

La bonne configuration dépend du serveur, de la bibliothèque TLS, du CDN et du public. Il est préférable d’utiliser les profils maintenus par Mozilla SSL Configuration Generator ou la documentation officielle de l’hébergeur plutôt que de copier une liste de suites ancienne trouvée dans un forum.

Pour un site public moderne, la base raisonnable est la suivante :

activer TLS 1.3 ;
conserver TLS 1.2 si les clients compatibles sont nécessaires ;
désactiver SSL 2.0, SSL 3.0, TLS 1.0 et TLS 1.1 ;
installer le certificat avec toute sa chaîne intermédiaire ;
automatiser le renouvellement et surveiller son résultat ;
protéger les clés privées et limiter les accès ;
tester le serveur après chaque changement ;
vérifier le CDN et l’origine séparément.

Sur Nginx, Apache, LiteSpeed, HAProxy ou Caddy, la syntaxe diffère. Une directive correcte pour une version du logiciel peut être inconnue ou déconseillée sur une autre. Il faut donc confirmer la version installée et sauvegarder la configuration avant modification. Un redémarrage ou rechargement doit être précédé d’un test de syntaxe.

Avec un CDN, deux connexions existent souvent : visiteur vers CDN, puis CDN vers origine. Un mode qui chiffre seulement la première moitié crée une fausse impression de sécurité. L’origine doit présenter un certificat valide et le CDN doit vérifier ce certificat lorsque le mode strict est disponible.

HSTS demande également de la prudence. Cet en-tête ordonne au navigateur d’utiliser HTTPS pendant une durée définie. Une valeur longue avec inclusion des sous-domaines peut rendre un service inaccessible si un sous-domaine n’est pas prêt. Il faut commencer avec une durée courte, observer, puis augmenter progressivement avant d’envisager le préchargement.

Quels problèmes SSL et TLS rencontre-t-on le plus souvent ?

Scénario 1 : le certificat a expiré. Le serveur prend en charge TLS 1.3, mais le navigateur bloque la connexion. La version du protocole n’est pas en cause. Il faut renouveler le certificat, déployer la nouvelle chaîne et vérifier que le service automatisé a rechargé le serveur.

Scénario 2 : le certificat ne couvre pas le domaine. Un certificat prévu pour `www.exemple.com` n’inclut pas nécessairement `api.exemple.com`. Le visiteur reçoit une erreur de nom commun. Le guide sur ERR_CERT_COMMON_NAME_INVALID aide à vérifier SAN, DNS, CDN et hébergement virtuel.

Scénario 3 : la chaîne intermédiaire est incomplète. Le certificat final semble valide sur l’ordinateur de l’administrateur, car celui-ci possède déjà un intermédiaire en cache, tandis que certains mobiles échouent. Il faut déployer le fichier de chaîne complet fourni par l’autorité.

Scénario 4 : aucun protocole commun n’est disponible. Un client ancien ne prend en charge que TLS 1.0 tandis que le serveur exige TLS 1.2 ou 1.3. Réactiver TLS 1.0 publiquement n’est pas la réponse par défaut. Il faut mettre à jour ou isoler le client.

Scénario 5 : le CDN et l’origine ne sont pas cohérents. La connexion publique fonctionne, mais le CDN renvoie une erreur 525 ou 526 parce que l’origine présente un certificat expiré, auto-signé ou associé au mauvais domaine. Testez l’origine indépendamment et utilisez le mode de validation strict.

Scénario 6 : du contenu mixte subsiste. La page HTML arrive en HTTPS, mais charge une image, un script ou une feuille CSS en HTTP. Le navigateur peut bloquer la ressource ou réduire les indicateurs de sécurité. Il faut corriger les URL dans le code, la base de données et les ressources tierces.

Scénario 7 : une inspection TLS perturbe la confiance. Un antivirus, un proxy d’entreprise ou un portail captif présente son propre certificat. Si son autorité racine n’est pas correctement gérée, les applications affichent des erreurs. Ne désactivez pas la validation ; identifiez l’équipement et suivez la politique de l’organisation.

FAQ

Faut-il acheter un certificat TLS si l’hébergeur fournit un certificat SSL ?

Non, pas uniquement à cause du nom. L’offre appelée « SSL » fournit probablement un certificat utilisable avec TLS. Vérifiez l’émetteur, les domaines couverts, le renouvellement et la configuration du serveur.

TLS 1.2 est-il encore sécurisé en 2026 ?

TLS 1.2 peut encore être utilisé avec des suites et échanges de clés modernes. Il reste utile pour la compatibilité, mais TLS 1.3 doit être privilégié. La sécurité de TLS 1.2 dépend davantage de la configuration.

TLS 1.3 remplace-t-il le certificat ?

Non. TLS 1.3 est le protocole. Le certificat reste utilisé pour authentifier le serveur dans les connexions web classiques. Les deux éléments remplissent des fonctions complémentaires.

Le cadenas prouve-t-il qu’un site est fiable ?

Il prouve surtout que le navigateur a établi une connexion chiffrée et authentifiée vers le domaine affiché. Il ne garantit ni la qualité du vendeur, ni l’absence d’arnaque, ni la sécurité de toute l’application.

Pourquoi dit-on encore certificat SSL ?

Parce que l’expression s’est imposée avant TLS et reste comprise du grand public. Dans une documentation précise, « certificat TLS » ou « certificat SSL/TLS » est plus exact.

Peut-on activer uniquement TLS 1.3 ?

Oui dans un environnement dont tous les clients sont compatibles. Pour un site public, conserver TLS 1.2 comme repli reste souvent raisonnable. La décision doit être prise à partir des clients réels, pas d’une hypothèse.