SSL-Zertifikate gibt’s von einer Menge Anbietern. Wir nehmen unter anderem auch die Dienste von StartCom in Anspruch, bei denen wir am ehesten den Eindruck haben, dass die auch selbst was von Sicherheit verstehen – ein Eindruck, den fatalerweise viele SSL-Zertifizierungsstellen nicht machen.
Zu diesem Eindruck trägt auch bei, dass StartCom konsequent auf SSL-Client-Zertifikate zur Authentifizierung setzt, und nicht auf das klassische Paar aus Benutzername/Passwort. Technisch gesehen läuft das so, dass man einen kleinen Assistenten durchläuft, der eine Browserfunktion anwirft, die einen privaten Schlüssel direkt im Browser erzeugt und ablegt (sprich, er wird nie an den Website-Betreiber übermittelt) und anschließend auf dieser Basis dann ein Zertifikat generiert, was dann direkt in den Browser importiert wird. Ist der Prozess abgeschlossen, kann man sich mit diesem Zertifikat gegenüber der Website ausweisen. Im Prinzip ist das ein gutes Beispiel, wie man starke Authentifizierung wirklich bequem und einsteigerfreundlich machen kann, denn der ganze Prozess ist sehr einfach gestaltet und lässt sich auch ohne besondere Vorkenntnisse durchlaufen. Die Frage, die unerfahrene Anwender dabei noch am ehesten stellen, ist von daher weniger „Was muss ich hier machen?“, sondern eher „Wieso funktioniert das einfach so, ich musste ja nicht mal ein Passwort eingeben?!“ – tja, willkommen in der manchmal doch ganz schönen Welt von SSL.
Damals hatte ich diesen ganzen Prozess mit Firefox abgewickelt. Mittlerweile nutze ich im Alltag fast nur noch Chrome, genaugenommen die freie Variante Chromium, für die Tom „spot“ Calloway Fedora-Pakete pflegt. In puncto SSL unterscheidet sich Chromium von Firefox: Unter Linux benutzt es nämlich die NSS-Funktionalität des Systems, statt einen eigenen Keystore zu basteln (was ich für eine äußerst gute Idee halte), während Firefox auf allen Plattformen einen eigenständigen Keystore nutzt. Natürlich können die Client-Zertifikate in Form von PKCS#12-Dateien exportiert und im jeweils anderen Tool importiert werden – das nur so zum Hintergrund.
Nun laufen auch Client-Zertifikate irgendwann aus, so dass ein neues fällig wurde. Also habe ich den Client-Zertifikats-Assistenten von StartCom angeworfen – diesmal aber im Chromium. Nun ist aber gerade jenes „Certificate Enrollment“ derzeit noch eine Baustelle und läuft beileibe nicht „einfach so“ rund, wie ich es oben beim Firefox noch so gelobt habe. Und damit meine ich nicht, dass es mehr Handarbeit bräuchte, sondern dass es schlicht überhaupt nicht erfolgreich funktioniert. Hätte ich mal vorher nachgeschaut – hatte ich aber nun mal nicht.
Das vorläufige Ende vom Lied: Chromium hat es durchaus geschafft, einen privaten Schlüssel in der NSS-Datenbank zu erstellen. Mit dem Import des darauf basierenden Zertifikats hat das aber leider nicht geklappt: „Fehler 207 (net::ERR_CLIENT_CERT)“ war alles, was ich zu sehen bekam – sprich, das war ein Schuss in den Ofen – und zwar noch ein schlimmerer, als ich dachte: Die naheliegendste Lösung, den Key einfach wegzuschmeißen und ein neues Client-Zertifikat zu erstellen (diesmal dann wieder im Firefox) klappt nämlich auch nicht: StartCom lässt es nicht zu, ein Client-Zertifikat zu erstellen, wenn ein vorheriges noch gültig ist.
Dunkle Wolken ziehen am Horizont auf. Das von StartCom generierte Client-Zertifikat kann ich über deren Toolbox immer wieder beziehen; das ist nicht das Problem – nur funktioniert es eben nur in Kombination mit dem Key. Und das ist genau das Problem: Im Chromium (bzw. in der NSS-Datenbank) habe ich den Key, bekomme aber das Client-Zertifikat nicht rein. Der Firefox könnte zwar das Client-Zertifikat importieren, aber da er den Key nicht hat, schlägt das fehl.
Mein nächster Gedanke war: „Bei SSL-Server-Zertifikaten hantieren wir ja auch immer mit einer Datei für den privaten Schlüssel und einer Datei mit dem Zertifikat. Wieso also nicht einfach den Key aus der NSS-Datenbank exportieren und in Firefox importieren – und dann, wenn der Firefox den Key hat, kann er ja wohl auch das Zertifikat aus der Toolbox importieren.“
Denkste. Christopher wies mich direkt darauf hin:
Nein, Firefox kann nur Keys nur in PKCS-Dingsbums importieren, nicht roh. Also kannst es versuchen, aber bei Firefox…
Wäre ja nett gewesen, überhaupt bis zum diesem Punkt zu kommen. Faktisch ist es nämlich gar nicht möglich, nur den Key aus der NSS-Datenbank zu exportieren. Exportieren geht nur im PKCS#12-Format, und das besteht zwingend aus Key und Zertifikat. Nelson B Bolyard schreibt:
Bare private keys by themselves?
NSS utility programs are intended to NOT do that.
The idea is to NOT make it easy for the user to ruin his own security.
Ja, toll. Ich will aber nicht meine Security ruinieren; ich weiß ja, was ich hier tue und warum. Und ich habe mir beileibe auch nicht aus freien Stücken ausgesucht, so vorzugehen. Chris ergänzt: „Abandon all hope, ye who enter here“. Wie wahr.
So oder so: Dieser Weg war wohl ein Schuss in den Ofen. Also vielleicht doch anders herum, sprich, „irgendwie“ an das Zertifikat kommen und das manuell in die NSS-Datenbank mit reinpacken. Nur wie? Erstmal müsste man dazu wissen, wie denn die URL heißt, unter der man das Zertifikat bekommen kann. Und das ist nicht so ganz einfach, denn die Toolbox vom StartCom ist völlig ajaxisiert; man kann sich nicht einfach irgendwo mal schnell eine URL rauskopieren. Abhilfe schafft das Firefox-Plugin Live HTTP Headers, das die HTTP-Header jeglicher Browserkommunikation mitschneidet – also auch die der Ajax-Kommunikation. Und siehe da: Klappt prima, und ich komme auf eine URL in dieser Form:
https://www.startssl.com/getcrt.ssl?certID=...
Genau was ich brauche!
Leider ist es damit nicht getan, denn Firefox versucht beim Aufruf dieser URL sofort, das Zertifikats zu importieren – was natürlich nicht geht, weil der dazu passende private Schlüssel im Keystore vom Firefox ja fehlt. Ich will das Zertifikat ja auch eigentlich nicht importieren, sondern herunterladen, sprich: als Datei speichern. Das Problem kann man grob damit vergleichen, wenn man die URL eines Bilds direkt im Browser eingibt: Dann wird man ja auch nicht gefragt, ob man das Bild anzeigen oder speichern will, sondern es wird eben einfach angezeigt. Mit einem entscheidenden Unterschied: Ich kann dann immer noch über das Kontextmenü „Bild speichern unter …“ auswählen und das Bild auf die Platte bannen. Hier wird aber ja gerade gar nichts angezeigt – ergo hilft mir das Kontextmenü (und auch das Datei-Menü, das einen gleichnamigen Punkt bietet) überhaupt nicht weiter.
Der Workaround, auf den ich schließlich gekommen bin, gehört zu der Kategorie, bei der man sich mit einem herzhaften „D’oh!“ an die Stirn schlagen möchte. Also: Wo kann man sonst noch über das Kontextmenü Dinge direkt abspeichern? Richtig, bei Links, „Ziel speichern unter …“. Zwar ist die StartCom-Toolbox wie gesagt ajaxisiert und bietet daher keinen solchen Link, aber das macht nichts: Da wir ja nun die URL kennen, bauen wir uns einfach selbst einen Link in einer lokalen Datei, rufen diese via file:///tmp/link.html im Firefox auf, rechte Maustaste auf den Link, Ziel speichern unter, und voilà: Das Zertifikat ist im PEM-Format mit der Endung .p7b auf der Festplatte gespeichert.
Damit ist die größte Klippe umschifft. Nun gilt es nur noch, diese Datei in die NSS-Datenbank zu importieren, wo bereits der zugrundeliegende Key wartet:
certutil -d sql:$HOME/.pki/nssdb -A -t "u,u,u" -n "Jonas Pasche" -i cert.p7b
Klappt sofort – und spontan kann Chromium das SSL-Client-Zertifikat benutzen. Der Vollständigkeit halber soll es aber auch in den Firefox. Also exportieren wir es aus der NSS-Datenbank; um genau zu sein, exportieren wir Zertifikat und Key, denn es gibt ja nur beides in Kombination:
pk12util -d sql:$HOME/.pki/nssdb -o export.p12 -n "Jonas Pasche"
Die resultierende Datei kann dann schließlich problemlos in Firefox importiert werden – und ein ätzendes Problem mit einem zunächst verwaisten Key in der NSS-Datenbank hat seinen sauberen Abschluss gefunden.
Bleibt noch zu sagen, dass dieser ganze Krampf rein akademischer Natur war. Es hätte nämlich auch gereicht, sich in der StartCom-Toolbox ein neues Client-Zertifikat mit einer anderen E-Mail-Adresse generieren zu lassen. Entscheidend für die Anmeldung an der Toolbox ist schließlich nicht die Mail-Adresse, sondern die damit verbundene Identität, und da sämtliche Client-Zertifikate, die ich in meinem Account ausstelle, auch auf meine Identität verweisen, kann ich auch alle gleichermaßen für den Login benutzen. An dieser Stelle soll nicht unerwähnt bleiben, dass diese letzte – natürlich viel einfachere – Variante dem wie immer hervorragenden StartCom-Support eingefallen ist. Danke dafür!