Eigene Zertifizierungsstelle (CA) mit Sub-Zertifizierungsstellen (Sub-CA’s)

Achtung! Dieser Artikel ist älter als ein Jahr. Der Inhalt ist möglicherweise nicht mehr aktuell!

Artikel zur Erstellung einer Zertifizierungsstelle mit nur einer Identität gibt es wie Sand am Meer. Die darin beschriebenen Methoden sind aber meistens sehr wage beschrieben oder verwenden veraltete Crypto.

Für die Arbeit habe ich eine neue PKI erstellen müssen. Im folgenden Artikel sind meine Erkenntnisse zusammengefasst.

Vorbereitung

Soll-Zustand

Als erstes sollte man sich Gedanken machen, wie die Struktur der Zertifizierungsstellen aussehen soll. Als Beispiel nehme ich in diesem Artikel die Example AG. Diese hat mehrere Abteilungen, zum Beispiel „Development“. Damit Unternehmensweit eine anständige Public-Key-Infrastruktur (PKI) verfügbar ist, soll eine unternehmensweite Zertifizierungsstelle (Root-CA) entstehen sowie eine Unter-Zertifizierungsstelle für jede Abteilung (Sub-CA).

Der Aufbau sieht also wie folgt aus:

Warnung: Das ist kein Copy & Paste Tutorial! Bitte unbedingt mitdenken!

Bestandteile, die nicht behandelt werden

Einige Bestandteile covert dieser Artikel (noch) nicht:

Im Normalfall existieren solche System schon oder werden gar nicht benötigt.

Verwendete Softwareumgebung

In diesem Artikel verwende ich einen normalen Debian 8.1 Server. Für die CAs wird OpenSSL aus den Standardrepositories verwendet. Aktuell habe ich die Version 1.0.1k vom 08. Januar 2015. Die Verwendete Linux Distribution ist im Normalfall irrelevant. Meistens ändert sich nur der Pfad der Standard-Konfigurationsdatei. Der Aufbau der Kommandos unterscheiden sich nicht.

Konfigurationsdatei

OpenSSL verwendet auf Debian-Basierenden Systemen standardmäßig die Config-Datei unter /etc/ssl/openssl.cnf . Diese Datei muss zuerst erweitert werden. Neue Blöcke sollten immer an das Ende der Datei gepackt werden.

Mit Blöcken sind Abschnitte gemeint, wobei jeder Abschnitt durch eine Zeile mit „[ irgendeintext]“ gekennzeichnet ist.

Zertifizierungsstellen definieren

Jede Zertifizierungsstelle benötigt einen eigenen Block in der Konfigurationsdatei. Für die Root-CA sieht der Block wie folgt aus:

Hervorzuhebende / Wichtige Einstellungen sind:

Für jede Sub-CA muss jeweils ein eigener Block eingefügt werden. Hier am Beispiel der Development Sub-CA:

Vergleicht man die Parameter mit der der Root-CA gibt es zwei wesentliche Unterschiede:

Optional: Policies

Dieser Schritt ist optional und nur wichtig, wenn eine eigene Policy angelegt werden soll. Im Normalfall reichen die vordefinierten Policies policy_match und policy_anything vollkommen aus.

Beispiel einer Policy anhand der bestehenden Policy policy_match:

Die einzelnen Optionen sind die selben, die man bei der Erstellung eines CSR ausfüllen muss. Dahinter steht dann entweder

Möchte man eine eigene Policy erstellen kopiert man den Block und ändert ihn dementsprechend.

Erstellen der Infrastruktur

In der Konfigurations-Datei wurde das Layout des Filesystems definiert. Nun muss diese Vorgabe physisch im Dateisystem erstellt werden. Danach erstellt man den privaten Schlüssel – dem wichtigsten Teil der PKI.

Erstellung der Root-CA

Wechsle ins Verzeichnis /opt und erstelle einen Ordner example-root-ca:

Erstellen der benötigten Dateien und Ordner sowie initiale Wertebefüllung:

Im Ordern certs werden Kopien der ausgestellten Zertifikate gespeichert. Im Ordner crl wird eine Kopie aller erstellen CRL’s gespeichert. Im Ordner private wird der private Schlüssel gespeichert. Hier möchte man eventuell die Rechte 0600 setzen.

Den privaten Schlüssel erstellt man mit folgendem Kommando:

Der private Schlüssel wird durch ein Passwort geschützt. Möchte man das nicht tun – was ich nicht empfehle – muss man nur den Parameter -aes256 entfernen.

Das Passwort sollte entsprechend lang und komplex sein.

Da das Zertifikat eine Gültigkeit von 10 Jahre besitzen soll muss die verwendete Kryptographie zukunftssicher sein. 1024 bit RSA oder DSA ist unter keinen Umständen mehr sicher. 2048 bit ist aktuell als sicher einzustufen, aber bestimmt nicht für die nächsten 10 Jahre. Deswegen wird 4096 bit RSA verwendet.

Die Root-CA muss Ihre Identität selbst unterschreiben. Deswegen wird das Zertifikat mit dem eigenen Key signiert („self signed“):

Man wird nun zur Eingabe von Zertifikatsdetails gebeten:

Das Root-Zertifikat ist nun 3650 Tage (~ 10 Jahre) gültig, hat einen starken Kryptographischen Unterbau und verwendet SHA-512 als Unterzeichnus-Algorithmus.

Erstellung von Sub-CA’s

Wenn die Root-CA steht können weitere Sub-CAs erstellt werden. Diese Zertifizierungsstellen beglaubigen letztendlich End-Zertifikate und werden bis auf den letzten Schritt identisch erstellt. Der Unterschied: Die Sub-CA unterschreibt ihr Zertifikat nicht mit dem eigenen privaten Schlüssel. Die Root-CA stellt das Zertifikat aus. Dadurch wird die „Chain of trust“ aufgebaut.

Angenommen die Example CA hat eine Abteilung Development, für die eine Sub-CA erstellt werden soll:

Während der Erstellung des neuen privaten Schlüssels wird man wieder nach einem Passwort gefragt. Dieses sollte sich von dem der Root-CA unterscheiden. Diese Identität muss nun von der Root-CA signiert werden. Dazu muss ein Certificate Signing Request (CSR) erstellt werden.

Bei der Erstellung wird man wieder nach den Details gefragt:

In jedem Ordner einer Sub-CA sollte nun ein CSR liegen. Diese werden nun nacheinander der Root-CA vorgeworfen, die letztendlich das Zertifikat ausstellt.

Arbeiten mit den CA’s

Signieren einer neuen Sub-CA

Wie oben beschrieben muss die Sub-CA zuerst erstellt werden. Der daraus resultierende CSR wird dann von der Root-CA bearbeitet und letztendlich das Zertifikat ausgestellt. Dazu wechselt man als erstes in den Ordner der Root-CA:

Mit Hilfe des folgenden Befehls wird der CSR eingelesen und ein Zertifikat ausgestellt:

Während des Vorgangs wird man nach einem Passwort gefragt. Dabei handelt es sich um das Passwort des privaten Schlüssels der Root-CA. Die benötigten default-Einstellungen wird mit Hilfe des Blocks in der Konfigurationsdatei und der Angabe als Parameter geladen (Orange-markiert).

Wichtig ist, dass man die grün markierten Pfade für jede Sub-CA ändert!

Signieren von normalen Zertifikaten

Normale Zertifikate werden mit den Sub-CA’s ausgestellt. Damit ein Zertifikat ausgestellt werden kann, wird ein CSR benötigt. Im Normalfall kommt jemand auf einen zu uns sagt: „Du bist doch der, der die Zertifikate macht – ich bräuchte eins“.

Angenommen dein Kollege hat dir schon einen CSR geschickt und du hast ihn auf dem Server unter /tmp/request.csr abgelegt. Zum Ausstellen des Zertifikates wird folgender Befehl verwendet:

Während dieses Vorgangs wird man wieder nach einem Passwort gefragt. Dabei handelt es sich um das Passwort für den privaten Schlüssel der Sub-CA. Danach liegt unter /tmp/certificate.pem das ausgestellte Zertifikat, das du deinem Kollegen schickst.

Verteilung der CA Zertifikate

Damit ausgestellte End-Zertifikate korrekt validiert werden und es zu keinen Fehlermeldungen oder Warnungen kommt, muss das Zertifikat der Root-CA und der Sub-CA an die Clients manuell als vertrauenswürdig eingestuft werden.

Bei Firefox und Chrome muss man die Zertifikate der Root-CA und Sub-CA als Zertifizierungsstellen hinzugefügt werden. Beim Java Keytool müssen beide Zertifikate in einen Keystore/Truststore importiert werden.

Nur wenn beide CA Zertifikate vorhanden und beglaubigt sind wird eine Fehlermeldung verhindert, da das ausgestellte Endzertifikat anhand der Chain of Trust überprüft werden kann.

Further Reading


Du hast einen Kommentar, einen Wunsch oder eine Verbeserung? Schreib mir doch eine E-Mail! Die Infos dazu stehen hier.

🖇️ = Link zu anderer Webseite
🔐 = Webseite nutzt HTTPS (verschlüsselter Transportweg)
Zurück