Un certificat SSL gratuit protège exactement aussi bien qu'un certificat SSL facturé 300 € par an. L'affirmation heurte l'intuition — et l'argumentaire qui accompagne la plupart des offres payantes — mais elle se vérifie : le chiffrement négocié entre le navigateur et le serveur ne dépend ni du montant payé ni de l'autorité émettrice, mais du protocole TLS, des suites cryptographiques activées et de la clé privée générée sur le serveur. Ce qui sépare gratuit et payant tient en deux points, dont aucun n'est cryptographique : la vérification d'identité avant l'émission, et les engagements contractuels attachés au produit.
À retenir
- Le chiffrement est identique entre un certificat DV gratuit et un certificat EV payant. Ce qui se paie est la vérification d'identité, pas la sécurité du transport.
- Let's Encrypt émet exclusivement du DV, automatisé par ACME, avec une durée de vie de 90 jours par défaut.
- Depuis le 15 mars 2026, le CA/Browser Forum plafonne tout certificat TLS public à 200 jours — 100 jours au 15 mars 2027, 47 jours au 15 mars 2029. L'argument « un certificat pour un an, posé et oublié » a cessé d'exister.
- Trois situations justifient encore un achat : garantie contractuelle exigée par un tiers, validation d'organisation imposée par un donneur d'ordre, usage hors TLS serveur. Le wildcard n'en fait pas partie :
*.domaine.frest gratuit via le challenge DNS-01.- Chez Tomco, le certificat SSL est provisionné automatiquement en quelques minutes après le pointage DNS, puis renouvelé sans intervention : le cycle de 90 jours reste invisible côté client.
Sommaire
- Gratuit ou payant : ce qui change réellement
- Comment fonctionne un certificat SSL/TLS
- DV, OV, EV — la vraie différence
- Let's Encrypt — mécanique et gratuité
- Quand un certificat gratuit suffit
- Quand le gratuit devient limitant
- Le certificat wildcard : couvrir tous les sous-domaines
- Ce qui se passe si le certificat expire
- Questions fréquentes
Gratuit ou payant : ce qui change réellement
Le tableau ci-dessous isole chaque critère de comparaison et indique où se situe une différence réelle.
| Critère | Certificat gratuit (Let's Encrypt) | Certificat payant |
|---|---|---|
| Chiffrement négocié | Identique | Identique |
| Niveau de validation | DV uniquement | DV, OV ou EV |
| Durée de vie | 90 jours, ou 6 jours en option | 200 jours maximum depuis le 15 mars 2026 |
| Délai d'émission | Quelques secondes | Secondes en DV, 1 à 5 jours ouvrés en OV/EV |
| Wildcard | Oui, via DNS-01 uniquement | Oui |
| Raison sociale dans le certificat | Non | Oui, en OV et EV |
| Garantie contractuelle | Aucune | Dizaines de milliers à plusieurs millions d'euros |
| Support | Documentation et forum communautaire | Support commercial du revendeur |
| Coût annuel | 0 € | Quelques euros à plusieurs centaines d'euros |
Trois lignes seulement portent une différence exploitable : le niveau de validation, la raison sociale inscrite dans le certificat, et la garantie contractuelle. Les six autres décrivent des écarts d'ergonomie ou de prix. La première — chiffrement identique — est celle que l'argumentaire commercial contourne le plus systématiquement.
Comment fonctionne un certificat SSL/TLS
Un certificat SSL ne chiffre rien. C'est un fichier signé qui associe une clé publique à un nom de domaine, et rien d'autre. Le chiffrement provient de la négociation TLS : au handshake, le navigateur et le serveur s'accordent sur une suite cryptographique, dérivent une clé de session symétrique par échange Diffie-Hellman éphémère (ECDHE), puis chiffrent tout le reste de l'échange avec cette clé. Le certificat sert uniquement à prouver que la clé publique présentée appartient au domaine demandé — la définition de TLS sur MDN détaille cette séparation entre authentification et chiffrement.
Cette preuve repose sur une chaîne à trois maillons. Au sommet, une autorité racine préinstallée dans le magasin de confiance du système d'exploitation ou du navigateur, dont la clé privée reste hors ligne et ne signe presque jamais directement. En dessous, des certificats intermédiaires qui assurent l'émission au quotidien : si l'un est compromis, il est révoqué sans invalider la racine. À la base, le certificat feuille, celui du domaine. Le navigateur remonte la chaîne jusqu'à une racine qu'il connaît ; s'il n'y parvient pas, il refuse la connexion.
Cette chaîne est identique pour tous les certificats publiquement reconnus : même mécanisme, même magasin de confiance, même handshake, qu'ils aient été payés ou non. Elle ne protège d'ailleurs que le transport — un site entièrement compromis se sert parfaitement en HTTPS. Le durcissement applicatif relève d'un tout autre chantier, détaillé dans le guide sécuriser WordPress.
DV, OV, EV — la vraie différence
Les trois niveaux de validation d'un certificat SSL sont définis par les Baseline Requirements du CA/Browser Forum, que toute autorité publiquement reconnue doit respecter. Ils décrivent une procédure de vérification préalable à l'émission, jamais une propriété cryptographique du certificat produit.
| Niveau | Ce que l'autorité vérifie | Automatisable | Délai typique |
|---|---|---|---|
| DV — Domain Validation | Le contrôle du domaine : réponse à un challenge HTTP, DNS ou TLS | Oui, intégralement | Quelques secondes |
| OV — Organization Validation | Le domaine, plus l'existence légale de l'organisation dans un registre officiel | Non | 1 à 3 jours ouvrés |
| EV — Extended Validation | Le domaine, plus une vérification renforcée : existence juridique, opérationnelle et physique de l'entité, mandat du demandeur | Non | 3 à 5 jours ouvrés |
La conséquence est directe : passer de DV à EV n'ajoute pas un bit d'entropie à la session TLS. Les trois niveaux aboutissent au même algorithme de signature, à la même longueur de clé, à la même suite cryptographique. Ce que l'EV ajoute est la mention de l'entité juridique dans les champs du certificat, vérifiable par un tiers qui prend la peine de l'inspecter.
Le second pilier de l'argumentaire EV, la barre d'adresse verte affichant le nom de l'entreprise, a disparu des navigateurs il y a sept ans : Chrome l'a retirée en septembre 2019 (version 77), Firefox en octobre 2019 (version 70), après une expérimentation où sa suppression pour un sous-ensemble aléatoire d'utilisateurs n'a fait bouger aucune métrique de comportement. Un site EV et un site DV affichent désormais le même cadenas ; l'identité de l'organisation n'apparaît qu'en ouvrant le panneau d'informations de connexion. Un argument de « confiance visuelle » adossé à un élément retiré en 2019 ne tient plus.
Let's Encrypt — mécanique et gratuité
Let's Encrypt est une autorité de certification opérée par l'Internet Security Research Group (ISRG), organisation à but non lucratif financée par des sponsors et des dons, dont le premier certificat date de septembre 2015. Elle émet exclusivement du DV et l'assume dans sa documentation : ni OV ni EV, ces niveaux n'étant pas automatisables.
L'automatisation intégrale est le cœur du modèle économique. Elle repose sur ACME (Automatic Certificate Management Environment), protocole standardisé par l'IETF sous la RFC 8555 : un client installé sur le serveur — certbot, acme.sh, lego, ou le module intégré au panneau d'hébergement — demande le certificat, prouve le contrôle du domaine par l'un des trois challenges, et récupère le certificat signé sans intervention humaine.
| Challenge | Preuve demandée | Wildcard |
|---|---|---|
HTTP-01 |
Servir un fichier à un chemin imposé sous /.well-known/acme-challenge/ |
Non |
DNS-01 |
Publier un enregistrement TXT dans la zone du domaine | Oui |
TLS-ALPN-01 |
Répondre au handshake TLS avec un certificat spécifique sur le port 443 | Non |
Le coût marginal d'un certificat tombant à quelques centimes de calcul, la gratuité devient soutenable. Les garde-fous sont quantitatifs, pas tarifaires : la documentation Let's Encrypt sur les limites d'émission fixe 50 certificats par domaine enregistré et par tranche de 7 jours, plafond hors d'atteinte hors multi-tenant à forte volumétrie. La durée de vie par défaut est de 90 jours ; depuis le 15 janvier 2026, un profil shortlived de 6 jours — 160 heures exactement — est disponible en option, durée si courte qu'elle rend la révocation inutile.
Sur l'hébergement web Tomco, cette mécanique est déléguée à l'infrastructure : le certificat Let's Encrypt est demandé automatiquement pour chaque domaine dès que le DNS pointe vers le serveur — quelques minutes entre le pointage et la mise en service — sans commande, sans demande au support et sans action dans le panel. Le renouvellement est lui aussi automatisé de bout en bout, ce qui supprime le risque d'expiration oubliée. Le SSL est gratuit et illimité sur toutes les offres, multi-domaines compris — le détail de la pile TLS figure sur la page technologies.
Quand un certificat gratuit suffit
Un certificat DV gratuit couvre le besoin dès lors qu'aucun tiers n'exige contractuellement autre chose — soit la très large majorité des sites en production.
| Profil de site | Certificat suffisant | Pourquoi |
|---|---|---|
| Site vitrine, blog, média | DV gratuit | Aucune donnée sensible saisie, aucune exigence contractuelle |
| Application SaaS B2C | DV gratuit | Authentification et chiffrement au repos relèvent de l'application |
| E-commerce standard | DV gratuit | Les données de carte transitent chez le prestataire de paiement |
| Intranet, préproduction, API interne | DV gratuit | Aucun visiteur externe à convaincre |
| Site institutionnel avec marché public | À vérifier au cahier des charges | Certains marchés imposent OV ou EV |
L'argument de vente qui distinguait le payant — « un certificat valable un an, posé une fois et oublié » — a cessé d'exister le 15 mars 2026, date d'entrée en vigueur du scrutin SC-081v3 du CA/Browser Forum, adopté en avril 2025 : la durée maximale d'un certificat TLS public est passée de 398 à 200 jours, avant de tomber à 100 jours le 15 mars 2027 puis à 47 jours le 15 mars 2029. Un certificat payant doit donc être renouvelé deux fois par an, et bientôt huit. L'automatisation devient obligatoire partout — au bénéfice de l'écosystème qui l'a implémentée le premier.
Reste le périmètre : un site servi en HTTPS avec un certificat EV et une extension obsolète reste vulnérable. La démarche de sécurité complète se joue sur le pare-feu applicatif, l'isolation des environnements et la gestion des mises à jour, pas sur la ligne du certificat.
Quand le gratuit devient limitant
Trois situations — à peu près trois seulement — justifient encore un achat.
1. Une garantie contractuelle exigée par un tiers. Les certificats payants sont assortis d'une garantie financière, de quelques dizaines de milliers à plusieurs millions d'euros selon le niveau. Point que les fiches produit détaillent rarement : elle protège la partie qui se fie au certificat — le visiteur trompé par une émission frauduleuse — et non son titulaire. Elle ne couvre ni une compromission du serveur, ni une fuite de données, ni une indisponibilité. Sa valeur est donc contractuelle : elle sert quand un assureur cyber, un donneur d'ordre B2B ou un cahier des charges la pose en condition. La question n'est alors plus technique, c'est une clause à satisfaire.
2. Une validation d'organisation dans le certificat lui-même. Certains contextes exigent que la raison sociale figure dans les champs du certificat, pour être contrôlable par un partenaire, un régulateur ou un auditeur. Un certificat DV ne contient aucun champ d'organisation, par construction : si l'exigence est écrite, OV ou EV est la seule réponse.
3. Un usage qui sort du TLS serveur. Signature de code ou de documents, certificats S/MIME, certificats clients pour l'authentification mutuelle, équipements incapables de dialoguer en ACME : Let's Encrypt ne couvre aucun de ces cas. Limite de périmètre, pas de gratuité.
Trois arguments sont à écarter, faute de support factuel : un certificat SSL payant n'apporte aucun chiffrement supérieur, aucun gain de référencement — Google traite HTTPS en signal binaire — et aucune confiance visuelle supplémentaire depuis le retrait de l'indicateur EV en 2019.
Le certificat wildcard : couvrir tous les sous-domaines
Un certificat wildcard couvre l'ensemble des sous-domaines d'un niveau donné. *.domaine.fr vaut pour www.domaine.fr, api.domaine.fr, client42.domaine.fr — avec deux limites fréquemment découvertes en production : il ne couvre pas domaine.fr lui-même, qui doit être ajouté comme identifiant supplémentaire, ni un second niveau comme api.v2.domaine.fr.
Let's Encrypt émet des wildcards gratuitement depuis mars 2018, avec une contrainte unique : la validation doit passer par le challenge DNS-01. Il faut donc publier un enregistrement TXT _acme-challenge.domaine.fr à chaque renouvellement, ce qui suppose un fournisseur DNS exposant une API et un client ACME capable de la piloter. C'est cette dépendance à la zone DNS, et non un surcoût, qui explique que le wildcard reste peu déployé.
Le réflexe wildcard est d'ailleurs rarement le bon. Un certificat ordinaire accepte jusqu'à 100 identifiants (SAN) : pour un jeu de sous-domaines connu et stable, il couvre le besoin sans dépendance à l'API DNS et limite la casse en cas de fuite de la clé privée — un wildcard compromis expose tous les sous-domaines, présents et futurs. Il ne s'impose que dans deux cas : des sous-domaines créés dynamiquement (SaaS multi-tenant en client.app.fr), ou une volumétrie heurtant la limite de 50 certificats par domaine et par semaine.
Vérifier ce qu'un certificat couvre réellement tient en une commande :
# Lister les identifiants (SAN) réellement présents dans le certificat servi
echo | openssl s_client -connect app.exemple.fr:443 -servername app.exemple.fr 2>/dev/null \
| openssl x509 -noout -text \
| grep -A1 "Subject Alternative Name"Chez Tomco, la question se pose rarement : chaque domaine et chaque sous-domaine déclaré reçoit son propre certificat, demandé automatiquement dès que son DNS pointe vers le serveur et renouvelé sans intervention. C'est la couverture par identifiant décrite ci-dessus, appliquée d'office — elle répond au besoin partout où la liste des sous-domaines est connue, c'est-à-dire dans la quasi-totalité des cas. Le certificat wildcard, lui, ne fait pas partie de ce provisioning automatique.
Ce qui se passe si le certificat expire
Un certificat SSL expiré ne dégrade pas l'expérience : il coupe le site. Le navigateur interpose une page d'erreur plein écran — NET::ERR_CERT_DATE_INVALID sur Chrome, SEC_ERROR_EXPIRED_CERTIFICATE sur Firefox — qui masque tout le contenu. Si l'en-tête HSTS a été servi lors d'une visite précédente, le navigateur applique la politique mémorisée et supprime le lien « continuer quand même » : l'accès devient impossible, administrateur compris.
L'impact sur le référencement est fréquemment mal décrit. Il n'existe aucune pénalité de classement liée à l'expiration : Google ne dispose pas d'un facteur « certificat expiré ». Le dommage est indirect, et plus rapide qu'une pénalité algorithmique — Googlebot cesse de crawler en HTTPS, l'abandon devant l'interstitiel avoisine la totalité du trafic, et les campagnes payantes continuent de facturer des clics qui n'atteignent plus le site.
Quatre contrôles écartent le risque. Le premier lit la date d'expiration réellement servie, qui peut différer de celle d'un panneau d'administration quand plusieurs certificats coexistent sur la machine :
# Sujet, émetteur et dates de validité du certificat effectivement servi
echo | openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>/dev/null \
| openssl x509 -noout -subject -issuer -datesLe deuxième vérifie que le serveur envoie aussi l'intermédiaire : une chaîne incomplète passe sur un navigateur de bureau, qui la reconstitue par cache, et échoue en mobile ou en API. Le troisième teste le renouvellement en simulation, sans consommer de quota d'émission :
# Simuler le renouvellement de tous les certificats gérés par certbot
certbot renew --dry-runLe quatrième surveille l'expiration depuis l'extérieur, avec une alerte au moins 14 jours avant échéance : une sonde hébergée sur la machine surveillée tombe en même temps qu'elle.
Sur l'infrastructure Tomco, ces quatre contrôles relèvent de l'hébergeur : le renouvellement Let's Encrypt est piloté côté serveur, sans client ACME à configurer ni échéance à noter. C'est pourquoi la durée de vie courte d'un certificat SSL gratuit, longtemps présentée comme un inconvénient, ne coûte rien en exploitation côté client.
