Certificats SSL/TLS expliques : ce qu'ils sont et pourquoi ils comptent

Pourquoi SSL/TLS pose encore des problemes

On pourrait croire qu'a ce stade, SSL/TLS est un probleme resolu. Chaque navigateur affiche un cadenas. Let's Encrypt a rendu les certificats gratuits. Les hebergeurs proposent HTTPS en un clic. Et pourtant, nous trouvons encore chaque semaine des certificats mal configures sur des sites en production. Certificats expires, chaines incompletes, avertissements de contenu mixte, en-tetes HSTS manquants. Ce ne sont pas des cas isoles : ce sont des erreurs courantes qui eroddent la confiance et penalisent le referencement.

Ce guide explique comment TLS fonctionne reellement, ce que signifient les differents types de certificats en pratique, comment automatiser la gestion des certificats, et quelles erreurs de configuration nous trouvons le plus souvent lors des audits de securite pour les entreprises en Suisse.

Bref historique : SSL, TLS et pourquoi les noms persistent

SSL (Secure Sockets Layer) a ete developpe par Netscape au milieu des annees 1990. SSL 2.0 est sorti en 1995, SSL 3.0 en 1996. Les deux avaient de graves failles cryptographiques. TLS (Transport Layer Security) 1.0 a remplace SSL 3.0 en 1999, et le protocole a evolue a travers TLS 1.1 (2006), TLS 1.2 (2008) et TLS 1.3 (2018).

Aujourd'hui, seuls TLS 1.2 et TLS 1.3 sont consideres comme surs. Tous les navigateurs majeurs ont abandonne le support de TLS 1.0 et 1.1. Malgre cela, on continue de dire "certificat SSL" parce que le terme est reste dans l'usage courant.

Comment fonctionne le handshake TLS

Chaque fois que votre navigateur se connecte a un site HTTPS, un handshake TLS a lieu avant tout echange de donnees. Comprendre ce processus aide a diagnostiquer les problemes quand quelque chose ne va pas.

Handshake TLS 1.2 (simplifie)

1. Client Hello - Le navigateur envoie au serveur une liste des suites de chiffrement supportees, sa version TLS et un nombre aleatoire.
2. Server Hello - Le serveur choisit une suite de chiffrement, envoie son propre nombre aleatoire et son certificat.
3. Verification du certificat - Le navigateur verifie le certificat par rapport a son magasin d'autorites de certification (CA) de confiance.
4. Echange de cles - Les deux parties generent un secret partage. Avec l'echange de cles RSA, le client le chiffre avec la cle publique du serveur. Avec Diffie-Hellman (DHE/ECDHE), les deux parties contribuent a la generation du secret partage.
5. Cles de session - Les deux parties derivent des cles de session symetriques a partir du secret partage et des nombres aleatoires.
6. Termine - Les deux parties envoient un message "Finished" chiffre avec les nouvelles cles de session.

Ce processus prend deux allers-retours (2-RTT) en TLS 1.2.

Handshake TLS 1.3 : plus rapide et plus simple

TLS 1.3 reduit cela a un seul aller-retour (1-RTT). Il supprime les suites de chiffrement obsoletes, impose le forward secrecy (uniquement l'echange de cles ECDHE) et combine les etapes. Resultat : etablissement de connexion plus rapide et securite renforcee par defaut.

Caracteristique	TLS 1.2	TLS 1.3
Allers-retours handshake	2-RTT	1-RTT (reprise 0-RTT)
Forward secrecy	Optionnel	Obligatoire
Echange de cles RSA	Supporte	Supprime
Suites de chiffrement	37+	5
Vulnerabilites connues	BEAST, POODLE (attenuees)	Aucune actuellement

Types de certificats : DV, OV et EV

Tous les certificats ne se valent pas. Les trois types principaux different par le niveau de validation, le cout et ce qu'ils communiquent aux utilisateurs.

Certificats Domain Validated (DV)

Les certificats DV prouvent que vous controlez le domaine. La CA le verifie par l'une de trois methodes : placer un fichier specifique sur votre serveur web, ajouter un enregistrement DNS TXT, ou repondre a un email a une adresse administrative du domaine.

Cout : Gratuit (Let's Encrypt, ZeroSSL) a environ 10 CHF/an

Ideal pour : Blogs, sites personnels, sites de PME, la plupart des applications web

Certificats Organization Validated (OV)

Les certificats OV exigent que la CA verifie que l'organisation derriere le domaine existe reellement. Cela implique la verification des documents d'enregistrement de l'entreprise et parfois une verification telephonique.

Cout : 50-200 CHF/an

Certificats Extended Validation (EV)

Les certificats EV exigent la validation la plus rigoureuse. La CA verifie l'existence legale, l'existence operationnelle, l'adresse physique et l'autorite du demandeur.

Cout : 100-500+ CHF/an

Contexte historique : Les certificats EV affichaient autrefois le nom de l'entreprise dans une barre d'adresse verte. Tous les navigateurs majeurs ont supprime cette distinction visuelle entre 2019 et 2020.

Let's Encrypt et le protocole ACME

Let's Encrypt a ete lance en 2016 et a fondamentalement change le paysage des certificats. Il fournit des certificats DV gratuits en utilisant le protocole ACME, qui automatise l'ensemble du processus d'emission et de renouvellement.

Comment fonctionne ACME

1. Le client genere une paire de cles de compte et s'inscrit aupres de la CA.
2. Le client demande un certificat pour un domaine, et la CA repond avec un ensemble de defis.
3. Le client complete un defi (HTTP-01 : placer un fichier a /.well-known/acme-challenge/, ou DNS-01 : creer un enregistrement DNS TXT).
4. La CA verifie le defi et emet le certificat.
5. Le client installe le certificat et planifie le renouvellement (les certificats Let's Encrypt sont valides 90 jours).

Outils d'automatisation

• Certbot - Le client ACME original. Fonctionne avec Apache et Nginx.
• acme.sh - Un client ACME base sur des scripts shell. Leger, sans dependances.
• Caddy - Un serveur web avec HTTPS automatique integre.
• Traefik - Un reverse proxy qui gere automatiquement les certificats pour les applications containerisees.

Nous avons vu des entreprises en Suisse perdre des jours entiers de trafic web parce qu'un cron job de renouvellement Let's Encrypt echouait silencieusement. L'automatisation ne fonctionne que si on la surveille.

Erreurs de configuration courantes

Lors de nos evaluations de securite web pour les clients, les problemes de certificats sont parmi les resultats les plus frequents.

1. Contenu mixte

Cela se produit quand une page est servie en HTTPS mais charge certaines ressources en HTTP. Les navigateurs bloquent le contenu mixte actif (scripts, iframes) et peuvent avertir du contenu mixte passif (images).

2. Certificats expires

Un certificat expire provoque un avertissement pleine page dans le navigateur. La plupart des utilisateurs ne passeront pas outre. Votre site est effectivement hors ligne.

3. Chaine de certificats incomplete

Votre serveur doit envoyer la chaine complete : votre certificat plus tous les certificats intermediaires. Si un intermediaire manque, certains navigateurs (surtout sur mobile) ne parviendront pas a valider le certificat.

4. Domaine incorrect / Non-correspondance SAN

Le Common Name ou les Subject Alternative Names (SAN) du certificat doivent correspondre au domaine visite. Un certificat pour example.com ne fonctionnera pas pour www.example.com sauf si ce dernier est liste comme SAN.

5. Utilisation de TLS 1.0 ou 1.1

Certains serveurs ont encore TLS 1.0 ou 1.1 actives pour la "compatibilite". Desactivez-les.

6. Suites de chiffrement faibles

Les configurations modernes ne devraient supporter que les chiffrements AEAD (AES-GCM, ChaCha20-Poly1305) avec forward secrecy. Utilisez le generateur de configuration SSL de Mozilla.

HSTS : HTTP Strict Transport Security

Meme avec HTTPS parfaitement configure, la premiere requete d'un utilisateur peut etre en HTTP, vulnerable au SSL stripping. HSTS resout ce probleme :

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Le navigateur retient que votre site ne doit etre accede qu'en HTTPS. Pour plus de details sur HSTS et les autres en-tetes de securite, consultez notre guide complet des en-tetes de securite.

SSL/TLS et SEO

Google a confirme HTTPS comme signal de classement en 2014. Voici ce que nous avons observe :

• Les signaux de confiance comptent. Un avertissement "Non securise" augmente le taux de rebond.
• HTTPS est requis pour HTTP/2 et HTTP/3. Ces protocoles offrent des ameliorations de performance significatives.
• Certaines API navigateur exigent un contexte securise. Geolocalisation, service workers, notifications push.
• Les donnees referrer sont perdues. Le trafic d'un site HTTPS vers un site HTTP perd l'en-tete referrer.

Certificate Transparency

Certificate Transparency (CT) est un systeme de journalisation publique ou les CA doivent enregistrer chaque certificat emis. Cela permet de detecter les certificats emis frauduleusement.

• crt.sh - Un moteur de recherche gratuit pour les journaux CT.
• Facebook CT Monitoring - Envoie des notifications lors de l'emission d'un nouveau certificat pour votre domaine.
• Certspotter - Un outil de surveillance qui alerte sur les nouveaux certificats.

Recommandations pratiques

1. Utilisez TLS 1.2 comme minimum. Desactivez TLS 1.0 et 1.1. Preferez TLS 1.3 si possible.
2. Automatisez la gestion des certificats. Let's Encrypt avec Certbot, ou un fournisseur qui gere les certificats automatiquement.
3. Surveillez l'expiration des certificats. Configurez des alertes.
4. Activez HSTS. Commencez avec un max-age court, testez, puis augmentez.
5. Verifiez votre chaine de certificats. Utilisez SSL Labs.
6. Eliminez le contenu mixte. Auditez chaque page.
7. Surveillez les journaux CT.
8. Utilisez des suites de chiffrement fortes.

Conclusion

Les certificats SSL/TLS sont une couche fondamentale de la securite web. Bien les configurer n'est pas difficile, mais cela demande de l'attention aux details souvent negliges.

Si vous n'etes pas sur de votre configuration actuelle, testez votre domaine sur SSL Labs. Si la note est inferieure a A, il y a du travail a faire.

Besoin d'aide pour securiser votre site web ? Contactez notre equipe a Lugano. Nous aidons les entreprises en Suisse avec la securite web, de la configuration des certificats aux audits de securite complets.