Let's Encrypt pour l'entreprise : quand le TLS gratuit cesse d'être gratuit

Ce que Let's Encrypt fait brillamment

Depuis son premier certificat de production émis le 14 septembre 2015, Let's Encrypt a fondamentalement réécrit l'économie du TLS public. En juillet 2024, l'Internet Security Research Group (ISRG) a rapporté que Let's Encrypt servait plus de 500 millions de certificats actifs pour environ 360 millions de domaines, avec une émission cumulée franchissant les quatre milliards sur sa durée d'existence. La courbe avant-après du graphique Firefox HTTPS Telemetry, qui se situait autour de 39 % des chargements de page début 2015 et a franchi 80 % en 2020, est largement une courbe Let's Encrypt.

Toute discussion honnête sur SSL et TLS à l'échelle commence par reconnaître cette contribution.

Les choix d'ingénierie derrière cette croissance tiennent toujours en 2026. Let's Encrypt a été le premier déploiement en production du protocole ACME, plus tard standardisé en RFC 8555 en mars 2019. ACME a fait passer l'émission de certificats d'un rituel par e-mail et CSV à une API HTTP en trois appels : newAccount, newOrder, finalize.

Des clients comme Certbot, acme.sh, lego et win-acme automatisent la validation de domaine via des challenges HTTP-01, DNS-01 ou TLS-ALPN-01, demandent le certificat et rechargent le serveur web. Tout le cycle, y compris la soumission OCSP et Certificate Transparency log, se termine en moins de quinze secondes pour un SAN unique.

L'autre choix structurel a été une durée de vie de certificat de 90 jours, décidée pour forcer la gestion automatisée des certificats dès le premier jour et pour limiter le rayon d'impact de toute compromission de clé unique.

Cette décision a extrêmement bien vieilli : le CA/Browser Forum pousse maintenant la durée de vie maximale du TLS public vers 47 jours d'ici mars 2029, et le muscle opérationnel que Let's Encrypt a forcé l'industrie à construire est exactement ce qui rend la durée de vie plus courte tolérable. Gratuit, automatisé, à courte durée de vie, journalisé par transparency : voilà à quoi ressemble un bon TLS public, et Let's Encrypt place la barre.

Les sept coûts invisibles à l'échelle

Let's Encrypt est brillant au travail pour lequel il a été conçu : émettre des certificats Domain Validated pour des services face publique, rapidement, gratuitement et à l'échelle planétaire. La discussion sur le coût commence seulement lorsqu'une entreprise essaie de lui faire porter le reste de son parc de certificats.

Le premier mur est les limites de débit. Les limites de production actuelles, publiées sur letsencrypt.org/docs/rate-limits, autorisent 300 New Orders par compte par trois heures, 50 certificats par Registered Domain par semaine, 5 certificats dupliqués par semaine et 5 validations échouées par hostname par heure.

Pour un seul site marketing ces chiffres sont invisibles. Pour un SaaS qui émet un certificat par tenant, une plateforme e-commerce avec des sous-domaines white-label, ou un cluster Kubernetes avec cert-manager faisant proliférer les ingress, le plafond de 50-par-semaine sur un domaine enregistré est une contrainte architecturale dure qui doit être conçue à dessein.

Le deuxième coût est l'absence de produits Organization Validated (OV) et Extended Validation (EV). Let's Encrypt n'émet que du DV. Pour la plupart du trafic web public c'est très bien, mais les achats, les paiements, les portails bancaires régulés et certaines intégrations B2B exigent encore des certificats OV ou EV avec une identité légale vérifiée dans le Subject. Cette exigence ne disparaît pas parce que la communauté technique considère EV obsolète ; elle apparaît comme une case à cocher dans un appel d'offres et la réponse doit être oui.

Les cinq coûts restants sont opérationnels plutôt que techniques. Let's Encrypt n'offre aucun SLA et aucun contrat de support : lorsque l'émission échoue à 03:00 vous lisez les logs de staging et le forum communautaire, vous n'ouvrez pas un ticket P1.

La piste d'audit est mince par conception — le détenteur du compte ACME est quiconque détient la clé privée, sans lien à une identité d'entreprise, sans approbation à quatre yeux, sans justification d'émission documentée.

La garde des clés est la responsabilité de chaque serveur individuel : une clé de compte ACME ou une clé privée serveur fuitée a un rayon d'impact borné uniquement par le nombre de hostnames que ce compte a jamais demandés.

Le risque de dépendance est réel et a été démontré le 4 mars 2020, lorsqu'un bug de re-vérification CAA a forcé la révocation d'environ 3 millions de certificats avec environ cinq jours de préavis ; le même risque a refait surface avec l'annonce du 23 janvier 2025 que le support OCSP serait déprécié, cassant les workflows qui en dépendaient.

Aucune de celles-ci ne sont des défauts de Let's Encrypt ; ce sont la forme naturelle d'un service de CA public gratuit, automatisé et financé par la communauté.

• 300 nouvelles commandes / 3 h — Par compte ACME. Frappe les SaaS multi-tenants, les runners CI et les opérateurs Kubernetes émettant à la création de namespace. Mitigation : sharder à travers les comptes et pré-émettre, mais vous exploitez maintenant une flotte de comptes.
• 50 certificats / domaine / semaine — Par Registered Domain tel que défini par la Public Suffix List. La plateforme qui met chaque client sur `{tenant}.app.example.com` frappe le mur au client 51 de toute fenêtre de sept jours.
• 5 doublons / semaine — Le certificat avec l'exacte même liste de SAN ne peut pas être émis plus de 5 fois en 7 jours. Les déploiements blue/green agressifs et la double émission accidentelle trébuchent constamment dessus.
• Pas d'OV, pas d'EV — DV uniquement. Tout ce qui exige une organisation vérifiée dans le Subject — portails de paiement, B2B régulé, certains processus d'achat — nécessite un émetteur différent.
• Pas de SLA, pas de support — Page de statut et forum communautaire. Les incidents de production sont déboggés en lisant le code source et les logs Boulder, ce qui est acceptable pour un projet hobbyiste et une conversation difficile avec un comité d'audit.
• Piste d'audit mince — Détenteur de la clé de compte = identité. Pas d'approbation à quatre yeux, pas de référence de ticket, pas d'attestation de politique par émission. Suffisant pour DV, insuffisant pour les dossiers de preuves SOX, SOC 2 ou ISO 27001.
• Dépendance à un seul service gratuit — Révocation de masse de mars 2020, dépréciation OCSP de janvier 2025, resserrement récurrent des limites de débit. Chacun est raisonnable isolément ; ensemble ils plaident pour un chemin de repli que vous répétez réellement.

CA internes : une catégorie que Let's Encrypt ne couvre pas

Le point le plus important dans cette discussion est le plus simple : Let's Encrypt n'émet de certificats que pour des noms de domaine publiquement résolubles et enregistrés ICANN, validés contre un serveur joignable depuis l'internet public. Cela exclut, par conception, chaque cas d'usage de certificat qui vit derrière le périmètre. Les services internes sur des namespaces .internal, .corp, ou RFC 6762 .local ne peuvent pas être émis par aucune CA publique, y compris Let's Encrypt, parce que les Baseline Requirements sous-jacentes du CA/Browser Forum interdisent l'émission vers des TLD non-IANA.

Même lorsque les services internes utilisent des noms enregistrés, exposer chaque load balancer interne à l'internet public pour un challenge HTTP-01 n'est pas un modèle viable.

La catégorie suivante est le TLS mutuel pour l'authentification service-à-service. Un certificat TLS/SSL dans un mesh mTLS a une identité client dans le Subject, un SPIFFE ID ou un nom de service-account Kubernetes dans le SAN, une durée de vie mesurée en heures, et un cycle de renouvellement piloté par le workload, pas par DNS.

SPIRE, Istio Citadel, le service d'identité de Linkerd et HashiCorp Vault PKI sont les émetteurs dans cet espace. Let's Encrypt ne l'est pas, et n'a jamais essayé de l'être.

La même logique s'applique à l'identité d'équipements et IoT, où les certificats sont provisionnés au moment de la fabrication sur des éléments sécurisés, intégrés dans le firmware, et tournés via SCEP, EST ou des protocoles bootstrap propriétaires contre une CA privée que le fabricant contrôle.

Elle s'applique au code signing, où le certificat de signature doit chaîner vers une CA explicitement approuvée par Windows, macOS, Java, Apple App Store ou Google Play, avec une garde de clé de niveau EV dans un équipement FIPS 140-2 Level 3.

Elle s'applique à S/MIME, où le certificat porte une identité e-mail vérifiée et chaîne vers une CA dans le trust store S/MIME de Mozilla.

Aucune de celles-ci ne sont des manques de Let's Encrypt : ce sont des catégories d'infrastructure à clé publique qui exigent un type différent de CA, avec des politiques différentes, une validation différente et une chaîne de confiance différente. Comprendre ce qu'est réellement une autorité de certification rend clair pourquoi une CA ne peut pas faire tout cela bien.

Écarts d'audit, de gouvernance et de conformité

L'image de conformité est l'endroit où le calcul gratuit-versus-payant devient inconfortable. SOC 2 Common Criteria CC6.1 et CC6.6 exigent des preuves de contrôles d'accès logique sur les clés cryptographiques et les certificats. ISO/IEC 27001:2022 Annexe A.5.17 et A.8.24 exigent une politique cryptographique documentée, des procédures de gestion de clé et des enregistrements de cycle de vie.

La directive UE NIS2, transposée en droit national à travers le bloc d'ici le 17 octobre 2024, exige des entités essentielles et importantes qu'elles démontrent des « politiques et procédures concernant l'utilisation de la cryptographie » sous l'Article 21(2)(h), avec des amendes pouvant atteindre 10 millions d'euros ou 2 % du chiffre d'affaires global.

DORA, applicable aux entités financières depuis le 17 janvier 2025, exige des preuves de gestion des risques ICT sous l'Article 9 couvrant les protections d'authentification et cryptographiques.

Le Cyber Resilience Act, entrant dans ses obligations principales en décembre 2027, exige des fabricants de produits avec éléments numériques qu'ils maintiennent un inventaire d'actifs cryptographiques.

Chacun de ces cadres pose les mêmes quatre questions opérationnelles : qui a approuvé ce certificat, qui détient la clé, comment l'émission a-t-elle été autorisée, et quelle est la procédure de révocation documentée lorsque la clé est compromise. La réponse de Let's Encrypt aux quatre est la même : quiconque contrôle le compte ACME.

C'est une réponse techniquement correcte et une réponse de conformité inadéquate. Il n'y a pas d'enregistrement d'approbation par émission, pas de référence de ticket, pas de ségrégation des tâches entre demandeur et approbateur, pas d'attestation de politique stockée avec le certificat, pas de lien entre le compte et un propriétaire humain nommé dans le répertoire d'entreprise.

Un cadre de politique et de gouvernance des certificats existe pour produire exactement les preuves que les régulateurs demandent, et il ne peut pas être ajouté après coup à un compte ACME qui émet anonymement au nom de tout processus qui détient le fichier de clé.

L'histoire de la révocation aggrave le problème. Let's Encrypt a déprécié le support du répondeur OCSP à partir du 6 mai 2025, avec un retrait complet prévu pour août 2025, le remplaçant par le statut basé sur CRL uniquement.

C'est une décision d'ingénierie défendable pour une CA émettant des certificats de 90 jours où la révocation est rarement la bonne remédiation. C'est aussi une décision sur laquelle l'abonné n'a pas son mot à dire, et elle change quelle preuve l'équipe peut produire lorsqu'un auditeur demande comment une clé compromise a été retirée dans la fenêtre requise. Une expiration naturelle de 90 jours n'est pas, en soi, une procédure de révocation.

• SOC 2 CC6.1 / CC6.6 — Preuves de contrôle d'accès logique sur les clés. Requis : qui peut demander, qui approuve, où la clé vit. Réponse Let's Encrypt : détenteur de la clé de compte, pas de log par émission lié à une identité nommée.
• ISO 27001:2022 A.5.17 / A.8.24 — Politique cryptographique documentée et enregistrements de cycle de vie de clé. Requis : politique, procédures, garde, preuves de rotation. Réponse Let's Encrypt : lisez le Certificate Practice Statement et le code Boulder ; les enregistrements abonné n'existent pas.
• NIS2 Article 21(2)(h) — Politiques et procédures cryptographiques pour entités essentielles. Requis : politique et application à l'échelle de l'organisation. Réponse Let's Encrypt : hors périmètre ; la CA ne peut pas appliquer de politiques qu'elle ne voit jamais.
• DORA Article 9 — Gestion des risques ICT incluant les protections cryptographiques, avec preuves de Register of Information. Requis : contrôles traçables. Réponse Let's Encrypt : pas de relation contractuelle, pas de DPA, pas de canal de support pour les déclarations de risque tiers ICT.
• CRA Annexe I § 1(3)(d) — Confidentialité via une cryptographie à l'état de l'art dans les produits avec éléments numériques. Requis : inventaire d'actifs cryptographiques par produit. Réponse Let's Encrypt : la CA émet ; l'inventaire produit est la responsabilité du fabricant, et Let's Encrypt n'est pas un produit.

Le modèle mixte : Let's Encrypt en périphérie + CA privée en interne

L'architecture 2026 réaliste n'est pas un choix binaire. C'est une frontière clairement tracée entre le trafic qui se termine sur l'internet public et le trafic qui ne le fait pas. À la périphérie — le CDN, le load balancer public, le site marketing, le portail de documentation, la passerelle API publique — Let's Encrypt reste un excellent choix. Les hostnames sont enregistrés ICANN, le challenge de validation est joignable, DV est suffisant, l'automatisation via cert-manager ou Certbot est mature, la rotation de 90 jours est opérationnellement bon marché.

Toute la classe de certificats qui exigeait auparavant un cycle d'achat, un appel de vérification OV et un renouvellement annuel à 300 $ ne coûte maintenant rien et se renouvelle elle-même. C'est la bonne réponse pour cette couche.

Derrière ce périmètre, une hiérarchie de CA privée émet tout le reste. La PKI privée exploite typiquement une racine hors-ligne dans un HSM, un ou plusieurs intermédiaires en ligne par environnement, et des CA émettrices liées par politique par cas d'usage : mTLS de workload, identité d'équipement, code signing, S/MIME, VPN, Wi-Fi 802.1X.

Le même protocole ACME qui pilote Let's Encrypt pilote la CA interne : ACME privé (acme-tiny, smallstep step-ca, Vault PKI ACME, Evertrust Stream ACME) donne aux services internes le même modèle d'automatisation sans aucune des contraintes de la CA publique.

Les workloads se renouvellent via ACME sur des noms DNS privés avec validation interne, les durées de vie sont ajustées au cas d'usage (24 heures pour les identités de service mesh, 30 jours pour ingress, 1 an pour code signing), et chaque émission est liée à une politique documentée et un propriétaire nommé.

La connexion entre les deux moitiés est un inventaire unifié. La découverte balaie le périmètre et les logs CT pour ce que Let's Encrypt a émis, la base de la CA interne pour ce qui a été émis en privé, et réconcilie les deux en une seule vue.

Cette vue unique est ce qu'un auditeur veut voir, ce sur quoi l'ingénieur d'astreinte est alerté pendant une panne, et ce que l'équipe architecture utilise lors de la planification de la migration PQC. Sans elle, l'organisation a deux parcs de certificats parallèles qui ne partagent rien sauf les personnes qu'ils réveillent à 04:00.

1. Couche périphérie — Load balancers face publique, CDN, sites marketing, API publiques. Let's Encrypt ou autre CA ACME publique. cert-manager avec `Issuer: letsencrypt-prod`, HTTP-01 ou DNS-01, rotation de 90 jours, OCSP/CRL via CDN. Renouvellement piloté par le contrôleur d'ingress, pas par les humains.
2. Couche ingress interne — Passerelles API internes, endpoints mTLS partenaires, consoles admin sur DNS privé. CA privée avec endpoint ACME interne, durées de vie 30 à 90 jours, validation via DNS-01 ou HTTP-01 interne.
3. Couche identité de workload — Service mesh (Istio, Linkerd, SPIRE), pods Kubernetes, mTLS de microservice. CA privée émettant des SPIFFE-IDs, durées de vie 1 à 24 heures, rotation automatique, matériel de clé en TPM de workload ou en mémoire uniquement.
4. Couche équipement et IoT — Routeurs, switches, contrôleurs OT, flottes IoT. CA privée via SCEP, EST ou bootstrap propriétaire. Durées de vie 1 à 5 ans, matériel de clé en TPM, élément sécurisé ou ligne de fabrication adossée HSM.
5. Couche humaine et signature — Code signing, signature de documents, S/MIME, logon par carte à puce. CA privée chaînée à une racine publique approuvée là où requis (code signing) ou interne uniquement là où non (S/MIME au sein de l'organisation). Clés de signature adossées HSM, approbation manuelle ou basée sur workflow.
6. Plan d'inventaire et de politique unifié — Un système unique de découverte et inventaire de certificats couvrant les cinq couches. Source unique de vérité pour le renouvellement, la révocation, la propriété, la conformité aux politiques et la planification de la migration PQC.

Quand remplacer entièrement

Pour la plupart des organisations, le modèle mixte est le bon état final. Il existe cependant des situations où garder Let's Encrypt dans l'image crée plus de friction opérationnelle qu'il n'en supprime. Cinq signaux marquent systématiquement ce point.

Le premier est le nombre de certificats. En dessous de quelques centaines de certificats, un modèle de CA publique basé sur ACME fonctionne bien. Au-dessus de cinq mille certificats actifs à travers des environnements mixtes, le coût opérationnel de suivre lesquels renouvellent où, lesquels sont sujets à quelle limite de débit, et lesquels vivent dans quel compte commence à dominer. Au-delà de 50 000 certificats — commun dans les déploiements service-mesh, les flottes IoT et les grandes plateformes SaaS — les maths ont depuis longtemps basculé.

Le deuxième signal est un audit de conformité à l'horizon. Le premier SOC 2 Type II, surveillance ISO 27001, évaluation de conformité NIS2 ou déclaration DORA Register of Information qui examine explicitement l'émission de certificats et la garde de clé posera des questions auxquelles une configuration ACME-uniquement ne peut pas répondre avec des preuves. Réorganiser le programme de certificats trois mois avant l'audit est bien plus coûteux que de le construire correctement dès le début.

Le troisième signal est les applications à confiance mixte. Lorsque la même application termine du trafic externe de clients publics, du trafic interne de réseaux d'entreprise, du mTLS de partenaires et du trafic d'équipement de matériel sur le terrain, exécuter une stratégie de CA par classe de trafic devient insoutenable.

Le quatrième est les exigences de garde de clé : lorsque la politique, la réglementation ou le modèle de menace exige des clés privées dans un HSM à FIPS 140-2 Level 3 ou FIPS 140-3 Level 3, le workflow doit être conçu autour de l'HSM, pas autour d'un client ACME écrivant un fichier PEM sur disque.

Le cinquième est un besoin business dur OV ou EV : un régulateur, un partenaire ou un schéma de paiement demande un certificat avec une entité légale vérifiée dans le Subject, et la réponse ne peut pas être « notre CA n'émet pas ceux-là ».

• Signal 1 : 5 000+ certificats en BAU — Le surcoût opérationnel des limites de débit, du sharding de compte et de la coordination de renouvellement dépasse les économies. Au-delà de 50 000 ce n'est plus un débat.
• Signal 2 : audit externe dans les 12 mois — SOC 2, ISO 27001, NIS2, DORA ou PCI DSS 4.0. Chacun posera des questions sur l'approbation d'émission, la garde de clé et les preuves de révocation. Construisez la réponse une fois, pas trois semaines avant l'arrivée de l'auditeur.
• Signal 3 : applications à confiance mixte — Le même workload sert du trafic externe, interne, partenaire et équipement. Exécuter une stratégie de CA par classe de trafic est fragile ; un plan de gouvernance unifié à travers une ou plusieurs CA ne l'est pas.
• Signal 4 : garde de clé adossée HSM requise — La politique, la réglementation ou le modèle de menace met les clés dans du matériel FIPS 140-2 Level 3 ou FIPS 140-3. Le flux d'émission doit s'enrôler contre l'HSM, pas écrire un fichier PEM depuis un client ACME.
• Signal 5 : OV ou EV est une exigence dure — Partenaire de paiement, régulateur ou acheteur demande une organisation vérifiée dans le Subject. Les CA publiques DV-uniquement ne peuvent pas répondre ; le programme nécessite une CA qui émet OV/EV à côté de tout le reste.

Où s'inscrit Evertrust

Cet article n'est délibérément pas une attaque contre Let's Encrypt. La catégorie CA publique gratuite, automatisée et journalisée par transparency que Let's Encrypt a définie est l'une des contributions d'infrastructure les plus précieuses de la dernière décennie, et la bonne réponse à la périphérie de la plupart des parcs d'entreprise reste une forme d'émission ACME publique. La question est ce qui tourne derrière cette périphérie, qui le possède, et comment c'est gouverné.

Evertrust adresse la couche que la catégorie CA publique n'a jamais été conçue pour couvrir : un plan de PKI privée qui émet du TLS interne, du mTLS de workload, des certificats d'équipement, code signing et S/MIME, gouverné par politique, adossé par HSM, exposé via ACME, SCEP, EST, REST et CMPv2, et lié à un inventaire unifié qui suit aussi ce que vos CA publiques ont émis.

Le moteur de politique produit les preuves que les auditeurs SOC 2, ISO 27001, NIS2, DORA et CRA demandent, par émission, par propriétaire, par justification.

La couche de découverte réconcilie l'émission Let's Encrypt, l'émission de CA interne, l'émission ADCS et l'émission cloud-native en une seule vue de chaque certificat dont l'organisation dépend, avec renouvellement, révocation et propriété attachés.

Pour voir comment le côté privé du modèle mixte est exploité en 2026, explorez Evertrust PKI.