ADCS vs oeffentliche CA
Zwei Vertrauensräume, eine klare Arbeitsteilung – intern ADCS, extern öffentliche CAADCS vs. öffentliche CAs – wann welche Lösung sinnvoll ist
Faustregel vorab: Sobald du regelmäßig Geräte- oder Nutzerzertifikate brauchst – Computer-Auth, Smartcard-Logon, 802.1X, VPN, S/MIME – baust du eine eigene PKI mit ADCS. Für die Handvoll öffentlich erreichbarer Webserver nimmst du eine öffentliche CA oder Let’s Encrypt. Das ist keine Glaubensfrage, sondern eine Frage des Vertrauensraums: ADCS ist intern unbegrenzt und kostenlos, aber nur in deiner Domäne vertraut. Eine öffentliche CA ist weltweit vertraut, kostet aber pro Zertifikat – und skaliert für interne Massen-Authentifizierung schlicht nicht.
Abb. 1: Zwei getrennte Vertrauensräume – intern (ADCS) und öffentlich (Browser-Trust) lösen unterschiedliche Probleme.
1. Der eine Unterschied, der alles entscheidet: der Vertrauensraum
Die meisten Diskussionen über „eigene CA oder gekauft“ laufen schief, weil sie über Kosten reden. Der eigentliche Punkt ist ein anderer: Wem vertraut das Gerät, das das Zertifikat prüft?
Eine öffentliche CA wie DigiCert, Sectigo oder GlobalSign sitzt in den Trust-Stores praktisch jedes Betriebssystems und Browsers der Welt. Stellst du dort ein TLS-Zertifikat für deine Website aus, vertraut ihm jeder fremde Rechner – ohne dass du irgendetwas verteilen musst. Das ist der ganze Trick, und dafür bezahlst du.
Eine ADCS-CA kennt erst mal niemand. Ihr Root-Zertifikat landet über Active Directory automatisch im Trust-Store jedes Domänenmitglieds – und damit endet der Vertrauensraum auch schon. Ein Privatkunde mit seinem Heim-PC vertraut deiner internen CA nicht, und das soll er auch nicht. Innerhalb deiner Domäne dagegen kannst du beliebig viele Zertifikate ausstellen, ohne dass je eine Rechnung kommt.
|
Info · Merksatz für die Diskussion mit dem Management Öffentliche CA = „Das ganze Internet soll uns vertrauen.“ ADCS = „Unsere eigenen Geräte und Mitarbeiter sollen sich gegenseitig vertrauen.“ Wer beides verwechselt, kauft entweder teure Public-Zertifikate für interne Webserver oder versucht, die eigene CA ins Internet zu prügeln. Beides geht schief. |
|---|
2. Was öffentliche CAs gut können – und was nicht
Öffentliche CAs sind unschlagbar, wenn etwas von außen erreichbar ist und fremde Clients ihm vertrauen müssen: die Firmenwebsite, ein Webshop, eine öffentlich erreichbare API, das Mailgateway mit TLS nach außen. Hier gibt es keine Alternative – eine interne CA hilft dir nicht, wenn der Browser eines Kunden das Zertifikat als „nicht vertrauenswürdig“ anmeckert.
Für interne Massenszenarien werden sie dagegen schnell unwirtschaftlich und unpraktisch. Stell dir vor, du willst 1.500 Notebooks mit Computer-Zertifikaten für 802.1X-WLAN-Authentifizierung versorgen. Bei einer öffentlichen CA müsstest du 1.500 Zertifikate kaufen, jährlich erneuern und manuell oder per Eigenbau verteilen. Mit ADCS klickst du eine Vorlage zusammen, setzt das Auto-Enrollment-Recht und die Geräte holen sich ihre Zertifikate selbst ab. Wie das konkret läuft, zeigt der Spoke „Auto-Enrollment konfigurieren“.
Wo öffentliche CAs zwingend sind
Wo sie nerven
3. Die Entscheidung in einem Diagramm
Die Entscheidung lässt sich auf zwei Fragen eindampfen. Erstens: Brauchst du geräte- oder nutzergebundene Zertifikate? Zweitens: In welcher Größenordnung? Der Rest ergibt sich fast von selbst.
Abb. 2: Entscheidungsbaum – zwei Fragen führen zur richtigen Lösung.
Der spannende Mittelweg ist der Hybrid: eine schlanke interne ADCS-PKI für alles Authentifizierungs-Gedöns, kombiniert mit einer öffentlichen CA oder ACME für die wenigen Public-TLS-Zertifikate. Das ist in der Praxis das mit Abstand häufigste Modell – und kein Widerspruch, sondern die saubere Arbeitsteilung. Mehr dazu in der ehrlichen Entscheidungsmatrix unter „Cloud-PKI vs. On-Prem ADCS“.
4. Kriterienvergleich – die ehrliche Tabelle
Wenn du es jemandem erklären musst, der es schwarz auf weiß will: hier die wichtigsten Kriterien nebeneinander.
|
Kriterium |
ADCS (intern) |
Öffentliche CA |
|---|---|---|
|
Vertrauensraum |
nur eigene Domäne |
weltweit, in jedem Browser |
|
Kosten je Zertifikat |
null (Server-Rolle) |
pro Stück und Jahr |
|
Skalierung |
praktisch unbegrenzt |
kosten-/lizenzgetrieben |
|
Geräte-/Nutzer-Auth |
Kernkompetenz |
kaum praktikabel |
|
Public TLS für Web |
nicht extern vertraut |
Kernkompetenz |
|
Automatisierung |
Auto-Enrollment, NDES/SCEP |
ACME, anbieterspezifisch |
|
Betriebsverantwortung |
liegt bei dir |
liegt beim Anbieter |
|
Audit-Relevanz |
hoch (Tier 0 im AD) |
beim Anbieter |
Abb. 3: Dieselben Kriterien als Skizze – praktisch für Folien und Workshops.
|
Praxis-Tipp · Der unterschätzte Betriebsaufwand Bei „kostenlos“ jubeln alle. Was gerne untergeht: Eine eigene PKI ist ein Tier-0-System wie der Domänencontroller. Die Root-CA, die Issuing-CA, die CRL-Verteilung und das Backup wollen betrieben und überwacht werden. Wer die CA „nebenbei“ mitlaufen lässt, hat in drei Jahren eine abgelaufene CRL und reihenweise tote Zertifikate. Die Lizenz ist gratis – die Sorgfalt nicht. |
|---|
5. Was es wirklich kostet – grob gerechnet
„Kostenlos“ stimmt nur für die Lizenz. ADCS ist eine Rolle im Windows Server, keine eigene SKU – wenn der Server ohnehin da ist, kostet die Rolle nichts extra. Realistisch sind die Kosten:
Bei der öffentlichen CA rechnest du dagegen pro Zertifikat. Solange das eine Handvoll Public-TLS-Zertifikate sind, ist das billiger als eine eigene PKI. Sobald du in den dreistelligen Bereich kommst oder geräte-/nutzergebundene Auth brauchst, dreht sich das Verhältnis – das ist der Kern der Break-Even-Betrachtung im Spoke „Wirtschaftlichkeit einer eigenen PKI“.
|
PowerShell: Schnell prüfen, ob im Bestand schon eine ADCS-CA läuft |
|---|
|
# Findet veröffentlichte Enterprise-CAs im aktuellen AD-Forest # Praktisch fürs erste Inventar vor jeder Architekturentscheidung certutil -config – -ping 2>$null
# Alle in AD registrierten CAs auflisten (Name, DNS, Flags) $root = ([ADSI]"LDAP://RootDSE").configurationNamingContext $caPath = "LDAP://CN=Enrollment Services,CN=Public Key Services," + "CN=Services,$root" Get-ChildItem "AD:\$( ([ADSI]$caPath).distinguishedName )" -EA SilentlyContinue | ForEach-Object { $ca = [ADSI]"LDAP://$($_.distinguishedName)" [PSCustomObject]@{ CAName = $ca.cn.Value DNS = $ca.dNSHostName.Value } } | Format-Table -AutoSize |
Praxis-Beispiel: Trendforge Digital GmbH
Die Trendforge Digital GmbH, ein cloud-affines Tech-Scaleup mit rund 400 Mitarbeitern, kam mit der Ansage „Wir wollen alles über Let’s Encrypt machen, das ist doch kostenlos“. Funktionierte hervorragend für die öffentlichen Web-Dienste – und gar nicht für den eigentlichen Schmerz: 802.1X-WLAN-Authentifizierung und Gerätezertifikate für die Intune-verwalteten Notebooks.
Das Ergebnis war ein sauberer Hybrid: Für die internen Geräte- und Nutzerzertifikate kam eine schlanke zweistufige ADCS-Umgebung, angebunden an Intune über NDES. Die öffentlich erreichbaren Web-Dienste blieben bei ACME/Let’s Encrypt. Kein Entweder-oder, sondern beide Werkzeuge für den jeweils passenden Vertrauensraum. Genau so, wie es der Entscheidungsbaum oben vorzeichnet.
Verwandte Themen
Häufige Fragen (FAQ)
Kann ich mit ADCS auch öffentlich vertraute TLS-Zertifikate ausstellen?
Nein. Eine ADCS-CA ist nur dort vertraut, wo ihr Root-Zertifikat im Trust-Store liegt – also in deiner Domäne. Für öffentlich erreichbare Webserver brauchst du eine öffentliche CA oder Let’s Encrypt. Versuche nicht, dein internes Root in fremde Geräte zu bekommen; das ist weder praktikabel noch erwünscht.
Ab wann lohnt sich eine eigene PKI gegenüber gekauften Zertifikaten?
Die grobe Schwelle: ab etwa 100 Zertifikaten pro Jahr oder sobald du geräte- bzw. nutzergebundene Authentifizierung brauchst. Darunter ist eine öffentliche CA günstiger und einfacher. Darüber spielt ADCS seine Stärken aus: unbegrenzte Ausstellung, Auto-Enrollment, kein Stückpreis.
Ist ADCS wirklich kostenlos?
Die Rolle ja – sie ist Teil von Windows Server und keine separate Lizenz. Nicht kostenlos sind Hardware, optionales HSM, Einrichtung und vor allem der laufende Betrieb. Wer den Betriebsaufwand ignoriert, spart an der falschen Stelle.
Brauche ich beides – ADCS und eine öffentliche CA?
In den meisten Unternehmen ja, und das ist völlig normal. ADCS übernimmt die interne Authentifizierung, die öffentliche CA die nach außen sichtbaren TLS-Zertifikate. Dieses Hybrid-Modell ist der Regelfall, kein Kompromiss.
Kann eine öffentliche CA meine internen Smartcard-Logons abdecken?
Praktisch nicht. Smartcard-Logon, Windows Hello for Business und 802.1X prüfen gegen dein Active Directory, nicht gegen das Internet. Diese Szenarien sind genau das, wofür ADCS gebaut wurde.
Was passiert mit meinen internen Zertifikaten, wenn ich die ADCS-CA abschalte?
Sie werden ungültig, sobald die CA-Vertrauenskette wegfällt oder die CRL nicht mehr veröffentlicht wird – mit teils unangenehmen Folgen für WLAN, VPN und Logon. Eine CA wird nicht „mal eben“ abgeschaltet; eine geordnete Migration oder Außerbetriebnahme will geplant sein.
Nächste Schritte mit boddenberg.de
Wenn du gerade vor genau dieser Entscheidung stehst – eigene PKI, gekaufte Zertifikate oder Hybrid – lohnt sich eine kurze Standortbestimmung, bevor du Geld in die Hand nimmst.
Kontakt: Uli Boddenberg · boddenberg.de · Dortmund