CA-Rollout: eine neue AD-CS-PKI kontrolliert einführen

Die neue CA soll WLAN, VPN und interne Dienste versorgen

Ein Unternehmen plant zertifikatsbasierte Geräteanmeldung und möchte manuell verteilte Serverzertifikate ablösen. Eine Windows-CA lässt sich schnell installieren. Weniger offensichtlich sind die Entscheidungen, die danach jahrelang wirken: Vertrauensanker, Veröffentlichungsadressen, Schlüsselverwahrung und die Frage, wer bei einem abgelaufenen Zertifikat tatsächlich eingreifen kann.

Dieser Beitrag behandelt den Aufbau und die Einführung einer neuen zweistufigen AD-CS-PKI. Die Härtung vorhandener Templates und CA-Berechtigungen sowie die Umstellung einzelner Anwendungen auf LDAPS sind eigene Arbeitspakete. Hier zählt die Reihenfolge: Infrastruktur vorbereiten, Vertrauen verteilen, Ausstellung begrenzen und erst nach belastbaren Tests erweitern.

Der Projektumfang beginnt mit konkreten Verbrauchern. Für jeden werden Plattform, Zertifikatszweck, verantwortliches Team, Vertrauensspeicher, Erneuerungsweg und tolerierbare Unterbrechung festgehalten. Ohne diese Liste entsteht eine technisch funktionierende CA mit unbekanntem Geschäftsrisiko.

Offline-Root und ausstellende CA haben getrennte Aufgaben

Das Zielbild besteht aus einer eigenständigen, nicht domänengebundenen Root-CA und einer Enterprise Issuing CA auf einem dedizierten Domänenmitgliedsserver, keinem Domain Controller. Die Root bleibt offline und signiert die untergeordnete CA sowie ihre eigene Sperrliste. Endgeräte erhalten ihre Zertifikate von der Issuing CA. Zusätzliche ausstellende CAs brauchen einen begründeten Kapazitäts-, Verfügbarkeits- oder Trennungsbedarf.

Öffentlich abrufbare CA-Zertifikate und Sperrlisten liegen auf gesonderten Veröffentlichungssystemen. Dafür braucht die Offline-Root keine Netzwerkverbindung. Ein dokumentierter Medien- und Freigabeprozess überträgt die signierten Dateien. Private Schlüssel verlassen dabei niemals als Bestandteil der Veröffentlichung die CA.

Zur Abnahme gehören drei Nachweise: vorgesehene Verbraucher akzeptieren die richtige Kette, unberechtigte Geräte erhalten kein Zertifikat und der Betrieb kann Sperrlisten sowie Ausstellung nach einem Ausfall wiederherstellen. Ein grüner Installationsassistent erfüllt keinen dieser Nachweise.

Namen, Laufzeiten und Schlüssel vor der Installation festlegen

CA-Namen und dauerhafte Veröffentlichungsadressen werden vorab freigegeben. Ein stabiler DNS-Alias für die PKI-Veröffentlichung entkoppelt Zertifikate vom späteren Austausch eines Webservers. Root-, Issuing- und Endzertifikatslaufzeiten erhalten einen gemeinsamen Erneuerungskalender. Die verbleibende Gültigkeit der ausstellenden CA begrenzt die maximal mögliche Gültigkeit neu ausgestellter Zertifikate.

Kryptografie und Schlüsselprovider werden anhand der tatsächlich eingesetzten Clients geprüft. Veraltete Algorithmen sind keine Kompatibilitätsstrategie; ebenso wenig hilft eine neue Konfiguration, die eine geschäftskritische Appliance nicht unterstützt. Abweichungen brauchen einen Austauschplan. Ein vorgesehenes HSM wird vor der CA-Installation integriert und einschließlich Wiederherstellung getestet.

Die geprüfte CAPolicy.inf, das Installationsprotokoll und die genehmigten Einstellungen gehören in die Betriebsdokumentation. Die Issuing CA startet ohne ungeprüfte Standardvorlagen; etwa über die dafür vorgesehene Einstellung LoadDefaultTemplates=0. Anschließend werden ausschließlich freigegebene Templates veröffentlicht.

CDP und AIA müssen funktionieren, bevor Zertifikate entstehen

Der CRL Distribution Point (CDP) verweist auf Sperrlisten. Authority Information Access (AIA) liefert hier das Zertifikat des Ausstellers für den Kettenaufbau. Die Root-Konfiguration muss vor Ausstellung des Issuing-CA-Zertifikats stimmen; die Issuing-CA-Konfiguration vor Ausstellung der ersten Endzertifikate. Spätere URL-Änderungen reparieren bereits ausgestellte Zertifikate nicht.

Trennen Sie den Schreibweg der Veröffentlichung vom Leseweg der Clients. Nur berechtigte Prozesse dürfen Dateien ersetzen. Clients benötigen einen zuverlässig erreichbaren Abruf ohne interaktive Anmeldung. HTTP kann für signierte CA-Zertifikate und CRLs sachgerecht sein: Integrität entsteht durch Signaturprüfung, während eine zusätzliche TLS-Abhängigkeit beim Kettenaufbau vermieden wird. Das erlaubt keinen ungeschützten Schreibzugriff.

Prüfen Sie den Abruf aus Clientnetzen, Serversegmenten, VPN und gegebenenfalls DMZ. Eine WLAN-Anmeldung darf nicht davon abhängen, dass der Client erst nach erfolgreicher Anmeldung die Sperrliste erreicht. Veröffentlichungsintervalle, Überlappung und Alarmvorlauf müssen Wiederherstellung und Vertretung ermöglichen. Auch die Offline-Root braucht fristgerecht eine neue CRL; ausgeschaltet bedeutet nicht wartungsfrei.

Vertrauen gezielt verteilen und getrennt prüfen

Das Root-Zertifikat wird nach unabhängigem Fingerabdruckabgleich in die vorgesehenen vertrauenswürdigen Stammspeicher verteilt. Auf Windows-Domänengeräten eignet sich eine eigene, zunächst begrenzte GPO unter Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies. Das Issuing-CA-Zertifikat gehört in den Zwischenzertifikatsspeicher, nicht pauschal zu den vertrauenswürdigen Roots.

Java-Anwendungen, Appliances und andere Plattformen können eigene Truststores verwenden. Ein Import in Windows beweist dort nichts. Prüfen Sie außerdem, welche CA-Zertifikate durch AD-Veröffentlichung bereits verteilt werden. Ein Pilot für Enrollment bedeutet nicht automatisch, dass auch Vertrauen nur im Pilotkreis besteht.

Für spätere AD-Zertifikatsauthentifizierung müssen zusätzlich die dafür erforderlichen Veröffentlichungen und Zuordnungen geprüft werden, insbesondere NTAuth. Ein erfolgreicher TLS-Test bestätigt diese Authentifizierungsvoraussetzungen nicht. Solche Anwendungsfälle erhalten eine eigene Freigabe.

Autoenrollment mit einer kleinen Gerätegruppe beginnen

Der Pilot umfasst wenige repräsentative Systeme und zunächst einen klaren Zertifikatszweck. Duplizieren Sie eine passende Vorlage, begrenzen Sie EKUs und konfigurieren Sie Subject/SAN passend zur Identitätsquelle. Die Pilotgruppe bekommt die benötigten Rechte Read, Enroll und Autoenroll; CA und Anwendung müssen die Konfiguration ebenfalls unterstützen. Eine GPO allein erteilt keine Ausstellungsberechtigung.

Aktivieren Sie Certificate Services Client – Auto-Enrollment in einer separaten GPO im passenden Computer- oder Benutzerkontext. Testen Sie Erstbezug, Erneuerung und tatsächliche Zertifikatsauswahl der Anwendung. Ein neues Zertifikat im Speicher ersetzt nicht zwingend das bisherige Dienst-Binding.

Führen Sie auch einen negativen Berechtigungstest mit einem vorgesehenen Testgerät außerhalb der Pilotgruppe durch. Das Ergebnis muss eine abgelehnte Ausstellung sein. Erst danach werden weitere Verbraucher in nachvollziehbaren Wellen aufgenommen. Enrollment-Webdienste, NDES oder OCSP werden nur ergänzt, wenn ein bestätigter Bedarf besteht.

Sperrung und Ausfälle gehören zur Pilotabnahme

Die folgenden lokalen Anzeigen verändern weder Vertrauen noch CA-Konfiguration. Verwenden Sie exportierte öffentliche Zertifikate und CRLs, keine PFX-Dateien mit privaten Schlüsseln:

certutil.exe -dump '.\pilot-server.cer'
certutil.exe -dump '.\issuing-ca.crl'

Vergleichen Sie Aussteller, Gültigkeit, EKUs, Namen und eingebettete Adressen mit dem Design. Bei der CRL sind insbesondere ThisUpdate und NextUpdate relevant. Diese Anzeige bestätigt weder Erreichbarkeit noch Anwendungsverhalten. Dafür folgen Kettenprüfung, Enterprise PKI (pkiview.msc) und Tests mit den echten Verbrauchern.

Sperren Sie ein ausschließlich dafür ausgestelltes Testzertifikat, veröffentlichen Sie die neue CRL und prüfen Sie die Ablehnung. Dokumentieren Sie Cachezeiten und das Verhalten bei nicht erreichbarer Sperrinformation. Ein weiterhin akzeptiertes Zertifikat ist ein offener Abnahmepunkt. Produktionsweite Cache-Löschungen oder abgeschaltete Sperrprüfung sind keine Reparatur.

Testen Sie außerdem einen ausgefallenen Veröffentlichungsknoten und eine vorübergehend gestoppte Ausstellung im freigegebenen Pilotfenster. Bereits ausgestellte Zertifikate werden durch einen CA-Stopp nicht automatisch ungültig; Erneuerung und rechtzeitige CRL-Veröffentlichung bleiben dennoch erforderlich.

Wiederherstellung vor der breiten Freigabe nachweisen

Der Wiederherstellungssatz enthält CA-Zertifikate und private Schlüssel, Datenbank und Logs, Registry-Konfiguration, CAPolicy.inf sowie die Liste veröffentlichter Templates. Template-Definitionen und ihre Berechtigungen liegen in AD und brauchen einen eigenen Sicherungs- und Rekonstruktionsweg. Bei HSM-Schlüsseln gilt der getestete Herstellerprozess.

Schlüsselmaterial und Zugangsdaten werden getrennt geschützt. Ein Restore wird isoliert durchgeführt, ohne eine zweite aktive Instanz derselben CA in Produktion zu erzeugen. Die Übung muss auch eine neue signierte CRL und den dokumentierten Veröffentlichungsweg nachweisen. Ein vorhandenes Backupfile allein ist keine Abnahme.

Für einen Rollout-Stopp werden weitere Ausstellung und betroffene Richtlinien kontrolliert angehalten. Bereits ausgegebene Zertifikate und bestehendes Vertrauen verschwinden dadurch nicht. Sperrung, Anwendungsrückbau und Entfernung von Vertrauen sind getrennte Entscheidungen. Eine alte PKI bleibt während einer Migration so lange betriebsfähig, wie akzeptierte Zertifikate und Prüfpfade von ihr abhängen.

Vorteile einer kontrollierten Einführung

• Begrenzte Auswirkungen: Ein kleiner Pilot macht fehlerhafte Truststores, Netzpfade und Dienst-Bindings sichtbar, bevor viele Systeme betroffen sind.
• Geschützter Vertrauensanker: Die Offline-Root reduziert die dauerhafte Angriffsfläche des Root-Schlüssels.
• Planbarer Betrieb: Erneuerung, Sperrung und Wiederherstellung bekommen überprüfbare Verantwortlichkeiten.
• Saubere Erweiterung: Neue Verbraucher nutzen freigegebene Abläufe, statt neue manuelle Schlüsselkopien zu erzeugen.

Nachteile und Grenzen der zweistufigen PKI

• Mehr Betriebsaufwand: Root-Zeremonien, Sperrlisten, Backupprüfungen und Dokumentation brauchen Zeit und Vertretung.
• Zusätzliche Kosten: Separate Systeme, geschützte Administration und gegebenenfalls HSMs verursachen laufenden Aufwand.
• Keine automatische Anwendungssicherheit: Manche Verbraucher prüfen Sperrstatus unzureichend oder wählen das falsche Zertifikat.
• Keine Heilung unsicherer Templates: Eine Offline-Root verhindert keine missbräuchliche Ausstellung durch eine kompromittierte Issuing CA. Deren Entzug erfordert wirksame Sperrprüfung und einen vorbereiteten Austausch.

Typische Stolperfallen beim Übergang in den Betrieb

Häufig wird die Pilot-GPO entfernt und damit fälschlich ein vollständiger Rückbau angenommen. Ebenso problematisch sind alte, weiter referenzierte CDP-Adressen, fehlende Besitzer für Java-Truststores und eine Root-CRL, deren Ablauf erst bei Anmeldefehlern auffällt. Monitoring muss deshalb die ausgelieferten Dateien und ihre Restgültigkeit prüfen, nicht nur den laufenden CA-Dienst. Ein erreichbarer Webserver mit veralteter CRL ist weiterhin eine Störung.

Projekt-Checkliste für den CA-Rollout

• [ ] Verbraucher, Truststores, Erneuerungswege und Verantwortliche erfassen.
• [ ] Root, Issuing CA, Schlüsselverwahrung und Wiederherstellungsziel freigeben.
• [ ] Namen, Laufzeiten und CDP/AIA vor der ersten Ausstellung prüfen.
• [ ] Veröffentlichungswege aus allen vorgesehenen Netzen testen.
• [ ] Root-Vertrauen und Zwischenzertifikate kontrolliert verteilen.
• [ ] Templates und Autoenrollment auf den Pilotkreis begrenzen.
• [ ] Erfolgreiche und abgelehnte Ausstellung sowie Dienst-Bindings nachweisen.
• [ ] Erneuerung, Sperrung, Cacheverhalten und Veröffentlichungsausfall testen.
• [ ] Isolierten Restore einschließlich CRL-Erzeugung dokumentieren.
• [ ] Alarmvorlauf, Vertretung, Rollout-Stopp und gegebenenfalls Alt-PKI-Rückbau festlegen.