Guide Beginner 12 min read

HTTPS expliqué

HTTPS est la version chiffrée de HTTP, qui protège les données échangées entre les navigateurs et les serveurs. Il s'appuie sur des certificats TLS émis par des autorités de certification de confiance. Ce guide explique le fonctionnement interne d'HTTPS, les différents types de certificats, les bonnes pratiques de déploiement et la gestion des certificats HTTPS à l'échelle de l'entreprise.

En bref

Type
Guide
Niveau
Beginner
Suivant
Le protocole ACME

Vue d'ensemble

HTTPS (HyperText Transfer Protocol Secure) est la version chiffrée d'HTTP, le protocole utilisé pour transférer des données entre un navigateur web et un site. HTTPS s'appuie sur TLS (Transport Layer Security) pour chiffrer la connexion, garantissant que les données ne peuvent être ni lues ni altérées en transit.

Lorsque vous apercevez l'icône de cadenas dans la barre d'adresse de votre navigateur, cela signifie que la connexion entre votre appareil et le serveur est chiffrée par HTTPS. Le serveur a présenté un certificat numérique émis par une autorité de certification (CA) de confiance, et votre navigateur l'a vérifié.

HTTPS était initialement réservé aux pages sensibles, comme les services bancaires en ligne et les formulaires de connexion. Aujourd'hui, il s'impose comme la norme sur l'ensemble du web. Depuis 2018, Google Chrome signale tous les sites en HTTP comme « Non sécurisés », et les moteurs de recherche pénalisent les sites non chiffrés dans leurs classements. Plus de 95 % du trafic web utilise désormais HTTPS.

Étapes clés

1

Client Hello

Le client envoie un message ClientHello contenant ses versions de TLS prises en charge, ses suites de chiffrement et une valeur aléatoire. En TLS 1.3, le client envoie également des key shares pour les groupes d'échange de clés anticipés, ce qui accélère le processus.

2

Server Hello + Certificat

Le serveur répond avec la suite de chiffrement retenue, son propre key share et sa chaîne de certificats. Le client vérifie le certificat par rapport à son magasin de confiance, contrôle que le Subject Alternative Name correspond au domaine demandé et valide la chaîne de signatures jusqu'à une CA racine de confiance.

3

Finished + Données applicatives

Les deux parties dérivent les clés de session partagées à partir de l'échange de clés. Le client envoie un message Finished chiffré avec les nouvelles clés. Les données applicatives peuvent alors circuler. En TLS 1.3, l'ensemble de ce processus ne prend qu'un seul aller-retour (1-RTT), contre deux en TLS 1.2.

Composants clés

Domain Validated (DV)

Vérifie uniquement la propriété du domaine. Émis en quelques minutes via une validation automatisée (HTTP-01, DNS-01). Utilisé par la plupart des workflows d'émission automatisée. Coût le plus bas, aucune information d'organisation affichée.

Organization Validated (OV)

Vérifie à la fois la propriété du domaine et l'existence légale de l'organisation. Délai de 1 à 3 jours ouvrés. Le nom de l'organisation apparaît dans le champ Subject du certificat. Courant pour les sites d'entreprise.

Extended Validation (EV)

Le plus haut niveau de validation. Exige une vérification approfondie de l'existence légale, physique et opérationnelle de l'organisation. La barre verte n'apparaît plus dans les navigateurs, mais ce niveau offre toujours la plus forte garantie d'identité.

Wildcard et SAN

Les certificats wildcard (*.example.com) couvrent tous les sous-domaines. Les certificats SAN listent plusieurs domaines spécifiques. Tous deux réduisent le nombre de certificats à gérer.

Exigences clés

Certificats expirés

La cause la plus fréquente des interruptions HTTPS. Un certificat expiré déclenche un avertissement pleine page dans le navigateur, que la plupart des utilisateurs ne peuvent contourner. Avec des durées de vie de 47 jours, le suivi manuel n'est plus viable.

Contenu mixte

Chargement de ressources HTTP sur une page HTTPS. Les navigateurs bloquent intégralement le contenu actif mixte (scripts, iframes) et peuvent avertir au sujet du contenu passif mixte (images). Auditez toutes les URL de ressources et utilisez des URL relatives au protocole ou en HTTPS.

Non-correspondance de nom du certificat

Le SAN du certificat ne correspond pas au domaine demandé. Fréquent lorsque le domaine nu (example.com) est absent d'un certificat qui ne couvre que www.example.com.

Suites de chiffrement faibles

Autoriser TLS 1.0/1.1, RC4 ou des chiffrements de qualité export rend votre serveur vulnérable à des attaques connues. Désactivez tout ce qui est en dessous de TLS 1.2 et privilégiez les suites de chiffrement TLS 1.3. Utilisez des outils comme SSL Labs pour vérifier votre configuration.

Comparaison

HTTPHTTPS
ChiffrementAucun (texte en clair)Chiffrement TLS
AuthentificationAucune preuve d'identité du serveurLe certificat atteste de l'identité du serveur
Intégrité des donnéesAltérables en transitInaltérables (vérification MAC)
Port par défaut80443
Impact SEOPénalisé par GoogleBonus au classement
PerformancePas de prise en charge d'HTTP/2HTTP/2 et HTTP/3 requièrent TLS
À retenir : HTTPS ne se résume pas au chiffrement. Il assure également l'authentification (prouver que le serveur est bien celui qu'il prétend être) et l'intégrité (détecter toute modification en transit). Ces trois éléments sont indispensables à une communication sécurisée.
Comment nous aidons

Evertrust & HTTPS expliqué

Émission automatisée des certificats HTTPSEvertrust PKI émet des certificats TLS via ACME, l'API REST et d'autres protocoles. Les certificats se renouvellent automatiquement, ce qui garantit la sécurité de vos points d'accès HTTPS sans intervention manuelle.

Visibilité complète sur HTTPSEvertrust CLM découvre l'ensemble des certificats HTTPS de votre infrastructure, des sites publics aux API internes. Recevez des alertes avant l'expiration de tout certificat.

Prêt pour les 47 joursGrâce à la prise en charge native d'ACME et à la gestion automatisée du cycle de vie, Evertrust permet à votre organisation d'aborder sereinement l'ère des certificats à courte durée de vie. Fini les renouvellements en urgence.