{"id":9,"date":"2016-08-18T19:11:39","date_gmt":"2016-08-18T17:11:39","guid":{"rendered":"http:\/\/www.markjunghanns.de\/?p=9"},"modified":"2016-09-17T00:22:39","modified_gmt":"2016-09-16T22:22:39","slug":"eine-eigene-root-zertifizierungsstelle-fuer-die-nutzung-im-lan-erstellen","status":"publish","type":"post","link":"https:\/\/www.markjunghanns.de\/de_DE\/index.php\/2016\/08\/18\/eine-eigene-root-zertifizierungsstelle-fuer-die-nutzung-im-lan-erstellen\/","title":{"rendered":"Eine eigene SSL Zertifizierungsstelle (Root CA) f\u00fcr die Nutzung im LAN erstellen – Teil I"},"content":{"rendered":"

Vertrauenssache – Interne SSL-Zertifikate<\/h3>\n

Im LAN werden oftmals SSL-Zertifikate zur Nutzung verschiedener\u00a0 Dienste ben\u00f6tigt. Oft bleibt hier nichts anderes \u00fcbrig, als selbstsignierte Zertifikate zu verwenden. Diese Zertifikate erf\u00fcllen zwar aus technischer Sicht ihren Zweck, den Anwender bzw. Administrator stellen sie aber immer wieder vor l\u00e4stige Probleme. Web-basierte Administrationsinterfaces von Ger\u00e4ten, Terminalsitzungen des RDP-Servers und vieles andere meldet dem Anwender mehr oder weniger regelm\u00e4\u00dfig, dass das selbst erzeugte Zertifikat nicht sicher w\u00e4re oder zumindest aus unsicherer Quelle stamme. Der User quittiert dies in der Regel einfach – vertrauensbildend ist dies jedoch nicht.<\/p>\n

Durch den antrainierten Reflex, fragw\u00fcrdige Zertifikate ohne Bedenken zu akzeptieren, k\u00f6nnen gro\u00dfe Sicherheitsrisiken entstehen. Ein derart konditionierter User hinterfragt irgendwann auch im Internet nicht mehr die Gr\u00fcnde, weshalb ein Zertifikat als unsicher eingestuft wurde. Gerade dort ist es jedoch wichtig, auf sichere Vertrauensstellungen in den Verschl\u00fcsselungsketten zu achten.<\/p>\n

Im LAN k\u00f6nnte man zum Ergebnis gelangen, dass eine verschl\u00fcsselte \u00dcbertragung vom User zum Server innerhalb der geschlossenen Infrastruktur vernachl\u00e4ssigt werden kann. Unter der Ma\u00dfgabe, dass es sich um keine sehr komplexe Struktur handelt und auch der Anwenderkreis vertrauensw\u00fcrdig ist, kann man dies unter Umst\u00e4nden bejahen. Allerdings fordern immer mehr Produkte eine Verschl\u00fcsselung ein. Atlassian Confluence, als Beispiel, gestattet beispielsweise die Nutzung bestimmter Features nur, wenn die Verbindungen verschl\u00fcsselt sind.<\/p>\n

Zertifikatsketten<\/h3>\n

Ein SSL-Zertifikat (X.509) enth\u00e4lt in der Regel Informationen \u00fcber den Namen des Inhabers, dessen \u00f6ffentlichen Schl\u00fcssel, eine G\u00fcltigkeitsdauer sowie den Namen der Zertifizierungsstelle. Die Zertifizierungsstelle signiert diese Informationen mit ihrem privaten Schl\u00fcssel und best\u00e4tigt dadurch die Korrektheit der in dem Zertifikat enthaltenden Angaben. Das Zertifikat kann mit dem zugeh\u00f6rigen \u00f6ffentlichen Schl\u00fcssel der Zertifizierungsstelle \u00fcberpr\u00fcft werden.<\/p>\n

Damit ein SSL-Zertifikat als vertrauensw\u00fcrdig eingestuft werden kann, sind bestimmte hierarchische Autorit\u00e4ten notwendig. Zun\u00e4chst baut das „Vertrauen“ innerhalb von SSL auf der Annahme auf, dass der Browser des Benutzers \u00fcber Listen mit Zertifizierungsstellen (Root-CA) f\u00fcr SSL-Zertifikaten verf\u00fcgen kann, deren ausgestellten Zertifikaten bedingungslos vertraut werden kann. Wird nun eine SSL-verschl\u00fcsselte Website aufgerufen, pr\u00fcft der Browser das f\u00fcr die Verschl\u00fcsselung herangezogene Zertifikat auf G\u00fcltigkeit, zur Webadresse passende Referenz sowie den Herausgeber. Kann hierf\u00fcr vom Zertifikat der entsprechende \u00d6ffentliche Schl\u00fcssel der entsprechenden Zertifizierungsstelle vorgewiesen werden (wurde es also von der Zertifizierungsstelle signiert) gilt das Host\/“Webseiten“-Zertifikat als g\u00fcltig – die Verschl\u00fcsselung ist intakt.<\/p>\n

Pr\u00e4sentiert 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 \u00fcbergehen und seine Aktivit\u00e4ten auf der betroffenen Website fortsetzen. Es gibt jedoch Situationen, in denen dies nicht m\u00f6glich ist – beispielsweise wenn Programme Zertifikate zur Authentifizierung nutzen.<\/p>\n

Bei selbstsignierten Zertifikaten ist genau dies regelm\u00e4\u00dfig 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.<\/p>\n

Eigene Root-CA f\u00fcr interne Zertifikate<\/h3>\n

Um diese Probleme zu umgehen, kann man sich eine eigene Zertifizierungsstelle bauen. Diese Root-CA wird beispielsweise innerhalb der Dom\u00e4ne oder eben auf allen Rechnern, die k\u00fcnftig Zertifikaten dieser CA vertrauen sollen, in die Liste der vertrauensw\u00fcrdigen Herausgeber aufgenommen und (im Falle einer Windows Dom\u00e4ne) an die Clients \u00fcber 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\u00e4ter.<\/p>\n

\n

Der Ablauf – Root Certificate Authority (CA) erstellen<\/h3>\n

Im ersten Moment mag man denken, dass eine Root CA einen dedizierten Server mit Diensten, Datenbanken, etc. umfa\u00dft. Tats\u00e4chlich besteht die Root CA aber in ihrem rudiment\u00e4ren Aufbau lediglich aus einem Private-Key und einem Root-Zertifikat. Nat\u00fcrlich muss man zur Erzeugung sowohl des Root CA Zertifikates als auch aller Host-Zertifikate \u00fcber eine Maschine verf\u00fcgen, die \u00fcber die ben\u00f6tigten OpenSSL-Bibliotheken verf\u00fcgt. Ich arbeite grunds\u00e4tzlich mit Linux (Debian und Derivate) und finde es damit verh\u00e4ltnism\u00e4\u00dfig einfach.<\/p>\n

Wie wird nun die Root CA (also das Root Zertifikat) erzeugt?<\/p>\n

In dieser Beschreibung gelten folgende Annahmen:<\/p>\n\n\n\n\n
Hostname des CA-Servers:<\/td>\ncert.mein-netz.local<\/em><\/td>\n<\/tr>\n
Host, f\u00fcr den ein Zertifikat erzeugt werden soll:<\/td>\nclient.mein-netz.local<\/em><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Den Private Key (geheimen Schl\u00fcssel) des Root Zertifikats erzeugen<\/strong> wir im Verzeichnis \/etc\/ssl\/myCA mit dem folgenden Befehl erzeugt.<\/p>\n\n\n\n
openssl genrsa -out myCA-key.pem 2048<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

bzw.<\/p>\n\n\n\n
openssl genrsa -aes256 -out myCA-key.pem 2048<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Der erzeugte Schl\u00fcssel hat eine L\u00e4nge von 2048 Bit, was schon eine vern\u00fcnftige und sichere Verschl\u00fcsselung erm\u00f6glicht. M\u00f6chte man es noch sicherer, kann auch ein 4096 Bit langer Schl\u00fcssel erzeugt werden. Mit der Option „-aes256“ verpassen wir dem Private Key einen Passwortschutz. Der Private Key der CA darf nicht in falsche H\u00e4nde gelangen, da mit ihm beliebige Zertifikate ausgestellt werden k\u00f6nnen. Missbraucht werden k\u00f6nnte dies, um Server als vertrauensw\u00fcrdig erscheinen zu lassen obwohl sie es nicht sind. Die m\u00f6glichen Missbrauchsszenarien sind vielf\u00e4ltig. Es muss also unbedingt darauf geachtet werden, den privaten Schl\u00fcssel sicher zu verwahren. Ein Verlust (im Sinne von „nicht mehr auffindbar“) des Keys ist sicherheitstechnisch nicht schlimm. Dennoch ist es l\u00e4stig, da dann keine Zertifikate mehr erzeugt werden k\u00f6nnen. In solch einem Fall m\u00fcsste 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\u00e4tigt werden k\u00f6nnen, m\u00fcssen in diesem Fall auch alle SSL-Zertifikate erneut erstellt werden. Ergo:<\/p>\n

    \n
  1. Private Key des Root Zertifikats gegen Diebstahl sichern<\/li>\n
  2. Backup des Private Keys und des Root Zertifikates anlegen<\/li>\n<\/ol>\n

    Der n\u00e4chste Schritt ist die Erzeugung des Root Zertifikates<\/strong>. Dies bewerkstelligen wir mit dem Befehl<\/p>\n\n\n\n
    \n
    \n
    openssl req -x509 -new -nodes -extensions v3_ca -key myCA-key.pem -days 730 -out myCA-root.pem -sha512<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Dies erzeugt nun einen 730 Tage lang g\u00fcltiges Root Zertifikat. Bei der G\u00fcltigkeitsdauer 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\u00f6nlich bin ich der Meinung, dass nichts gegen eine G\u00fcltigkeitsdauer von 10 oder gar 20 Jahren spricht, aber ja – das muss jeder f\u00fcr sich selbst entscheiden.<\/p>\n

    W\u00e4hrend der Erzeugung werden das Passwort des Private Keys sowie andere Daten abgefragt.<\/p>\n\n\n\n
    Enter pass phrase for myCA-key.pem:
    \nYou are about to be asked to enter information that will be incorporated
    \ninto your certificate request.
    \nWhat you are about to enter is what is called a Distinguished Name or a DN.
    \nThere are quite a few fields but you can leave some blank
    \nFor some fields there will be a default value,
    \nIf you enter '.', the field will be left blank.
    \n-----
    \nCountry Name (2 letter code) [AU]: DE<\/em><\/strong>
    \nState or Province Name (full name) [Some-State]: BW<\/em><\/strong>
    \nLocality Name (eg, city) []: Eningen u.A.<\/strong><\/em>
    \nOrganization Name (eg, company) [Internet Widgits Pty Ltd]: ACME, Inc.<\/strong><\/em>
    \nOrganizational Unit Name (eg, section) []: IT<\/strong><\/em>
    \nCommon Name (e.g. server FQDN or YOUR name) []: mein-netz.local<\/strong><\/em>
    \nEmail Address []: admin@wasauchimmer.com<\/strong><\/em><\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    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).<\/strong> \u00dcbrigens: 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.<\/p>\n

    \"2016-09-05<\/p>\n

    \n

    So geht’s weiter:<\/h3>\n