Serie „Migration auf Windows Server 2019“ – Migration der PKI

Zielsetzung

Ist-Situation

Ich betreibe in meiner Windows Server Infrastruktur eine eigene PKI. Diese wird durch den Server WS-CA1 bereitgestellt und läuft aktuell auf einem Windows Server 2016 Server Core. Es handelt sich dabei um eine Active Directory integrierte Root-Zertifizierungsstelle. Damals hatte ich keine Anforderung für eine mehrstufige PKI mit Offline-Root-CA.

Verschiedene Zertifikatvorlagen werden von meinen Systemen bei der automatischen Ausstellung von Zertifikaten genutzt. Die Zertifikate werden dabei nicht traditionell, sondern über CEP-CES ausgestellt (Certificate Enrollment Policy Service & Certificate Enrollment Web Service). Diese beiden zusätzlichen Services auf meiner Zertifizierungsstelle ermöglichen die Anfrage und die Ausstellung von Zertifikaten über HTTPS statt RPC-DCOM, was eine Platzierung der Zertifizierungsstelle hinter einer Firewall deutlich vereinfacht.

Das Zertifizierungsstellen-Zertifikat läuft in den nächsten 12 Monaten aus.

Soll-Situation

Ich habe verschiedene Anforderungen für die Migration definiert:

  • Das Betriebssystem soll auf Windows Server 2019 umgestellt werden.
  • CEP-CES soll weiter genutzt werden.
  • Zusätzlich soll ein Online Responder eine Echtzeitsperrprüfung ermöglichen.
  • Das Sperrsystem soll später auch über das Internet erreichbar sein.
  • Sperrlisten sollen nicht mehr über LDAP oder http erreichbar sein. Ich möchte nur noch über OCSP (Online Responder) verwenden.
  • Eine Bereinigung der bisher ausgestellten Zertifikate ist durchaus sinnvoll.
  • Das Zertifizierungsstellen-Zertifikat muss erneuert werden. Dabei können auch die neuen Certificate Revocation List Distribution Points veröffentlicht werden, denn diese werden in alle neuen Zertifikate integriert.
  • Der Server Core hat mir mehr Probleme verursacht als Nutzen gebracht. Daher soll der neue Server mit der grafischen Oberfläche bereitgestellt werden.

Das wird mein Ziel-System:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Migrationsszenario

Durch die Besonderheit des erforderlichen neuen Zertifizierungsstellen-Zertifikats muss die Migration über mehrere Schritte geführt werden:

  • Cleanup: Zuerst werde ich die Bereinigung und die Erneuerung des Zertifizierungsstellen-Zertifikats auf der alten Windows CA durchführen.
  • Migration: Dann werde ich mittels Wipe & Load den Service auf das neue Betriebssystem verschieben. So kann ich den Namen des Betriebssystems weiterführen und die IPv4-Adresse wiederverwenden und erspare mir verschiedene Anpassungen in Richtlinien und Firewall-Regeln.
  • Erweiterung: Zuletzt erweitere ich die PKI mit einem Online Responder.

Generell kann man an dieser Stelle auch über eine parallele, neue Zertifizierungsstelle sinnieren. Diese könnte frisch aufgesetzt und nach Wunsch konfiguriert zuerst ausgiebig getestet werden. Anschließend könnte man alle bisher ausgestellten und noch gültigen Zertifikate auf allen Systemen mit der neuen CA erneut ausstellen. Wenn keine Zertifikate der alten CA mehr in Verwendung sind, dann könnte diese einfach abgeschaltet werden. Durch das bereits ablaufende Zertifizierungsstellen-Zertifikat ist die Restlaufzeit einiger ausgestellter Zertifikate bereits reduziert (Eine Zertifizierungsstelle kann keine Zertifikate über ihre eigene Gültigkeit hinaus signieren). Die vielen Windows Systeme könnten bequem durch Gruppenrichtlinien automatisiert migriert werden. Aber in meinem Fall sind auch fast alle Nicht-Windows-Systeme mit Zertifikaten versorgt: Das sind z.B. alle Netzwerkgeräte. Und da würde mir eine Umstellung der Zertifikate mehr Arbeit bereiten als eine Bereinigung und Migration der alten CA.

Daher bleibe ich beim Wipe & Load.

Vorbereitung

Berechtigungen

Für den Zugriff auf meine PKI bzw. den Review sind mehrere Gruppenmitgliedschaften erforderlich. Diese delegiere ich mit meinem PAM-Script für 24 Stunden an meine Admin-Kennung:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die Gruppe „GG-Admin-PKI“ ist in eine Gruppe „LD-Admin-PKI“ verschachtelt, welcher ich die administrativen Rechte in meiner PKI delegiert habe.

Review

So ausgestattet verbinde ich mich mit meiner Admin-Kennung auf meinen Admin-Server. Dort hatte ich mir eine Management-Konsole für den Remotezugriff auf die PKI-Services erstellt – der Server WS-CA hat ja als Server Core keine grafische Oberfläche.

Beginnen wir mit den Zertifikatvorlagen. Ich denke, die Namensgebung sagt genug aus:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Das Zertifizierungsstellen-Zertifikat wurde bereits einmal erneuert. Das aktuelle ist jetzt weniger als 12 Monate gültig:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Zertifikate müssen auch gesperrt werden können, wenn sie z.B. kompromittiert wurden. Dafür müssen aber im Vorfeld Sperrlistenverteilungspunkte definiert werden. Ich habe damals den Webserver, der auf der Windows CA für CEPCES erforderlich ist, auch für die Veröffentlichung der CRL (Certificate Revocation List) verwendet. Den Zugriff auf die Web-Ressource hatte ich an einen CNAME crl.ws.its gebunden. So hätte ich jederzeit eine Verschiebung auf einen anderen Webserver vornehmen können. Zusätzlich habe ich im Active Directory die Sperrliste veröffentlicht:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Der Pfad c:\admin… in den Verteilungspunkten ist das Backend-Verzeichnis des lokalen Webservers. Hier legt die CA die Sperrliste ab. Über den mittleren Eintrag wird dann der Zugriff über http definiert.

In den Stelleninformationen schaut es weniger angepasst aus. Diese arbeiten mit den Default-Settings:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ein wichtiger Punkt bei der Planung der Migration ist das Vorhandensein von archivierten, privaten Schlüsseln. Diese können Teil eines Recovery-Szenarios sein und machen immer dann Sinn, wenn Benutzer die ausgestellten Zertifikate für Datenverschlüsselungen verwenden (können). Verliert der Benutzer nach einer Verschlüsselung sein Zertifikat mit dem Private Key, dann kann er seine Daten selber nicht mehr entschlüsseln! In meiner CA habe ich darauf geachtet, dass die ausgestellten Zertifikat-Vorlagen keine Verschlüsselung ermöglichen. Daher hatte ich für die Archivierung auch keine Notwendigkeit:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Hinweis: Wenn die alte CA über archivierte Schlüssel verfügt, dann ist eine Side-by-Side-Migration – also der Aufbau einer neuen CA und das Ablösen der alten CA – wesentlich schwieriger. Denn selbst wenn alle Benutzer neue Zertifikate erhalten haben und diese für Verschlüsselungen verwenden können: Es kann immer noch Daten geben, die mit den alten Zertifikaten verschlüsselt wurden. Und für eine Entschlüsselung benötigen die Benutzer demnach auch die alten Zertifikate!

Mit PKIVIEW prüfe ich den Zustand der Verteilungspunkte. Hier ist alles ok:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Das Verzeichnis c:\admin… enthält die Sperrlisten-Dateien:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Der Server wird als VM auf einem meiner Hyper-V-Server ausgeführt. Die Systemanforderungen sind überschaubar:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die System-Festplatte ist recht klein geblieben:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Es gibt keine geplanten Aufgaben.

Aufbau der neuen VM (mit Windows Update Problem)

Auf meinem Hyper-V-Server ist noch ausreichend Platz für die neue VM:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ich kopiere mir ein Basefile mit Windows Server 2019 in das alte Verzeichnis:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Dann erstelle ich eine neue VM mit dem gleichen Bezeichner im gleichen Verzeichnis:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Damit ich nicht durcheinanderkomme, benenne ich den neuen Server um:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Jetzt passe ich noch einige Eigenschaften an und integriere die eben kopierte VHDX:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nach dem Anpassen der Startreihenfolge kann es losgehen. Aber das System startet nicht:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ich hatte versehentlich die alte VHDX mit dem Windows Server 2016 zugewiesen. Aber die wird ja vom alten Server verwendet. Also passe ich den Pfad an:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Jetzt startet das System. Weiter geht es im Out-Of-Box-Experience-Mode:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Den neuen Server klemme ich fix ins Client-VLAN:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Hier kann er nach Updates im Internet suchen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Danach wird der Neustart erforderlich:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ich bin aber etwas irritiert: Das Betriebssystem hatte ich aus einer VHDX-Datei mit dem Patchlevel 2020-05 erzeugt. Hier müssten wesentlich mehr Updates installiert werden! Ich passe den Pfad der Windows Updates an. So kann der Standalone-Server mit meinem WSUS kommunizieren:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Dann starte ich die Suche gegen meinen WSUS. Im Resmon sieht man, dass er mit dem WSUS kommuniziert:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Aber auch hier gibt es keine Updates!

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Dann schauen wir mal etwas genauer hin. Die Versionsnummer kann mit winver.exe ermittelt werden:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Mit dieser Info suche ich im Netz nach dem Patch-Level. Es ist wie erwartet 2020-05:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Offensichtlich stimmt hier was nicht! Vielleicht fehlen Voraussetzungen für die aktuelleren Updates. Vielleicht ist der Cache auf dem Server beschädigt. Aber da habe ich bei einem neuen Server keine Lust. Ich installiere lieber neu, denn der neue Server soll ja auch einige Jahre problemfrei laufen!

Verlasst euch bitte nicht auf den Update-Dialog. Der kann trügerisch sein!

Aufbau der neuen VM (Neuinstallation)

Microsoft stellt in unregelmäßigen Abständen neue ISOs mit integrierten Updates bereit. Ich lade das aktuellste mit dem Patchlevel 2020-11 herunter und kopiere es auf meinen Hyper-V-Server:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die defekte VHDX entferne ich:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Dann erstelle ich eine leere VHDX:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Mit dem ISO und der leeren Festplatte wird die Installation gestartet:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nach dem Start des neuen Windows Servers suche ich nach Updates. Das sieht viel besser aus:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

So macht nun auch eine Aktivierung Sinn:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Damit ist der neue Server vorbereitet.

CleanUp PKI

Weiter geht es mit dem Aufräumen in der alten CA. Die grafische Oberfläche bietet hier nur begrenzte Möglichkeiten. Und mit dem Befehl certutil.exe ist das Arbeiten auch nicht immer einfach. Daher hatte ich mir vor einigen Monaten einige PowerShell-Funktionen erstellt. Diese möchte ich heute verwenden:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Aktuell sind 478 abgelaufene Zertifikate in der Datenbank der alten CA. Mit meinen PowerShell-Funktionen ist diese Ermittlung echt einfach:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die Ausgabe kann auch in ein Gridview-Steuerelement umgelenkt werden. So kann ich also einfach und gezielt nach Zertifikaten suchen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Meine Funktionen sind Pipeline-fähig. So kann ich mir das Ergebnis einer Suche nicht nur ansehen, sondern auch weiterverarbeiten. Hier suche und lösche ich abgelaufene Zertifikate in einer Zeile:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Dabei werden die Zertifikate nacheinander durch certutil-Aufrufe gelöscht. Das kann etwas dauern.

Weiter geht es mit ausstehenden Anfragen, die nie abgeschlossen wurden. Das sind nicht so viele:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Aber auch diese benötige ich nicht länger:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Es wird Zeit für einen Blick in die grafische Oberfläche. Hier stehen noch etliche fehlgeschlagenen Requests:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Aber auch diese kann ich mit der PowerShell-Funktion suchen und löschen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Anpassungen an der PKI

Weiter geht es mit Anpassungen an der PKI. Ab jetzt soll die alte CA keine Zertifikate mehr ausstellen. Damit beginnt also ein Wartungszeitfenster.

Ich entferne die auszustellenden Vorlagen. Die Vorlagen sind nur Verknüpfungen. Die Definitionen bleiben erhalten und ich kann die Vorlagen jederzeit wieder hinzufügen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Wenn keine auszustellenden Vorlagen mehr vorhanden sind, dann werden neue Requests abgelehnt. So kann ich nun die Anpassungen eintragen. Ich beginne mit den Sperrlisten-Verteilungspunkten. Zukünftig sollen Sperrlisten nicht mehr über LDAP verteilt werden. Ich kann aber nicht einfach den Record löschen, denn hier hängt nicht nur die Veröffentlichung in den ausgestellten Zertifikaten dran, sondern auch die Veröffentlichung der Sperrlisten selber. In bisher ausgestellten Zertifikaten steht also drin, dass das vorliegende Zertifikat über eine Sperrliste aus dem Active Directory geprüft werden kann:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Wenn ich nun den LDAP-Record komplett entferne, dann wird dieser Eintrag in neuen Zertifikaten nicht mehr vorhanden sein. Gleichzeitig wird die CA aber auch keine aktuellen Sperrlisten im AD veröffentlichen und alte Zertifikate sind nicht mehr komplett verifizierbar! Das kann ich so also nicht gebrauchen. Daher entferne ich nur die Haken für die Integration in neue Zertifikate. Die Veröffentlichung der Sperrlisten im Hintergrund läuft einfach weiter:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Spätestens zum Ablauf des alten Zertifizierungsstellen-Zertifikates Ende 2021 sind alle alten Zertifikate abgelaufen und durch neue ersetzt. Dann kann ich den LDAP-Record gefahrlos entfernen.

Ich möchte auch keinen Download der Sperrliste über http ermöglichen. So bleibt später nur noch der neue Online Responder, mit dem ich eine Echtzeit-Sperrprüfung erzwingen kann:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Auch in den Stelleninformationen muss ich aufräumen. Die Defaults enthalten einen File-Record. Den brauche ich nicht:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Auch soll es keinen Hinweis in den Zertifikaten mehr geben, dass das Zertifizierungsstellen-Zertifikat im Active Directory gefunden werden kann. Das sind alles Grundvoraussetzungen für eine saubere Veröffentlichung von internen Zertifikaten ins Internet:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Also fliegt auch dieser Haken raus:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Diesen Default-Record benötige ich ebenfalls nicht:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Und dieser Default ist auf den FQDN der CA ausgelegt. Damit wird also immer der interne Name der CA in den Zertifikaten veröffentlicht:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Also raus mit dem Record:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Als Ersatz trage ich nun einen neuen http-Record ein. Hier verwende ich einen neuen CNAME, den ich später auch aus dem Internet heraus erreichbar machen kann:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Und ebenso registriere ich hier einen neuen Record für meinen noch nicht vorhandenen Online Responder:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nach den Anpassungen muss der CA-Service neugestartet werden:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Bevor ich hier was testen kann muss ich den neuen Namen ca.ws-its.de über DNS auflösbar gestalten. Da es aktuell noch keinen Grund für eine Veröffentlichung im Internet gibt, erstelle ich eine interne DNS-Zone mit dem Namen des CNAMEs:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

In der neuen DNS-Zone erstelle ich nun einen Host-A-Record:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Wichtig ist, dass der neue Record keinen Namen hat. So lenke ich Clients auf die interne IPv4:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ein Test von einem Client zeigt den Erfolg:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Backup PKI

Die Migration des Services wird durch ein simples Backup & Restore erreicht. Also sichere ich jetzt auf dem alten Server alle Bestandteile. Die Konfiguration des Services liegt in der Registry. Diese exportiere ich in eine Datei:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die eigentliche Datenbank und die Zertifikate kann ich mit certutil sichern:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die lokal erstellten Sicherungsdateien kopiere ich auf mein AdminShare:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Jetzt kann die Migration starten.

Migration

Austausch des Servers

Eine Maintenance für den Service brauche ich nicht einrichten, denn automatische Zertifikatanforderungen werden alle 8 Stunden auf den Clients getriggert. Sollte mal ein Request nicht beantwortet werden, dann kommt der Client eben später wieder.

Weiter geht es also mit dem Abschalten der alten Windows Server 2016 Maschine:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Damit ich die Identität des Computerkontos übertragen kann, setze ich im Active Directory das Konto zurück:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Auf dem neuen Server ändere ich den Computernamen, ohne die Domain zu betreten:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ebenso passe ich die Netzwerkkonfiguration an und trage die alte IPv4 ein. Der Server ist jetzt im Server-VLAN:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nach einem Neustart nehme ich den Server in die Domain auf:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Damit ist das Betriebssystem ausgetauscht.

Rolleninstallation

Jetzt installiere ich die erforderlichen Rollen und Features:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

In den Details der Rolle „Active Directory Zertifikatdienste“ wähle ich zusätzlich noch den Online Responder und CEP-CES aus. Der Zertifikatregistrierungsrichtlinien-Webdienst ist CEP, der Zertifikatregistrierungs-Webdienst ist CES:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Der Rest passt:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Problem mit 802.1x

Meine eigenen Migrationen führe ich in meiner Freizeit aus. Da kann es schon einmal vorkommen, dass ich nicht am Stück arbeiten kann, auch wenn es beim Lesen meiner WSHowTo`s vielleicht so scheinen mag. So ist es auch bei dieser Migration. Zwischen den bisherigen Arbeitsschritten und jetzt sind leider einige Tage vergangen. In dieser Zeit war die alte Windows CA nicht mehr erreichbar und der neue Server führt den Service noch nicht aus. Ich dachte mir, das wird schon kein Problem sein und im Vorfeld habe ich natürlich auch nach demnächst ablaufenden Zertifikaten Ausschau gehalten. Da gab es aber keine. Leider hatte ich aber eine andere Abhängigkeit vergessen: Meinen Netzwerkschutz mit 802.1x…

Mein WLAN-Segment für meine internen Clients ist mit einer zertifikatbasierten Authentifizierung konfiguriert. Ein Client, der sich am WLAN-Accesspoint anmelden möchte, muss also ein gültiges Clientzertifikat verwenden. Der Accesspoint leitet diese Information weiter an meinen WS-NPS1 – das ist ein Radiusserver. Und dieser Server beweist seine Identität ebenfalls mit einem Serverzertifikat.

Der NPS (Network Policy Server) prüft die Identität des Clients anhand der Gültigkeit des Client-Zertifikates. Dabei verwendet er auch eine Sperrprüfung. Nur in meinem aktuellen Fall ist die Gültigkeit der auf dem NPS zwischengespeicherten Sperrliste abgelaufen, da die für die Erneuerung zuständige Zertifizierungsstelle offline ist. Daher verweigert der NPS alle Anfragen für eine WLAN-Anmeldung. Das wäre bei einer zügigen Bereitstellung der neuen CA nicht passiert.

Für meinen Fall ist es einfach: Ich ignoriere das WLAN-Problem, da es nur einen betroffenen Client gibt (mein Notebook ist meist verkabelt ans Netzwerk angeschlossen). In der realen Welt wäre jetzt eine Verlängerung der Sperrliste mit manueller Veröffentlichung sinnvoll.

Es geht also weiter mit dem Austausch.

Migration der ADCS

Nun starte ich das Post-Deployment der ADCS:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Wichtig ist hier, dass die AD-Integration nur von einem Enterprise-Administrator vorgenommen werden kann:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Mein Admin stephan-t1 ist aber nur Memberserver-Admin. Also bereite ich meine T3-Kennung vor:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Anschließend wechsle ich den Sicherheits-Kontext:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ich installiere nur die Rolle ADCS:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Der neue Server soll eine Enterprise Root-CA werden – so wie vorher:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Aber anders als bei einer Neuinstallation muss ich hier die Zertifikate des alten Servers verwenden. Diese definieren die Identität:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die Zertifikate wurden durch das Backup mit Certutil in PFX-Dateien exportiert. Ich muss aber nur noch das aktuell gültige auswählen und importieren:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die Pfade belasse ich im Default:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Das sieht gut aus. Der alte Name der CA wurde über das alte Zertifikat gefunden:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Das hat funktioniert:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Bei Neuinstallationen werden ohne weitere Anpassungen die Standardvorlagen aktiviert. Da ich aber eine Migration ausführe und die Vorlagen vorab auf der alten Maschine entfernt hatte und die Identität wiederverwende, ist die Liste der auszustellenden Vorlagen leer. So werden dann keine Zertifikate versehentlich ausgestellt:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die Datenbank der Windows CA wurde neu erstellt. Deshalb gibt es noch keine aktiven Zertifikate:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nun deaktiviere ich den Service für die Wiederherstellung:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die auf dem alten Server angepasste Konfiguration importiere ich nun auf dem neuen Server:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die gesicherte Datenbank spiele ich mit certutil ein:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Jetzt kann der Services wieder starten:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Durch die Wiederherstellung wurde die leere Datenbank durch die alte DB ausgetauscht. Somit sind auch wieder alle alten Zertifikate im Bestand enthalten:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die auszustellenden Vorlagen werden über ein Attribut im Active Directory zugewiesen. Die Wiederherstellung ist aber eine rein lokale Angelegenheit. Daher ist der Speicher der auszustellenden Vorlagen immer noch leer:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Anpassung und Überarbeitung der Sperrlistenverteilung

Nun kommen wir zu den Nacharbeiten und dem Feintuning. Für die Sperrlistenveröffentlichung habe ich in der Konfiguration ein lokales Verzeichnis angegeben. Dieses muss ich noch erstellen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Der Verteilungspunkt LDAP ist weiter mit dabei, denn die bisher ausgestellten Zertifikate haben einen Verweis auf das LDAP. Nur neue Zertifikate werden nicht mehr über LDAP verifizierbar sein: Die Option „In CDP-Erweiterung des ausgestellten Zertifikates Einbeziehen“ ist nicht mehr aktiv.

Dennoch habe ich mit meinem 802.1x-Problem während der Downtime der CA festgestellt, dass ich auf eine Sperrlistenprüfung angewiesen bin. Bis hier wollte ich diese Funktion nur noch über OCSP bereitstellen. NPS wäre dazu auch in der Lage. Aber der OSCP-Server muss dafür immer online sein, denn der NPS wird die Antworten nicht cachen. In meinem Fall ist der OCSP-Service aber nicht hochverfügbar. Ein Ausfall würde also WLAN-Anmeldungen verhindern. Ich möchte jetzt aber keinen zweiten Server aufbauen. Also werde ich einen Sperrlistenverteilungspunkt über http erstellen. Dort kann sich mein NPS-Server die Sperrliste herunterladen, zwischenspeichern und somit WLAN-Zugriffsanfragen auf bei ausgefallener CA validieren. Den Verteilungspunkt lenke ich auf einen „öffentlichen FQDN“:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die Optionen verankern den Verteilungspunkt in den neu ausgestellten Zertifikaten:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die neue URL ca.ws-its.de soll auf meiner Windows CA aufsetzen. Daher erstelle ich im IIS-Manager ein neues virtuelles Verzeichnis „certs“ für die AIA-Stelleninformationen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Dieses lasse ich auf den lokalen Speicherpfad zeigen, in dem meine CA ihre Sperrlistendateien und die Zertifikate bei der Veröffentlichung ablegt:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ein weiteres virtuelles Verzeichnis „crl“ wird für die Sperrlistenveröffentlichung über http://ca.ws-its.de/crl benötigt:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Auch dieses Verzeichnis zeigt auf den lokalen Ordner c:\admin\pki:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ich aktiviere das Directory Browsing, damit ich den Inhalt des Verzeichnisses direkt im Browser ansehen kann:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Da der FQDN in meinem DNS-Server bereits erstellt wurde und auf die interne IPv4 meiner Windows CA zeigt, kann ich das Verzeichnis einfach im Browser aufrufen und testen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Grundkonfiguration und Ausstellung eines neuen Zertifizierungsstellen-Zertifikates

Es wird Zeit für ein neues Zertifizierungsstellen-Zertifikat, denn das bisherige läuft bald ab:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Der Vorgang kann einfach weil grafisch durchgeführt werden:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ich erstelle dabei gleich ein neues Schlüsselpaar:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nach Abschluss ist das neue Zertifikat im Speicher sichtbar. 2025 ist für eine interne Windows CA nicht viel, aber ich bin damit zufrieden.

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Das Zertifikat hat einen neuen öffentlichen Schlüssel. Diesen exportiere ich in eine Datei:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Diese Datei lege ich im AIA-Verzeichnis ab, denn hier könnte ein Client danach suchen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Achtung: Die Dateiendung wurde nicht korrekt erstellt und muss korrigiert werden:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nun erstelle ich eine neue Sperrliste für die beiden gültigen Zertifizierungsstellen-Zertifikate:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

OK, das scheint noch nicht zu funktionieren. Im Active Directory gab es keine Veröffentlichung:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Im Dateisystem dagegen ist die neue Sperrliste erstellt worden:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Also ist es ein reiner Fehler im Active Directory…

TroubleShooting – Korrektur des LDAP-Sperrlistenverteilungspunktes

Im Active Directory veröffentlicht meine Windows Zertifizierungsstelle in der Konfigurationspartition ihre Sperrlisten. Hier finde ich 2 Sperrlisten – je eine pro altes Zertifizierungsstellen-Zertifikat. Aber für das neue Zertifikat fehlt der Eintrag! Stimmen hier vielleicht die Berechtigungen nicht?

Die Berechtigung für das Bearbeiten der beiden alten Sperrlisten ist an den Computer-Account gebunden:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Aber auf dem darüberliegenden Container „CN=WS-CA1“ fehlt die Berechtigung! Normal wird der Record einer neuen Sperrliste durch den Benutzer-Account des Administrators automatisch erzeugt und dann wird das Recht automatisch an den Computer-Account delegiert. Aber meine Admin-Kennung ist kein Mitglied der Gruppe Enterprise-Admins, wie es eigentlich üblich ist. Daher wurde der Record nicht erstellt und die Windows CA kann ihn danach auch nicht aktualisieren.

Der Versuch, die Berechtigung auf dem Container direkt an die Windows CA bzw. an den Computer-Account zu delegieren wird nicht ausreichen. Aber dennoch wage ich einen Versuch und nehme den Computer-Account in die ACL auf:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Denn hier kann ich auch das Recht auf untergeordnete Objekte delegieren:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nun muss ich nur noch ein cRLDistributionPoint-Object erzeugen – das würde ein Admin mit Enterprise-Permission automatisch bei Ausstellen eines neuen Zertifizierungsstellen-Zertifikates in der Windows CA mit erledigen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Der Datentyp ist leicht zu finden:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Der Name des neuen CRL-Objektes muss sich an dem Schema der Benennung orientieren. Das neue Zertifizierungsstellen-Zertifikat hat den Zähler (2). Der muss hier mit aufgenommen werden:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ein Blick in die ACL der neuen CRL zeigt, dass meine Windows CA nicht berechtigt wurde. Egal, dann füge ich den erforderlichen Eintrag manuell ein:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nun starte ich auf meinem CA-Server die CRL-Generierung erneut – das geht auch über die cmd. Und jetzt ist der Vorgang erfolgreich:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Fortsetzung der Grundkonfiguration

Jede Anpassung an den Zertifizierungsstellen-Zertifikaten, den AIA-Positionen oder den Sperrlisten sollte mit PKIVIEW kontrolliert werden. Ich starte die msc. Das Ergebnis überrascht mich nicht. Es gibt noch Korrekturbedarf bei der Deltasperrliste und OCSP ist noch nicht installiert:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die Deltasperrliste enthält ein plus-Zeichen. Dieses Sonderzeichen ist in einer URL nicht gerne gesehen. Ein IIS kann das nur mit dem sogenannten „Double-Escaping“. Das Feature muss manuell im IIS-Manager aktiviert werden:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nach einer PKIVIEW-Aktualisierung ist die Deltasperrliste erreichbar:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nun schließe ich noch einige andere Konfigurationen ab. Dazu gehört die Aktivierung des Loggings. Eine erforderliche Voraussetzung ist die Aktivierung und die Konfiguration des Advanced Audits. Diese habe ich global über Gruppenrichtlinien bereits abgeschlossen. So fehlen nur noch einige Haken in den Properties meiner neuen CA:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Damit ist die Grundkonfiguration abgeschlossen.

Bereitstellung des Online Responders

Weiter geht es mit den Zusatzdiensten. Der Online Responder ist eine Web-Anwendung, mit der ein Client ein einzelnes Zertifikat durch seine Seriennummer auf eine Sperrung überprüfen kann, ohne dabei selbst die komplette Sperrliste herunterladen und durchsuchen zu müssen. Ohne den Download der Sperrliste umgehe ich das Abwarten der Cache-Dauer der Sperrliste im Falle einer Zertifikatsperrung. Oder kurz gesagt: Jeder Client kann Zertifikate live und in „Echtzeit“ auf Sperrung validieren lassen.

Der Online Responder muss seine Antworten digital signieren, damit der Client ihm vertraut. Dafür benötige ich eine spezielle Zertifikatvorlage. Diese erstelle ich in meiner Zertifizierungsstelle:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ich kopiere das Original:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Oder auch nicht. Denn auch hierfür sind Enterprise-Adminrechte erforderlich…

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Das hatte ich für meine PKI nie angepasst. Aber heute ist dafür der richtige Zeitpunkt. Ich wechsle auf meinen Domain Controller mit meiner T0-Kennung. Diese nehme ich zuvor in die Gruppe Enterprise-Admins auf. Im ADSIEdit navigiere ich zum Container, in dem die Templates liegen. Hier editiere ich die ACL und nehme meine eigene Gruppe LD-Admin-PKI mit Schreibrechten auf:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die Aktion wiederhole ich auf dem dazugehörigen Container OID:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Anschließend dupliziere ich erfolgreich die Vorlage in meiner Zertifizierungsstelle. Nun kann ich noch einige Parameter anpassen. Dazu gehört die Kompatibilitätsebene:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Auch der Name darf sich in mein Namensschema einfügen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die Kryptografie passt für den Anwendungsfall:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Das Recht zur Editierung passe ich in der Sicherheit an. Hier kommt meine Admin-Gruppe wieder dazu:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Der Online Responder wird in einem Sicherheitskontext ausgeführt. Die dazugehörige Identität muss in der Lage sein, Zertifikate auf Basis der neuen Vorlage zu ziehen. Mein Online Responder wird im System-Kontext der Windows CA laufen. Also berechtige ich den Computer-Account für ein Enrollment:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Damit ist die Vorlage fertig. Nun nehme ich die Vorlage in die auszustellenden Vorlagen auf. Erst danach können passende Zertifikate angefragt werden:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Eventuell wird die Vorlage nicht sofort angezeigt. Dann muss noch eine Domain Controller Replikation abgewartet werden. Bei mir hat der zeitliche Versatz ausgereicht:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Weiter geht es mit dem Einrichten der Rolle. Die Rolleninstallation ist bereits abgeschlossen. Es fehlt noch das Post-Deployment. Dieses kann im Server Manager gestartet werden:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Der Online Responder benötigt nur lokal administrative Rechte. Meine T1-Kennung ist Mitglied in den lokalen Admins:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ich aktiviere nur den Online Responder. Die anderen Rollen kommen später dran:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Mehr ist hier nicht erforderlich:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Der Online Responder hat eine eigene Management-Konsole. Hier muss ich nun noch die Sperrlisten zuweisen, die er bedienen soll:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Jede Sperrliste wird durch einen Namen gekennzeichnet. Ich nehme hier den Namen meiner Zertifizierungsstelle:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Im nächsten Schritt wird die dazugehörige Zertifizierungsstelle gesucht. Ich kann das durch meine AD-Integration einfach halten:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Der Auswahldialog zeigt meine interne Windows CA:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Für diese CA und ihre Sperrliste muss ein Signaturzertifikat gewählt werden. Dieses wird sich mein Online Responder auf der neuen Zertifikatvorlage basierend automatisch ausstellen. Die Vorlage wurde bereits automatisch gefunden und zugewiesen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nach einem Kontakt zur Zertifizierungsstelle werden die möglichen Sperrlistenverteilungspunkte gelistet und zur Auswahl angeboten. Der Online Responder lädt sich die Listen selber herunter und prüft damit die Anfragen der Clients. Bei mir ist nur noch der neue Verteilungspunkt über http sichtbar. Das soll genügen. Aber die Aktualisisierungsfrequenz darf gerne wesentlich kleiner sein als als der Wert, der auf den Sperrlisten steht. So erhalte ich ein „Echtzeit-Sperrverhalten“:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nach der Bestätigung organisiert sich der Online Responder ein OSCP-Signaturzertifikat und meldet seine Einsatzbereitschaft:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ein abschließender Blick im PKIVIEW zeigt nun alle Services fehlerfrei an:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Einen realen Testlauf werde ich später ausführen.

Bereitstellung von CEPCES

Vorher möchte ich einen weiteren Service integrieren: CEPCES. Die Idee dahinter habe ich bereits in der Zielsetzung erklärt.

Für die Anfrage und die Ausstellung von Zertifikaten über https benötigt mein CEPCES ein Webserver-Zertifikat. Das alte Zertifikat habe ich im PKCS12-Format mit privatem Schlüssel auf meinem AdminShare liegen. Ich importiere das Zertifikat auf meinen neuen WS-CA1:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Das Zertifikat binde ich nun im IIS-Manager an den Port 443 meiner Default Website:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Danach starte ich das Post-Deployment der Rolle im Server Manager. Die Rolleninstallation hatte ich ja bereits ausgeführt:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

CEPCES wird im Active Directory in der Konfigurationspartition als Endpunkt registriert. Das kann nur ein Enterprise-Admin durchführen. Daher privilegiere ich meine T3-Kennung und wechsle den Sicherheitskontext im Assistenten:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die Privilegierung übernimmt mein PAM-Script:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

CEP und CES gehören hier zusammen. Daher starte ich das Post-Deployment gemeinsam:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Zuerst ist CES an der Reihe. CES muss mit einer Windows Zertifizierungsstelle „verheiratet“ werden. Wird CES auf einem Zertifizierungsstellen-Server installiert, dann muss dieser gewählt werden. Ich hab es einfach, denn es gibt nur eine Windows CA:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Clients und Benutzer sollen sich mit Kerberos am Webservice vom CES anmelden. So gibt’s Sicherheit und Single-Sign-On:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

CES selber läuft im einfachen Sicherheitskontext des Application Pools im IIS. Damit spare ich mir einige Anpassungen rund um das Thema SPN:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Mehr braucht mein CES nicht. Nahtlos geht es mit CEP weiter. Hier muss ich die gleiche Authentifizierung wie beim CES wählen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Dann ist alles angegeben. Der Assistent richtet beide Webservices ein:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ich hatte bereits vorher einen CEPCES im Einsatz. Daher muss ich meine Clients und Benutzer nicht mehr neu informieren. Die bestehende Gruppenrichtlinie passt unverändert:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

CEPCES benötigt aber noch einige Anpassungen im IIS, die nicht vom Post-Deployment vorgenommen werden. Also geht es in den IIS in die Webanwendung vom CEP. Hier brauche ich die Anwendungseinstellungen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Das Feld Friendly Name darf nicht leer sein. Das ist aber leider der Default. Damit meine Gruppenrichtlinie weiter passt, trage ich den gleichen Text ein, den auch meine vorherige Zertifizierungsstelle verwendete:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Damit ist der CEPCES einsatzbereit.

Testphase

Bevor ich den Service testen kann, muss ich meiner Windows Zertifizierungsstelle noch weitere Zertifikatvorlagen zuweisen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Für einen Testlauf nehme ich nur meine Webserver-Vorlage dazu. Diese kann kein AutoEnrollment und ich vermeide somit ungewollte Zertifikate, bevor meine Tests abgeschlossen sind:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Jetzt sind 2 Vorlagen aktiv:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Es wird Zeit für einen Testlauf. Ich starte eine certlm.msc und frage ein neues Zertifikat an:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die Management-Konsole befragt das Active Directory, welche Zertifizierungsstellen existieren. Da wird dann mein CEP mit seiner URL genannt:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Der CEP listet mir nun die möglichen Zertifikatvorlagen auf. Ich wähle das Template für ein Webserver-Zertifikat. Da muss ich eine Angabe zum Antragstellernahmen vornehmen. Ich erstelle ein Test-Zertikat:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die Registrierung läuft und ist wenige Sekunden später abgeschlossen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Danach kontrolliere ich die CDP und AIA-Informationen, die beim Ausstellen von der Zertifizierungsstelle übergeben werden. Das neue Zertifikat ist nur noch über eine Sperrliste über http verifizierbar:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

In den Stelleninformationen finde ich 2 Einträge: einer zeigt, wo ein Client das Zertifizierungsstellen-Zertifikat organisieren kann. Und der andere Link gibt die Position meines Online-Responders an:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die Ausstellung über CEPCES funktioniert also. Ebenso werden die Erweiterungsinformationen korrekt ausgegeben. Dann bleibt nun noch die Kontrolle des Online-Responders. Diese Funktion kann mit certutil grafisch verprobt werden. Dazu exportiere ich das eben ausgestellte Test-Zertifikat in eine cer-Datei und rufe certutil mit dem Parameter URL auf. In der grafischen Oberfläche kann ich nun die einzelnen Stelleninformationen und Sperrlistenoptionen prüfen. Ich beginne mit dem Download des Zertifizierungsstellen-Zertifikates. Das funktioniert wie erwartet:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Auch der Download der klassischen Sperrlisten über http funktioniert einwandfrei:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Und auch der Online Responder reagiert wie gewünscht:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Aber ich möchte auch das „Echtzeit“-Sperrverhalten testen. Daher sperre ich in der Zertifizierungsstelle das Test-Zertifikat:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Üblicherweise wird hierfür eine Begründung mit angegeben:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nach dieser Aktion muss die Sperrliste außerhalb ihrer automatischen Veröffentlichung manuell erstellt werden. Das geht mit der cmd recht schnell:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Beim Einsatz eines Online Responders hängt es nun vom Aktualisierungsinterval ab. Ich hatte 5 Minuten angegeben. Die könnte ich nun noch abwarten. Aber ich kann es mit der Management Konsole auch beschleunigen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Ein Sperrlistentest mit certutil zeigt, dass die klassische Sperrlistenfunktion das Zertifikat noch nicht als zurückgezogen deklariert, denn mein Client hat sich beim ersten Test die Datei über http heruntergeladen und die Datei im Cache ist noch gültig. Er wird sich also die neue Version noch nicht herunterladen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Aber der Online Responder hat diese neue Sperrliste bereits verarbeitet und reagiert dementsprechend mit einem Sperrhinweis. Damit ist diese Sperrfunktion wesentlich schneller und agiler als die Verwendung der klassischen Sperrlisten:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Meine Zertifizierungsstelle hat alle Tests bestanden. Es kann also mit der Aktivierung der Standardfunktionen weiter gehen.

Aktivierung der PKI

Meine Computer und Benutzer werden über Gruppenrichtlinien angewiesen, die PKI regelmäßig zu besuchen, um dort nach Zertifikatvorlagen mit Auto Enrollment zu suchen. Solange meine Zertifizierungsstelle also keine passenden auszustellende Vorlagen hat, passiert nichts. Das kann ich nach meinen erfolgreichen Tests nun ändern. Ich nehme weitere Vorlagen zur Ausstellung dazu:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Mein Vorlagenkatalog ist recht überschaubar:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Damit kann meine PKI ihre Arbeit aufnehmen.

Nacharbeiten

Konfiguration der Datensicherung

Es folgen die üblichen Standardarbeiten. Eine wichtige ist die Konfiguration der Datensicherung. Die Zertifizierungsstelle werde ich wieder mit der Windows Serversicherung sichern. Dafür registriere ich wieder meine Standardaufgabe in der Aufgabenplanung:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Der Account ist wieder nur als Dummy eingetragen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Über mein gMSA-Script kann ich nun vom Domain Controller aus den Sicherungsaccount durch einen Group Managed Service Account ersetzen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Damit ist alles erledigt. Die Sicherungsdefinition liegt ja zentral in meiner Konfiguratiosdatei. Das genügt mir.

Monitoring

Weiter geht es mit dem Monitoring. Die aktuellen Sensoren zeigen meinen Base-Sensor im Fehlerstatus. Das liegt am Fehlen der alten Systemfestplatte, die über ihre GUID referenziert wurde. Ich lösche diesen alten Sensor im Webportal:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Danach kann ich ihn neu erstellen. Der Sensor ist ein eigens programmierter. Er gehört nicht zum Standard vom PRTG:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nach wenigen Sekunden sind die Counter im Sensor geladen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Updates

Im WSUS verschiebe ich den neuen Server noch in den passenden Update-Container. Den Rest erledigen meine Gruppenrichtlinien:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Bereinigungen

Im Hyper-V steht noch der alte VM-Eintrag. Diese VM kann ich nun löschen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Die dazugehörige Festplattendatei muss manuell bereinigt werden:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Problem Smartcard Logon

Ich verwende auf einem System eine Smartcard für die Anmeldung. Weil ich heute zufällig vor Ort bin, tausche ich das Zertifikat gleich manuell aus. Aber nach dem Austausch hängt die Anmeldung mit der neuen Smartcard mit dieser Fehlermeldung:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Da hat etwas bei der Neuausstellung des Zertifizierungsstellen-Zertifikates nicht geklappt. Für eine Smartcard-Anmeldung muss der Domain Controller dem Aussteller des Smartcard-Zertifikates vertrauen. Das ist üblicherweise vollautomatisch und wird unsichtbar im Hintergrund konfiguriert. Ich nutze aber ein angepasstes Administrationsmodell. Und bei dem hatte ich ja auch schon Probleme bei der CRL-Veröffentlichung im Active Directory. Offenbar wurde hier noch etwas im AD vergessen…

Ich führe das Problem also auf mein administratives Tier-Management zurück, in dem ich eben nicht alles als Domain Admin oder Enterprise Admin durchführe.

Aber ich kenne die notwendigen Schritte: Meine Domain Controller müssen das neue Zertifizierungsstellen-Zertifikat als NTAuth-Zertifikat konfiguriert bekommen. Um das zu konfigurieren, berechtige ich meinen T3-Admin als PKI-Admin und als Enterprise Admin:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Mit diesen Rechten ausgestattet starte ich eine PKIVIEW-Konsole. Hier kann man nicht nur die PKI überprüfen, sondern auch Anpassungen im AD-Kontext vornehmen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Für eine Smartcard-Anmeldung werden vertrauenswürdige NTAuthCertificates verwendet. Und genau hier liegt das Problem: Das neue Zertifizierungsstellen-Zertifikat fehlt in der Auflistung! Gelistet ist nur das alte:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Über den Schalter „Hinzufügen“ kann ich nun das neue Zertifikat zuweisen:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Dennoch wird die Anmeldung mit einer Smartcard erst funktionieren, wenn der prüfende Domain Controller über diese Veränderung informiert wurde. Denn jeder DC wird in seiner Registry die Zertifikate cachen. Bei mir ist es einfach, denn der Client mit der Smardcard steht in meiner Außenstelle und dort gibt es nur einen Domain Controller. In der Registry finde ich nur einen Zertifikateintrag für das alte Zertifizierungsstellen-Zertifikat:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Mit einem simplen gpupdate kann ich den Domain Controller dazu bringen, die Daten neu zu laden. Das hat nichts mit Gruppenrichtlinien zu tun. Aber der erzwungene Kontakt zu einem Domain Controller aktualisiert eben auch diese Daten. Und auch Domain Controller verhalten sich hier eben wie alle anderen Server und Clients. Nach dem gpupdate wird auch das neue Zertifikat lokal gelistet:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Nachdem der Domain Controller das neue Zertifizierungsstellen-Zertifikat gespeichert hat, akzeptiert er auch die Smartcard-Anmeldung vom Client:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Damit wäre auch dieses Problem behoben.

Problem Snort

Das nächste Problem lässt nicht lange auf sich warten. Mein Advanced Threat Analytics (ATA) meldet mir per Mail, dass es meinen WS-DC3 nicht mehr erreichen kann. Das sieht erst einmal nicht nach einem zertifikatbasierten Problem aus:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Aber direkt danach erhalte ich eine weitere Mail von meinem Monitor-Server. Dort läuft ein PowerShell-Script, dass die Logfiles im dort installierten SYSLOG analysiert. Im SYSLOG protokolliert meine Firewall und mein IPS diverse Meldungen. Und eine davon zeigt meinen WS-DC3:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Das sehe ich mir im IPS genauer an. Mein IPS ist ein Snort, dass in meiner PFSense mitläuft und den erlaubten Traffic regelbasiert analysiert und ggf. die Verbindungen blockiert. Da mein WS-DC3 in meinem Außenstandort läuft und daher über ein VPN angebunden ist, muss die Kommunikation durch den „äußeren Filter“. Hier sind die blockierten Hosts sichtbar. Das sind alles System im Außenstandort:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

In den Alerts kann ich die Ursache finden. Es war eine Kommunikation zwischen den blockierten Hosts und meiner neuen Zertifizierungsstelle. Besonders interessant ist dabei der Port 80:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Auf diesem Port läuft mein neuer OCSP. Ebenso kann hier aber auch der Sperrlisten-Download drüber laufen! Anscheinend werden die Verbindungen falsch bewertet. Daher erstelle ich eine neue Ausnahme:

Serie „Migration auf Windows Server 2019“ – Migration der PKI

Danach entferne ich noch die geblockten Hosts und die Verbindungen funktionieren wieder. An diesem Live-Beispiel kann man sehen, wie ein aktives und intelligentes Monitoring beim Lösen von Problemen helfen kann.

Zusammenfassung

Ein schwieriger Windows Service

Auch diese Migration verlief nicht ohne Probleme. Einige wären vermeidbar gewesen. Dennoch ist jede Problemlösung ein Lieferant für wertvolles Wissen.

Nachdem dieser Server nun mit meinem Ziel-Betriebssystem läuft, bereite ich mich auf den nächsten vor. Viele sind ja nicht mehr über…

Den Artikel gibt es wie gewohnt hier als PDF zum downloaden. Einige meiner PowerShell-Scripte können ganz unten auf der Übersichtsseite gefunden werden.

Stay tuned!

Hier geht es zum Übersichtsbeitrag meiner Serie „Migration auf Windows Server 2019“

Kommentar hinterlassen