CA Restore

Im ersten Teil dieser CA Blogbeitragsreihe habe ich gezeigt wie ein sinnvolles automatisiertes Backup der CA angefertigt werden kann. In diesem Beitrag möchte ich zeigen wie die Daten des Backups wieder eingespielt werden können. Dabei behandele ich das Szenario eines Totalausfalls, also das einer CA, die aufgrund eines Hardwarefehlers nicht mehr genutzt werden kann.

Ich hoffe, dass die meisten den Blogbeitrag nur aus Interesse lesen und nicht, weil sie sich mit dem Problem beschäftigen müssen. Sollte das so sein, würde ich empfehlen die Schritte auf die eigene Umgebung anzupassen und den Extremfall in einer Testumgebung einmal zu testen. Wenn das Szenario später mal in einer Produktivumgebung durchgeführt werden muss, hilft es sehr die Schritte schon einmal durchgeführt zu haben.

Also: Meine Issuing CA ist ausgefallen. Was jetzt?
Zunächst prüfe ich wie lange die vorhandenen CRLs noch gültig sind. Wenn die CRLs abgelaufen sind und keine Neuen mehr veröffentlicht werden, funktioniert nichts mehr. Denn wenn ein Client ein Zertifikat nicht mithilfe einer CRL verifizieren kann, traut er ihm auch nicht.

Ich gehe mal davon aus, dass die CRLs noch ausreichend lange gültig sind. Da meine CA ohnehin offline ist, hätte ich auch nichts gegen ablaufende CRLs tun können. Ich hätte nur gewusst, dass ich mich beeilen muss ;-)

Als nächstes entferne ich den Eintrag des defekten Servers aus dem AD. Im nächsten Schritt installiere ich dann einen neuen Server für meine Issuing CA und füge diesen zur Domäne hinzu. Es ist möglich dem neuen Server den Namen des alten CA Servers zu geben, notwendig ist es aber nicht. Auf einem CA Server sollten neben der CA Rolle keine weiteren Rollen installiert sein. Deswegen nehme ich keinen der existierenden Server.

Nun installiere ich auf diesem Server die CA Rolle und konfiguriere diese anschließend. Dabei gehe ich vor wie bei der Erstkonfiguration, wähle aber anstatt einen neuen Schlüssel zu erstellen, die Option einen existierenden Schlüssel zu importieren. 

Hier kommt der im letzten Blogeintrag gesicherte Schlüssel zum Einsatz.

Nach dem Import des Schlüssels wähle ich diesen aus und führe die Konfiguration der Rolle damit zu Ende.

Nun starte ich die PowerShell, um die Datenbank wiederherzustellen. Die Datenbank kann ich mit certutil –f –restoredb  importieren. Wichtig ist, dass ich bei DB Pfad das Unterverzeichnis des Datenbankpfades angebe. Liegen die Daten also in C:/CADBBackup/database, schreibe ich certutil –f –restoredb C:/CADBBackup. Der Parameter –f wird benötigt, da certutil ansonsten darauf hinweist, dass die aktuelle CA DB nicht leer ist. Daher wird diese nicht überschrieben, es sei denn man erzwingt dies mit –f. Sollte die Fehlermeldung The process cannot access the file because it is being used by another process geworfen werden,

muss der CA-Service erst mit net stop certsvc gestoppt werden. Anschließend sollte die Datenbank importiert werden können

Zwei geschafft, zwei fehlen noch. 
Als nächstes passe ich die Registry Einträge der neuen CA an. Auch wenn es verlockend ist die gesicherten Registry Einträge zu importieren, sollte davon abgesehen werden, da dies zu Problemen führt die den Start des certsvc verhindern. Auf dieser Seite [1] gibt Microsoft die Registrykeys an, die von der alten CA übernommen werden müssen. Nun werden diese mit denen der neuen CA verglichen und gegebenenfalls geändert.

Nun da auch das geschafft ist bleiben die Templates. Wurde die Liste der Templates vorher wie von mir beschrieben exportiert, kann man die Templates nun wieder über die PowerShell festlegen. Dazu nutzt man folgenden Befehl und fügt statt CAtemplateliste eine kommaseparierte Liste der Templatenamen aus der catemplates.txt Datei ein:

certutil –setcatemplates +

Wir haben die Registryeinstellungen der alten CA importiert, um unter anderem, dafür zu sorgen, dass neue Zertifikate und CRLs an der gleichen Stelle veröffentlicht werden wie auch von der alten CA. Damit die neue CA die Zertifikate und CRLs dort erfolgreich veröffentlichen kann, muss sie die notwendigen Rechte haben. Sollte sich der Name des Servers nicht geändert haben, entfallen die Schritte. Andernfalls, gehen wir wie folgt vor:

  • Anmeldung an einem Server mit Zugriff auf die AD-Standorte und Dienste

  • Im Kontextmenü des obersten Knotens in der Liste auf Ansicht -> Dienstknoten anzeigen klicken

  • Die Services und danach die Public Key Services ausklappen

  • Das AIA Verzeichnis auswählen

  • Die Eigenschaften der CA anzeigen lassen

  • Unter dem Reiter Sicherheit, Hinzufügen anklicken

  • Den Objekttyp zu Computer ändern, den Name der neuen CA hinzufügen und OK klicken

  • Unter Zulassen, Vollzugriff wählen und anschließend bestätigen

  • Das alte CA Computer Objekt kann hier entfernt werden, indem man es markiert und anschließend auf Entfernen und danach auf OK klickt

  • Anschließend in der Übersicht von AD-Standorte und Dienste CDP ausklappen

  • Das Verzeichnis der CA auswählen und in die Eigenschaften des obersten cRLDistributionPoint in der Liste wechseln

  • Unter dem Reiter Sicherheit, Hinzufügen anklicken

  • Den Objekttyp zu Computer ändern, den Name der neuen CA hinzufügen und OK klicken

  • Unter Zulassen, Vollzugriff wählen und anschließend bestätigen

  • Auch hier kann man das alte CA Computer Objekt entfernen, indem man es markiert und anschließend auf Entfernen und danach auf OK klickt

  • Die Schritte für die CDP müssen für alle weiteren cRLDistributionPoints in der Liste wiederholt werden, falls weitere vorhanden sind

Nach diesen Schritten ist das Backup der CA erfolgreich eingespielt und alles sollte wieder wie gewohnt funktionieren. Jetzt nicht vergessen wieder das automatische Backup der neuen CA einzurichten. Wieder in der Hoffnung, dass man es niemals braucht.

Hier geht es zum ersten Teil der Blogeintragsreihe.
[1] https://technet.microsoft.com/en-us/library/ee126140(v=ws.10).aspx#BKMK_RestoreReg

BackupESCde Windows Server TeamRestore, CA