Private Key

Der private Schlüssen ist für die Entschlüsselung eingehender Mails erforderlich und signiert ausgehende Mails. Der Verlust des Schlüssels ist entsprechend kritisch. Ein Key Backup ist essentiell. Hier finden Sie entsprechende Informationen.

In schreibe oft von "Zertifikaten". Ein Zertifikate selbst ist aber nur der signierte öffentliche Schlüssel mit ein paar zusätzlichen Informationen. Wichtiger ist hier der komplementäre Schlüssel zum Zertifikat, d.h. den passenden privaten Schlüssel. Der muss zusammen mit dem Zertifikat gesichert werden.

Lebensdauer eines Private Key

Nicht jeder Schlüssel ist gleich wichtig. Sie müssen schon genauer unterscheiden, welche Schlüssel "essentiell" sind und welche nicht. Wichtige Schlüssel müssen Sie nicht nur während der Laufzeit des Zertifikate vorhalten, sondern sogar noch viel länger. Wer z.B. eine verschlüsselt empfangene Mail auch noch nach Jahren öffnen möchte, benötigt den passenden privaten Schlüssel. Daher ist es auch ein Unterschied, ob Sie ein abgelaufenes Zertifikat "verlängern" oder einfach neu ausstellen. Bei einer Verlängerung eines Zertifikats bleibt das Schlüsselpaar unverändert und wird nur neu signiert.

Wer aber jedes Jahr sich ein neues "Kostenfreies Zertifikat" irgendwo besorgt, wo es einfach günstig oder sogar kostenfrei ist, hat am Ende nur nur ein aktives Zertifikat sondern mehrere Zertifikate. Die abgelaufenen Zertifikate dürfen Sie natürlich nicht löschen da sie ansonsten nicht mehr an ihre alten Mails kommen. Sie müssen die alten Schlüssel auch alle auf Dauer mitführen, d.h. sogar auf die nächsten Computer übertragen. Das ist manchmal gar nicht einfach, insbesondere wenn die Zertifikate als "nicht exportierbar" gekennzeichnet sind. Dazu aber später mehr.

Es gibt aber auch Zertifikate, die wichtig aber nicht von Dauer sind, d.h. der private Schlüssel wird zwar verwendet aber wenn er verloren geht oder getauscht wird, dann ist das nicht schlimm. Das ist in der Regel der Fall, wenn mit den Schlüsseln keine Daten dauerhaft sondern nur temporär verschlüsselt werden. Darunter fallen HTTPS, SMTPS, POP3S, IMAP4S etc. Aber auch die Anmeldung an einem PC per Zertifikat ist so ein Beispiel. Einige dieser Zertifikate können sogar automatisch ausgerollt werden. Siehe auch AutoEnroll.

Das bedeutet nicht, dass solche Schlüssel nicht auch gesichert werden sollten. Wenn Sie z.B. eine WebServer-Zertifikat bei einer öffentlichen Zertifizierungsstelle kaufen und der Server kaputt ist, dann kann benötigen Sie schon wieder ein Zertifikat, damit alles funktioniert. Auch wenn das Neuausstellen einfach ist so kostet es meistens Geld und die Verifikation kann einige Zeit dauern. Sie verlieren aber keine Daten sondern der Zugriff ist bis dahin nur unterbunden.

Etwas aufwändiger wird es, wenn Sie mit "Certificate Pinning" arbeiten oder das Zertifikat statisch irgendwo als "Trusted" addiert ist. Dann ist ein Tauschen des Zertifikats schon noch aufwändiger. Hier mal ein Versuch einer Übersicht:

Protokoll Anwendungsfall Lebensdauer Backup

HTTPS

WebServer, Webservices

Kurz

Ratsam

POP3/IMAP4

Mailserver Abholung

Kurz

Ratsam

SMTPS/SSMTP

Mailserver Zustellung

Kurz

Ratsam

S/MIME und PGP

Verschlüsselung und Signierung von Mails

Lang
Jahre/Jahrzehnte

Zwingend

EFS

Wenn Sie die Dateiverschlüsselung von NTFS nutzen, dann kommen dazu auch Zertifikate zum Einsatz. Ohne das Zertifikat eines berechtigten Benutzers ist kein Zugriff mehr möglich.

Lang

Zwingend

RMS

Zum Schutz von Dokumenten mit Rights Management Server kommen auch Zertifikate zum Einsatz. Allerdings passiert dies auf dem RMS-Server und nicht auf dem Client. Auf dem Client ist daher nicht viel zu tun, da sich der Client beim Zugriff eh wieder vom RMS-Service ein Decryption Zertifikat besorgt, was eine kurze Gültigkeit (Stunden oder Tage) hat. Die RMS-Services selbst haben aber langlaufende Zertifikate und die sind essentiell und auf die kommt es mir auf der Tabelle an

Lang

Zwingend

Client Authentifizierung 1

Anwendungen können sich auch beim Service mit Zertifikaten ausweisen. Das is bei Skype for Business sogar Default und mit Windows Anmeldungen ist es ebenfalls einfach möglich

Kurz

Nein

Client Authentifizierung 2

Anders sieht es bei Anwendungen wie Banking (HBCI) oder Steuersachen (Elster) aus. Wenn Sie so ein Zertifikat verlieren, ist der Aufwand schon hoch. Hier ist ein Backup auf jeden Fall Ratsam

1-2 Jahre

Wichtig

Die Aufgabenstellung wird klarer, wenn Sie die Zertifikate nach Anwendungsfall trennen. Sie können unter Windows natürlich ein "Benutzer-Zertifikat" ausstellen, das vom Anwender dann für die Smartcard-Anmeldung aber auch für EFS und SMIME genutzt werden kann. Ratsam ist dies aber nicht.

Backupoptionen

Nachdem Sie den Bedarf für Sicherungen festgestellt haben, bleibt natürlich die Frage, wie die Sicherungen anzufertigen sind. Das hänge auch davon ab, wo denn die Zertifikate liegen. Auch hier gibt es mehrere Optionen:

  • Windows Zertifikatsspeicher
    Auf Windows Systeme ist der Zertifikatsspeicher des Betriebssystem der am häufigsten genutzte Platz. Der wird über den "Systemstate" normalerweise mit gesichert
  • PFX/PEM-Dateien
    Auf UNIX-Systemen ist es fast üblich, die Zertifikate als PEM-Datei im Dateisystem an einem geeigneten Platz abzulegen. Sie können damit einfach als Datei auch mit gesichert werden. Vergessen Sie aber auch hier die entsprechende Konfiguration. Sie können übrigens auch Zertifikate aus dem Zertifikatsspeicher in eine PFX-Datei als "Backup" exportieren und als Datei sichern.
  • Applikations-Speicher
    Es gibt durchaus Anwendungen, die von ihnen verwendete Zertifikate in eigenen Datenstrukturen ablegen. Ich habe schon Zertifikate in SQL-Datenbanken gefunden, die von den Applikationen beim Start eingelesen und verwendet wurden. Hier müssen Sie dann schon noch mal die Unterlagen des Herstellers über Backup/Recovery konsultieren
  • Benutzerprofil/ Certificate-Roaming
    Zertifikate des Anwenders sind natürlich im Profil des Anwender unter "HKEY_CURRENT_User". Wer also "Roaming Profiles" konfiguriert hat, bei dem werden die Zertifikate als Teil des Profils auch auf dem Server gesichert und auf anderen Clients ebenfalls wieder hergestellt. Wer nur die Zertifikate ohne dem Profil "roamen" möchte, kann dies auch explizit einstellen. Siehe dazu auch Client Zertifikate und Roaming. Beide Verfahren verschlüsseln die Zertifikate aber mit den Benutzeranmeldedaten. Wenn ein Admin das Kennwort ändert, z.B: weil der Anwender es vergessen hat, dann sind die Zertifikate nicht mehr erreichbar. Dies ist also kein "Backup" sondern eher eine Bequemlichkeit
  • Zertifizierungsstelle
    Ein Betreiber einer PKI kann zumindest unter Windows vorschreiben, dass der private Schlüssel als "Backup" auf der CA landen muss. Das wird gerne z.B. für SMIME-Zertifikate gemacht, um eben ein Zertifikat bei einem Verlust neu ausstellen zu können. Die Anforderungen an solch eine Lösung sind aber hoch, da dann quasi alle privaten Schlüssel an einem zentralen Ort liegen.

Es gibt also verschiedene Wege die Zertifikate zu speichern und zu sichern.

Zertifikate und private Schlüssel sichern !

Wenn Sie nun Zertifikate auf den Client eventuell schon per AutoEnrollment verteilt haben und die vorbereitenden Schritte zur Sicherung des privaten Schlüssels aus der CA vergessen oder mangels Enterprise Lizenz nicht aktiviert haben, dann sollten Sie sich schon mal Gedanken machen, wie die die Zertifikate samt privatem Key entsprechend sichern. Denn wenn das Zertifikat (d.h. der Public Key) über das Active Directory für alle Outlook Benutzer im Forest erreichbar wird, können diese sehr einfach auch Mails "verschlüsselt" senden. Eine "Sicherung" der privaten Schlüssel ist daher ratsam aber wird von vielen Anwendern nicht vernünftig durchgeführt. Ein Roaming Profile ist auch kein rechter Schutz, denn wenn der Benutzer das Kennwort vergisst, dann können Sie es als Administrator zwar "zurücksetzen", aber ein Zugriff auf die privaten Schlüssel ist damit dennoch nicht möglich, weil der "Protected Store" zusätzlich gesichert ist.

Es ist durchaus denkbar, per Software eine "Sicherung" der Schlüssel samt privatem Key z.B. auf einen Dateiserver oder ein anderes Medium durchzuführen. Ein fertiges Programm habe ich bislang aber nicht gefunden. Firmen mit Active Directory fahren mit dem "Zertifikat Roaming" oder "Roaming Profiles" am besten. Einzelpersonen sollten ihr System entsprechend sichern oder beim Erhalt eines Zertifikats manuell eine Kopie an einem anderen Ort hinterlegen.

CAPICOM 2.1.0.2
http://www.microsoft.com/downloads/details.aspx?FamilyId=860EE43A-A843-462F-ABB5-FF88EA5896F6&displaylang=en

Security Update für CAPICOM (KB931906) (for Capicom prior to 2.1.0.2)
http://www.microsoft.com/downloads/details.aspx?FamilyId=CA930018-4A66-4DA6-A6C5-206DF13AF316&displaylang=en

Private Schlüssel schützen

Die privaten Schlüssel sind ein schützenswertes Gut. Das Zertifikat selbst ist ja nur der signierte öffentliche Schlüssel. Wer aber den privaten Schlüssel hat, kann alle mit dem dazugehörigen öffentlichen Schlüssel verschlüsselten Informationen lesbar machen. Das betrifft lokale Dateien (EFS) genauso wie Mails (SMIME/PGP) als auch SSL-verschlüsselte Verbindungsmitschnitte. Daher kann ein Zertifikat so beim Anlegen oder Import entsprechende gekennzeichnet werden.

Wenn dann versucht wird, das Zertifikat zu exportieren, dann ist die entsprechende Option nicht verfügbar:

Nach offiziellen Quellen ist damit der private Schlüssel auf diesem PC vorhanden aber kann nicht einfach übertragen werden. Natürlich können Sie die Windows Installation selbst "klonen" oder per Backup/Restore auf einem anderen PC herstellen. Das ist aber nicht die vielleicht gewünschte Flexibilität.

When exporting the server certificate from the server's personal certificate store, you may not have the option to export the private key. If this is the case, when the certificate was imported, the option to allow the private key to be exported may have been unchecked. This is a security measure to prevent a possible compromise of the server's private key. Since this could be a potential security risk, the option to mark the private key as exportable is not checked by default.
In order to correct this problem, you will need access to the original certificate backup (.pfx) file. To ensure this problem does not happen in the future (should you want to export the private key again) make sure during the import process that you select the box "mark the private key as exportable.
Quelle: IIS: Export Private Key Option is Grayed When Exporting a Server Certificate  https://support.microsoft.com/de-de/help/232154/iis-export-private-key-option-is-grayed-when-exporting-a-server-certificate

Exportierbarkeit zentral steuern

Ob ein privater Schlüssel exportierbar ist oder nicht, kann auch der PKI Administrator über die Templates vorschreiben. Hier sehen Sie die Einstellung des "WebServer"-Template von Windows:

Bei einem eigenen Template können Sie neben der Exportfähigkeit des privaten Schlüssels auch bestimmen, dass der private Schlüssel auf der CA hinterlegt werden muss:

Allerdings sind dazu einige Vorarbeiten erforderlich. So müssen auf der CA die Archivierung eingeschaltet und entsprechende Key Recovery Zertifikate hinterlegt werden.

Diese Einstellungen sollten Sie nicht ohne entsprechenden Konzept ändern oder umsetzen.

Mimikatz

Auch wenn Windows vorschreibt, dass der private Schlüssel nicht exportierbar sein soll, so ist es letztlich doch auch nur ein Stück Software und Information auf dem PC. Mit entsprechenden Berechtigungen (Administrator), kann natürlich jeder Schutz irgendwie umgangen werden. Es braucht nur das entsprechende Werkzeug. Benjamin Delpy hat mit dem Kommandozeilenprogramm Mimikatz solch ein Werkzeug geschaffen.

Sie können es kostenfrei und sogar im Source-Code bei GitHub herunter laden.

Hinweis: Verschiedene Virenscanner blockieren eventuell den Zugriff, da Sie einen Schadcode dahinter vermuten. Es liegt in ihrer Verantwortung, entsprechende Ausnahmen zu definieren oder den Scanner temporär zu deaktivieren.

Das Programm selbst öffnet einfach eine Art Eingabeaufforderung, in der ich persönlich bislang nur folgende vier Befehle genutzt habe:

crypto::capi

crypto::listKeys 

crypto::certificates /systemstore=CERT_SYSTEM_STORE_LOCAL_MACHINE /export
crypto::certificates /systemstore=CERT_SYSTEM_STORE_CURRENT_User /export

Die beiden letzten Befehle exportieren jeweils alle Zertifikate mit privatem Schlüssel als PFX-Datei in das aktuelle Verzeichnis. Das Kennwort für die PFX-Datei ist jeweils "mimikatz". Sie sollten also nach dem Export die PFX-Dateien gut gegen fremden Zugriff sichern. Sie können, sofern erlaubt, die Zertifikate ja wieder importieren und erneut exportieren.

Ansonsten hilft ihnen auch OpenSSL beim Exportieren und Importieren:

Rem Export der PFX Datei in eine PEM-Datei. Kennwort wird abgefragt
openssl pkcs12 -in zertifikat.pfx -out zertifikat.pem -nodes

Rem Konvertierung der PEM in PFX. Kennwort wird abgefragt:
openssl pkcs12 -export -out zertifikatneu.pfx -in zertifikat.pem

Rem  Entfernen der temporaeren Dateien
Del zertifikat.pem
Del zertifikat.pfx

Beachten Sie, dass das Löschen kein 100% Schutz ist.

Weitere Links