Let's Encrypt ou certificat SSL payant : lequel vous faut-il vraiment ?

Pour la plupart des sites web, Let's Encrypt suffit amplement : il fournit gratuitement un chiffrement reconnu par les navigateurs, avec un renouvellement automatisé. Les certificats SSL commerciaux justifient leur prix lorsque vous avez besoin d'une vérification d'identité au niveau de l'organisation, de garanties contractuelles ou d'un support payant, et non parce qu'ils seraient plus robustes sur le plan cryptographique.

La question revient sans cesse lorsque des équipes harmonisent leur stratégie de certificats sur des dizaines de domaines et de fournisseurs. Le niveau de confiance technique est identique dans les deux cas : la différence tient à ce qui se trouve derrière le certificat.

Ce que Let's Encrypt vous apporte réellement

Let's Encrypt est une autorité de certification (CA) gratuite et automatisée, gérée par l'organisation à but non lucratif Internet Security Research Group (ISRG). Elle émet uniquement des certificats à validation de domaine (DV), qui confirment que vous contrôlez un domaine, mais ne disent rien de votre identité en tant qu'entité juridique.

Les points techniques essentiels :

• L'émission passe par ACME (Automatic Certificate Management Environment, RFC 8555), ce qui permet d'automatiser entièrement le renouvellement par script.
• La durée de validité par défaut est de 90 jours, et la recommandation officielle est de renouveler automatiquement au bout de 60 jours.
• Let's Encrypt propose aussi un profil de courte durée de 6 jours optionnel, destiné à limiter l'impact d'une clé compromise.
• Les certificats wildcard (*.example.com) sont pris en charge, mais uniquement via le challenge DNS-01 : vous devez prouver que vous contrôlez le DNS, et pas seulement servir un fichier en HTTP.
• Des limites de débit s'appliquent par domaine enregistré (historiquement environ 50 certificats par domaine et par semaine, avec des limites distinctes pour les doublons et les validations échouées). Consultez la documentation actuelle de Let's Encrypt sur ces limites avant un déploiement à grande échelle, car ces chiffres sont régulièrement révisés.
• La chaîne de confiance remonte à ISRG Root X1 (RSA) et ISRG Root X2 (ECDSA), deux racines autosignées directement approuvées dans les magasins de certificats racines modernes.
• Il n'y a ni garantie, ni assurance responsabilité, et le support se limite au forum communautaire.

Ce qu'apportent les autorités de certification commerciales

Les CA commerciales (DigiCert, Sectigo, GlobalSign, Entrust et d'autres) émettent les mêmes certificats DV que Let's Encrypt, ainsi que deux niveaux que Let's Encrypt ne propose pas :

• Validation de l'organisation (OV) : la CA vérifie l'existence légale de votre entreprise avant l'émission.
• Validation étendue (EV) : un processus de vérification plus approfondi, incluant des contrôles juridiques, physiques et opérationnels.

Le hic : l'EV ne change plus ce que le visiteur voit dans la barre d'adresse. Chrome a supprimé l'affichage spécifique de la barre verte EV vers la version 77 (2019), et les autres grands navigateurs ont suivi une voie similaire. La valeur pratique de l'OV/EV aujourd'hui réside donc dans la piste d'audit et le dossier de vérification, et non dans un signal de confiance visible pour l'utilisateur final.

Ce que vous achetez réellement auprès d'une CA commerciale :

• Une garantie ou police de responsabilité (généralement de six ou sept chiffres en USD) en cas d'émission erronée d'un certificat par la CA.
• Une émission couverte par un SLA et un support payant par téléphone ou e-mail.
• Une identité d'organisation vérifiée, utile pour les référentiels de conformité, les grilles d'achat ou les secteurs où un auditeur souhaite voir un certificat vérifié au niveau de l'entreprise.

DV, OV ou EV : comparatif des certificats SSL par autorité

Un point mérite d'être souligné : la validité maximale de 398 jours est une exigence de base (Baseline Requirement) du CA/Browser Forum qui s'applique à tout le secteur, et non une limitation propre à Let's Encrypt à laquelle on pourrait échapper en payant plus cher. Le Forum discute en outre de nouvelles réductions de durée de vie dans ses récents votes : attendez-vous donc à des durées maximales plus courtes chez toutes les CA publiquement reconnues. En pratique, l'automatisation devient obligatoire, quelle que soit la CA choisie.

Quand un certificat ACME gratuit suffit

Let's Encrypt est le bon choix par défaut pour :

• Les sites web standards, les API et les services internes pour lesquels les visiteurs n'ont pas besoin de savoir qui détient légalement le domaine.
• Toute configuration où vous pouvez automatiser le renouvellement : certbot piloté par cron, client ACME intégré à votre répartiteur de charge ou plateforme qui renouvelle pour vous.
• Les agences qui gèrent des certificats sur de nombreux domaines clients, où l'automatisation compte davantage que le coût par certificat.
• L'infrastructure éphémère : environnements de préproduction, serveurs temporaires, tout ce qui est créé et détruit régulièrement.

Si vous ne savez pas exactement ce qui est déployé sur un domaine, passez-le dans notre vérificateur SSL pour afficher l'émetteur, le niveau de validation, la date d'expiration et la chaîne : un moyen rapide de faire un audit avant d'harmoniser.

Quand payer pour un certificat SSL commercial

Tournez-vous vers une CA commerciale lorsque :

• Les achats ou la conformité exigent une vérification OV/EV documentée (courant dans la finance, la santé ou les contrats B2B grands comptes).
• Vous avez besoin d'une couverture de responsabilité contractuelle plutôt que d'un projet communautaire fonctionnant au mieux.
• Vous voulez une ligne de support payante en cas de problème d'émission pendant une période de lancement.
• Votre organisation émet des certificats suffisamment rarement pour que l'automatisation ne vaille pas l'investissement, et une durée de validité plus longue (jusqu'à 398 jours) réduit la charge de renouvellement.

Pour la plupart des équipes d'infrastructure qui gèrent des dizaines ou des centaines de domaines, le calcul favorise l'automatisation plutôt qu'une longue validité : un certificat gratuit de 90 jours qui se renouvelle seul sans intervention est plus simple à exploiter qu'un certificat de 398 jours que quelqu'un doit penser à remplacer manuellement.

Exemple : automatiser le renouvellement Let's Encrypt

Une vérification de renouvellement certbot typique, exécutée via cron ou un timer systemd :

certbot renew --quiet --deploy-hook "systemctl reload nginx"

Cette commande vérifie tous les certificats de la machine, renouvelle ceux qui expirent dans moins de 30 jours et ne recharge nginx que si un renouvellement a effectivement eu lieu. Pour une émission wildcard via DNS-01, vous exécuteriez plutôt quelque chose comme :

certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d '*.example.com' -d 'example.com'

Dans les deux cas, l'objectif est le même : le renouvellement doit être une tâche planifiée, pas un rappel dans un agenda.

Gérer ses certificats SSL chez plusieurs fournisseurs

Dès que vous utilisez Let's Encrypt sur certains domaines et des certificats commerciaux sur d'autres (ce qui est normal pour les agences et les équipes multicloud), le suivi manuel des expirations devient vite source d'erreurs. La gestion des certificats d'InfraNest vous offre un tableau de bord unique pour l'émission, le renouvellement et les alertes d'expiration, quels que soient le registrar et la CA, afin qu'un renouvellement oublié ne se transforme pas en panne de production.

Si vous auditez ce qui est en ligne actuellement, commencez par passer vos domaines clés dans le vérificateur SSL avant de décider où l'automatisation peut remplacer un certificat payant, et où elle ne le peut pas.