Deinstallation einer CA

Windows macht es per Assistent sehr einfach, eine Zertifizierungsstelle zu installieren und zu deinstallieren. Im Hintergrund werden automatisch Einträge im AD hinterlegt, damit Domainmitglieder die neue CA als Vertrauenswürdig ansehen und wissen, welche Templates sie anbieten. Eine gut geplante PKI muss nicht wirklich deinstalliert werden, sondern wird über Jahre oder gar Jahrzehnte immer wieder weiter betrieben. Kommt es aber zu dem Fall, dass eine CA entfernt werden muss, dann sollte dies "geplant "passieren.

Gründe für die Deinstallation

Üblicherweise kann eine Zertifizierungsstelle über viele Jahre bestehen und kontinuierlich an die Anforderungen angepasst werden. Selbst für Übertragung auf andere Server und sogar andere Betriebssysteme und Zertifizierungsprogramme ist meist möglich, zumindest wenn das Zertifikat der Zertifizierungsstelle samt privatem Schlüssel exportiert werden kann. Dennoch erleben wir es häufig, dass eine früher "mal eben schnell" installierte CA heute nicht mehr "gewollt" ist. Oft zeigen sich bei der bisherigen CA diverse Limitierungen, z.B.

  • Name der CA ist "unpassend"
    Das ist ein häufiger Fall, wenn eine Firma umbenannt wird und alle Spuren auf den früheren Namen eliminieren will.
  • Veränderungen beim Admin-Konzept
    Wurde früher eine CA auch schon mal gerne auf einem DC installiert, was für die Ausstellung von Zertifikaten für WebServer und Computer sogar toleriert werden könnte, so wird man heute CAs entweder Standalone (z.B. die Root) oder auf einem Memberserver installieren. So lassen sich Berechtigungen besser steuern und der "DomainAdmin" ist nicht immer "Gott" im Netzwerk.
  • Mehrstufigkeit gewünscht
    Genauso oft wurde früher gerne eine einzelne AD-Integrierte Root-CA installiert. Ist heute eine neue PKI erforderlich, dass wird meist eine eigenständige RootCA aufgebaut, die eine Issuing-CA zertifiziert, die dann die Zertifikate ausstellt. Dann muss irgendwann die "alte Root" natürlich weg.

Dann gibt es noch einige andere Gründe, die gerne für eine neue PKI angeführt werden, aber nicht wirklich zwingend sind. Oft ist es ein fehlendes Wissen. Dazu fehlen gehören u.a.:

  • Fehlender oder falsch definierter CRL-Pfad
    Eine RootCA bietet zwar eine CRL an, mit der Clients die ausgestellten Zertifikate prüfen können aber das Root Zertifikat selbst hat keine CRL-Adresse. Es ist ja ein Root Zertifikat. Nur das Zertifikat einer untergeordneten CA hat eine CRL.
  • Ablaufendes Stammzertifikat
    Anders sieht es aus, wenn das Stammzertifikat langsam an das Ende seiner Gültigkeit kommt. Kein davon abgeleitetes Zertifikat kann über das Ablaufdatum der CA gültig sein. Das Stammzertifikat können Sie natürlich verlängern. Aber es muss auf allen Clients dennoch neu als "trusted" addiert werden.
  • Zu viele CAs nebeneinander
    Diverse Dienste wie z.B. Direct Access nutzen Computerzertifikate auf dem Client zur Authentifizierung, aber erwarten dabei eine bestimmte ausstellende CA. Wer also mehere Zertifizierungsstellen hat, die z.B. Computerzertifikate ausstellen, könnten sie bekommen. Deswegen muss aber nicht die komplette CA deinstalliert werden. Hier kann man mit Berechtigungen, Steuerung des AutoEnrollment und Templates eine Lösung finden.

Wenn Sie nicht sicher sind, warum sie eine Zertifikatsstelle deinstallieren wollen, dann sollten Sie sich Hilfe organisieren.

Wir können und mit Zertifizierungsstellen und Zertifikaten aus. Hier auf der MSXFAQ gibt es sehr viele Seiten zum Thema aber bei so einer kritischen Komponenten sollten Sie sich nicht scheuen, fachliche Hilfe anzufordern. Siehe Net at Work

Risiken einer ungeplanten Abschaltung

Gut, sie haben mindestens einen Grund eine bestehende CA zu entfernen. Ein einfaches "Abschalten und Wegwerfen" ist zwar möglich aber bringt zumindest negative Effekte mit sich.

  • CLR Erreichbarkeit
    Zum einen ist dann die CRL nicht mehr erreichbar und die Clients, die weiter mit dem Zertifikat arbeiten, fangen an irritiert zu suchen. Einige werden das Fehlen ignorieren und weiter machen, anderen werden stoppen und nachfragen und wieder andere werden sich weigern. Einige SSL-Verbindungen benötigen mehr Zeit beim Aufbau. Kniffliger wird es, wenn Authentifizierungsverfahren auf Clientzertifikate warten und aktiv deren Gültigkeit prüfen wollen.
    So starten Skype for Business Dienste eventuell nicht mehr, wenn die Zertifikatsprüfung nicht mehr geht.
  • Ein nicht sauber deinstallierte CA bleibt im Active Directory weiter bestehen. Prozesse, die automatisch Zertifikate von einer "bekannten CA" anfordern, versuchen die nicht mehr vorhandene CA zu erreichen. Mit etwas Glück erwischen Sie früh genug eine andere funktionierende CA und melden nur eine Warnung. Es kann aber auch ganz anders ausgehen

Zudem nehmen Sie sich mit dem ungeplanten Abbau einer CA auch die Möglichkeit, eine Liste der von ihr ausgestellten Zertifikate zu erhalten und diese zu tauschen.

Abbau mit Planung

Der Abbau einer Zertifizierungsstelle geht in den meisten Fällen mit dem Aufbau einer neuen PKI einher. Zertifikate werden eher wichtiger denn unwichtiger und ehe Sie eine CA abbauen, sollten alle von ihr ausgestellten Zertifikate auf den jeweiligen Systemen nur neue Zertifikate einer anderen CA ersetzt worden sein. Also sollten Sie die Deinstallation planen.

Arbeitsschritt Erledigt

Bestimmen der aktuellen Funktion

Zuerst sollten Sie alle Informationen über die aktuelle CA sammeln, solange diese noch aktiv ist. insbesondere:

  • Liste der Zertifikate
    Sie sollten genau wissen, welche Zertifikate die CA in der Vergangenheit ausgestellt hat und daher auf den Systemen vermutlich noch im Einsatz sind.
  • Angebotenen Templates
    Welche Zertifikate wurden von der CA an Clients angeboten. Windows nutzt dazu Templates, die bei einer AD-Integrierten CA im Forest gespeichert sind und damit einfach auf eine andere CA übertragen werden können.

Aufbau der Alternative

Dann müssen Sie die verbliebenen Server ihrer PKI ggfls. anpassen, dass diese nun die Aufgaben übernehmen, die ihre alte CA bislang hatte. Wer eine "falsche" CA abbaut, hat oft auch bei den anderen CAs noch deutliche Defizite. Prüfen Sie, dass die verbleibenden CAs ihren Anforderungen entsprechen

  • Liste der Zertifikate

Alte CA als "ReadOnly" setzen

Damit meine ich, dass die bisherige CA keine neuen Zertifikate mehr ausstellen darf aber sonst weiter natürlich CRL-Listen pflegen muss. Am einfachsten geht das, indem Sie die Verknüpfung zu den Templates von der alten CA entfernen, nachdem Sie die Funktion der neuen Umgebung sichergestellt haben.

Zertifikate tauschen

Dann sollten Sie nacheinander alle noch gültigen Zertifikate, die von dieser CA ausgestellt wurden, auf den entsprechenden Servern durch neue Zertifikate einer anderen CA ersetzen. Das kann durchaus einige Zeit erfordern.

Wenn Sie es perfekt machen wollen, dann sollten Sie die nun hoffentlich nicht mehr genutzten Zertifikate in der CA auch zurückrufen. Das kann aber dazu führen, dass ein Zertifikat, welches auf mehreren Servern zum Einsatz gekommen ist und die dies nicht gefunden haben, zu Problemen führt. Wenn Sie das Zertifikat nicht über die CRL unbrauchbar machen, dann müssen Sie sich selbst eine Liste führen, welche Zertifikate "erledigt" sind.

Ob sie die Zertifikate zurückziehen ist nicht so wichtig, da die CRL nach der Deinstallation der PKI vielleicht auch nicht mehr verfügbar ist.

Kontrolle

Wenn Sie nun alle Zertifikate ersetzt haben, dann sollte im Idealfall kein Client oder Server mehr diese CA ansprechen. Kontrollieren Sie einfach mal das IISLogs auf Zugriffe auf die CRL. Wenn irgendwo doch noch bislang unerkannt etwas diese CRLs anspricht, dann sollten sie hier noch nacharbeiten. Denn gleich ist die CA gar nicht mehr da.

CRL umziehen

Wenn Sie vor der Deinstallation die Zertifikate alle zurückgezogen haben und diese Information auch noch nach der Deinstallation der CA bestand haben soll, dann müssen Sie die CRL dieser CA noch zumindest so lange weiter betreiben, bis das am längsten laufende Zertifikat ausgelaufen ist.

Achtung:
Wenn Sie so die CRL weiter bereitstellenm können Sie diese nicht mehr ändern. Idealerweise ist der Schritt daher nicht erforderlich, wenn Sie die Zertifikate ale getauscht haben.

Das bedeutet dann aber:

  • Webseite für CRL bereitstellen
  • CRL-Verfallszeit deutlich verlängern
    Normalerweise ist auch eine CRL mit einem Verfalldatum versehen, d.h. die CA muss die CRL regelmäßig erneuern. Das geht natürlich nicht, wenn die CA deinstalliert ist. Als letzte Aktion sollten Sie also die CRL mit einer Restlaufzeit versehen, die über dem Ablaufdatum des letzten Zertifikats liegt
REM CRl Datei z.B. auf 100 Tage setzen
certutil -setreg CA\CRLDeltaPeriodUnits 1000
certutil -setreg CA\CRLDeltaPeriod "days"

CRL jetzt generieren
certutil -dspublish -f "name_of_root_ca_cert.CRT"  RootCA
certutil -dspublish -f "name_of_ca_crl.CRL"
  • CRL an neuem Platz veröffentlichen
    Nun legen Sie diese CRL am besten auf einen Webserver, der noch länger funktioniert und von dem wie bisher die Clients sich die Daten anonym herunter laden können.

Wenn Sie damals bei der Einrichtung keinen CNAME für die CRL verwendet haben, dann müssen Sie nach dem Abbau der CA und das Servers den DNS-Eintrag auf den neuen Server umbiegen.

Tipp
Sie haben vermutlich eine neue CA daneben installiert. Diese kann auf ihre Webserver problemlos auch diese zusätzliche CRL bereitstellen.

CA deinstallieren

Die Deinstallation der CA ist bei Windows ebenfalls über einen Assistenten einfach möglich. Aber das ist nicht alles.

  • Deinstallation der CA
    Das geht noch recht einfach über die Systemsteuerung von Windows.
  • Entfernen des Stammzertifikats auf dem Server
    Sie müssen unter allen umständen verhindern, dass jemand wieder eine CA mit dem Zertifikat aufbaut, dem viele Clients noch einige Zeit trauen. Sie sollten also das Stammzertifikat auf dem Server löschen und idealerweise auch Kopien, Sicherungen, Snapshot o.ä.
  • Entfernen des Stammzertifikats auf den Client
    Das Setup entfernt zwar die meisten Einträge im AD aber damit ist nicht sicher gestellt, dass die CA selbst auf allen Clients aus dem Speicher für "vertrauenswürdige Stammzertifizierungsstellen" verschwindet. Sie können dies aber ignorieren, wenn die CRL alle je ausgestellten Zertifikate ungültig macht und wirklich niemand noch ein Backup, Snapshot o.ä. der alten CA hat.

AD-Objekte

Eine AD-integriert PKI veröffentlicht ihr Stamm-/Issuing-Zertifikat auch im Active Directory. Prüfen und entfernen Sie ggfls. obsolete Zertifikate.

 

Eine Deinstallation ist also schon etwas mehr als "nur" Setup -Weiter -Weiter aufzurufen. Nur durch eine saubere Planung und koordinierte Vorgehensweise bleiben Ausfälle oder Verzögerungen aus. Sehen Sie diese Schritte als Chance, ihre PKI "sauberer" zu machen und endlich z.B. auch die "richtigen" Zertifikate mit einer korrekten CRL, entsprechender Gültigkeit und Dokumentation auszustellen.

Weitere Links