Types de certificats SSL : choisir la solution adaptée
Publié le 30 septembre 2026
Le bon certificat SSL remplit deux fonctions à la fois : il chiffre le trafic entre un visiteur et votre serveur, et il présente l’identité dont vos visiteurs ont besoin pour avoir confiance. Les types de certificats SSL se distinguent principalement par la manière dont cette identité est validée et par le nombre de noms d’hôte qu’ils couvrent. Pour la plupart des sites, faire le bon choix relève moins de la cryptographie que de l’adéquation entre la couverture et la validation du certificat et le fonctionnement réel du service.
Un petit site vitrine, une page de paiement, une plateforme SaaS mutualisée et une agence gérant 40 domaines clients peuvent tous utiliser les mêmes normes de chiffrement TLS. Ils ne devraient toutefois pas utiliser automatiquement le même certificat. Le fonctionnement est plus serein lorsque le plan de certificats correspond au plan d’infrastructure.
Types de certificats SSL selon le niveau de validation
Le niveau de validation détermine les vérifications effectuées par l’autorité de certification avant la délivrance du certificat. Tout certificat valide chiffre la connexion. La différence réside dans le niveau de vérification de l’identité et, dans certains cas, dans les informations affichées dans les détails du certificat.
Certificats à validation de domaine
Un certificat à validation de domaine, ou DV, confirme le contrôle d’un nom de domaine. L’autorité de certification vous demande généralement de créer un enregistrement DNS, de téléverser un fichier de vérification ou d’approuver un e-mail envoyé à une adresse autorisée. Une fois cette vérification réussie, la délivrance peut être très rapide.
Le DV est un choix pratique pour les blogs, les pages d’atterrissage, les environnements de développement, les API, les outils internes exposés via un domaine et de nombreux sites web professionnels classiques. Il fournit aux visiteurs le cadenas HTTPS et chiffre les identifiants, les formulaires, les sessions et tout autre trafic en transit.
Le compromis est simple : le DV ne vérifie pas l’entreprise légalement constituée derrière le site web. Un visiteur peut voir que sa connexion est chiffrée et que le site contrôle le domaine, mais le certificat de l’autorité de certification ne lui fournit pas une identité d’organisation vérifiée séparément. Pour de nombreuses entreprises, c’est parfaitement approprié.
Certificats à validation de l’organisation
Les certificats à validation de l’organisation, ou OV, exigent que l’autorité de certification vérifie à la fois le contrôle du domaine et l’organisation qui demande le certificat. Cela implique normalement de vérifier les informations d’immatriculation de l’entreprise, son adresse et un moyen de contact confirmé.
Les certificats OV conviennent aux entreprises établies, aux portails B2B, aux sites d’agences, aux plateformes d’approvisionnement et aux espaces clients où l’identité de l’organisation revêt de l’importance. Les informations vérifiées sur l’organisation sont disponibles dans les détails du certificat, ce qui peut faciliter les échanges de contrôle préalable avec les clients d’entreprise ou les équipes de sécurité.
Le chiffrement n’est pas plus puissant que celui d’un DV simplement parce que le certificat est OV. La protection TLS moderne dépend de la configuration du serveur, des versions de protocole prises en charge, des suites de chiffrement et du type de clé du certificat. L’OV ajoute un processus d’assurance d’identité plus exigeant, pas un chiffrement magique supplémentaire. Toujours utile, mais pas de sorcellerie.
Certificats à validation étendue
Les certificats à validation étendue, ou EV, impliquent le processus de validation le plus détaillé. L’autorité de certification vérifie l’existence légale de l’organisation, son statut opérationnel, son adresse physique et l’identité du demandeur autorisé selon des règles définies.
L’EV peut être pertinent pour les organisations réglementées, les services financiers, les marques de commerce électronique à forte valeur et les entreprises soumises à des exigences formelles d’approvisionnement ou de conformité. Il peut également être demandé par un partenaire disposant de sa propre liste de contrôle de sécurité des fournisseurs.
Pour un site web de petite entreprise classique, l’EV ne constitue pas automatiquement le meilleur investissement. Les navigateurs modernes n’affichent plus la barre d’adresse verte très visible qui permettait autrefois à l’EV de se distinguer auprès des utilisateurs ordinaires. Choisissez-le lorsque son processus de validation répond à un véritable besoin de confiance, contractuel ou lié aux politiques, et non parce que vous espérez une hausse spectaculaire de la conversion visuelle.
Types de certificats SSL selon la couverture des domaines
Après la validation, la couverture constitue la prochaine décision. C’est à cette étape que les achats de certificats tournent le plus souvent mal. Un certificat peut être valide et correctement installé, tout en échouant pour un nom d’hôte qu’il n’a jamais été délivré pour protéger.
Certificats pour un seul domaine
Un certificat pour un seul domaine protège un nom de domaine complet, tel que `www.example.com` ou `app.example.com`. Selon la configuration du certificat, le domaine racine et sa version `www` peuvent nécessiter une couverture distincte. Ne supposez jamais que les deux sont inclus sans vérifier les noms alternatifs du sujet du certificat, souvent appelés SAN.
Les certificats pour un seul domaine sont simples et faciles à gérer pour un service unique. Ils conviennent lorsqu’une application dispose d’un nom d’hôte dédié et d’un cycle de renouvellement indépendant.
Certificats génériques
Un certificat générique protège un domaine et ses sous-domaines de premier niveau, tels que `shop.example.com`, `api.example.com` et `status.example.com`, à l’aide d’un nom comme `*.example.com`. Il est utile pour les plateformes auxquelles des sous-domaines sont régulièrement ajoutés, notamment les déploiements d’agences, les portails clients et les environnements SaaS en expansion.
Une limite surprend souvent : `*.example.com` ne protège pas `example.com` sauf si le domaine racine est inclus séparément, et il ne couvre pas `east.api.example.com`. Les certificats génériques ne couvrent qu’un seul niveau de sous-domaine. Ce n’est pas la situation DNS la plus élégante à découvrir pendant un lancement ; cartographiez donc les noms d’hôte avant de commander.
Les certificats génériques nécessitent généralement une validation basée sur DNS, car prouver le contrôle d’un domaine générique requiert un défi DNS. C’est généralement simple lorsque l’accès au DNS est organisé, mais il faut en tenir compte avant de choisir un processus de renouvellement automatisé.
Certificats pour plusieurs domaines ou SAN
Un certificat pour plusieurs domaines, également appelé certificat SAN, protège plusieurs noms d’hôte spécifiques avec un seul certificat. Par exemple, un certificat peut couvrir `example.com`, `www.example.com`, `app.example.net` et `customer.example.org`.
Cela est utile pour les entreprises qui exploitent plusieurs marques, les agences qui hébergent des services clients associés ou les équipes qui ont besoin d’un certificat contrôlé unique pour un groupe défini de points de terminaison. Cela peut réduire la prolifération des certificats, mais crée également une dépendance partagée. Si vous remplacez ou révoquez ce certificat, tous les noms d’hôte couverts peuvent être affectés.
Dans les environnements de grande taille, des certificats distincts par application, unité opérationnelle ou responsable du renouvellement peuvent être plus sûrs sur le plan opérationnel. Moins de certificats ne signifie pas toujours moins de travail lorsqu’une modification a un vaste rayon d’impact.
Comment choisir le bon certificat
Commencez par les noms d’hôte, pas par le nom du produit. Répertoriez chaque domaine public, nom `www`, point de terminaison d’API, portail d’administration, point de terminaison lié à la messagerie et sous-domaine prévu qui nécessite TLS. Déterminez ensuite si ces noms sont fixes, susceptibles d’évoluer de manière imprévisible ou gérés par différentes équipes.
Un certificat DV pour un seul domaine suffit généralement pour un site web ou un point de terminaison d’application unique. Un certificat DV générique est souvent la réponse la plus judicieuse pour un ensemble croissant de sous-domaines de premier niveau. Un certificat SAN convient bien à un ensemble fixe de noms répartis sur plusieurs domaines. La validation OV ou EV entre en jeu lorsque la vérification de l’identité est exigée par les clients, les politiques, les pratiques du secteur ou les conditions contractuelles.
Tenez également compte de l’environnement situé derrière le certificat. Si le trafic s’arrête au niveau d’un équilibreur de charge, d’un proxy inverse, d’un CDN ou d’un serveur web géré, le certificat doit être installé et renouvelé au point où TLS s’arrête. L’installer sur un serveur principal ne sera d’aucune aide si les visiteurs se connectent d’abord à un proxy dont le certificat a expiré.
Renouvellement, automatisation et risques opérationnels
Un certificat expiré peut interrompre les connexions, les parcours de paiement, les appels d’API et la confiance du navigateur, avec très peu d’avertissement pour les clients. Le renouvellement des certificats doit être traité comme une tâche opérationnelle, et non comme un rappel de calendrier que quelqu’un espère remarquer pendant un vendredi chargé.
Utilisez le renouvellement automatisé lorsque votre type de certificat et votre méthode de validation le permettent. La validation DNS est particulièrement utile pour les certificats génériques, mais l’automatisation nécessite un accès sécurisé aux enregistrements DNS. Limitez soigneusement ces identifiants et documentez la personne qui en est responsable. Pour une validation basée sur un fichier, vérifiez que les redirections, les règles de mise en cache, les pare-feu d’applications web et les pipelines de déploiement ne bloquent pas le chemin de vérification.
Après l’installation ou le renouvellement, vérifiez davantage que le cadenas. Vérifiez la chaîne de certificats, les noms couverts, la date d’expiration, le comportement des redirections et le point de terminaison TLS qui dessert réellement le trafic public. La surveillance doit générer une alerte bien avant l’expiration et tester le nom d’hôte utilisé par les clients, pas uniquement l’adresse d’un serveur interne.
Pour les équipes qui préfèrent ne pas assumer seules cette charge opérationnelle, l’assistance d’un hébergement géré peut aider à installer les certificats, effectuer les vérifications de renouvellement et de validation DNS, ainsi qu’à assurer la surveillance du service. Chez kodu.cloud, l’objectif pratique n’est pas de rendre les certificats passionnants. Il s’agit de maintenir la disponibilité des services chiffrés pendant que vous vous consacrez au travail qui paie les factures.
Choisissez la couverture de certificat la plus restreinte qui couvre de manière fiable vos services réels, automatisez les renouvellements que vous pouvez et conservez suffisamment de visibilité pour qu’une personne puisse détecter les exceptions. La sécurité fonctionne au mieux lorsqu’elle est ennuyeuse, de la meilleure manière possible.
Andres Saar Customer Care Engineer