Private vs. Public CAs: Vielleicht nutzt du die falsche

Für ein IT-Team unter Druck sieht eine öffentliche Zertifizierungsstelle (Public CA) oft aus wie ein Hammer, und jede Verschlüsselungsanforderung wie ein Nagel. Aber eine Public CA für jede Aufgabe einzusetzen, ist einer der häufigsten Wege, den Produktivbetrieb still und leise zu zerlegen.

Wofür Public CAs gebaut sind

Eine Public CA wie DigiCert, Sectigo oder Let’s Encrypt ist für ein Hauptszenario gedacht: Du musst Vertrauen zu Geräten herstellen, die du nicht kontrollierst. Die Idee dahinter: Externe Nutzer müssen auf ihrer Seite nichts konfigurieren, um deiner Website oder deinem Dienst zu vertrauen.

Eine Public CA ist sinnvoll, wenn:

• du öffentlich erreichbare Dienste für externe Nutzer, Kunden oder Partner betreibst, die keine bestehende Vertrauensbeziehung zu deiner Organisation haben
• externe APIs oder Dienste sich ohne eigene Client-Konfiguration mit deiner Infrastruktur verbinden
• Zertifikatsfehler bei Endnutzern als Browser-Warnung auftauchen würden
• du E-Mails signierst und Empfänger die Signatur ohne vorherige Konfiguration prüfen sollen

Das CA/Browser Forum legt fest, was Public CAs ausstellen dürfen. Du unterliegst Regeln, die du nicht kontrollierst, was für viele in den oben genannten Szenarien ein vertretbarer Kompromiss ist. Zum Problem wird eine Public CA, sobald du dieselben Zertifikate für interne Authentifizierung verwendest.

Wofür Private CAs gebaut sind

Eine Private CA betreibst du selbst, oder dein Anbieter betreibt sie für dich. Du legst die Ausstellungsrichtlinie fest. Den Zertifikaten wird standardmäßig nirgends vertraut. Du verteilst das Stammzertifikat deiner Private CA über Gruppenrichtlinien, Intune oder deine MDM-Plattform an Geräte und Benutzer, und deine verwalteten Endpunkte vertrauen dann den Zertifikaten deiner Private CA.

Eine Private CA passt überall dort, wo nur deine eigene Infrastruktur dem Zertifikat vertrauen muss:

• Geräteauthentifizierung, also der Nachweis, dass ein Rechner verwaltet wird und zu deiner Organisation gehört
• Benutzerauthentifizierung über Zertifikate, passwortloses Anmelden, Smartcard-Äquivalente oder Zugriff auf interne Anwendungen
• Absicherung von Wi-Fi (802.1X) und VPN-Verbindungen
• Aufbau von Mutual TLS (mTLS) zwischen Backend-Microservices
• Code Signing für interne Werkzeuge und Skripte

Du behältst die volle Kontrolle über Vertrauenskette und Ausstellungsrichtlinie, ohne Abhängigkeit von der Governance einer externen CA.

Public CA oder Private CA? Ein kurzer Vergleich

Wo es schiefgeht

Der häufigste Fehler in IT-Teams ist, Zertifikate von Public CAs für interne Authentifizierung einzusetzen. Public CAs waren nie für interne Workloads gedacht, und zwei Entwicklungen, die gerade laufen, machen diese Lücke unübersehbar.

1. Keine Client-Authentication-EKUs mehr in öffentlichen TLS-Zertifikaten

Öffentlich vertrauenswürdige TLS-Zertifikate dürfen die Client-Authentication-EKU nicht mehr enthalten. Getrieben vom Ballot SC-081 des CA/Browser Forums und von Updates der großen Root-Programme, stellen Public CAs clientAuth vor dem harten Stichtag im März 2027 ein. Wenn deine interne Geräte- oder Benutzerauthentifizierung auf öffentlichen Zertifikaten beruht, funktionieren diese Setups nach der nächsten Erneuerung nicht mehr.

2. Rapide schrumpfende Laufzeiten

Public CAs kürzen die Gültigkeitsfenster von Zertifikaten laufend. Unter SC-081v3 liegt die öffentliche Obergrenze bei 200 Tagen (2026), sinkt im März 2027 auf 100 Tage und bis März 2029 auf 47 Tage. Automatisierte Werkzeuge bewältigen 90-Tage-Erneuerungen auf öffentlichen Webservern problemlos, aber Tausende interne Laptops oder Geräte alle sechs Wochen neu zu enrollen, ist ein administrativer Albtraum.

Eine Private CA liegt außerhalb dieser Vorgaben. Weil du die Sperrung direkt in deiner eigenen Umgebung steuerst, brauchst du keine künstlich kurzen Laufzeiten und keine externen Prüfungen. Du legst die Gültigkeitsdauern und Regeln fest, die zu deinem Team passen.

So entscheidest du, welche du brauchst

Frage dich bei jedem Zertifikat in deiner Umgebung: Kontrollierst du jedes Gerät und jeden Client, der dieses Zertifikat prüfen muss?

• Wenn ja: Nimm eine Private CA. Du verteilst das Stammzertifikat, bestimmst, was ausgestellt wird, und bist externen Regeländerungen nicht mehr ausgeliefert.
• Wenn nein: Du brauchst eine Public CA. Wer sich von außen ohne vorherige Konfiguration verbindet, braucht eine CA, der sein Gerät bereits vertraut.

Die meisten IT-Abteilungen brauchen am Ende beides: öffentliche Zertifikate für nach außen gerichtete Dienste, private Zertifikate für Geräte, Benutzer und interne Dienste.

Wo SCEPman ins Bild passt

SCEPman ist eine cloud-native Private CA, die sich in Microsoft Intune und Entra ID integriert, über SCEP und EST auch in andere MDM-Plattformen. Sie übernimmt die automatische Zertifikatsausstellung für verwaltete Geräte und Benutzer.

In Intune-Umgebungen koppelt SCEPman die Gültigkeit von Zertifikaten an den Compliance-Status des Geräts. Ein Gerät, das zurückgesetzt wird oder aus der Compliance fällt, verliert sein Zertifikat und damit automatisch den Zugriff auf Wi-Fi, VPN und interne Anwendungen.

SCEPman kann Zertifikate über den Certificate Master auch manuell ausstellen. So ersetzen IT-Abteilungen Zertifikate von Public CAs in internen Systemen wie Webportalen, Anwendungen und Oberflächen zur Geräteverwaltung.

Wo du anfängst

Wenn du keine Private CA hast oder von den alten On-Premises Active Directory Certificate Services (ADCS) wegwillst, ist das ein guter Einstieg in ein Gespräch über SCEPman.

Probier SCEPman selbst aus

Starte eine 30-tägige Testphase und sieh, wie SCEPman Zertifikate einer Private CA für deine Geräte, Benutzer und internen Dienste ausstellt und verwaltet, ohne dass du eine eigene PKI betreiben musst.

SCEPman 30 Tage testen

Häufige Fragen