Sovereign Certificate Authority

Sovereign Certificate Authority ist eine interne Certificate Authority, die das Let’s-Encrypt-Erlebnis 1:1 ins eigene Netz holt: ACME-Protokoll, automatisches Cert-Enrollment, automatische Erneuerung — für alle internen Dienste, Subdomains und Mitarbeiter- Geräte. Produktiv im Einsatz.

  flowchart LR
    A[Interner Dienst] -->|ACME-Request| B[Sovereign CA]
    B -->|Challenge| C[HTTP-01 / DNS-01]
    C -->|erfolgreich| D[Zertifikat 90 Tage ausstellen]
    D --> A
    A -.->|nach 60 Tagen erneuern| B

Worum es geht

Jedes Unternehmen mit eigenen internen Diensten — vom Wiki über das Issue-Tracker-System bis zum internen Monitoring-Dashboard — kennt das Spiel: TLS-Zertifikate. Drei klassische Varianten gibt es, und keine davon ist gut:

1. Selbstsignierte Zertifikate — Jeder Browser warnt, Benutzer klicken sich an Warnungen vorbei (Sicherheitskultur kaputt), und irgendwann ist ein Phishing-Klick nicht mehr unterscheidbar.
2. Public-CA-Zertifikate für interne Hostnamen — kostenpflichtig (€150 – €500 pro Zertifikat pro Jahr), und alle internen Hostnamen erscheinen in den öffentlichen Certificate-Transparency- Logs — Angreifer können dort ablesen, welche internen Systeme es gibt.
3. Let’s Encrypt — kostenfrei, aber funktioniert nicht für reine Intranet-Hosts (keine öffentliche Erreichbarkeit für die HTTP-Validation), und mit 50 Zertifikaten pro Woche pro Domain harte Rate-Limits.

Die Sovereign Certificate Authority ist die Antwort: derselbe Komfort wie Let’s Encrypt, aber intern, ohne Public-Log-Exposition und ohne Limits.

Die Let’s-Encrypt-Erfahrung — intern

Jeder ACME-fähige Client funktioniert direkt mit der internen CA — keine Code-Änderung, keine speziellen Tools, keine proprietäre API.

• 🤖 Auto-Enrollment — Ein Dienst muss nur den ACME-Endpoint der internen CA kennen, dann zieht er sein Zertifikat selbst.
• 🔁 Auto-Renewal — Standardlaufzeit 90 Tage, automatische Erneuerung nach 60 Tagen. Niemand muss mehr an Ablaufdaten denken.
• 🌐 HTTP-01 + DNS-01 Challenge — Beide Standard-Validierungsmethoden, je nach Use-Case.
• 🃏 Wildcards — Wildcard-Zertifikate für ganze Subdomain-Räume möglich (*.intern.example.com).
• 📜 Standard-Clients — certbot, acme.sh, lego, dehydrated, Caddy, Traefik, nginx-acme — alle funktionieren ohne Anpassung.

Warum nicht einfach Let’s Encrypt?

Der entscheidende Punkt: CT-Log-Exposition. Jedes von einer Public-CA ausgestellte Zertifikat — auch das von Let’s Encrypt — landet in einem öffentlichen, durchsuchbaren Log. Wer crt.sh abfragt, sieht alle deine internen Hostnamen. Reconnaissance-Tools für Angreifer nutzen genau das.

Eine interne CA stellt Zertifikate aus, ohne dass sie irgendwo öffentlich erscheinen. Die internen Hostnamen bleiben intern.

Operative Features

• 🌳 Mehrstufige PKI-Hierarchie — Root-CA offline, Intermediate-CA online für die ACME-Ausstellung. Standard-PKI-Praxis.
• 🔄 Automatische Revocation — CRL- und OCSP-Endpoints für Sperrlisten, kompromittierte oder ausgemusterte Zertifikate werden sauber gesperrt.
• 🔐 Hardware-Schlüssel-Optional — Intermediate-Key kann in einem HSM oder TPM gehalten werden — selbst bei kompromittiertem Server kein freier CA-Key.
• 📊 Monitoring & Inventory — Übersicht aller ausgestellten Zertifikate, Ablaufdaten, betroffene Hosts.
• 🎯 Policy Engine — Welcher Client darf welche Zertifikate ausstellen? Account-Bindung, Domain-Allowlists, Maximum-Validity-Limits pro Rolle.
• 🔌 Service-Integration — Tunnel-Zertifikate (VPN, mTLS), Service-Mesh (Envoy/Istio-kompatibel), Mail-Server (SMTP/IMAP TLS), Reverse-Proxies, IoT-Devices.
• ⏰ Lebenszeit-Konfiguration — Kurze Cert-Lifetimes (24h für Pipelines, 90 Tage für Dienste, 1 Jahr für IoT) — feingranular pro Use-Case.
• 🔍 Audit-Log — Jede Ausstellung, Erneuerung und Sperrung wird strukturiert protokolliert.

Typische Use-Cases

• 🏢 Interne Web-Anwendungen — Wiki, Tracker, CRM, Dashboards mit echten TLS-Zertifikaten, die jeder Browser akzeptiert (nach Root-Installation auf Endgeräten).
• 🤝 Service-to-Service mTLS — Microservices/Service-Mesh mit gegenseitiger Authentifizierung statt API-Keys.
• 📱 Geräte-Authentifizierung — Mitarbeiter-Laptops und mobile Endgeräte erhalten Client-Zertifikate für WLAN-, VPN- und Service-Zugang.
• 📧 E-Mail-Infrastruktur — SMTP-Submission, IMAP/POP mit gültigen Zertifikaten ohne Public-CA-Kosten.
• 🛠️ CI/CD-Pipelines — Kurzlebige Zertifikate für Build-Runner, automatisch ausgestellt und nach dem Job verworfen.
• 🌍 Internal-DNS-Domains — .internal, .lan, eigene Top-Level-Subdomains — Zertifikate, wo Let’s Encrypt prinzipiell nicht ausstellen kann.

Warum das ein CEO-Thema ist

• 💰 Cost-Avoidance — Pro 100 interne Dienste mit Public-CA-Zertifikaten: typischerweise 30 000–50 000 € pro Jahr. Mit interner CA: 0 €.
• 🔍 Reconnaissance-Schutz — Interne Hostnamen sind heute der größte Verrat im Pre-Attack-Reconnaissance — sie verraten Angreifern die Topologie der Organisation. Eine interne CA eliminiert diese Lecks vollständig.
• 🛡️ Souveränität — Volle Kontrolle über die Vertrauenskette. Keine Abhängigkeit von externen CAs, deren Root-Programm sich ändern oder deren CA-Vertrauen widerrufen werden kann (Symantec, DarkMatter, …).
• 📋 Compliance — Vollständige Custody-Chain. Für regulierte Branchen (Finanz, Gesundheit, Verteidigung) sind interne CAs oft sogar Pflicht.
• ♻️ Geschäftskontinuität — Bei Ausfall der externen CA (z. B. wegen Wartung, Sanktionen, Insolvenz) sind die internen Zertifikate weiter ausstellbar.
• 🔧 Skalierung ohne Marginalkosten — 10 oder 10 000 Zertifikate — der Aufwand und die Kosten ändern sich praktisch nicht.

Technologisches Fundament

Realisiert auf Basis erprobter Open-Source-CA-Implementierungen, die das ACME-Protokoll vollständig unterstützen.

Sovereign Certificate Authority — interne Let’s-Encrypt-Variante · ACME RFC 8555 · vollautomatisches Enrollment · keine Public-CT-Log-Exposition · Produktiv im Einsatz