BenBE's humble thoughts Thoughts the world doesn't need yet …

Wenn man sich im Internet umschaut, findet man zu Hauf Anleitungen, wie man SSL-Zertifikate für Server generieren kann. Leider gehen viele dieser Anleitungen als erstes auf die Variante mit Self-Signed-Zertifikaten ein, ohne auf die zahlreichen Nachteile dieser hinzuweisen. Auch fehlt in vielen Howtos leider die Beleuchtung der Zusammenhänge zwischen den verschiedenen Schritten und was jeder einzelne von ihnen bewirkt. Daher möchte ich mit dieser Anleitung einmal versuchen, ein wenig Licht in’s Dunkel der Zertifikate zubringen.

Eine sehr häufig genutzte, aber bei weitem nicht die einzige, Möglichkeit, um solche Zertifikate zu erstellen, ist OpenSSL. Dieses wird an zahlreichen Stellen eingesetzt und ist zudem auf vielen Plattformen verfügbar. Zudem genießt OpenSSL den Bonus, sich durch seine Unhandlichkeit auf faszinierende Weise von der Konkurrenz abzuheben, um nicht die gnadenlose Eignung als Geschenk für Sadisten zu betonen. Und genau daher werde ich es im Folgenden zur Erklärung des Sachverhaltes nutzen.

Aber im Grunde ist SSL recht einfach: Damit man mit einem Unbekannten sicher und vertraulich kommunizieren kann, benötigt man in der Regel einen vertrauenswürdigen Dritten, der einem dabei hilft, die Identität seines Gegenüber zu bestätigen. Diese vertrauenswürdigen Dritten heißen in der Terminologie der X.509-Zertifikate „Certificate Authorities“, also „Zertifizierungsstellen“. Hier bekommt man keine Certificates of Authenticity, wie sie auf jedem billigen Discounter-Notebook kleben, sondern eine Bestätigung seiner Identität. Je nach CA sind für diese Bestätigung unterschiedliche Dinge notwendig, was von einem einfachen „Ich glaub’s einfach mal“ (Comodo anyone?), über das persönliche Treffen mit dem Anwärter (CAcert) aber auch bis hin zu millionenschweren Prüfungen von aktenschrankweise anzuhäufenden Papieren und Bescheinigungen kann. Abhängig von der Art der Prüfung fällt dann auch das Zertifizierungslevel aus. Einfache Class-1-Zertifikate bestätigen z.B. nur den Namen des, bzw. die Identität des zertifizierten Gegenstandes – d.h. die Domain eines Servers oder einer Email-Adresse. Finden weitergehende Prüfungen statt und kann neben dem Berechtigten Vertretungsanspruch auch die Identität hinreichend sichergestellt werden, kann diese in das Zertifikat aufgenommen werden, was zu einem sog. Class-3-Zertifikat führt. Für erhöhte Sicherheit kann sogar eine sogenannte „Extended Validation“ vorgenommen werden, wie sie besonders bei bekannten Seiten wie eBay anzutreffen ist.

Die von einer CA ausgestellten Zertifikate können für eine Reihe unterschiedlicher Aufgaben verwendet werden. Der wohl häufigste und daher auch bekannteste Fall sind sogenannte Server-Zertifikate, die z.B. beim Online-Banking oder verschlüsselten Login an Webanwendungen zum Schutz der übertragenen Daten eingesetzt werden. Mit diesen Zertifikaten identifiziert sich ein Webserver bei einem Client (zumeist Browser), dass er der gültige Vertreter für einen bestimmten Domainnamen ist, was vom Client basierend auf der in dem Zertifikat enthaltenen Unterschrift der CA überprüfen kann.

Was für Server funktioniert, geht analog aber auch für Clients: Mit sogenannten Client-Zertifikaten kann sich eine Anwendung, bzw. ein Anwender gegenüber einem System identifizieren um so – ganz vergleichbar mit einem Kennwort – Zugang zu diesem zu erhalten. Neben dieser Authentifizierungsfunktion können diese aber auch für das Unterschreiben und Verschlüsseln von Emails verwendet werden, was basierend auf dem hierzu verwendeten Standard oftmals auch als S/MIME (Secure Multipurpose Internet Mail Extensions) bezeichnet wird und analog PGP/MIME (Pretty Good Privacy, RFC 2440 und RFC 4880) funktioniert. Weiterhin bieten Client-Zertifikate je nach enthaltenen Angaben zudem die Möglichkeit, sogenannte SSO (Single Sign-On) zu realisieren, was eine Nutzung zur Authorisierung darstellt.

Neben diesen Authorisierungsaufgaben lässt sich mit Zertifikaten jedoch auch die Echtheit von Dokumenten bestätigen, was unter anderem bei der Authentizitätsprüfung von Programmcode zum Einsatz kommt. Neben dem Signieren von Java-Applets und dem von Microsoft entwickelten AuthentiCode gibt es je nach Platform zahlreiche weitere Systeme. Die Validierung findet hierbei anhand eines, aus den Daten des zu prüfenden Dokumentes oder Programmcodes gebildeten, Fingerabdrucks statt, der dieses möglichst zweifelsfrei identifizieren soll. Der Fingerabdruck wird dabei so gebildet, dass bereits kleine Änderungen am Dokument ausreichen, um eine große Änderung im Fingerprint zu erzeugen.

Der Fingerprint einer Nachricht ist somit bei diesem Schutzsystem eine der zentralen Komponenten, die jedoch alleine wertlos wäre, da jedermann diesen Fingerabdruck aus Gründen der Überprüfbarkeit berechnen können muss. Um dieses Problem zu beheben, setzt man daher in Zertifikaten sogenannte asymmetrische Krypto-Verfahren ein. Bei diesen existieren statt einem symmetrischen Schlüssel zwei oder mehr getrennte Schlüssel, die jeweils zu unterschiedlichen Aufgaben verwendet werden: So kann einer der Teilschlüssel nur Verschlüsseln, ein anderer nur Entschlüsseln. Welcher der Schlüssel dabei welche Aufgabe übernimmt, ist in einem Krypto-Protokoll „per Konvention“ festgelegt. Die Schlüssel werden hierbei oft als Private Key bzw. Public Key bezeichnet, was auf den nötigen Schutzstatus dieser Komponenten eingeht. Der Public Key dient bei einem solchen System hierbei der Verschlüsslung und der Unterschriften-Verifikation, während der Private Key für das Entschlüsseln und das Unterschreiben von Dokumenten verwendet wird.

Soviel zur Vorrede, wir wollten uns eigene Client-Zertifikate erstellen 😉 Also dann los!

Der erste Schritt beim Erstellen eines SSL-Zertifikates ist es, sich eine Reihe von Rahmendaten zu überlegen. Diese beinhalten neben der Länge (und damit der Stärke) des Schlüssels auch Überlegungen in Bezug auf die Verwendung und die einzubettenden Informationen. So können kurze Schlüssel von etwa 1024 Bit bereits in überschaubarer Zeit geknackt werden (RSA 768 wurde bereits faktorisiert), weshalb man in der Regel solche Schlüssel vermeiden sollte. Oftmals findet man derzeit Schlüssel mit 4096 Bit; möchte man jedoch etwas Längerfristiges haben, sollte man gleich auf 8192 Bit oder höher gehen; muss dann aber beachten, dass Operationen mit derart langen Schlüsseln deutlich spürbar Zeit benötigen (Der Verbindungsaufbau zu einem HTTPS-Server mit einem 8192-Bit-Zertifikat kann durchaus 2-3 Sekunden benötigen!) oder anderwertig Kompatibilitätsprobleme verursachen, wenn die verwendeten Bibliotheken mit den eingesetzten Schlüssellängen nicht korrekt arbeiten können.

Hat man sich nun für eine bestimmte Schlüssellänge entschieden, kann man sich einen Private-Key mit zugehörigem Public Key mit Hilfe von OpenSSL recht einfach erzeugen:

openssl genrsa -out client.key 8192

Je nach Rechner UND verfügbarem Vorrat an Zufallszahlen kann dieser Vorgang wenige Sekunden bis mehrere Minuten, Stunden oder Tage brauchen (letzteres jedoch nur mit einem 65536-Bit-Schlüssel ausprobiert, dessen Erzeugung ~4 Tage benötigte). Hat man diesen Schritt erledigt, ist der zeitaufwändige Teil der Arbeit auch bereits getan. Wer an dieser Stelle „Zeit sparen“ möchte und daher die Schlüsselerzeugung von einem Drittanbieter durchführen lässt (und sei es von der CA), darf an dieser Stelle seinen frisch generierten Schlüssel gleich wieder entsorgen, da er nicht mehr als vertrauenswürdig gelten darf und damit ungesehen widerrufen (revoked) und vernichtet gehört – auch wenn einige CAs wie z.B. StartCom dies als „Service“ anbieten.

Hat man nun einen vertrauenswürdigen Schlüssel erstellt und eine Datei client.key erhalten, geht es an den zweiten Schritt: Das Erstellen einer „Unterzeichnungsanforderung“ bzw. „Certificate Signing Request“. Dies ist eine Datei, in der man seiner CA neben dem Public Key des soeben erzeugten Schlüsselpaars eine Reihe von weiteren Angaben mitteilt, die man in das Zertifikat aufgenommen haben möchte. Um dies zu bewerkstelligen gibt es im Wesentlichen zwei Methoden:

1. Interaktiv
oder
2. Batch Mode, ohne Nachfragen

Existiert für OpenSSL keine Konfigurationsdatei, führt der folgende Befehl den interaktiven Modus aus. OpenSSL erfragt hierbei alle fehlenden Informationen der Reihe nach um daraus das Zertifikat zu erstellen:

openssl req -new -key client.key -out client.csr

Möchte man das Erstellen der CSR ohne Nachfragen erledigen oder hat mit dem interaktiven Modus Probleme, geht dies durch Angabe einer Konfigurationsdatei client.cfg. Diese sieht etwa wie folgt aus:

[ req ]
default_bits       = 8192
distinguished_name = req_DN
string_mask        = nombstr

[ req_DN ]
countryName                     = "1. Country Name             (2 letter code)"
countryName_default             = DE
countryName_min                 = 2
countryName_max                 = 2
stateOrProvinceName             = "2. State or Province Name   (full name)    "
#stateOrProvinceName_default     =
localityName                    = "3. Locality Name            (eg, city)     "
localityName_default            = Chemnitz
0.organizationName              = "4. Organization Name        (eg, company)  "
0.organizationName_default      = Mustermann
organizationalUnitName          = "5. Organizational Unit Name (eg, section)  "
#organizationalUnitName_default  =
commonName                      = "6. Common Name              (eg, CA name)  "
commonName_max                  = 64
commonName_default              = Max Mustermann
emailAddress                    = "7. Email Address            (eg, name@FQDN)"
emailAddress_max                = 40
emailAddress_default            = max.mustermann@example.org

Ist diese Datei erstellt UND an die eigenen Bedürfnisse angepasst, kann man das CSR aus dem Keyfile wie folgt erzeugen:

openssl req -config client.cfg -new -key client.key -out client.csr

Unabhängig von der in diesem zweiten Schritt gewählten Methode entsteht nun im Idealfall die Datei client.csr, die im sogenannten PEM-Format vorliegt. Dieses beinhaltet in Base64-kodierter Form eine Vorstufe für das zu erstellende X.509-Zertifikates. Die CSR-Datei kann somit als „Textdatei“ betrachtet werden und ohne Weiteres in jedem beliebigen Editor geöffnet werden. Da sich Base64 jedoch in der Regel zum Lesen relativ bescheiden macht, kann man mit OpenSSL die in das CSR aufgenommenen Angaben anzeigen lassen:

openssl req -text -noout -in client.csr

Stimmen die im CSR enthaltenen Angaben, kann man nun fortfahren und den im CSR enthaltenen Textblock im nächsten Schritt für das Unterschreiben durch die CA kopieren. Mehr dazu aber gleich.

Denn hier wären wir auch schon bei einer zweiten Falle: Klar, kann man sich sein Zertifikat an dieser Stelle auch selber unterschreiben, da dies aber genauso viel Aussagekraft wie die mündliche Behauptung der Identität bei einer polizeilichen Ausweiskontrolle besitzt, werde ich hierauf nicht weiter eingehen. Auch hier gilt: Wenn man sinnvoll mit Zertifikaten arbeiten möchte, sollte man es richtig tun – und Selfsigned-Zertifikate gehören aus verschiedenen Gründen abgeschafft.

Also: Wir gehen daher auf die Seite der CA unserer Wahl (in meinem Fall CAcert), melden uns an, gehen auf „Neues Client-Zertifikat“ und finden hoffentlich (ggf. durch einen Klick auf Erweitert) ein Eingabefeld mit der Beschriftung „CSR“ bzw. „Certificate Signing Request“ – was man als gutes Zeichen interpretieren darf, dass genau hier dieser etwa 2 Bildschirmseiten lange Zeichensalat aus der CSR-Datei reinkopiert werden darf. Wer Maschineschreiben üben möchte, darf aber auch die Gelegenheit beim Schopfe packen und den gesamten Block Zeichen für Zeichen abschreiben. Unter Umständen sollte man nun – möglichst VOR dem Absenden – die anderen Felder des Formulars der CA beachten und auf korrekte Werte prüfen. Ist man mit den Angaben zufrieden, darf man das Formular getrost absenden oder aber es sich anders überlegen und es sein lassen 😛

Nach dem Absenden des Formulars erhält man – abhängig von der CA – entweder das unterschriebene Zertifikat via Mail, als Download ODER wie es bei CAcert ist: als unansehnlichen Textklumpen in der Antwortseite. In jedem Falle sorgt man dafür, dass die Antwort der CA in eine Datei mit dem Namen client.crt manövriert wird und man nun im letzten Schritt die Nutzung des Zertifikats vorbereiten kann, auch wenn man theoretisch bereits jetzt alle nötigen Informationen für die Verwendung hätte.

Dieser letzte Schritt ist jedoch dennoch nötig, da zahlreiche Programme – um nicht zu sagen eigentlich alle -, die mit Client-Zertifikaten hantieren mit losen .key+.crt-Files reichlich wenig anfangen können (wollen). Daher muss man im letzten Schritt die Informationen der Key-File mit denen des unterschriebenen Zertifikats zusammenführen, was sich ganz einfach wie folgt realisieren lässt:

openssl pkcs12 -export -in client.crt -inkey client.key -out client.pfx

Die in diesem Schritt erzeugte client.pfx ist als PKCS#12 kodiert und enthält nun sowohl den privaten, wie auch den öffentlichen Schlüssel und die von der CA erzeugte Unterschrift in einer einzigen Datei. Diese kann nun über die Zertifikatsverwaltung von Thunderbird (Extras –> Einstellungen –> Erweitert –> Zertifikate), Firefox (genauso), Explodierer (Extras –> Internetoptionen –> Sicherheit –> Zertifikate) oder anderen Browsern als „Client-Zertifikat“ importiert werden und sollte unter „Ihre Zertifikate“ auftauchen. Zudem ist es im Thunderbird explizit nötig, unter Extras –> Kontoeinstellungen unter dem Punkt S/MIME das korrekte Zertifikat für die Mailverschlüsslung auszuwählen. In beiden Eingabefeldern sollte hierbei der gleiche Eintrag ausgewählt werden.

Ist bis hierhin alles gutgegangen, sollte man nun sein Client-Zertifikat problemlos verwenden können, indem man beim Erstellen von Mails bei dem Dropdown-Button S/MIME den Punkt Unterschreiben anhakt. Hat man vom gewünschten Empfänger auch ein Zertifikat verfügbar, so kann zusätzlich auch der Punkt Verschlüsseln ausgewählt werden.

Am Ende noch eine kurze Anmerkung zu den während der Ausführung von OpenSSL erfragten Passphrasen: Diese dienen dem Schutz des Private Keys für den Fall, dass die .key- bzw. .pfx-Datei einmal in fremde Hände fallen sollten. Daher sollten hier ausreichend sichere Passphrasen verwendet werden. Die Eingabe dieser Passphrasen ist immer dann wichtig, wenn auf die unverschlüsselten Daten des privaten Schlüsselteils zugegriffen werden muss. Weder die .csr noch das von der CA erzeugte .crt enthalten den Private Key und können daher problemlos veröffentlicht werden, wobei es sich bei der CSR nur um eine Transport-Datei handelt, die nach Ausstellung des CRT-Files gelöscht werden kann. Möchte man mit jemand anderem verschlüsselt kommunizieren benötigt man allein die CRT-Datei vom gegenüber in seinem Mailprogramm importiert. Dies geschieht in der Regel automatisch, wenn man von jemandem eine mit S/MIME unterschriebene Email erhält.

Ich hoffe, dieser Anleitung für sichere Client-Zertifikate war einfach zu folgen und alle Schritte konnten Problemlos nachvollzogen werden. Fragen beantworte ich jedoch auch noch in den Kommentare, sollten diese auftauchen.