22. Februar 2017

Ich bau mir eine Certificate Authority - Machst du mit?

Bereits in einem älteren Artikel habe ich schon über selbstsignierte TSL Zertifikate geschrieben. Wenn du mit dem Gedanken spielst, dir eine kleine Server Infrastruktur aufzubauen, dann würde ich dir sowieso empfehlen alles direkt über TSL zu lösen.

Mal abgesehen davon, dass durch die TSL-Zertifikate sowieso die Verbindung per se sicherer ist, gibt es auch Dienste, die keine unverschlüsselte Verbindung mehr erlauben.

Du kannst jetzt auch für jeden einzelnen Dienst (bzw. Webseite) in deinem Intranet ein eigenes Zertifikat kaufen. Aber ich glaube, so viel Geld bist du nicht bereit auszugeben.

Ich bin es jedenfalls nicht 😃

OK, alternativ kannst du dir auch selbst Zertifikate ausstellen. Die Browser haben bei diesen Zertifikaten die Angewohnheit diese als unsicher zu deklarieren. Und das nicht ohne Grund.

Solche Zertifikate werden nämlich von keiner bekannten Zertifizierungsstelle (Certificate Authority) unterschrieben.

Certificate Authority? Kann man diese nicht einfach selber erstellen?

Doch, das geht 😃

Eigene Certificate Authority erstellen

Das komplette Tutorial basiert eigentlich nur auf einem einzigen (und sehr mächtigen) Tool: openssl. Zunächst stellen wir sicher, dass es überhaupt installiert ist.

Kleine Anmerkung: Ich arbeite hier mit root Rechten, somit werden alle Befehle direkt als root ausgeführt.

$ apt-get install openssl

Nachdem das erledigt wurde, wechseln wir ins root Verzeichnis (oder ein beliebiges anderes) und erstellen zunächst ein paar Ordner:

$ cd ~
$ mkdir ca ssl
$ mkdir ca/private ca/public
$ mkdir ssl/private ssl/public

Im Folgenden werde ich das Verzeichnis auch nie wechseln. Das gibt mir auch etwas mehr Durchblick bei der ganzen Struktur 😃

So. Als Nächstes wird dann zunächst einen private key unserer Certificate Authority erstellt:

$ openssl genrsa -aes256 -out ca/private/milky-way.key 4096

Es kommt direkt eine Passwortabfrage. Dieses Passwort bitte sehr gut merken und auch ein möglichst sicheres Passwort verwenden. Ist das Passwort weg, ist die komplette Zertifizierungsstelle quasi nutzlos, da es keine neuen Zertifikate mehr ausstellen kann.

Sofort im Anschluss kannst du dann den public key deiner Certificate Authority erzeugen.

$ openssl req -x509 -new -nodes -extensions v3_ca -key ca/private/milky-way.key -days 9131 -out ca/public/milky-way-ca.pem -sha512

Wer sich über die merkwürdige Tagesangabe wundert, es sind auf den Tag genau 25 Jahre 😃 (bis zum nächsten Schaltjahr).

Auch hier kommt wieder eine Passwortabfrage. Da musst du das Passwort deines private keys angeben.

Anschließend musst du noch die typischen Fragen für das Zertifikat beantworten. Hier kannst du dich fast frei austoben. Hier mal meine Konfiguration:

Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Germany
Locality Name (eg, city) []:Luedenscheid
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Privux
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:MILKY WAY ROOT CA
Email Address []:sergej@knet.mw

Wenn du Windows Systeme in deinem Netzwerk hast, musst du das Zertifikat noch in das Windows Format konvertieren. Dies geschieht wie folgt:

$ openssl x509 -in ca/public/milky-way-ca.pem -outform der -out ca/public/milky-way-ca.crt

Und? Hast du wirklich gedacht, es wäre mehr Arbeit? 😃

Und da hast du auch recht, denn wir müssen noch ein paar Rechte setzen, damit die private keys nur für den root lesbar sind 😃

$ chmod -R 700 ssl/private
$ chmod -R 700 ca/private

Jetzt war es aber wirklich schon 😃

So stellst du neue Zertifikate aus

Auch für die normalen Zertifikate wird zunächst ein privater Schlüssel benötigt. Dies geschieht genauso wie auch bei der Certificate Authority.

$ openssl genrsa -out ssl/private/zertifikat.key 4096

Per private key wird anschließend einen "Antrag" an die Certificate Authority gestellt:

$ openssl req -new -key ssl/private/zertifikat.key -out ssl/public/zertifikat.csr -sha512

Es gibt ein kleinen Fallstrick bei den "normalen" Zertifikaten. Hier spielt nämlich der "Common Name" eine wesentliche Rolle und muss schlau vergeben werden.

Exkurs: Common Name

Sagen wir mal, du möchtest beispielsweise ownCloud in deinem Netzwerk einsetzen und per TSL schützen.

Wenn du über eine IP wie z.B. 172.26.47.11 darauf zugreifen möchtest, muss als Common Name auch exakt diese IP hinterlegt werden.

Hast du ein DNS Server im Einsatz und greifst z.B. über cloud.mylan darauf zu, wird halt genau diese FQDN (Full Qualified Domain Name) eingetragen.

Eine dritte Möglichkeit ist noch der einsatz von Wildcard Zertifikaten. Diese kannst werden mit einem Sternchen markiert. *.cloud.mylan ist beispielsweise gültig für www.cloud.mylan oder auch admin.cloud.mylan aber nicht für cloud.mylan selbst!

Back to the topic!

Die CA muss diesen Antrag jetzt wie folgt genehmigen:

$ openssl x509 -req -in ssl/public/zertifikat.csr -CA ca/public/milky-way-ca.pem -CAkey ca/private/milky-way.key -CAcreateserial -out ssl/public/zertifikat.pem -days 1461 -sha512

Das Zertifikat wird das Zertifikat für 4 Jahre genehmigt 😃

Wenn du noch den public key deiner Certificate Authority deinem neuen public key hinzufügst, musst du dies später bei der Server Konfiguration nicht mehr tun 😃

$ cat ca/public/milky-way-ca.pem >> ssl/public/zertifikat.pem

Übrigens kannst du den "Antrag" jetzt wieder löschen. Der ist quasi nutzlos.

$ rm ssl/public/zertifikat.csr

Make the life easier

Ganz ehrlich, ich habe keine Lust jedes Mal immer wieder die gleichen Fragen zu beantworten 😃

Glücklicherweise kann man OpenSSL wenigstens die Standardfragen bereits beantworten. Also wer du bist, woher du kommst etc. pp.

Dazu habe ich eine "kleine" Konfiguration auf phildev.net gefunden und für meine Bedürfnisse leicht abgeändert. Ich erspare es dir jetzt hier ein gist einzufügen 😃 stattdessen kannst du es direkt bei github angucken.

Für die config müssen noch 2 Dateien angelegt werden:

$ touch database
$ touch serial

Jetzt kannst du bei jedem Antrag auf die Konfig verweisen und wenigstens die Standardantworten per [Enter] bestätigen.

Zusätzlich habe ich mir ein kleines Bash Script erstellt, welches ich hier mit dir teilen möchte:

#!/bin/bash
echo "+-------------------------------------------------------------------+"
echo "| ______ _ |"
echo "| (_____ \ (_) |"
echo "| _____) )___ _ _ _ _ _ _ _ |"
echo "| | ____/ ___) | | | | | | ( \ / ) |"
echo "| | | | | | |\ V /| |_| |) X ( |"
echo "| |_| |_| |_| \_/ \____(_/ \_) |"
echo "| |"
echo "+-------------------------------------------------------------------+"
if [ -z $1 ]
then
echo Es muss ein Name angegeben werden!
else
echo Privater Schluessel fuer \"$1\" wird erstellt
openssl genrsa -out ssl/private/$1.key 4096
echo Zertifizierungsanfrage wird gestellt
openssl req -new -config caconf.ini -key ssl/private/$1.key -out ssl/public/$1.csr -sha512
echo Das Zertifikat fuer \"$1\" wird jetzt signiert
openssl x509 -req -in ssl/public/$1.csr -CA ca/public/milky-way-ca.pem -CAkey ca/private/milky-way.key -CAcreateserial -out ssl/public/$1.pem -days 1461 -sha512
rm ssl/public/$1.csr
echo Kombiniere Zertifikat mit dem CA public key
cat ca/public/milky-way-ca.pem >> ssl/public/$1.pem
fi
view raw create_tsl.sh hosted with ❤ by GitHub

Sagen wir mal, du benötigst ein neues Zertifikat für deine Domain "www.cooles-projekt.lan". Dann kannst du mit dem Script wie folgt ein TSL-Zertifikat erstellen:

$ sh ~/create_tsl.sh www.cooles-projekt.lan

Mehr ist nicht mehr nötig. Ist das nicht cool? 😃

Certificate Authority publizieren

Mal ganz ehrlich, was bringen jetzt einem der Haufen Zertifikate, wenn alle Clients immer noch diese komische Meldung von wegen unsicher anzeigen?

Richtig. Nichts!

Blöd ist nur, dass du bei jedem Gerät einzeln das Root-Zertifikat installieren musst. Leider kann man das auch nicht wirklich automatisieren. Nur ggf. etwas vereinfachen, wenn du beispielsweise ein Domain Controller hast.

Der Vorteil ist aber, wenn du das Root-Zertifikat einmal installiert hast, kannst du beliebig viele Zertifikate ausstellen und es wird allen vertraut!

Ich habe mir einfachheitshalber für das Root-Zertifikat ein Samba Share erstellt und diesem Share nur Leserechte vergeben.

Windows / Chrome / Chromium

Windows teilt sich mit Chrome den Zertifikatpool. Es reicht teoretisch auch aus, wenn du die *.crt Datei ausführst und auf "Zertifikat installieren" klickst.

Ansonsten navigierst du dich in Chrome wie folgt durch:

Einstellungen » Erweiterte Einstellungen anzeigen » HTTPS/SSL » Zertifikate verwalten » Zertifizierungsstellen » Importieren » "milky-way-ca.crt" auswählen » Diesem Zertifikat zur Identifizierung von Websites vertrauen.

Mozilla Firefox / Thunderbird

Mozilla hat einen anderen Zertifikatpool. Also musst du bei Firefox das Zertifikat noch einmal installieren. Dies geschieht wie folgt:

Einstellungen » Erweitert » Zertifikate » Zertifikate anzeigen » Zertifizierungsstellen » Importieren » "milky-way-ca.crt" auswählen » Dieser CA vertrauen, um Websites zu identifizieren.

Debian / Ubuntu

Wer hätte es gedacht? Bei den Debian derivaten geht es mal wieder viel einfacher 😃

$ cp milky-way-ca.crt /usr/share/ca-certificates/milky-way-ca.crt
$ dpkg-reconfigure ca-certificates

Android

"Leider" habe ich nur ein Android Phone zur Verfügung um es zu testen. Aber ich vermute, auf anderen Geräten funktioniert es ähnlich. Hier reichte es vollkommen aus, das Zertifikat per USB auf mein Gerät zu übertragen und auszuführen.

Seitdem meckert Android zwar bei jedem Neustart über Zertifikate aus nicht vertrauenswürdigen Quellen, aber ansonsten funktioniert alles wie gewollt 😃

Fazit - Certificate Authority

Ich finde, es ist heutzutage sehr einfach, sich sowohl ein neues Zertifikat als auch eine komplett neue Certificate Authority auszustellen.

Schon allein aus diesem Grunde verstehe ich persönlich nicht, warum es manche Firmen gibt, die Unsummen an Geld für solche Zertifikate verlangen.

Bedenkt man noch die Tatsache, dass es hier um die globale Sicherheit geht, finde ich es fair wenn man die TSL-Zertifikate auch kostenlos rausgeben würde. Ich meine, es ist doch echt nicht schwer so ein Zertifikat automatisiert zu erstellen, bzw. sich bei Bedarf eins erstellen zu lassen.

Oder denkst du wirklich, dass eine Webseite immer zu 100% sicher ist, nur weil es ein TSL-Zertifikat einsetzt? Nein, auch hier kann Malware schlummern.

Wird aber ein TSL-Zertifikat verwendet, sind alle übertragenen Daten komplett verschlüsselt.

Übrigens gehe ich davon aus, dass in nicht allzu weiter Ferne alle Webseiten ohne TSL-Zertifikat von den Browsern blockiert werden.

Der Internet Explorer macht es bereits vor. So wird Software, die nicht signiert wurde, direkt nach dem Herunterladen gelöscht. Es könnte ja unsicher sein. Ach, echt? Warum? Nur weil Microsoft denkt, dass Hacker kein Geld für ein Zertifikat haben?

Und wie viele andere Software Anbieter müssen jetzt zusätzlich ein Zertifikat kaufen nur um diese Sperre zu umgehen?

Wenn dir das gefallen hat, wirst du diese Artikel lieben!

Die neuesten Artikel, die du gelesen haben musst!

teilen

Noch mehr privux?

Verpasse keine spannende Beiträge & Tutorials mehr!

Jetzt kostenlosen Newsletter abonieren!

Jetzt newsletter abonieren