Von PKI Cloning, verwaisten Zertifikaten und ungewollten Zwillingen

Von PKI Cloning, verwaisten Zertifikaten und ungewollten Zwillingen

  • Comments 2
  • Likes

(Dieser Post handelt von einer PKI Disaster Recovery Strategie, welche zu ungewollten Seiteneffekten führte.)

 

PKI Cloning

Bekanntermaßen ist der CA Dienst unter Windows Server 2003 nicht Clusterfähig. Aus diesem Grund hatte mein Kunde, aus bestimmten betriebsbedingten Zwängen, die folgende Disaster Recovery Strategie gewählt - was den CA Server hochverfügbar gemacht - dabei aber Seiteneffekte verursacht hat.

Es wurden zwei 'baugleiche' Server und zwei Hardware Security Module (HSM) angeschafft. Eine CA wurde auf dem ersten Server in die vorhandene PKI Struktur installiert. Der Private Schlüssel wurde dabei von der ersten HSM erzeugt.

Dann wurde ein Image des ersten CA Servers (nachfolgend OrgCA genannt) erstellt. Dieses Image wurde auf den zweiten Server (CloneCA) übertragen. Ebenfalls wurde (wie auch immer das vonstatten ging) die erste HSM auf die zweite HSM übertragen. Was mein Kunde erhielt ist eine CloneCA, welche theoretisch der eigentlichen OrgCA gleicht.

 

Abgesehen davon, daß Cloning von Support Engineers alles andere als gerne gesehen wird,
Denn Hardware ist niemals gleich, jedes Bauteil hat andere Seriennummern. Bauteile können aus verschiedenen Produktionen stammen, oder andere Firmware enthalten. Bestes Beispiel ist die Netzwerkkarte, diese hat immer eine andere MAC Adresse. Diese Fälle sind hier bei uns schon häufiger aufgetreten. Das Image läuft auf der einen Hardware tadellos, auf der anderen 'gleichen' Hardware treten Probleme auf. Aus diesem Grund ist nur das Systemstate Backup die Variante die Support erhält. –
kann dies zu Konflikten im Netzwerk und im Active Directory kommen. Es wurden Regeln vereinbart, damit dies nicht passiert. Als Beispiel dürften beide CA Server nicht gleichzeitig ans Netzwerk angeschlossen werden. Ergänzend wurde täglich eine Systemstate Backup und stündlich ein CA Backup mit certutil –backup erstellt.

 

Aus Gründen der Systemwartung musste die OrgCA heruntergefahren werden. Vorher wurde noch ein Systemstate Backup und CA Backup erstellt, danach ging die OrgCA offline. Die aktuellen Backups wurden in die CloneCA eingespielt und die CloneCA ging online. Es kam zu keinen Komplikationen.

 

Nach einigen Tagen, in denen es keine Auffälligkeiten bezüglich der CA gab, wurde die CloneCA heruntergefahren. Danach ging die OrgCA ohne Probleme wieder online.

 

Mhhh.... Frage: Was ist an diesem Bild nicht richtig? Wer's erkennt, darf's behalten. J 

 

 

Vorgeschichte Ende - Anfang Support

 

 

Verwaiste Zertifikate

Begriffsklärung: Es sind Zertifikate die bei den Antragstellern existieren, jedoch nicht in der Datenbank der CA.

Es wurde vergessen mindestens das CA Backup der CloneCA zu erstellen, was danach in die OrgCA eingespielt hätte werden müssen. Da die CloneCA mehrere Tage lief, sind auch neue Zertifikate ausgestellt worden. Was bedeutet, in der CloneCA befanden sich nun verwaiste Zertifikate. Im Grunde kein Weltuntergang. Die verwaisten Zertifikate waren ohne Einschränkung prüf- und benutzbar. Doch das dicke Ende kam, als man versuchte diese Zertifikate auf der OrgCA zurückzurufen. Die verwaisten CloneCA Zertifikate waren in der OrgCA Datenbank nicht enthalten.

Dies kann übrigens ebenfalls geschehen, wenn Zertifikate ausgeben werden. Zwischen Backup und dem Ausfall des CA Servers Zeit vergangen ist, welcher eine Widerherstellung der Datenbank erfordert. –

 

Da nun die OrgCA ihrerseits Zertifikate ausgestellt hatte, konnte ein CA-Backup der CloneCA nicht mehr eingespielt werden. Egal wie man es auch drehte und wendete, man hätte immer verwaiste Zertifikate erhalten.

 

Gelöst wurde diese Zwickmühle, indem man Dummy Zertifikate in der OrgCA Datenbank erzeugte. Danach diese Zertifikaten dann sofort zurückgerufen hatte.

Folgende Schritte waren nötig.

1)    CloneCA ohne Netzwerkverbindung starten.

2)    Notieren der Cert_Ser_Number eines Zertifikats, welches nicht in der OrgCA enthalten ist. Leicht am Ausstellungsdatum zu identifizieren.

3)    Auf der OrgCA den Befehl 'certutil –sign Cert_Ser_Number Dummy_Cert.cer' ausführen.

4)    Falls mehr als eine CA im AD existiert erscheint ein Popup Fenster. Darin sind alle CA Zertifikate aufgeführt, welche in der PKI existieren. Hier ist es enorm wichtig, daß richtig CA Zertifikat auszuwählen. Dieses Zertifikat bestimmt, in welche Certificate Revocation List (CRL) das Dummy_Cert aufgenommen wird. Ein Fehler hier bedeutet, daß Dummy_Cert landet nicht in der OrgCA CRL.

5)    Um das Dummy_Cert in die Datenbank aufzunehmen führt man den Befehl 'certutil –importcert Dummy_Cert.cer' aus.

6)    Es wird ein weiteres Zertifikat in der OrgCA angezeigt, welches dann zurückgerufen wird. Bei meinem Kunden haben wir 'Superseded' als Grund gewählt.

7)    Wiederholung der Schritte für alle verweißten Zertifikate der CloneCA.

8)    Ausgabe einer neuen CRL.

Vorteil dieser Methode ist, es wird nur eine CRL am Ende ausgestellt. Theoretisch gibt es eine zweite Methode, bei der aber für jedes Dummy_Cert eine neue CRL ausgestellt wird. Dies führt zu vermehrtem Replikationsverkehr. Ebenfalls kann ein Client eine CRL herunterladen und später ausgestellte CRLs dann nicht mehr beachten. Da der Clients erst nach Ablauf der CRL nach einer neuen sucht.

 

 

Case closed...? Nein leider nicht!

 

 

Zwillinge

Begriffserklärung: Es sind Zertifikate mit gleicher Seriennummer aber unterschiedlichen Schlüsselpaaren.

Da die Liste aller verwaisten Zertifikate umfangreich war, wurden Seriennummern aus versehen zweimal für die Dummy Zertifikatserstellung benutzt.

 

Leider konnte immer nur ein Zwilling zurückgerufen werden. Bei dem anderen Zwilling wies eine Meldung darauf hin, daß dieses Zertifikat bereits zurückgerufen wurde.

 

Mit einem direkten Eingriff in die Datenbank konnte dies behoben werden.

– Hier ein wichtiger Hinweis. Certutil arbeitet hier ohne eine Sicherheitsabfrage! Startet man den Befehl, gibt es kein zurück mehr. Daher sollte vor beginn der Arbeiten ein Backup erstellt werden. –

Folgende Schritte waren nötig.

1)    Notieren der 'Request ID' des verbleibenden Zwillings. Nicht der Seriennummer, diese ist ja von beiden gleich. (Zu finden ist die 'Request ID' u.a. in der ersten Spalte aller Zertifikatslisten der CA Verwaltung.)

2)    Um den zweiten Zwilling aus den 'Issued Certificates' zu löschen, wird der Befehl 'certutil –deleterow Request_ID cert' auf der OrgCA ausgeführt.

 

 

Yeah, nu aber. Close case....

 

 

Als Empfehlung nun noch kurz folgendes.
Wer die Hochverfügbarkeit benötigt, sollte Windows Server 2008 zum Einsatz bringen. Hier der CA Dienst Clusterfähig.
Für eine Normale PKI Struktur reicht ein regelmäßiger Systemstate und CA Backup. Damit lässt sich eine CA ohne weiteres, in einer akzeptablen Zeitspanne, wiederherstellen.
Dazu sind diese beiden KB Artikel die ideale Referenz.

298138 - How to move a certification authority to another server

555012 - How to move a certificate authority to a new server running on a domain controller.

 

Vielen Dank für die Aufmerksamkeit! (wer es denn bis hier unten noch geschafft hat :-)

Grüße Lutz P.
Comments
  • Hallo,

    spannende Sache. Da leider keine Zeitangabe gemacht wurde würde mich noch interessieren, wie schnell habt Ihr es geschafft den Fehler zu lokalisieren?

    Schöne Grüße

    Peter Forster

    MVP Virtual Machine

    Austria

  • Hallo Peter

    Nun der Kunde hatte das Problem mit den verwaisten Zertifikaten selber erkannt, nur leider ein paar Tage zu spät. Er eröffnete schon die Anfrage mit der expliziten Fragestellung.

    Die Zwillinge waren dann durch Doppelbenutzung von Seriennummern entstanden. Was erst nicht sofort aufgefallen war. Damit war nicht zu rechnen.

    Gruß Lutz

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment