Eine eigene SSL Zertifizierungsstelle (Root CA) für die Nutzung im LAN erstellen – Teil I

Vertrauenssache – Interne SSL-Zertifikate

Im LAN werden oftmals SSL-Zertifikate zur Nutzung verschiedener  Dienste benötigt. Oft bleibt hier nichts anderes übrig, als selbstsignierte Zertifikate zu verwenden. Diese Zertifikate erfüllen zwar aus technischer Sicht ihren Zweck, den Anwender bzw. Administrator stellen sie aber immer wieder vor lästige Probleme. Web-basierte Administrationsinterfaces von Geräten, Terminalsitzungen des RDP-Servers und vieles andere meldet dem Anwender mehr oder weniger regelmäßig, dass das selbst erzeugte Zertifikat nicht sicher wäre oder zumindest aus unsicherer Quelle stamme. Der User quittiert dies in der Regel einfach – vertrauensbildend ist dies jedoch nicht.

Durch den antrainierten Reflex, fragwürdige Zertifikate ohne Bedenken zu akzeptieren, können große Sicherheitsrisiken entstehen. Ein derart konditionierter User hinterfragt irgendwann auch im Internet nicht mehr die Gründe, weshalb ein Zertifikat als unsicher eingestuft wurde. Gerade dort ist es jedoch wichtig, auf sichere Vertrauensstellungen in den Verschlüsselungsketten zu achten.

Im LAN könnte man zum Ergebnis gelangen, dass eine verschlüsselte Übertragung vom User zum Server innerhalb der geschlossenen Infrastruktur vernachlässigt werden kann. Unter der Maßgabe, dass es sich um keine sehr komplexe Struktur handelt und auch der Anwenderkreis vertrauenswürdig ist, kann man dies unter Umständen bejahen. Allerdings fordern immer mehr Produkte eine Verschlüsselung ein. Atlassian Confluence, als Beispiel, gestattet beispielsweise die Nutzung bestimmter Features nur, wenn die Verbindungen verschlüsselt sind.

Zertifikatsketten

Ein SSL-Zertifikat (X.509) enthält in der Regel Informationen über den Namen des Inhabers, dessen öffentlichen Schlüssel, eine Gültigkeitsdauer sowie den Namen der Zertifizierungsstelle. Die Zertifizierungsstelle signiert diese Informationen mit ihrem privaten Schlüssel und bestätigt dadurch die Korrektheit der in dem Zertifikat enthaltenden Angaben. Das Zertifikat kann mit dem zugehörigen öffentlichen Schlüssel der Zertifizierungsstelle überprüft werden.

Damit ein SSL-Zertifikat als vertrauenswürdig eingestuft werden kann, sind bestimmte hierarchische Autoritäten notwendig. Zunächst baut das „Vertrauen“ innerhalb von SSL auf der Annahme auf, dass der Browser des Benutzers über Listen mit Zertifizierungsstellen (Root-CA) für SSL-Zertifikaten verfügen kann, deren ausgestellten Zertifikaten bedingungslos vertraut werden kann. Wird nun eine SSL-verschlüsselte Website aufgerufen, prüft der Browser das für die Verschlüsselung herangezogene Zertifikat auf Gültigkeit, zur Webadresse passende Referenz sowie den Herausgeber. Kann hierfür vom Zertifikat der entsprechende Öffentliche Schlüssel der entsprechenden Zertifizierungsstelle vorgewiesen werden (wurde es also von der Zertifizierungsstelle signiert) gilt das Host/“Webseiten“-Zertifikat als gültig – die Verschlüsselung ist intakt.

Präsentiert das Host-Zertifikat jedoch einen Herausgeber, den der PC bzw. Browser nicht kennt, meldet dieser zumindest einen Zertifikatsfehler. In der Regel kann der Anwender diesen Fehler jedoch übergehen und seine Aktivitäten auf der betroffenen Website fortsetzen. Es gibt jedoch Situationen, in denen dies nicht möglich ist – beispielsweise wenn Programme Zertifikate zur Authentifizierung nutzen.

Bei selbstsignierten Zertifikaten ist genau dies regelmäßig der Fall. Der entsprechende Dienst oder Server signiert sich sein Zertifikat selbst und alle Clients, die diesen Dienst in Anspruch nehmen wollen, kennen keine Root-CA zu diesem Zertifikat.

Eigene Root-CA für interne Zertifikate

Um diese Probleme zu umgehen, kann man sich eine eigene Zertifizierungsstelle bauen. Diese Root-CA wird beispielsweise innerhalb der Domäne oder eben auf allen Rechnern, die künftig Zertifikaten dieser CA vertrauen sollen, in die Liste der vertrauenswürdigen Herausgeber aufgenommen und (im Falle einer Windows Domäne) an die Clients über das AD verteilt. Dies funktioniert derzeit mit dem Microsoft Internet Explorer sowie dem Google Chrome Browser. Mozilla Firefox nutzt ein anderes Verfahren, hier muss das Zertifikat manuell installiert werden. Wie dies bewerkstelligt werden kann – dazu später.

---

Der Ablauf – Root Certificate Authority (CA) erstellen

Im ersten Moment mag man denken, dass eine Root CA einen dedizierten Server mit Diensten, Datenbanken, etc. umfaßt. Tatsächlich besteht die Root CA aber in ihrem rudimentären Aufbau lediglich aus einem Private-Key und einem Root-Zertifikat. Natürlich muss man zur Erzeugung sowohl des Root CA Zertifikates als auch aller Host-Zertifikate über eine Maschine verfügen, die über die benötigten OpenSSL-Bibliotheken verfügt. Ich arbeite grundsätzlich mit Linux (Debian und Derivate) und finde es damit verhältnismäßig einfach.

Wie wird nun die Root CA (also das Root Zertifikat) erzeugt?

In dieser Beschreibung gelten folgende Annahmen:

Hostname des CA-Servers:	cert.mein-netz.local
Host, für den ein Zertifikat erzeugt werden soll:	client.mein-netz.local

Den Private Key (geheimen Schlüssel) des Root Zertifikats erzeugen wir im Verzeichnis /etc/ssl/myCA mit dem folgenden Befehl erzeugt.

openssl genrsa -out myCA-key.pem 2048

bzw.

openssl genrsa -aes256 -out myCA-key.pem 2048

Der erzeugte Schlüssel hat eine Länge von 2048 Bit, was schon eine vernünftige und sichere Verschlüsselung ermöglicht. Möchte man es noch sicherer, kann auch ein 4096 Bit langer Schlüssel erzeugt werden. Mit der Option „-aes256“ verpassen wir dem Private Key einen Passwortschutz. Der Private Key der CA darf nicht in falsche Hände gelangen, da mit ihm beliebige Zertifikate ausgestellt werden können. Missbraucht werden könnte dies, um Server als vertrauenswürdig erscheinen zu lassen obwohl sie es nicht sind. Die möglichen Missbrauchsszenarien sind vielfältig. Es muss also unbedingt darauf geachtet werden, den privaten Schlüssel sicher zu verwahren. Ein Verlust (im Sinne von „nicht mehr auffindbar“) des Keys ist sicherheitstechnisch nicht schlimm. Dennoch ist es lästig, da dann keine Zertifikate mehr erzeugt werden können. In solch einem Fall müsste ein neuer Private Key und ein neues Root Zertifikat erzeugt werden, das letztere wiederum an die Clients verteilt werden. Da die mit dem verlorenen Private Key signierten SSL-Zertifikate nicht mehr gegen das neue Root Zertifikat bestätigt werden können, müssen in diesem Fall auch alle SSL-Zertifikate erneut erstellt werden. Ergo:

1. Private Key des Root Zertifikats gegen Diebstahl sichern
2. Backup des Private Keys und des Root Zertifikates anlegen

Der nächste Schritt ist die Erzeugung des Root Zertifikates. Dies bewerkstelligen wir mit dem Befehl

openssl req -x509 -new -nodes -extensions v3_ca -key myCA-key.pem -days 730 -out myCA-root.pem -sha512

Dies erzeugt nun einen 730 Tage lang gültiges Root Zertifikat. Bei der Gültigkeitsdauer muss man bedenken, dass mit Ablauf dieses Datums ein neues Root Zertifikat gegen den Private Key erzeugt und erneut an alles betroffenen Clients verteilt werden muss. Persönlich bin ich der Meinung, dass nichts gegen eine Gültigkeitsdauer von 10 oder gar 20 Jahren spricht, aber ja – das muss jeder für sich selbst entscheiden.

Während der Erzeugung werden das Passwort des Private Keys sowie andere Daten abgefragt.

Enter pass phrase for myCA-key.pem: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]: DE State or Province Name (full name) [Some-State]: BW Locality Name (eg, city) []: Eningen u.A. Organization Name (eg, company) [Internet Widgits Pty Ltd]: ACME, Inc. Organizational Unit Name (eg, section) []: IT Common Name (e.g. server FQDN or YOUR name) []: mein-netz.local Email Address []: admin@wasauchimmer.com

So – geschafft! Wir haben nun zwei Dateien erzeugt, die unsere Root CA definieren: Den Private Key (myCA-key.pem) und unser Root Zertifikat (myCA-root.pem). Übrigens: Es spielt keine Rolle, ob der Private Key auf .pem oder .key endet. Genauso macht es keinen Unterschied, ob das Root Zertifikat auf .pem oder .cert endet.

---

So geht’s weiter:

• In Teil II beschreibe ich, wie wir nun mit unserer Root CA SSL-Zertifikate für den internen Gebrauch erzeugen.
• In Teil III verteilen wir das Root-Zertifikat innerhalb der Windows Domäne über das ADS und schauen uns an, wie wir Mozilla Firefox dazu bewegen, unserer Root CA zu vertrauen
• In Teil IV stelle ich eine von mir entwickelte Web GUI vor, mit deren Hilfe man interne Zertifikate bequem erzeugen und mittels des CSR auch verlängern kann.