Private S/MIME Zertifikate erstellen, 2022 Edition

Dass jede Mail, die man im Internet verschickt, in etwa so geheim ist wie der Text auf einer Postkarte, sollte eigentlich heute jedem bewusst sein und kann nicht oft genug wiederholt werden. Möglichkeiten, die Inhalte seiner Mails zu verschlüsseln gibt es viele, aber nur wenige davon sind auch universell und praxistauglich.

Die PGP-Jahre

Viele Jahre lang war ich ein großer Verfechter von Pretty Good Privacy (PGP). Zum einen, weil ich ein großer Freund von quell­offener Software bin, zum andere, weill ich den Ansatz eines dezentralisierten “Web of Trust”, das ohne übermächtige Notare auskommt, für sinnvoller hielt. Dass zudem die USA große, teilweise recht bizarre Bemühungen unter­nom­men haben, um die Verbreitung von PGP einzuschränken, war fast so etwas wie ein Qualitäts­siegel.

So habe ich seit 1996 regelmäßig meine PGP-Keys verteilt und bei diversen Key-Signing Parties Ringelpietz mit Personal­aus­weis-Zeigen gespielt, um eine gute Beglaubigung im Web of Trust sicherzustellen.

Leider war die Verwendung von PGP in einem Mail-Workflow von Nicht-Technikern nie einfach. Auch über die Jahre hat sich daran, trotz verschiedener Bemühungen, nichts geändert. Den Todesstoß haben PGP für Mail­ver­schlüs­selung¹ dann wohl auch die zahlreichen Probleme mit dem Web of Trust und den öffentlichen Keyservern gegeben.

S/MIME in aktuellen Mailclients

Eine alternative Technologie gibt es schon lange: S/MIME basiert auf X.509 und ist in allen gängigen Mail User Agents von Thunderbird über Outlook bis zu Apples Mail.app schon lange verbaut und dort bestens integriert. Im besten Falle muss ich einem Benutzer nur seinen Schlüssel installieren, dann werden seine Mails auto­matisch signiert. Falls sich an­schlie­ßend zwei Mailpartner mit Schlüsseln auf diese Weise begegnen (z.B. durch signierte Mails), kann ab der 2. Runde auto­ma­tisch auch eine Mailverschlüsselung aktiviert werden.

Der Haken? Die S/MIME-Schlüssel müssen aus einer an­er­kann­ten PKI stam­men. Für ein Unternehmen ist das kein Problem, denn die lassen sich einfach einen Inter­mediate-Key signieren und kön­nen dann autark und in der Regel auch auto­mati­siert für Ihre Mitarbeiter Schlüssel erstellen und verteilen.

Für Privatpersonen gab es bis vor einigen Jahren noch ver­schie­dene Angebote, einen kostenlosen S/MIME Schlüssel zu erhalten, der ausschließ­lich die Email-Adresse selbst be­glau­bigte (Level 1). Gegen einen kleinen Aufpreis bekam man oft auch die Beglaubigung des Vor- und Zunamens (Level 2). Diese Ange­bote waren einfach bedienbar, dass man auf deren Webseite direkt einen Key erstellen, be­glau­bigen und das S/MIME-Zerti­fikat dann direkt im richtigen Format herunter­laden konnte. Alle diese Angebote sind inzwischen allerdings vom Markt ver­schwun­den².

Kostenlose (seriöse) Angebote konnte ich keine mehr finden. Eines der wenigen bezahlbaren Angebote fand ich aber bei Xolphin (ehemals “Komodo”): Hier kann man als Privatperson ein einfaches, 3 Jahre gültiges S/MIME Zertifikat für 19,04 EUR incl. MwSt. bekommen. Zertifiziert wird allerdings nur noch die E-Mail­adresse, eine tatsächlich Identitätsverifizierung kann man auch gegen Aufpreis als Privatperson nicht erhalten. Das tangiert aber die eigentliche Verschlüsselung und Signierung nicht.

Leider ist es nicht mehr so einfach wie damals, ein S/MIME-Zertifikat für gängige Mailclients zu erstellen. Nachdem ich das seit dem letzten Zertifikat vor 3 Jahren schon wieder verlernt hatte, habe ich hier der Prozess als Reminder für mich selbst zusammengetragen, damit ich mir die richtigen Formate und Optionen nicht in 3 Jahren wieder heraussuchen muss :-).

Erstellung eines S/MIME Schlüssels

Am einfachsten fand ich die einzelnen Schritte mit openssl, das für alle wichtigen Platt­formen erhältlich ist. Tatsächlich sind die einzelnen Schritte auf der Kommando­zeile am einfachsten (Ich will mir gar nicht vorstellen, wie das wohl mit einer GUI ginge. Es gibt aber einen sehr amüsanten Versuch, sich diesen Horror auszumalen).

1. Erstellung eines Keys und des Certificate Signing Requests (CSR)

Inhaltlich sind das zwei separate Schritte:

1. Die Erstellung des Schlüssels zum späteren Signieren und Ver­schlüsseln. Dieser Schlüssel sollte niemals den eigenen Rechner verlassen, auch nicht zum zertifizieren!
2. Die Erstellung eines Certificate Signing Requests (CSR), anhand dessen ein Treu­händer wie Xolphin die Authentizität unseres Schlüssels bestätigen und signieren kann, ohne den Schlüssel selbst dafür zu benötigen. (Math rocks🤘)

Beide kann openssl aber in einem einzigen Durchlauf ausführen. Wichtig ist das Setzen des korrekten Common Names (CN) und Landes (C):

$ openssl req -nodes -newkey rsa:4096 -sha256 -keyout mykey.key -out mykey.csr -subj '/CN=sisyphus.de/C=DE'
Generating a 4096 bit RSA private key
.......++
.............++
writing new private key to 'mykey.key'

Dabei wurde nicht nur die Datei mykey.key angelegt, sondern auch mykey.csr.

2. Signierung

Jetzt kann man bei Xolphin die passende Laufzeit wählen. In dem folgenden For­mu­lar pasted man den Inhalt der erstellten CSR-Datei und füllt noch Name unE-Mail-Adressese aus. Wenige Minuten später erhält man eine Mail mit einem Download-Link für das Zertifikat.

3. Download und Umwandlung des Zertifikats

Leider war weder der Inhalt der Mail noch der Name des Down­loads besonders hilfreich dabei, herauszufinden, was genau man da eigentlich heruntergeladen hat. Mir ist es nicht gelun­gen, mit Safari das Zertifikat korrekt herunterzuladen, die Datei hieß immer collectccc und war nicht identifizierbar:

$ file ~/Downloads/collectccc
 /Users/hoeni/Downloads/collectccc: data

Erst, als ich den Download dann mit Chrome noch einmal ver­sucht habe (viel­leicht geht auch Firefox?) wurde eine sinnvolle Datei namens user.crt herun­ter­geladen:

$ file ~/Downloads/user.crt
 /Users/hoeni/Downloads/user.crt: Certificate, Version=3

Wir wissen jetzt also, dass das Zertifikat im DER-Format vorliegt. Es muss erst ein­mal in das Base64-basierte PEM Format umgewandelt werden, damit wir damit weiterarbeiten können:

$ openssl x509 -inform der -in user.crt -out mykey.pem

Erstellung des PKCS#12-Containers

Damit wir alles, was wir brauchen (Schlüssel + Zertifikat) in einer Datei zusammen haben, erstellen wir jetzt einen PKCS#12-Container mit den beiden benötigten Dateien. Damit können unsere Mail-Clients dann direkt arbeiten:

$ openssl pkcs12 -export -inkey mykey.key -in mykey.pem -out mykey.p12

Dabei werden wir nach einem Passwort zum Schutz gefragt. Dieses Passwort benötigt man später jedes Mal, wenn man das ent­stan­dene Zertifikat mykey.p12 in einem Client instal­lieren will.

Installation

MacOS

Die Installation ist denkbar einfach. Am Mac reicht ein Doppel­klick auf mykey.p12. Nach Eingabe des Passworts kann man den Schlüssel dann im Key Ring (oder wie der Mac das so schön eindeutscht: “Schlüsselbundverwaltung”) bewundern. Bei mir gab es immer eine nichts-sagende Fehlermeldung beim Import. Da aber alles dennoch funk­tio­niert hat, ignoriere ich die. Ich bin dank­bar für jeden Tipp, woran das liegen könnte.

Jetzt muss dieser Schlüssel noch als Standardschlüssel festgelegt werden: Rechtsklick auf den Schlüssel => neue Identitätseinstellung. Hier gibt man dann bei “Ort oder E-Mail-Adresse” die exakte E-Mail-Adresse an, für die der Schlüssel ausgestellt wurde.

Wenn jetzt alles geklappt hat, bietet der Mail-Client direkt ein Icon für die Signatur der Nachrichten an. Die Verschlüsselung bietet er dann an, wenn er vom Gegen­über bereits einen öffentlichen Schlüssel erhalten hat, z.B. durch dessen Signatur.

iOS / iPadOS

Ganz anders funktioniert es am iPad oder iPhone. Zunächst muss einmal der Schlüssel dorthin gelangen. Am einfachsten ging das über AirDrop: Ich kann einfach das erstellte Zertifikat mykey.p12 im Finder auf das Client-Gerät ziehen und fallen lassen:

Wenn man das (z.B. am iPad) akzeptiert hat, findet man hinterher dort in den System­ein­stel­lun­gen ganz oben einen Menüpunkt “Profil geladen”, über den man das Zertifikat installieren kann. Neben diversen Warnungen, dass das gesamte Paket von niemandem signiert wurde (ach was?), muss man den Sicherheitscode für das iPad und das Passwort für das Zertifikat eingeben.

Im nächsten Schritt müssen wir den Schlüssel noch mit der E-Mail-Adresse ver­knüp­fen, das ist leider auch hervorragend versteckt: Immer noch in der Einstellungs-App gehen wir zum Punkt Mail => Accounts, dort zum passenden Mail-Account. Wenn man dort auf “Account” geht und ganz nach unten scrollt, findet man “Erweitert”. Auch hier muss man wieder ganz nach unten scrollen und kann dort, jeweils sepa­rat zum Signieren und zum Verschlüsseln einen Schlüssel aktivieren.

Fazit

Wenn man das alles durch hat, hat man 3 Jahre Ruhe :-). Ausgehende Mails wer­den automatisch signiert und – falls man bereits eine signierte Mail des Emp­fän­gers erhalten hat – auch automatisch verschlüsselt, ohne dass man dafür einen Finger krumm machen muss. Transparent am Rechner genauso wie auf Tablets und Mobiltelefonen.

Warum sich bis heute für den Prozess der Schlüsselerstellung und -beglaubigung kein anwenderfreundlicher Prozess gefunden hat, will sich mir nicht erschließen.

Schon gar nicht, warum so etwas nicht als hoheit­liche, staat­liche Aufgabe be­trach­tet wird. Warum kann ich nicht einfach z.B. beim Kreisverwaltungsreferat einen S/MIME-Key hoch­quali­fi­ziert beglaubigen lassen, sondern muss mich mit irgend­wel­chen selt­samen, aus­län­di­schen Dienstleistern herumschlagen? Warum muss unser Staat ständige Experimente mit unreifen, praxis­fernen Techno­logien (z.B. De-Mail, e-Perso) machen, an­statt einfach mal eine seit Jahr­zehnten gut gehende Techno­logie zu implementieren?