{"id":606,"date":"2010-04-01T22:13:17","date_gmt":"2010-04-01T20:13:17","guid":{"rendered":"http:\/\/blog.benny-baumann.de\/?p=606"},"modified":"2010-04-01T22:13:17","modified_gmt":"2010-04-01T20:13:17","slug":"client-zertifikate-leichtgemacht","status":"publish","type":"post","link":"https:\/\/blog.benny-baumann.de\/?p=606","title":{"rendered":"Client-Zertifikate leichtgemacht"},"content":{"rendered":"

Wenn man sich im Internet umschaut, findet man zu Hauf Anleitungen<\/a>, wie man SSL<\/a>-Zertifikate f\u00fcr 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\u00e4nge zwischen den verschiedenen Schritten und was jeder einzelne von ihnen bewirkt. Daher m\u00f6chte ich mit dieser Anleitung einmal versuchen, ein wenig Licht in’s Dunkel der Zertifikate zubringen.<\/p>\n

Eine sehr h\u00e4ufig genutzte, aber bei weitem nicht die einzige, M\u00f6glichkeit, um solche Zertifikate zu erstellen, ist OpenSSL<\/a>. Dieses wird an zahlreichen Stellen eingesetzt und ist zudem auf vielen Plattformen verf\u00fcgbar. Zudem genie\u00dft OpenSSL den Bonus, sich durch seine Unhandlichkeit auf faszinierende Weise von der Konkurrenz abzuheben, um nicht die gnadenlose Eignung als Geschenk f\u00fcr Sadisten zu betonen. Und genau daher werde ich es im Folgenden zur Erkl\u00e4rung des Sachverhaltes nutzen.<\/p>\n

Aber im Grunde ist SSL recht einfach: Damit man mit einem Unbekannten sicher und vertraulich kommunizieren kann, ben\u00f6tigt man in der Regel einen vertrauensw\u00fcrdigen Dritten<\/a>, der einem dabei hilft, die Identit\u00e4t seines Gegen\u00fcber zu best\u00e4tigen. Diese vertrauensw\u00fcrdigen Dritten hei\u00dfen in der Terminologie der X.509<\/a>-Zertifikate „Certificate Authorities“, also „Zertifizierungsstellen“. Hier bekommt man keine Certificates of Authenticity, wie sie auf jedem billigen Discounter-Notebook kleben, sondern eine Best\u00e4tigung seiner Identit\u00e4t. Je nach CA sind f\u00fcr diese Best\u00e4tigung unterschiedliche Dinge notwendig, was von einem einfachen „Ich glaub’s einfach mal“ (Comodo anyone?<\/a>), \u00fcber das pers\u00f6nliche Treffen mit dem Anw\u00e4rter (CAcert) aber auch bis hin zu millionenschweren Pr\u00fcfungen von aktenschrankweise anzuh\u00e4ufenden Papieren und Bescheinigungen kann. Abh\u00e4ngig von der Art der Pr\u00fcfung f\u00e4llt dann auch das Zertifizierungslevel aus. Einfache Class-1-Zertifikate best\u00e4tigen z.B. nur den Namen des, bzw. die Identit\u00e4t des zertifizierten Gegenstandes – d.h. die Domain eines Servers oder einer Email-Adresse. Finden weitergehende Pr\u00fcfungen statt und kann neben dem Berechtigten Vertretungsanspruch auch die Identit\u00e4t hinreichend sichergestellt werden, kann diese in das Zertifikat aufgenommen werden, was zu einem sog. Class-3-Zertifikat f\u00fchrt. F\u00fcr erh\u00f6hte Sicherheit kann sogar eine sogenannte „Extended Validation“ vorgenommen werden, wie sie besonders bei bekannten Seiten wie eBay anzutreffen ist.<\/p>\n

Die von einer CA ausgestellten Zertifikate k\u00f6nnen f\u00fcr eine Reihe unterschiedlicher Aufgaben verwendet werden. Der wohl h\u00e4ufigste und daher auch bekannteste Fall sind sogenannte Server-Zertifikate, die z.B. beim Online-Banking oder verschl\u00fcsselten Login an Webanwendungen zum Schutz der \u00fcbertragenen Daten eingesetzt werden. Mit diesen Zertifikaten identifiziert sich ein Webserver bei einem Client (zumeist Browser), dass er der g\u00fcltige Vertreter f\u00fcr einen bestimmten Domainnamen ist, was vom Client basierend auf der in dem Zertifikat enthaltenen Unterschrift der CA \u00fcberpr\u00fcfen kann.<\/p>\n

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

Neben diesen Authorisierungsaufgaben l\u00e4sst sich mit Zertifikaten jedoch auch die Echtheit von Dokumenten best\u00e4tigen, was unter anderem bei der Authentizit\u00e4tspr\u00fcfung von Programmcode<\/a> zum Einsatz kommt. Neben dem Signieren von Java-Applets<\/a> und dem von Microsoft entwickelten AuthentiCode<\/a> gibt es je nach Platform zahlreiche weitere Systeme. Die Validierung findet hierbei anhand eines, aus den Daten des zu pr\u00fcfenden Dokumentes oder Programmcodes gebildeten, Fingerabdrucks<\/a> statt, der dieses m\u00f6glichst zweifelsfrei identifizieren soll. Der Fingerabdruck wird dabei so gebildet, dass bereits kleine \u00c4nderungen am Dokument ausreichen, um eine gro\u00dfe \u00c4nderung im Fingerprint zu erzeugen.<\/p>\n

Der Fingerprint einer Nachricht ist somit bei diesem Schutzsystem eine der zentralen Komponenten, die jedoch alleine wertlos w\u00e4re, da jedermann diesen Fingerabdruck aus Gr\u00fcnden der \u00dcberpr\u00fcfbarkeit berechnen k\u00f6nnen muss. Um dieses Problem zu beheben, setzt man daher in Zertifikaten sogenannte asymmetrische Krypto-Verfahren<\/a> ein. Bei diesen existieren statt einem symmetrischen Schl\u00fcssel zwei oder mehr getrennte Schl\u00fcssel, die jeweils zu unterschiedlichen Aufgaben verwendet werden: So kann einer der Teilschl\u00fcssel nur Verschl\u00fcsseln, ein anderer nur Entschl\u00fcsseln. Welcher der Schl\u00fcssel dabei welche Aufgabe \u00fcbernimmt, ist in einem Krypto-Protokoll „per Konvention“ festgelegt. Die Schl\u00fcssel werden hierbei oft als Private Key bzw. Public Key bezeichnet, was auf den n\u00f6tigen Schutzstatus dieser Komponenten eingeht. Der Public Key dient bei einem solchen System hierbei der Verschl\u00fcsslung und der Unterschriften-Verifikation, w\u00e4hrend der Private Key f\u00fcr das Entschl\u00fcsseln und das Unterschreiben von Dokumenten verwendet wird.<\/p>\n

Soviel zur Vorrede, wir wollten uns eigene Client-Zertifikate erstellen \ud83d\ude09 Also dann los!<\/p>\n

Der erste Schritt beim Erstellen eines SSL-Zertifikates ist es, sich eine Reihe von Rahmendaten zu \u00fcberlegen. Diese beinhalten neben der L\u00e4nge (und damit der St\u00e4rke) des Schl\u00fcssels auch \u00dcberlegungen in Bezug auf die Verwendung und die einzubettenden Informationen. So k\u00f6nnen kurze Schl\u00fcssel von etwa 1024 Bit bereits in \u00fcberschaubarer Zeit geknackt werden (RSA 768 wurde bereits faktorisiert<\/a>), weshalb man in der Regel solche Schl\u00fcssel vermeiden sollte. Oftmals findet man derzeit Schl\u00fcssel mit 4096 Bit; m\u00f6chte man jedoch etwas L\u00e4ngerfristiges haben, sollte man gleich auf 8192 Bit oder h\u00f6her gehen; muss dann aber beachten, dass Operationen mit derart langen Schl\u00fcsseln deutlich sp\u00fcrbar Zeit ben\u00f6tigen (Der Verbindungsaufbau zu einem HTTPS-Server mit einem 8192-Bit-Zertifikat kann durchaus 2-3 Sekunden ben\u00f6tigen!) oder anderwertig Kompatibilit\u00e4tsprobleme verursachen, wenn die verwendeten Bibliotheken mit den eingesetzten Schl\u00fcssell\u00e4ngen nicht korrekt arbeiten k\u00f6nnen.<\/p>\n

Hat man sich nun f\u00fcr eine bestimmte Schl\u00fcssell\u00e4nge entschieden, kann man sich einen Private-Key mit zugeh\u00f6rigem Public Key mit Hilfe von OpenSSL recht einfach erzeugen:<\/p>\n

openssl genrsa -out client.key 8192<\/pre>\n
Je nach Rechner UND verf\u00fcgbarem Vorrat an Zufallszahlen<\/a> kann dieser Vorgang wenige Sekunden bis mehrere Minuten, Stunden oder Tage brauchen (letzteres jedoch nur mit einem 65536-Bit-Schl\u00fcssel ausprobiert, dessen Erzeugung ~4 Tage ben\u00f6tigte). Hat man diesen Schritt erledigt, ist der zeitaufw\u00e4ndige Teil der Arbeit auch bereits getan. Wer an dieser Stelle „Zeit sparen“ m\u00f6chte und daher die Schl\u00fcsselerzeugung von einem Drittanbieter durchf\u00fchren l\u00e4sst (und sei es von der CA), darf an dieser Stelle seinen frisch generierten Schl\u00fcssel gleich wieder entsorgen, da er nicht mehr als vertrauensw\u00fcrdig gelten darf und damit ungesehen widerrufen (revoked) und vernichtet geh\u00f6rt – auch wenn einige CAs wie z.B. StartCom dies als „Service“ anbieten<\/a>.<\/p>\n
Hat man nun einen vertrauensw\u00fcrdigen Schl\u00fcssel 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\u00fcsselpaars eine Reihe von weiteren Angaben mitteilt, die man in das Zertifikat aufgenommen haben m\u00f6chte. Um dies zu bewerkstelligen gibt es im Wesentlichen zwei Methoden:<\/p>\n
1. Interaktiv
\noder
\n2. Batch Mode, ohne Nachfragen<\/p>\n
Existiert f\u00fcr OpenSSL keine Konfigurationsdatei, f\u00fchrt der folgende Befehl den interaktiven Modus aus. OpenSSL erfragt hierbei alle fehlenden Informationen der Reihe nach um daraus das Zertifikat zu erstellen:<\/p>\n
openssl req -new -key client.key -out client.csr<\/pre>\n
M\u00f6chte man das Erstellen der CSR ohne Nachfragen erledigen oder hat mit dem interaktiven Modus Probleme, geht dies durch Angabe einer Konfigurationsdatei<\/a> client.cfg. Diese sieht etwa wie folgt aus:<\/p>\n
\r\n[ req ]\r\ndefault_bits       = 8192\r\ndistinguished_name = req_DN\r\nstring_mask        = nombstr\r\n\r\n[ req_DN ]\r\ncountryName                     = \"1. Country Name             (2 letter code)\"\r\ncountryName_default             = DE\r\ncountryName_min                 = 2\r\ncountryName_max                 = 2\r\nstateOrProvinceName             = \"2. State or Province Name   (full name)    \"\r\n#stateOrProvinceName_default     =\r\nlocalityName                    = \"3. Locality Name            (eg, city)     \"\r\nlocalityName_default            = Chemnitz\r\n0.organizationName              = \"4. Organization Name        (eg, company)  \"\r\n0.organizationName_default      = Mustermann\r\norganizationalUnitName          = \"5. Organizational Unit Name (eg, section)  \"\r\n#organizationalUnitName_default  =\r\ncommonName                      = \"6. Common Name              (eg, CA name)  \"\r\ncommonName_max                  = 64\r\ncommonName_default              = Max Mustermann\r\nemailAddress                    = \"7. Email Address            (eg, name@FQDN)\"\r\nemailAddress_max                = 40\r\nemailAddress_default            = max.mustermann@example.org\r\n<\/pre>\n
Ist diese Datei erstellt UND an die eigenen Bed\u00fcrfnisse angepasst, kann man das CSR aus dem Keyfile wie folgt erzeugen:<\/p>\n
openssl req -config client.cfg -new -key client.key -out client.csr<\/pre>\n
Unabh\u00e4ngig von der in diesem zweiten Schritt gew\u00e4hlten Methode entsteht nun im Idealfall die Datei client.csr, die im sogenannten PEM-Format vorliegt. Dieses beinhaltet in Base64-kodierter Form eine Vorstufe f\u00fcr das zu erstellende X.509-Zertifikates. Die CSR-Datei kann somit als „Textdatei“ betrachtet werden und ohne Weiteres in jedem beliebigen Editor ge\u00f6ffnet 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:<\/p>\n
openssl req -text -noout -in client.csr<\/pre>\n
Stimmen die im CSR enthaltenen Angaben, kann man nun fortfahren und den im CSR enthaltenen Textblock im n\u00e4chsten Schritt f\u00fcr das Unterschreiben durch die CA kopieren. Mehr dazu aber gleich.<\/p>\n
Denn hier w\u00e4ren 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\u00fcndliche Behauptung der Identit\u00e4t bei einer polizeilichen Ausweiskontrolle besitzt, werde ich hierauf nicht weiter eingehen. Auch hier gilt: Wenn man sinnvoll mit Zertifikaten arbeiten m\u00f6chte, sollte man es richtig tun – und Selfsigned-Zertifikate geh\u00f6ren aus verschiedenen Gr\u00fcnden abgeschafft.<\/p>\n
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 \u00fcben m\u00f6chte, darf aber auch die Gelegenheit beim Schopfe packen und den gesamten Block Zeichen f\u00fcr Zeichen abschreiben. Unter Umst\u00e4nden sollte man nun – m\u00f6glichst VOR dem Absenden – die anderen Felder des Formulars der CA beachten und auf korrekte Werte pr\u00fcfen. Ist man mit den Angaben zufrieden, darf man das Formular getrost absenden oder aber es sich anders \u00fcberlegen und es sein lassen \ud83d\ude1b<\/p>\n
Nach dem Absenden des Formulars erh\u00e4lt man – abh\u00e4ngig 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\u00fcr, dass die Antwort der CA in eine Datei mit dem Namen client.crt man\u00f6vriert wird und man nun im letzten Schritt die Nutzung des Zertifikats vorbereiten kann, auch wenn man theoretisch bereits jetzt alle n\u00f6tigen Informationen f\u00fcr die Verwendung h\u00e4tte.<\/p>\n
Dieser letzte Schritt ist jedoch dennoch n\u00f6tig, da zahlreiche Programme – um nicht zu sagen eigentlich alle -, die mit Client-Zertifikaten hantieren mit losen .key+.crt-Files reichlich wenig anfangen k\u00f6nnen (wollen). Daher muss man im letzten Schritt die Informationen der Key-File mit denen des unterschriebenen Zertifikats zusammenf\u00fchren, was sich ganz einfach wie folgt realisieren l\u00e4sst:<\/p>\n
openssl pkcs12 -export -in client.crt -inkey client.key -out client.pfx<\/pre>\n
Die in diesem Schritt erzeugte client.pfx ist als PKCS#12<\/a> kodiert und enth\u00e4lt nun sowohl den privaten, wie auch den \u00f6ffentlichen Schl\u00fcssel und die von der CA erzeugte Unterschrift in einer einzigen Datei. Diese kann nun \u00fcber 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\u00f6tig, unter Extras –> Kontoeinstellungen unter dem Punkt S\/MIME das korrekte Zertifikat f\u00fcr die Mailverschl\u00fcsslung auszuw\u00e4hlen. In beiden Eingabefeldern sollte hierbei der gleiche Eintrag ausgew\u00e4hlt werden.<\/p>\n
Ist bis hierhin alles gutgegangen, sollte man nun sein Client-Zertifikat problemlos verwenden k\u00f6nnen, indem man beim Erstellen von Mails bei dem Dropdown-Button S\/MIME den Punkt Unterschreiben anhakt. Hat man vom gew\u00fcnschten Empf\u00e4nger auch ein Zertifikat verf\u00fcgbar, so kann zus\u00e4tzlich auch der Punkt Verschl\u00fcsseln ausgew\u00e4hlt werden.<\/p>\n
Am Ende noch eine kurze Anmerkung zu den w\u00e4hrend der Ausf\u00fchrung von OpenSSL erfragten Passphrasen: Diese dienen dem Schutz des Private Keys f\u00fcr den Fall, dass die .key- bzw. .pfx-Datei einmal in fremde H\u00e4nde fallen sollten. Daher sollten hier ausreichend sichere Passphrasen verwendet werden. Die Eingabe dieser Passphrasen ist immer dann wichtig, wenn auf die unverschl\u00fcsselten Daten des privaten Schl\u00fcsselteils zugegriffen werden muss. Weder die .csr noch das von der CA erzeugte .crt enthalten den Private Key und k\u00f6nnen daher problemlos ver\u00f6ffentlicht werden, wobei es sich bei der CSR nur um eine Transport-Datei handelt, die nach Ausstellung des CRT-Files gel\u00f6scht werden kann. M\u00f6chte man mit jemand anderem verschl\u00fcsselt kommunizieren ben\u00f6tigt man allein die CRT-Datei vom gegen\u00fcber in seinem Mailprogramm importiert. Dies geschieht in der Regel automatisch, wenn man von jemandem eine mit S\/MIME unterschriebene Email erh\u00e4lt.<\/p>\n
Ich hoffe, dieser Anleitung f\u00fcr 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.<\/p>\n
\"Flattr<\/a><\/p>","protected":false},"excerpt":{"rendered":"
Wenn man sich im Internet umschaut, findet man zu Hauf Anleitungen, wie man SSL-Zertifikate f\u00fcr 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\u00e4nge zwischen den verschiedenen Schritten und was jeder […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[4],"tags":[38,15,69,112,61,346,50,237],"class_list":["post-606","post","type-post","status-publish","format-standard","hentry","category-server","tag-datenschutz","tag-firefox","tag-internet","tag-kryptographie","tag-openssl","tag-server","tag-ssl","tag-verschlusslung"],"_links":{"self":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts\/606","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=606"}],"version-history":[{"count":3,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts\/606\/revisions"}],"predecessor-version":[{"id":617,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts\/606\/revisions\/617"}],"wp:attachment":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=606"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=606"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=606"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}