Eigene CA betreiben: private PKI einfach erklärt

Für öffentliche Websites ist eine Zertifizierungsstelle wie Let’s Encrypt die richtige Wahl. Doch viele Zertifikate werden gar nicht von Browsern fremder Leute geprüft: Server im Firmennetz, Geräte, VPN-Zugänge, Client-Zertifikate oder Dienste in Kubernetes. Dafür betreiben Firmen und auch Technikbegeisterte oft eine eigene CA, eine private PKI. Dieser Artikel erklärt, wann sich das lohnt und wann nicht, wie eine gute Hierarchie aussieht, welche Werkzeuge es gibt, und zeigt eine kleine CA mit step-ca.

Wann eine eigene CA sinnvoll ist

Interne Namen: Öffentliche CAs stellen seit 2015 keine Zertifikate mehr für Namen wie server.local oder Adressen aus privaten Netzen aus. Eine eigene CA kann das.
Client-Zertifikate: Öffentliche Website-Zertifikate eignen sich dafür nicht mehr: Let’s Encrypt stellt sie seit 2026 nicht mehr mit Client-Verwendung aus, und Chrome erlaubt für neue Website-Zertifikate ab März 2027 nur noch den Server-Zweck. Für Mutual TLS braucht man ohnehin eine eigene CA; siehe Mutual TLS einfach erklärt.
Geräte und Maschinen: Router, Drucker, Sensoren oder Dienste in Containern, die nur intern erreichbar sind.
Firmen-WLAN, VPN und E-Mail: Anmeldung mit Zertifikat statt Passwort, interne Signaturen.
Eigene Regeln: Laufzeiten, Namen und Felder bestimmt die Organisation selbst, und interne Namen landen nicht in den öffentlichen Certificate-Transparency-Protokollen; siehe Certificate Transparency.

Wann nicht

Für alles, was Besucher von außen aufrufen, ist eine eigene CA ungeeignet: Ihre Root steckt nicht in den Root Stores fremder Geräte, und jeder Besucher sähe eine Warnung. Auch intern gilt: Wenn ein Dienst unter einem echten, öffentlichen Domainnamen erreichbar ist und Let’s Encrypt per DNS-Prüfung ausstellen kann, ist das oft einfacher als eine eigene PKI. Eine eigene CA ist Verantwortung: Wer ihren Root-Schlüssel stiehlt, kann jedem Gerät, das ihr vertraut, beliebige Websites vorspielen.

Zwei Spalten: Eine eigene CA lohnt sich für interne Namen, Client-Zertifikate, Geräte, WLAN, VPN und E-Mail; für öffentliche Websites ist eine öffentliche CA besser. — Wann sich eine eigene CA lohnt.

Aufbau: Offline-Root und ausstellende CA

Eine bewährte private PKI hat mindestens zwei Ebenen, wie öffentliche CAs auch; siehe Zertifikatskette einfach erklärt:

Root-CA: lange gültig, etwa 10 bis 20 Jahre. Ihr Schlüssel liegt offline, auf einem Rechner ohne Netzwerk oder in einem Hardware-Sicherheitsmodul, und wird nur benutzt, um ausstellende CAs zu unterschreiben und Sperrlisten zu erneuern.
Ausstellende CA (Intermediate): online, einige Jahre gültig, stellt die eigentlichen Zertifikate aus. Wird sie kompromittiert, sperrt man sie mit der Root und richtet eine neue ein.
Endzertifikate: möglichst kurz gültig, von 24 Stunden bis 90 Tagen, und automatisch erneuert.

Zusätzlich lohnt die Erweiterung Name Constraints: Sie beschränkt eine CA auf bestimmte Namensräume, etwa auf intern.beispiel.de. Selbst wenn diese CA missbraucht wird, kann sie keine gültigen Zertifikate für fremde Domains ausstellen. Als Namensraum eignet sich eine Subdomain einer eigenen, echten Domain oder die Endung .internal, die die ICANN 2024 für private Netze reserviert hat. Die Endung .local ist dagegen für die automatische Namensauflösung im lokalen Netz vorgesehen und führt oft zu Konflikten.

Drei Ebenen: Root-CA offline mit 10 bis 20 Jahren Laufzeit, ausstellende CA online mit Namensbeschränkung, Endzertifikate mit 24 Stunden bis 90 Tagen. — Empfohlene Hierarchie einer eigenen CA.

Werkzeuge: von step-ca bis AD CS

step-ca (Smallstep): ein schlanker Open-Source-Server, der auch das ACME-Protokoll spricht. Dienste können sich Zertifikate damit genauso automatisch holen wie bei Let’s Encrypt.
Active Directory Certificate Services (AD CS): die CA von Windows Server, eng mit dem Active Directory verbunden. Rechner und Benutzer bekommen Zertifikate über Gruppenrichtlinien automatisch. Fehlkonfigurierte Zertifikatsvorlagen sind allerdings ein beliebter Angriffsweg, der seit 2021 unter Sicherheitsforschern breit dokumentiert ist. Zum Active Directory siehe Active Directory und LDAP.
EJBCA: eine umfangreiche Open-Source-PKI für große Umgebungen.
HashiCorp Vault und der Fork OpenBao: stellen kurzlebige Zertifikate für Anwendungen und Container aus.
Cloud-Dienste wie AWS Private CA oder Google Certificate Authority Service, die den Betrieb übernehmen.
OpenSSL allein reicht für ein Testlabor, ist für den Dauerbetrieb aber zu fehleranfällig.

Tabelle: step-ca für Homelab und Dienste, AD CS für Windows-Netze, EJBCA für große Umgebungen, Vault und OpenBao für Anwendungen, Cloud-CAs bei AWS und Google. — Verbreitete Werkzeuge für private PKIs.

Beispiel: eine kleine CA mit step-ca

Mit dem Kommandozeilenwerkzeug step ist eine Test-CA in wenigen Minuten eingerichtet:

step ca init --name "Beispiel Intern" --dns ca.intern.beispiel.de --address :443 --provisioner admin
step-ca $(step path)/config/ca.json
step ca certificate wiki.intern.beispiel.de wiki.crt wiki.key
step ca provisioner add acme --type ACME

Der erste Befehl erzeugt Root- und ausstellende CA samt Schlüsseln, der zweite startet den Server, der dritte holt ein Zertifikat für einen Wiki-Server. Standardmäßig gelten Zertifikate von step-ca nur 24 Stunden und werden automatisch erneuert; der vierte Befehl schaltet ACME ein, sodass certbot, Caddy oder Kubernetes-Werkzeuge direkt mit der eigenen CA arbeiten können. Für den Dauerbetrieb gehört der Root-Schlüssel danach vom Server entfernt und sicher verwahrt. Wie ein Zertifikatsantrag aussieht, zeigt Schlüsselpaar und CSR erstellen.

Die Root verteilen und absichern

Damit Geräte der eigenen CA vertrauen, muss ihr Root-Zertifikat in deren Root Store:

unter Windows per Gruppenrichtlinie oder Geräteverwaltung,
auf Mac, iPhone und Android über Profile der Geräteverwaltung,
unter Linux etwa nach /usr/local/share/ca-certificates/ kopieren und update-ca-certificates ausführen,
in Java und manchen Programmen, die eigene Root Stores nutzen, zusätzlich dort.

Danach gelten dieselben Pflichten wie bei einer öffentlichen CA im Kleinen: Sperrlisten veröffentlichen, Laufzeiten überwachen, den Root-Schlüssel sichern und den Zugang zur ausstellenden CA streng begrenzen. Root Stores im Allgemeinen erklärt Root Stores einfach erklärt.

Häufige Fragen

Reicht nicht ein selbstsigniertes Zertifikat pro Server? Für einen einzelnen Testserver vielleicht. Bei mehreren Diensten muss man sonst jedes Zertifikat einzeln auf jedem Gerät als vertrauenswürdig eintragen. Eine CA braucht nur eine Root auf jedem Gerät.

Wie lange sollte die Root gültig sein? Lang genug, um nicht ständig alle Geräte umzustellen, typischerweise 10 bis 20 Jahre. Entscheidend ist, dass ihr Schlüssel offline bleibt.

Kann ich meiner Heim-CA im Heimnetz trauen? Ja, wenn Sie den Root-Schlüssel gut schützen. Installieren Sie die Root nur auf Ihren eigenen Geräten.

Was passiert, wenn der Root-Schlüssel verloren geht? Dann können Sie keine neuen ausstellenden CAs und keine Sperrlisten mehr signieren. Eine verschlüsselte Sicherung an einem zweiten Ort ist Pflicht; siehe Backup-Strategie 3-2-1.

Fazit

Eine eigene CA lohnt sich für interne Namen, Client-Zertifikate, Geräte und alles, was nicht von fremden Browsern geprüft wird. Gute Praxis sind eine Offline-Root, eine ausstellende CA mit Namensbeschränkung, kurze Laufzeiten und Automatisierung über ACME, etwa mit step-ca. Für öffentliche Websites bleibt eine öffentliche CA die richtige Wahl. Mehr in der Übersicht Verschlüsselung und IT-Sicherheit.