X.509-Zertifikate mit KDE und KMail verwenden

Bei X.509-Zertifikaten handelt es sich um Schlüssel für die Verschlüsselung und Signatur von Emails mit Hilfe des Public-Key-Verfahrens, die von vielen Mail-Programmen und Browsern unterstützt werden. Im Folgenden einige Hinweise zur Verwendung der Zertifikate mit KMail.

Voraussetzungen

Die Anleitung bezieht sich auf ein Debian 3.1 (unstable) Linux. Sie sollte sich aber auch mit anderen Linux-Systemen nachvollziehen lassen. Im folgenden wird vorausgesetzt, dass KMail bereits eingerichtet ist und außerdem die folgenden Pakete installiert sind:

  • gnupg: Verwaltet die Schlüssel und sichert den Privaten Schlüssel
  • gpgsm: Versteht das Secure Mime (S/MIME) Format
  • openssl: Extrahiert die öffentlichen und privaten Schlüssel
  • kleopatra: Graphische Oberfläche für KDE zur Verwaltung der Zertifikate

Sollten sie fehlen, können sie auf Debian-Systemen einfach mit

apt-get install {Paketname}

installiert werden. Ich nehme an, dass es für RPM-basierte Systeme (z.B. SuSE oder Redhat) Pakete mit ähnlichem Namen gibt, die sich dann mit rpm -i {Paketname} installieren lassen.

Export der Zertifikate aus der Anwendung

Üblicherweise werden X.509-Zertifikate im Format ">PKCS12 (Public Key Cryptographic Standard #12) ausgetauscht, auch an der Endung der exportierten Datei .p12 zu erkennen. An einen solchen Container mit dem Zertifikat (öffentlicher Schlüssel) und dem privaten Schlüssel kommt man, in dem man es zum Beispiel im Browser in der Zertifikatsverwaltung (Firefox und Internet Explorer können das auf jeden Fall) oder in der Zertifikatsverwaltung von Windows sein Zertifikat exportiert. Dabei ist darauf zu achten, dass auch der private Schlüssel exportiert wird!

Konvertierung für GnuPG

Leider kann die Zertifikatsverwaltung unter Linux bisher nicht richtig mit dem PKCS12-Format umgehen. Daher muss der PKCS12-Container zunächst in seine Einzelteile zerlegt werden.

Zunächst wird er ins PEM-Format (Privacy Enhanced Mail) konvertiert, wobei nach dem beim Export festgelegten Passwort gefragt wird:

openssl pkcs12 -in {*.p12-Datei} -out certbundle.pem -nodes

Dann kann man den privaten Schlüssel extrahieren:

openssl pkcs12 -in certbundle.pem -export -out certkey.p12 -nocerts -nodes

Bei der PEM-Datei handelt es sich um ein ASCII-Format, aus dem man auch "von Hand", d.h. mit einem Texteditor die einzelnen Schlüssel herauskopieren kann. Ein Schlüssel beginnt mit der Zeile Bag attributes und endet mit -----END CERTIFICATE-----. Am besten speichert man die Schlüssel einzeln in *.pem-Dateien.

Import unter KDE

Nun kann man entweder kleopatra starten (Bei mir habe ich in KDE keinen Menüpunkt dafür, also auf der Konsole starten) und dort File, Import Certificates verwenden, um den privaten Schlüssel (certkey.p12 und die öffentlichen Schlüssel in den *.pem-Dateien importieren. Kommt es zu Problemen, ist unter Umständen die Ausgabe des gpg-log-agent hilfreich, den man über das Menü Tools starten kann.

Alternativ kann man den Import auch auf der Kommandozeile durchführen. Dazu verwendet man den Befehl gpgsm:

gpgsm --import certkey.p12

(manchmal wird auch

gpgsm --call-protect-tool --p12-import --store certkey.p12

vorgeschlagen, mir ist nicht klar, wo die Unterschiede liegen)

Hat das funktioniert, so sollte man in Kleopatra auf die Baumansicht umschalten (View, Hierarchical Key List), mit F5 aktualisieren und seine Zertifikat-Hierarchie dort sehen - genaugenommen die Public Keys.

Die importierten privaten Schlüssel kann man sich auf der Kommandozeile mit

gpgsm --list-secret-keys

anzeigen lassen.

Vertrauenseinstellungen für Root-Zertifikate

Das Root-Zertifikat des Thawte-Freemail-Projekts (siehe www.thawte.com ) ist standardmäßig nicht als Vertrauenswürdig markiert, daher kann man zunächst keine damit signierten Zertifikate zum Verschlüsseln oder Signieren verwenden.

Um das zu ändern, trägt man den SHA1-Hash-Wert (Secure Hashing Algorithm

1) des Thawte-Zertifikats in der Datei trustlist.txt im Verzeichnis

~/.gnupg ein. Den Hashwert bekommt man in Kleopatra heraus, indem man das Root-Zertifikat rechts anklickt, dann Certificate Details, Dump wählt, und den Ausdruck hinter sha1_fpr kopiert und in die Datei trustlist.txt einfügt.

Danach muss man dem Programm gnupg-agent bekannt machen, dass sich die Datei trustlist.txt geändert hat. Dazu schickt man ihm mit

kill -SIGHUP {PID von gnupg-agent}

ein Signal oder startet einfach KDE bzw. den Rechner neu.

Verschlüsseln einer Nachricht

Nun kann man in KMail eine neue Nachricht erstellen, in der Symbolleiste als Verschlüsselungsmethode "S/MIME" wählen und daneben die Symbole für Signieren und / oder Verschlüsseln anklicken.

Zum Testen kann man einfach eine Mail an sich selbst schreiben. (von sich selbst hat man ja auf jeden Fall Public und Private Key gerade importiert). Beim Senden wird man dann zunächst gebeten, den Public Key für den Empfänger auszuwählen und dann auch noch den Private Key für den Absender (ich weiss nicht, ob die Frage danach immer kommt, oder nur, wenn mehrere Private Keys zur angegebenen Email-Adresse passen).

Fehlersuche

Wenn irgendein Schritt nicht funktioniert, kann man zum einen auf der Kommandozeile mit

gpgsm --list-keys

und

gpgsm --list-secret-keys

schauen, welche Schlüssel erfolgreich importiert wurden. Andererseits kann man mit dem GnuPG Log Viewer (in Kleopatra im Tools-Menü aktivieren) auch gut verfolgen, was das System gerade macht bzw. woran es scheitert. Den Detailgrad der Meldungen kann man in Kleopatra im Menü Settings, Configure GpgME Backend, GPG for S/MIME unter Debugstufe auf Name setzen erhöhen, indem man dort guru einträgt.

Anmerkungen

Ich habe mein EMail-Zertifikat aus dem Thawte-Freemail-Programm. Bei dem vor ca. einem Jahr erstellten Zertifikat (also im Juni 2004) gab es keine Probleme beim Importieren des privaten Schlüssels. Das nun (Juni 2005) verlängerte Zertifikat kann ich bisher nicht importieren. Anscheinend hat gpgsm (Version 1.9.15) einen Bug beim Lesen der PKCS12-Datei, wie hier zu lesen ist.

Ich habe bisher Probleme, Mails die von Outlook Express gesendet wurden, zu entschlüsseln. Der verwendete Algorithmus RC2 wird (noch?) nicht unterstützt. Vermutlich gibt es das Problem auch bei Mails von MS Outlook, dort kann aber anscheinend der verwendete Verschlüsselungsalgorithmus eingestellt werden (AES oder 3DES sollten funktionieren).

LinkedIn logo mail logo