Sovereign Certificate Authority

Sovereign Certificate Authority is an internal certificate authority that brings the Let’s Encrypt experience 1:1 into your own network: ACME protocol, automated cert enrollment, automatic renewal — for every internal service, subdomain, and employee device. In active production.

  flowchart LR
    A[Internal service] -->|ACME request| B[Sovereign CA]
    B -->|challenge| C[HTTP-01 / DNS-01]
    C -->|pass| D[Issue 90-day cert]
    D --> A
    A -.->|after 60 days, renew| B

What it is

Every organization with internal services — from the wiki to the issue tracker to internal monitoring dashboards — knows the song and dance: TLS certificates. Three classic options, none of them good:

1. Self-signed certificates — Every browser warns, users click past warnings (security culture broken), and at some point a phishing click is no longer distinguishable from normal traffic.
2. Public CA certificates for internal hostnames — chargeable (€150–€500 per certificate per year), and all internal hostnames end up in the public Certificate Transparency logs — attackers can read off exactly which internal systems exist.
3. Let’s Encrypt — free, but doesn’t work for pure intranet hosts (no public reachability for HTTP validation), and with 50 certificates per week per domain it has hard rate limits.

The Sovereign Certificate Authority is the answer: the same comfort as Let’s Encrypt, but internal, without public log exposure, and without limits.

The Let’s Encrypt experience — internal

Every ACME-capable client works directly with the internal CA — no code change, no special tooling, no proprietary API.

• 🤖 Auto-enrollment — A service only needs to know the ACME endpoint of the internal CA; from there it pulls its own certificate.
• 🔁 Auto-renewal — 90-day default lifetime, automatic renewal after 60 days. No more thinking about expiration dates.
• 🌐 HTTP-01 + DNS-01 challenge — Both standard validation methods, depending on the use case.
• 🃏 Wildcards — Wildcard certificates for entire subdomain spaces (*.internal.example.com).
• 📜 Standard clients — certbot, acme.sh, lego, dehydrated, Caddy, Traefik, nginx-acme — all work without modification.

Why not just Let’s Encrypt?

The crucial point: CT log exposure. Every certificate issued by a public CA — including Let’s Encrypt — ends up in a public, searchable log. Anyone querying crt.sh sees all your internal hostnames. Reconnaissance tools for attackers leverage exactly this.

An internal CA issues certificates without them appearing anywhere publicly. Internal hostnames stay internal.

Operational features

• 🌳 Multi-tier PKI hierarchy — Root CA offline, intermediate CA online for ACME issuance. Standard PKI practice.
• 🔄 Automatic revocation — CRL and OCSP endpoints for revocation lists; compromised or decommissioned certificates are revoked cleanly.
• 🔐 Hardware-key optional — Intermediate key can be held in an HSM or TPM — even on a compromised server the CA key is not exposed.
• 📊 Monitoring & inventory — Overview of every issued certificate, expiration dates, affected hosts.
• 🎯 Policy engine — Which client may issue which certificates? Account binding, domain allowlists, max-validity limits per role.
• 🔌 Service integration — Tunnel certificates (VPN, mTLS), service mesh (Envoy/Istio compatible), mail servers (SMTP/IMAP TLS), reverse proxies, IoT devices.
• ⏰ Lifetime configuration — Short cert lifetimes (24h for pipelines, 90 days for services, 1 year for IoT) — finely tunable per use case.
• 🔍 Audit log — Every issuance, renewal, and revocation is structured-logged.

Typical use cases

• 🏢 Internal web applications — Wiki, tracker, CRM, dashboards with real TLS certificates that every browser accepts (after installing the root on endpoints).
• 🤝 Service-to-service mTLS — Microservices / service mesh with mutual authentication instead of API keys.
• 📱 Device authentication — Employee laptops and mobile devices receive client certificates for Wi-Fi, VPN, and service access.
• 📧 Email infrastructure — SMTP submission, IMAP/POP with valid certificates without paying public CA fees.
• 🛠️ CI/CD pipelines — Short-lived certificates for build runners, issued automatically and discarded after the job.
• 🌍 Internal DNS domains — .internal, .lan, custom top-level subdomains — certificates where Let’s Encrypt can’t issue by definition.

Why this matters at the CEO level

• 💰 Cost avoidance — For 100 internal services with public CA certificates: typically €30,000–€50,000 per year. With an internal CA: €0.
• 🔍 Reconnaissance protection — Internal hostnames are today the biggest pre-attack reconnaissance leak — they hand attackers a map of the organization. An internal CA eliminates this leak entirely.
• 🛡️ Sovereignty — Full control over the chain of trust. No dependency on external CAs whose root program may change or whose trust may be revoked (Symantec, DarkMatter, …).
• 📋 Compliance — Complete custody chain. For regulated industries (finance, healthcare, defense) internal CAs are often mandatory.
• ♻️ Business continuity — If the external CA is unavailable (maintenance, sanctions, insolvency), internal certificates can still be issued.
• 🔧 Scaling without marginal cost — 10 or 10,000 certificates — the effort and cost are practically the same.

Technology foundation

Built on proven open-source CA implementations with full ACME protocol support.

Sovereign Certificate Authority — internal Let’s Encrypt variant · ACME RFC 8555 · fully automated enrollment · no public CT log exposure · in production