Vertrauenswürdige Zertifikate erstellen

Wenn ihr wie ich mit allen möglichen Applikationen und Servern herum experimentiert oder diese dann irgendwann sogar in den produktiv Betrieb übergehen ist es nervig bzw. störend wenn wir per Browser immer eine Sicherheitswarnung erhalten, dass die Seite des Dienstes oder des Servers unsicher sei. Was bei Servern, welche aus dem Internet erreichbar sind, über entsprechende Stellen sogar recht einfach möglich ist, kann im privaten Bereich mühsam und störend sein.
Natürlich kann ich für jeden Dienst und jeden Server ein eigenes Zertifikat erstellen und dies dann auf allen Hosts ausbringen, aber das kann sich zu einer ganz schönen Aufgabe ausweiten. Weiterhin ist nicht immer klar, ob das Zertifikat alleine ausreichend ist um die Sicherheitswarnung zu verhindern.
Die Hauptursache für dieses Problem ist die fehlende Zertifizierungsstelle für das Zertifikat. In der großen Welt werden Zertifikate von vertrauenswürdigen Zertifizierungsstellen, einer sogenannten Certificate Authority oder kurz CA, validiert also wiederum als vertrauenswürdig eingestuft. Diese CA fehlt uns im privaten und nicht öffentlichen Bereich.
Wir können aber eine CA nachstellen bzw. unsere Zertifikatsstruktur dementsprechend aufbauen. Was wir genau benötigen, ist ein Stammzertifikat, welches wir dann auf die Geräte in unserem Netzwerk ausbringen. Dieses Stammzertifikat, oder auch „root-certificate“, hat auch den großen Vorteil, dass wir beliebig viele unter Zertifikate damit verifizieren können. Das verringert den Aufwand bei der Zertifikatspflege enorm!
Alle arbeiten führe ich auf einem frisch installiertem Debian Buster System durch. Ich habe mich sogar für einen eigenen Server (virtuell) entschieden, auf welchem ich die Zertifikatserstellung durchführen will. Wie immer wurde das System vorher auf den aktuellsten Stand gebracht.
Fangen wir an……..
Für alle Steps benötigen wir zur Erstellung das Tool „openssl“. Dieses ist für alle gängigen Plattformen verfügbar und auf Linux Systemen in der Regel schon vorinstalliert.
In diesem Beispiel nennen wir unsere interne Domain „own.local“. Ich habe mir angewöhnt die Zertifikate und Schlüssel voll qualifiziert (FQDN) zu benennen. Gerade wenn es doch ein paar mehr Sub-Domains werden, verliert man sonst schnell den Überblick.
Als erstes erstellen wir uns das „root-certificate“ mit dem dazugehörigen privaten Schlüssel. Wir fangen sogar mit dem privatem Schlüssel an.
openssl genrsa -out root.own.local.key 2048
Als nächstes erstellen wir uns das Zertifikat. Übrigens nutze ich für alle Schlüssel die Endung „.key“ und für alle Zertifikate „.crt“. Wenn wir uns jetzt das Zertifikat erstellen, werden wir nach ein paar Informationen gefragt. Diese Informationen gibt das Zertifikat später auch mit aus. Hier sollten sinnvolle Angaben gemacht werden. Da wir die Zertifikate aber nur lokal verwenden, ist es auch ok wenn ihr nix angebt. Gefragt werdet ihr nach dem Land, dem Bundesland, die Stadt, wie eure Organisation heißt bzw. zu welcher Abteilung ihr (euer Zertifikat) gehört und dem FQDN und einer Email Adresse unter welcher jemand verantwortliches zu erreichen ist.
openssl req -x509 -new -nodes -key root.own.local.key -sha256 -days 3650 -out root.own.local.crt
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Saxony
Locality Name (eg, city) []:Hometown
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Firma
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:own.local
Email Address []:admin@own.local
Was genau bedeutet der Befehl eigentlich? Wir fordern bei openssl ein neues x509-Zertifikat an, welches den vorhin erstellten Schlüssel verwenden und per sha256 verschlüsselt werden soll. Weiterhin soll dieses Zertifikat eine Laufzeit von 3650 Tagen haben und natürlich in eine spezielle Datei geschrieben werden. Ob alles geklappt hat könnt ihr euch auch mit openssl anschauen. Hierzu einfach den folgenden Befehl ausführen.
openssl x509 -in root.own.local.crt -text -noout
Interessant ist neben der Laufzeit der Zusatz „CA:TRUE“. Hieran erkennen wir auch in Ausgabeform unser Stammzertifikat. Alle anderen werden diesen Zusatz nicht aufweisen.
Wir könnten unser „root-certificate“ eigentlich schon verteilen aber ich werde vorher noch auf das erstellen der Sub-Domain eingehen. Wir sind ja gerade auf dem System. Hier ist zu beachten, dass der Vorgang in Schritten erfolgen muss. Als erstes erstellen wir einen sogenannten CSR (Certificate Signing Request) und einen dazugehörigen privaten Schlüssel. Da wir ja vor haben mehrere Zertifikate zu erstellen, hat sich das vorgehen über eigene Konfigurationsdateien bewährt. Mit einer solchen Konfiguration müssen nur minimale Werte angepasst werden um sowohl den CSR als auch den Schlüssel für eine weitere Sub-Domain zu erzeugen. Wir erstellen uns also eine Datei und nennen diese own.local.csr.cnf!
[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
[dn]
C=DE
ST=Saxony
L=Hometown
O=Firma
emailAddress=admin@own.local
CN = web.own.local
Wie ihr seht können wir bis auf die letzte Zeile alles gleich belassen, solange wir für unsere „own.local“ Domain neue Sub-Domains erzeugen. Im CN wird dann einfach der Domainname geändert.
Jetzt können mit einem weiteren openssl Befehl der CSR und der dazugehörige private Schlüssel erstellt werden.
openssl req -new -sha256 -nodes -out web.own.local.csr -newkey rsa:2048 -keyout web.own.local.key -config own.local.csr.cnf
Wie CSR (Certificate Signing Request) schon vermuten lässt, müssen wir uns aus dem CSR noch ein richtiges Zertifikat erzeugen. Auch hierfür ist es ratsam, sich eine neue Konfigurationsdatei anzulegen. Auch hier legen wir diese so an, dass wir uns schnellstmöglich neue Sub-Domain Zertifikate erstellen können. Ich nenne diese Datei own.local.crt.cnf und dort hinein kommt der folgende Inhalt.
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = web.own.local
Wenn wir uns neue Sub-Domains anlegen wollen, müssen wir nur die Eintrag in der Sektion „alt_names“ anpassen. Hier noch ein Tipp. Diese alternativen Namen werden von immer mehr Überprüfern vorausgesetzt um ein Zertifikat als valide zu erkennen. Weiterhin kann hierüber auch z.B. ein Active-Passiv Cluster abgedeckt werden. Sagen wir wir haben zwei Server und beide machen eigentlich das selbe aber solange der aktive seinen Dienst tut, ist der zweite nur passiv. Wenn es jetzt zu einem sogenannten „failover“ kommt, wollen wir ja das gleiche Zertifikat sehen wie auf dem anderen Server. Mit nur einem alternativen Namen würde dies nicht möglich sein. Wir können dem Zertifikat mehrere Namen mitgeben und können ein solches Szenario abdecken.
Machen wir aber weiter mit unserem aktuellen Thema. Wir erstellen uns jetzt ein Zertifikat. Wieder über einen openssl Befehl. Diesmal geben wir zusätzlich noch die Stammzertifikatsdateien mit. Natürlich soll das neue Zertifikat auch genau solange gültig sein.
openssl x509 -req -in web.own.local.csr -CA root.own.local.crt -CAkey root.own.local.key -CAcreateserial -extfile own.local.crt.cnf -out web.own.local.crt -days 3650 -sha256
Ob wir alles richtig gemacht haben können wir wieder mit openssl prüfen. Schauen wir uns das neue Zertifikat einmal an.
openssl x509 -in web.own.local.crt -text -noout
Wir sehen in der Data Sektion, dass unser Zertifikat knapp 10 Jahre gültig ist und das die richtige Sub-Domain im CN steht. Unter den X509 Erweiterungen können wir sehen, dass es kein Stammzertifikat ist und das wir einen alternativen Namen vergeben haben. Es sieht also gut aus.
Wie machen wir jetzt weiter? Wie oben schon angekündigt, hätten wir das „root-certificate“ und den dazugehörigen Schlüssel schon verteilen können. Diese beiden Dateien, oder auch nur eine, müssen auf alle Geräte aufgespielt werden, die final unsere Sub-Domains als gültig erkennen sollen/müssen. Das wie ist natürlich von System und Applikation abhängig und überall unterschiedlich. Ich werde nur ein Beispiel mit dem Chrome Browser anführen. Solltet ihr trotz Google Probleme mit einem Gerät (außer Apple) haben, dann schreibt mir. Zusammen bekommen wir das bestimmt hin. Aber jetzt zum Beispiel zurück.
Unter Chrome klicken wir auf die drei Punkte in der oberen rechten Ecke und wählen den Menü Punkt „Einstellungen“. Im sich daraufhin öffnenden Fenster wählen wir „Sicherheit und Datenschutz“ aus und klicken direkt auf den Punkt „Sicherheit“. Jetzt scrollen wir ganz nach unten und klicken auf „Zertifikate verwalten“. Im nächsten Fenster wählen wir den Reiter „Vertrauenswürdige Stammzertifizierungsstellen“ aus und können jetzt hier unsere Dateien importieren. Jetzt öffnet sich ein Assistent welcher uns erklärt wofür er da ist, also direkt auf „weiter“. Jetzt suchen wir uns über „Durchsuchen“ unser Stammzertifikat aus und drücken auf „weiter“. Als letztes werden wir noch gefragt, wo wir es speichern wollen. Hier belassen wir es bei „Vertrauenswürdige Stammzertifizierungsstellen“ und klicken wieder auf „weiter“. Jetzt bekommen wir noch einen Überblick was gemacht wird und können über „Fertig stellen“ das Zertifikat importieren. Natürlich bekommen wir jetzt nochmal eine Warnung! Wäre ja schlimm wenn nicht. Ab jetzt sollten alle eure Sub-Domains von diesem Chrome Browser als gültig anerkannt werden!
Wie immer handelt es sich um mein Beispiel. Passt also alles an eure Voraussetzungen an.
Ich hoffe euch hat der Artikel gefallen. Solltet ihr Fehler gefunden haben, generelle Fragen haben, oder wollt ihr einfach noch zusätzliche Informationen, dann schreibt mir bitte in die Kommentare. Ich versuche diese zeitnah zu beantworten.
Danke fürs lesen…..
Euer cedigger

Schreibe einen Kommentar