Sovereign Certificate Authority

Sovereign Certificate Authority est une autorité de certification interne qui reproduit 1:1 l’expérience Let’s Encrypt dans votre propre réseau : protocole ACME, enrôlement automatique des certificats, renouvellement automatique — pour tous les services internes, sous-domaines et appareils des collaborateurs. En production active.

  flowchart LR
    A[Service interne] -->|Requête ACME| B[Sovereign CA]
    B -->|challenge| C[HTTP-01 / DNS-01]
    C -->|OK| D[Émettre certificat 90 jours]
    D --> A
    A -.->|renouveler à 60 jours| B

De quoi il s’agit

Toute organisation avec des services internes — du wiki au tracker de tickets en passant par les tableaux de bord de monitoring — connaît la danse : les certificats TLS. Trois options classiques, aucune n’est satisfaisante :

1. Certificats auto-signés — Chaque navigateur affiche un avertissement, les utilisateurs cliquent en outrepassant (culture de sécurité ruinée), et à un moment on ne distingue plus un phishing d’un trafic normal.
2. Certificats d’AC publique pour des hostnames internes — payant (150–500 € par certificat et par an), et tous les hostnames internes finissent dans les Certificate Transparency logs publics — un attaquant y lit exactement quels systèmes internes existent.
3. Let’s Encrypt — gratuit, mais ne fonctionne pas pour des hôtes purement intranet (pas d’accessibilité publique pour la validation HTTP), et avec 50 certificats par semaine par domaine, les rate limits sont durs.

La Sovereign Certificate Authority est la réponse : le même confort que Let’s Encrypt, mais en interne, sans exposition aux logs publics et sans limites.

L’expérience Let’s Encrypt — en interne

Chaque client compatible ACME fonctionne directement avec l’AC interne — aucune modification de code, aucun outil spécial, aucune API propriétaire.

• 🤖 Auto-enrôlement — Un service n’a qu’à connaître l’endpoint ACME de l’AC interne ; il récupère ensuite son certificat tout seul.
• 🔁 Auto-renouvellement — Durée par défaut 90 jours, renouvellement automatique après 60 jours. Plus personne ne pense aux dates d’expiration.
• 🌐 Challenge HTTP-01 + DNS-01 — Les deux méthodes de validation standard, selon le cas d’usage.
• 🃏 Wildcards — Certificats wildcards pour des espaces de sous-domaines entiers (*.intern.example.com).
• 📜 Clients standard — certbot, acme.sh, lego, dehydrated, Caddy, Traefik, nginx-acme — tous fonctionnent sans adaptation.

Pourquoi pas simplement Let’s Encrypt ?

Le point décisif : l’exposition CT log. Chaque certificat émis par une AC publique — y compris Let’s Encrypt — atterrit dans un journal public, indexable. Quiconque interroge crt.sh voit tous vos hostnames internes. Les outils de reconnaissance des attaquants en tirent exactement parti.

Une AC interne émet des certificats sans qu’ils n’apparaissent publiquement nulle part. Les hostnames internes restent internes.

Fonctionnalités opérationnelles

• 🌳 Hiérarchie PKI multi-tiers — AC racine hors ligne, AC intermédiaire en ligne pour l’émission ACME. Pratique PKI standard.
• 🔄 Révocation automatique — Points de distribution CRL et répondeur OCSP ; certificats compromis ou retirés sont révoqués proprement.
• 🔐 Clé matérielle optionnelle — La clé intermédiaire peut être détenue dans un HSM ou un TPM — même sur un serveur compromis, la clé d’AC n’est pas exposée.
• 📊 Monitoring & inventaire — Vue d’ensemble de chaque certificat émis, dates d’expiration, hôtes concernés.
• 🎯 Moteur de politiques — Quel client peut émettre quels certificats ? Liaison de comptes, allowlists de domaines, limites de validité maximales par rôle.
• 🔌 Intégration de services — Certificats de tunnel (VPN, mTLS), service mesh (compatible Envoy/Istio), serveurs mail (SMTP/IMAP TLS), reverse proxies, appareils IoT.
• ⏰ Configuration de durée de vie — Durées de vie courtes (24 h pour les pipelines, 90 jours pour les services, 1 an pour l’IoT) — finement ajustable par cas d’usage.
• 🔍 Journal d’audit — Chaque émission, renouvellement et révocation est journalisée de manière structurée.

Cas d’usage typiques

• 🏢 Applications web internes — Wiki, tracker, CRM, tableaux de bord avec de vrais certificats TLS que chaque navigateur accepte (après installation de la racine sur les endpoints).
• 🤝 mTLS service-à-service — Microservices / service mesh avec authentification mutuelle plutôt que clés API.
• 📱 Authentification des appareils — Ordinateurs portables et appareils mobiles reçoivent des certificats client pour l’accès Wi-Fi, VPN et services.
• 📧 Infrastructure e-mail — Soumission SMTP, IMAP/POP avec certificats valides sans payer une AC publique.
• 🛠️ Pipelines CI/CD — Certificats à courte durée de vie pour les runners de build, émis automatiquement et jetés après le job.
• 🌍 Domaines DNS internes — .internal, .lan, sous-domaines top-level personnalisés — certificats là où Let’s Encrypt ne peut par définition pas en émettre.

Pourquoi c’est un sujet de niveau CEO

• 💰 Évitement de coûts — Pour 100 services internes avec certificats d’AC publique : typiquement 30 000–50 000 € par an. Avec une AC interne : 0 €.
• 🔍 Protection contre la reconnaissance — Les hostnames internes sont aujourd’hui la plus grosse fuite en reconnaissance pré-attaque — ils dressent aux attaquants la carte de l’organisation. Une AC interne supprime entièrement cette fuite.
• 🛡️ Souveraineté — Contrôle total sur la chaîne de confiance. Aucune dépendance envers des AC externes dont le programme racine peut changer ou la confiance peut être révoquée (Symantec, DarkMatter, …).
• 📋 Conformité — Chaîne de garde complète. Dans les secteurs réglementés (finance, santé, défense) les AC internes sont souvent obligatoires.
• ♻️ Continuité d’activité — En cas d’indisponibilité de l’AC externe (maintenance, sanctions, insolvabilité), les certificats internes restent émettables.
• 🔧 Mise à l’échelle sans coût marginal — 10 ou 10 000 certificats — l’effort et le coût sont quasi identiques.

Fondation technologique

Construite sur des implémentations d’AC open source éprouvées avec support complet du protocole ACME.

Sovereign Certificate Authority — variante interne de Let’s Encrypt · ACME RFC 8555 · enrôlement entièrement automatisé · sans exposition aux CT logs publics · en production