Die eigene Certificate Authority (CA)

Wer wäre nicht gerne seine eigene CA? Statt teure Zertifikate von VeriSign und Co. zu kaufen, einfach seine Anträge selber unterschreiben! Technisch ist das kein Problem: Auch „echte“ CAs benutzen selbst unterschriebene Zertifikate, nur die sind eben in allen großen Browsern und Betriebssystemen installiert. Wenn man sich aber die Mühe macht, sein eigenes Root-Zertifikat an allen benutzten Rechnern zu installieren, ist es kein Problem seine eigene CA zu sein. Dabei muss man zwei Sachen beachten:

  • Windows hat zwar einen zentralen Zertifikatsspeicher, aber Firefox und Thunderbird benutzen (jeweils) einen eigenen. Das Zertifikat muss in allen installiert werden.
  • Es gibt einen unterschied zwischen einer eigenen CA und selbst unterschriebenen Zertifikaten: Die selber abgesegneten Zertifikate muss man alle einzeln bestätigen, wobei hingegen es reicht das eigene Root-Zertifikat zu installieren, um automatisch allen davon unterzeichneten Zertifikaten zu vertauen. Viele Programme generieren bei der Installation selbst-unterschriebene Zertifikate, die man also immer einzeln akzeptieren muss.

Fangen wir also an! Die Anleitung basiert auf dieser Beschreibung. Wir legen uns erst Mal einen neuen Ordner an, und wechseln zu root (hatte ich erwähnt, das ich von Linux rede?). Die Zertifikate sollte nach Möglichkeit nur von root gelesen werden können, daher ist es sinnvoll diesen Benutzer auch zum erstellen zu benutzen.


openssl genrsa -des3 -out ca.key 4096
 openssl req -new -x509 -days 365 -key ca.key -out ca.crt

Diese beiden Zeilen generieren zunächst einen privaten Schlüssel in der Datei ca.key, der mit einem Passwort geschützt wird. Er sollte nicht aus der Hand gegeben werden! Er ist zwar passwortgeschützt, aber er beinhaltet eben den privaten Schlüssel, den wir zum signieren brauchen. Wem das jetzt allen nichts sagt, macht sich bei Wikipedia schlau: Asymmetrische Kryptosysteme. Kurzfassung: Mit dem privaten Schlüssel kann man Zertifikate signieren, mit dem öffentlichen nur Signaturen überprüfen.

Die zweite Zeile erzeugt jetzt eben diesen öffentlichen Schlüssel, der zusammen mit ein paar Daten zum Aussteller in der Datei ca.crt landen. Alle Texte sind beliebig, wenn man nichts angeben will, reicht ein Punkt (.). Der Parameter hinter days gibt die Gültigkeitsdauer an, ein Jahr ist evtl. etwas kurz, 10 sollten reichen. Dieser Zertifikat wird nun automatisch selber unterschrieben, weil es ja niemanden gibt, der eine CA bestätigen kann.

Jetzt kommt das Erstellen eines neuen Zertifikates dran:


openssl genrsa -des3 -out server.key 4096
 openssl req -new -key server.key -out server.csr

Wir erstellen wieder einen Key, der auch mit einem Passwort geschützt wird. Danach erstellen wir statt einem Zertifikat wie oben, einen Certificate-Sign-Request (.csr). Es werden wieder ein paar Daten abgefragt, doch  hier ist es nicht ganz egal, was angegeben wird: Der CommonName (CN) sollte zum Server passen! Wenn das nicht der Fall ist, gibt es beim Starten des Servers eine Warnung, und die Client beschweren sich, das es einen Identitätsdiebstal gab, weil Domain und CN eben nicht passen. Für Webserver sollte man hier *.domain.tld angeben (mit den richtigen Werten natürlich), für Mail und FTP Server sollte genau der passende Name angegeben werden. Wenn man auch noch Email-Zertifikate haben will, muss die Email-Adresse hier angegeben werden.

Jetzt spielen wir wieder CA: (Das ist das, wofür die so viel Geld haben wollen:)


openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

Wir signieren den Request, den wir grade erstellt haben für 356 Tage (anpassen, 3560 ist besser), und benutzen dabei unser oben erstelltes CA-Zertifikat. Dabei wird auch nach dem Passwort des CA-Private-Keys gefragt, denn der ist zum signieren nötig. Die Seriennummer muss angepasst werden, wenn ein neues Zertifikat für den gleichen Domain ausgestellt wird (z.B. weil es abgelaufen ist): Client speichern das Zertifikat bei der ersten Verbindung und beschweren sich, wenn es sich geändert hat (könnte ja ein Hacker gewesen sein). Wenn die Seriennummer anders ist, gibt es kein Warnung.

Damit landet jetzt das unterschriebene Zertifikat in der Datei server.crt. Wenn man das Zertifikat jetzt in einem Server benutzen will, muss der den privaten Schlüssel beim Start laden, und braucht dazu das Passwort. Wem das zu blöd ist, kann das Passwort auch entfernen, muss dann aber mit geringerer Sicherheit leben. (Der private-key der CA sollte nie entschlüsselt werden!)


openssl rsa -in server.key -out server.key.insecure

So, damit ist unser Zertifikat fertig. Damit keine die private-keys klaut ist es keine schlecht Idee, diese nur für root lesbar zu machen. Die CSRs können gelöscht werden.

Nach diesem Muster kann man jetzt beliebig viele Zertifikate signieren. Allen wird vertraut, wenn denn das Root-Zertifikat installiert ist. Unter Firefox/Thunderbird geht das über Einstellungen/Erweitert/Zertifikate anzeigen/Zertifizierungstellen/Importieren (hier muss die öffentliche Datei importiert werden, also die .crt-Datei). Um das CA-Zertifikat Windows näher zu bringen öffnet man die Managment-Konsole per Win+R/mmc Dort wird ein SnapIn hinzugefügt: Strg+M/Zertifikate/Hinzufügen/Eigenes Benutzerkonto/Fertig stellen/OK. Das Zertifikat muss unter „Vertrauenswürdige Stammzertifizierungsstellen“ (was für ein Wort) eingefügt werden, was unter Kontext-Menü/Alle Aufgaben/Importieren möglich ist.

Fehlen nur noch die Server. Natürlich hängt das jetzt stark von der Software ab, ich erkläre einfach mal das, was ich gemacht habe:

Apache: In den passenden vHost müssen diese Anweisungen:


SSLEngine On
 SSLCertificateFile /etc/apache2/ssl/server.crt
 SSLCertificateKeyFile /etc/apache2/ssl/server.key

Also private Schlüssel und öffentliches Zertifikat, das dem Client geschickt wird. Danach ist natürlich ein Neustart/Reload von Apache nötig. Was mir leider trotzt langem Ausprobieren nicht geglückt ist, ist es meine Website die unter ISPConfig laufen (wie dieser Blog) mit Zertifikaten zu versehen. ISPConfig hat da sein eigenes System, das nicht so richtig will wie ich… Dennoch sieht es wenigstes für die Admin-Oberfläche jetzt so aus wie auf dem Bild.

Weiter gehts mit Courier: Der IMAP Daemon ist ziemlich einfach mit Zertifikaten zu beglücken: Einfach .key und .crt Datei ein eine .pem Datei kopieren (einfach hintereinander), und die Datei nach /etc/courier/imapd.pem schieben. Danach ist natürlich auch ein Neustart fällig.

Wie es mit Postfix (SMTP Daemon) geht steht hier schon wunderbar.

Als letztes bliebt noch der FTP-Server Pure-FTPd: Der hat etwas seltsame Ansichten, weil er keine Konfigurationsdateien benutzt… Das Zertifikat muss wieder zusammen mit dem Key in die Datei /etc/ssl/private/pure-ftpd.pem (der Dateiname ist einkompiliert), danach muss noch die Datei /etc/pure-ftpd/conf/TLS mit dem Inhalt „1“ angelegt werden. Nach einem Neustart spricht dann auch der FTP-Server SSL.

Fazit: Wenn man den Dreh erst Mal raus hat, ist es ziemlich einfach, alles per SSL abzusichern. Langsam beginne ich auch den Sinn hinter Sachen wie S/MIME oder der ePost zu sehen. Mit günstigen Zertifikaten, die nur mit Ausweis ausgestellt werden, wäre das echt praktisch… (Nicht so wie es die Post macht, aber vom Prinzip her). Wie alles bei Unix/Linux (oder besser im Server Umfeld) funktioniert es echt gut, und ist super durchdacht, wenn man es erst Mal verstanden hat…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert