Kurz gesagt: Die Wahl zwischen einer privaten vs öffentlichen Zertifizierungsstelle hängt davon ab, wer den Zertifikaten vertrauen muss. Eine öffentliche CA wird von Browsern und Betriebssystemen vorab als vertrauenswürdig eingestuft und eignet sich für öffentlich erreichbare Dienste. Eine private CA schafft Vertrauen innerhalb der eigenen Organisation – flexibel, kostengünstig und ideal für interne TLS-, Geräte- und Automatisierungsszenarien.
Zertifikate sind nur so viel wert wie die Stelle, die sie ausstellt. Diese Stelle – die Zertifizierungsstelle (Certificate Authority, CA) – bürgt dafür, dass ein öffentlicher Schlüssel wirklich zu einer bestimmten Identität gehört. Fällt dieses Vertrauen weg, sind auch die schönsten kryptografischen Verfahren wertlos.
In der Praxis stellt sich früher oder später die Frage nach der richtigen privaten vs öffentlichen Zertifizierungsstelle: Betreibt man eine eigene CA oder bezieht man Zertifikate von einem öffentlich anerkannten Anbieter? Die Antwort hängt weniger von der Technik als vom Vertrauensmodell des jeweiligen Anwendungsfalls ab. Dieser Beitrag ordnet die Unterschiede, die Hierarchie und die typischen Einsatzszenarien ein.
Private vs öffentliche Zertifizierungsstelle: der Hauptunterschied
Der entscheidende Unterschied liegt im Vertrauensanker. Eine öffentliche Zertifizierungsstelle ist mit ihrem Root-Zertifikat in den Vertrauensspeichern von Browsern und Betriebssystemen hinterlegt und unterliegt strengen, extern auditierten Regeln (etwa den Anforderungen des CA/Browser-Forums). Zertifikate einer öffentlichen CA werden daher von beliebigen Dritten ohne weitere Konfiguration akzeptiert.
Eine private CA betreibt die Organisation selbst. Ihr Rootzertifikat muss aktiv in den relevanten Systemen verteilt werden – dafür hat man volle Kontrolle über Richtlinien, Laufzeiten, Namensräume und Zertifikatsprofile. Für geschlossene Ökosysteme kann das ein Vorteil sein. Man kann Zertifikate exakt auf interne Anforderungen zuschneiden, ohne an öffentliche Baseline-Vorgaben gebunden zu sein.
Wie eine CA-Hierarchie aufgebaut ist
Beide Modelle nutzen in der Regel eine mehrstufige Hierarchie. An der Spitze steht eine Root-CA, deren privater Schlüssel besonders geschützt und meist offline gehalten wird. Darunter liegen eine oder mehrere ausstellende CAs (Issuing CAs), die das "Tagesgeschäft" übernehmen und die eigentlichen Zertifikate ausgeben.
- Root-CA: Bildet den Vertrauensanker, signiert nur untergeordnete CAs, bleibt weitgehend offline.
- Ausstellende CA: Gibt die eigentlichen End-Entity-Zertifikate für Nutzer, Dienste und Geräte aus.
- HSM-Schutz:: Die Signaturschlüssel beider Ebenen gehören in ein Hardware-Sicherheitsmodul.
Diese Trennung begrenzt den Schaden bei einer Kompromittierung und erlaubt es, ausstellende CAs bei Bedarf auszutauschen, ohne den gesamten Vertrauensanker zu wechseln. Sie ist damit auch die Grundlage für eine langfristig wartbare PKI.
Anwendungsfälle: wann welche CA passt
Die Faustregel: Öffentlich erreichbare Dienste brauchen eine öffentliche CA, interne und IoT Szenarien profitieren von einer privaten CA. In der Realität setzen viele Organisationen beide Modelle nebeneinander ein:
- Öffentliche CA: Web-TLS für öffentlich erreichbare Websites und APIs, teils S/MIME und öffentlich vertrauenswürdiges Code Signing.
- Private CA: internes TLS und mTLS zwischen Diensten, Geräte- und Maschinenidentitäten, Nutzer-Authentifizierung, interne Automatisierung.
- Mischbetrieb: viele Organisationen betreiben beides parallel – öffentlich nach außen, privat nach innen.
Kostentreiber ist selten das einzelne Zertifikat, sondern die Menge: Wer intern zehntausende kurzlebige Zertifikate benötigt, fährt mit einer privaten CA meist wirtschaftlicher und flexibler, weil sich Ausstellung und Erneuerung frei gestalten lassen.
Auch die Laufzeit spielt eine Rolle: Öffentliche TLS-Zertifikate unterliegen zunehmend kurzen, standardisierten Laufzeiten, während eine private CA die Gültigkeitsdauer frei am eigenen Bedarf ausrichten kann. Wer automatisieren kann, wählt kurze Laufzeiten – wer es nicht kann, riskiert Ausfälle.
Entscheidungshilfe: private oder öffentliche CA?
Diese Fragen helfen bei der Einordnung und lassen sich als kurze Checkliste anwenden:
- Müssen unbekannte Dritte (Browser, Partner) den Zertifikaten ohne vorherige Einrichtung vertrauen? Wenn ja, dann öffentliche CA.
- Bleiben die Zertifikate innerhalb kontrollierter Systeme? Dann spricht vieles für eine private CA.
- Wie viele Zertifikate mit welcher Laufzeit sind zu erwarten und wie ist der Prozess für die Erneuerung?
- Gibt es das KnowHow und die Ressourcen um eine eigene CA zu betrieben?
- Müssen die Signaturschlüssel der Root- und ausstellenden CA in einem onPremise HSM geschützt werden?
- Wie flexibel müssen die Zertifikatsprofile gestaltet sein? Gibt es unternehmensspezifische Anforderungen, die in "Standardzertifikaten" nicht abbildbar sind?
So wird aus der Frage private vs öffentliche Zertifizierungsstelle eine bewusste Architekturentscheidung statt einer Zufallswahl – oft mit dem Ergebnis, dass beide Modelle ihren klar abgegrenzten Platz bekommen.
Wie CRYPTAS hilft
Ob private oder öffentliche Zertifizierungsstelle – entscheidend ist der verlässliche Betrieb dahinter. CRYPTAS plant und betreibt CA-Hierarchien mit HSM-geschützten Schlüsseln und automatisiertem Zertifikats-Lifecycle, damit interne und öffentliche Zertifikate aus einer Hand steuerbar bleiben. Wissen Sie, wie viele private und öffentliche Zertifikate heute in Ihrer Umgebung im Umlauf sind?