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
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.
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.
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.
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.
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.
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.
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.
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é.
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.
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.
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.
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.
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.
| HTTP | HTTPS | |
|---|---|---|
| Chiffrement | Aucun (texte en clair) | Chiffrement TLS |
| Authentification | Aucune preuve d'identité du serveur | Le certificat atteste de l'identité du serveur |
| Intégrité des données | Altérables en transit | Inaltérables (vérification MAC) |
| Port par défaut | 80 | 443 |
| Impact SEO | Pénalisé par Google | Bonus au classement |
| Performance | Pas de prise en charge d'HTTP/2 | HTTP/2 et HTTP/3 requièrent TLS |
Émission automatisée des certificats HTTPS — Evertrust 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 HTTPS — Evertrust 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 jours — Grâ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.