Autorités de Certification · Guide mondial 2025–2026
SSL &
Certificate Authorities
Des fondamentaux techniques aux enjeux géopolitiques — qui signe les certificats qui sécurisent l'internet mondial ?
01 · Explication
Comment fonctionnent les certificats SSL/TLS ?
Un certificat SSL/TLS est un document numérique qui remplit deux fonctions : chiffrer les données en transit, et authentifier l'identité du serveur. Il est émis par une Autorité de Certification (CA) — un tiers de confiance inscrit dans le root store des navigateurs.
La clé publique du cert permet au navigateur d'établir une session TLS chiffrée. Protocole actuel : TLS 1.3 (RFC 8446), utilisé par 75 % des sites en 2025.
La CA confirme que le propriétaire contrôle bien le domaine. Sans ça, n'importe qui pourrait se faire passer pour mabanque.fr. La signature est vérifiée contre le root store.
CA racine → CAs intermédiaires → cert final. Le root store (Mozilla, Apple, Google, Microsoft) liste les racines reconnues. CA non listée = avertissement navigateur.
DV — propriété du domaine uniquement, automatisable, gratuit. OV — vérifie aussi l'organisation. EV — audit juridique complet, payant, plusieurs semaines.
Currently 90 jours (LE). Apple a imposé 45 jours max en 2025. D'ici 2028, le CA/Browser Forum imposera 47 jours à toutes les CA. L'automatisation ACME devient indispensable.
Un cert peut être révoqué avant expiration (clé compromise, changement de propriétaire). La CA publie une CRL ou répond via OCSP. Voir ci-dessous pourquoi c'est plus complexe qu'il n'y paraît.
Automatise intégralement le cycle de vie d'un certificat — demande, validation du domaine (HTTP, DNS ou TLS-ALPN), émission et renouvellement — sans intervention humaine. Conçu par Let's Encrypt, adopté par toute l'industrie. certbot (EFF) est le client le plus répandu.
Le paradoxe de départ
L'article commence par une observation simple mais frappante : tous les outils qui existent pour gérer des certificats SSL sont conçus pour qu'ils ne tombent jamais en panne. Certbot, acme.sh, Caddy, Traefik — ils surveillent l'expiration, renouvellent automatiquement, alertent si quelque chose cloche. La totalité de l'écosystème converge vers un seul objectif : maintenir le certificat valide.
Sauf que Let's Encrypt, en tant que CA, est soumise à une obligation réglementaire exactement inverse. Le CA/Browser Forum — l'organisme qui fixe les règles que toutes les CAs publiques doivent respecter pour rester dans les root stores des navigateurs — exige que chaque CA maintienne en permanence des sites de test accessibles avec des certificats dans trois états différents : valide, expiré, et révoqué. Ces sites ne sont pas là pour faire joli. Des projets réels comme upki (le nouveau système de validation de certificats d'Ubuntu, basé sur Rustls et CRLite) s'en servent activement pour tester leur code en conditions réelles. Sans ces URLs, il est impossible de valider correctement qu'un client HTTPS gère bien les cas d'erreur.
LE a quatre certificats racines (Root X1, X2, YE, YR). Il faut donc maintenir 12 URLs de test en permanence — 3 états multipliés par 4 racines — chacune dans le bon état, en continu, 24h/24.
Pourquoi c'est un vrai problème d'ingénierie
Avant cet article, LE gérait ça avec certbot, nginx, et des scripts shell. Matthew McPherrin écrit que "les scripts devenaient trop compliqués". Ce n'est pas une formule de modestie — c'est une description technique précise de ce qui se passe quand on essaie de gérer des états de certificats anormaux avec des outils prévus pour les états normaux. Ils ont donc réécrit le tout en Go.
Voici pourquoi chacun des trois états pose un problème différent :
Cas standard. Le programme utilise la bibliothèque Lego (client ACME en Go) pour émettre et renouveler automatiquement. La validation du domaine se fait via le challenge TLS-ALPN-01 — différent du HTTP-01 que certbot utilise par défaut. TLS-ALPN-01 répond directement sur le port 443 sans nécessiter de serveur HTTP séparé, ce qui convient parfaitement à un serveur Go qui gère lui-même le TLS.
La stratégie : émettre le certificat le plus court possible (6 jours, la durée minimale que LE propose), puis attendre qu'il expire naturellement. Une fois expiré, il peut servir indéfiniment — un cert expiré ne se ré-expire pas davantage. Le vrai problème est côté serveur : normalement, un serveur TLS refuse d'envoyer un cert périmé. Le programme Go contourne ça via un callback GetCertificate personnalisé qui sélectionne le cert à servir par SNI — et qui, pour ce site précis, accepte explicitement de servir un cert expiré.
C'est ici que la logique devient délicate. Le cert révoqué doit satisfaire deux contraintes simultanées : être révoqué et ne pas encore être expiré. Si on attend trop longtemps après la révocation, le cert expire et le site de test devient inutilisable. La séquence exacte est : émettre → révoquer via ACME (le compte émetteur peut révoquer son propre cert) → poller la CRL embarquée dans le cert jusqu'à ce que son numéro de série y apparaisse → attendre encore 24 heures supplémentaires pour que les caches intermédiaires propagent l'information → seulement alors, servir ce cert.
Le mécanisme "cert suivant" — un pattern à retenir
Pour gérer les transitions sans jamais servir le mauvais état, le programme Go maintient en permanence deux versions de chaque certificat en mémoire : le cert actuel (celui qui est servi aux clients) et le cert "suivant" (celui qui est en train de maturer — attendant d'expirer, ou que sa révocation soit propagée). Quand le cert "suivant" est prêt, il remplace atomiquement le cert actuel.
C'est fondamentalement différent du comportement de certbot, qui remplace le cert dès qu'il en obtient un nouveau. Ici, l'obtention et le déploiement sont deux étapes séparées dans le temps, avec une logique de validation entre les deux. C'est un pattern solide pour tout renouvellement critique en production.
La révocation en pratique : une illusion de sécurité
L'article termine sur un point qui mérite d'être lu attentivement. Il invite à visiter l'un des sites révoqués dans son navigateur. Et il prévient d'avance : on n'obtiendra probablement aucune erreur.
Ce n'est pas un bug de ces sites de test. C'est le reflet de l'état réel de la vérification de révocation dans les navigateurs grand public. Historiquement, les mécanismes OCSP et CRL dans les browsers ont été implémentés de façon molle, soit pour des raisons de performance (une requête OCSP par connexion ralentit le chargement), soit pour éviter les faux positifs qui bloqueraient des sites légitimes. Chrome utilise des "CRLSets" — une liste curatée manuellement par Google qui ne couvre que les révocations considérées comme critiques. Safari fait de l'OCSP staple mais uniquement pour les certs EV. Firefox est le seul à déployer CRLite, un système qui télécharge en avance la liste complète des certs révoqués sous forme compressée, sans requête réseau au moment de la connexion — c'est efficace et privé. Ubuntu construit dessus avec upki.
La conséquence directe : si une clé privée SSL fuite — dans un dépôt Git public, dans des logs de déploiement, dans un screenshot — révoquer le certificat ne protège pas les utilisateurs qui n'ont pas Firefox avec CRLite actif, c'est-à-dire la grande majorité. La bonne réponse à une fuite de clé est de révoquer et d'émettre immédiatement un nouveau cert avec une nouvelle clé, et d'activer HSTS pour forcer les navigateurs à n'accepter que du HTTPS valide à l'avenir.
Les 12 URLs de test — publiques et utilisables
curl (sans header Accept: text/html) renvoie une version texte avec le logo LE en ASCII art. Le paramètre ?txt force ce mode, ?html force le HTML.
Le programme Go est disponible sur github.com/letsencrypt/test-certs-site. L'article invite explicitement les autres CAs à l'utiliser ou à s'en inspirer. Si on monte une CA interne avec step-ca ou XiPKI, cette base de code est une référence directement réutilisable pour construire ses propres environnements de test — sans repartir de zéro avec des scripts shell qui deviennent vite ingérables.
02 · Alternatives
Contexte par région, bloc géopolitique & usage
Let's Encrypt domine massivement (60%+ des certs). L'UE dispose de CAs propres qualifiées eIDAS pour la souveraineté numérique. AWS ACM et GCP GTS servent les workloads cloud.
TrustAsia (Shanghai) domine avec ~40% des certs chinois. BJCA est la CA étatique. DigiCert conserve une présence enterprise. Let's Encrypt pour les sites à audience internationale.
Depuis 2022, les sanctions bloquent les renouvellements auprès des CA occidentales. Gosuslugi CA créée par le Ministère du Numérique — gratuite, mais reconnue uniquement par Yandex Browser et Atom.
SECOM Trust Systems est la CA historique japonaise avec ~30% du marché local — surtout les sites gouvernementaux et enterprise. Let's Encrypt progresse sur les PME.
Pas de CA africaine dans les root stores des browsers. Seulement 45 certs SSL pour tout l'Érythrée (2024). Documentation quasi-exclusivement en anglais, freinant l'adoption francophone.
AWS (ACM), Google (GTS) et Azure ont leurs propres CA publiques gratuites — mais liées à leur écosystème, non exportables. Cloudflare combine LE + GTS pour les certs edge.
HARICA (réseau académique grec, reconnu par tous les browsers), InCommon (fédération US), RNP (Brésil). Gratuites pour les membres, refusées aux particuliers.
Buypass (🇳🇴, 180j gratuit), Actalis (🇮🇹, ACME illimité), Certum (🇵🇱 Asseco), GlobalSign (🇧🇪). Conformité RGPD native, données hébergées en UE.
03–04 · Carte mondiale & tableau
Influence des CA par pays
Choroplèthe de la CA dominante par pays. Survolez un pays pour les détails. Les marqueurs ● indiquent les sièges des principales CA.
Chargement de la carte…
05 · Résumé général
Toutes les CA : gratuit, validité, prix, UE, CNIL
La CNIL applique le RGPD en France. Pour les certs DV, peu de données personnelles sont impliquées (email, nom de domaine). Les CA américaines opèrent sous le EU-US Data Privacy Framework et des SCCs. Pour une conformité maximale : préférer les CA hébergées en UE. Les CA chinoises (TrustAsia, BJCA) et russe (Gosuslugi) ne sont pas conformes RGPD.
| CA | Siège | Gratuit | Validité | Prix payant | Basée UE | RGPD/CNIL | ACME | Navigateurs | Open source |
|---|---|---|---|---|---|---|---|---|---|
| Let's Encrypt | 🇺🇸 Californie (ISRG) | ✅ Illimité | 90j → 45j (2028) | N/A — ONG | ❌ | SCCs | ✅ | Tous | ✅ |
| ZeroSSL | 🇦🇹/🇸🇪 Assa Abloy | ⚠️ 3 certs | 90j | ~$10–15/mois | ⚠️ | Partiel | ✅ | Tous | ❌ |
| Buypass Go SSL | 🇳🇴 Norvège | ✅ DV | 180 jours | OV/EV payant | ✅ EEE | ✅ RGPD | ✅ | Tous | ❌ |
| Actalis | 🇮🇹 Italie · Aruba | ✅ Illimité ACME | 90j | OV/EV payant | ✅ UE eIDAS | ✅ RGPD | ✅ | Tous | ❌ |
| GlobalSign | 🇧🇪 Belgique · GMO | ❌ | 1–2 ans | €150–500/an | ✅ UE | ✅ RGPD | ✅ | Tous | ❌ |
| Certum | 🇵🇱 Pologne · Asseco | ❌ | 1–2 ans | €50–200/an | ✅ UE | ✅ RGPD | ✅ | Tous | ❌ |
| HARICA | 🇬🇷 Grèce · Académique | ✅ Académique | 1 an | OV payant | ✅ UE | ✅ RGPD | ✅ | Tous | ❌ |
| DigiCert | 🇺🇸 Utah | ❌ | 1 an | $200–500/an | ❌ | SCCs | ✅ | Tous | ❌ |
| Sectigo | 🇺🇸 USA (ex-Comodo) | ❌ | 1–2 ans | $80–300/an | ❌ | SCCs | ✅ | Tous | ❌ |
| AWS ACM | 🇺🇸 Amazon | ✅ AWS only | Auto | N/A | ❌ | SCCs | ❌ | Tous | ❌ |
| Google Trust Svc | 🇺🇸 Google / GCP | ✅ GCP only | 90j | N/A | ❌ | SCCs | ✅ | Tous | ❌ |
| TrustAsia | 🇨🇳 Shanghai | ⚠️ Limité | 1 an | Payant (CNY) | ❌ | ❌ Non RGPD | ⚠️ | Tous | ❌ |
| SECOM | 🇯🇵 Tokyo | ❌ | 1–2 ans | ¥10k–100k/an | ❌ | Partiel | ❌ | Tous | ❌ |
| Gosuslugi CA | 🇷🇺 Russie · État | ⚠️ Entités RU | 1 an | N/A | ❌ | ❌ Non RGPD | ❌ | Yandex seulement | ❌ |
| step-ca | Auto-hébergé | ✅ Open source | Configurable | Enterprise payant | ✅ local | ✅ local | ✅ | ⚠️ Interne | ✅ Apache 2 |
| XiPKI | Auto-hébergé (Lijun Liao) | ✅ Open source | Configurable | N/A | ✅ local | ✅ local | ✅ + post-quantique | ⚠️ Interne | ✅ Apache 2 |
Let's Encrypt pour un usage perso/PME (gratuit, automatisé, ONG sans motif lucratif). Actalis ou Buypass pour une conformité RGPD maximale sans dépendance US. AWS ACM ou GTS si déjà dans l'écosystème cloud. step-ca pour un réseau interne. XiPKI pour la cryptographie post-quantique dès aujourd'hui.