00: Zertifikatsfehler im Brwoser In vielen Heim-Netzwerk gibt es immer mehr Web-Frontends, mit denen Endgeräte konfiguriert werden: der WLAN-Router, das NAS oder der Raspberry sind da nur einige Beispiele. Ich möchte auch auf meine internen Netzwerk-Services nach Möglichkeit ausschließlich über TLS zugreifen. Da werden die TLS-Fehlermeldungen die vom Browser präsentiert werden nicht nur lästig, sondern stellen auch ein Sicherheitsrisiko dar. Wenn immer ein TLS-Fehler angezeigt wird, kann ein Man-in-the-Middle nicht mehr erkannt werden.

Daher ist es durchaus sinnvoll eine eigene interne CA zu erstellen mit deren Hilfe entsprechende Server-Zertifikate ausgestellt werden können.

00| Software installieren

Grundsätzlich kann eine CA und die damit auszustellenden Zertifikate natürlich auch mit OpenSSL verwaltet werden. Aber das ist nicht wirklich bequem. Insbesondere wenn man mehr als ein Zertifikat ausstellen will. Durch Zufall bin ich auf XCA gestoßen. Mit dieser Software können X.509 Zertifikate, Zertifikat-Requests, RSA, DSA and EC Schlüssel, Smartcards und CRLs erstellt und verwaltet werden und das sogar unter einer Oberfläche. Zugegeben – auch hier sollte ein Grundwissen über Zertifikate und derer Verwaltung vorhanden sein. Das Tool ist aber deutlich komfortabler als OpenSSL an der Kommandozeile.

Dabei ist das Tool sehr flexibel und es können damit die unterschiedlichsten Zertifikate verwaltet werden. Im folgenden beschränke ich mich aber auf SSL/TLS-Server-Zertifikate.

Unter Windows wird von XCA ein fertiges Setup angeboten. Dies muss nur installiert werden und danach kann es schon losgehen.

01| Datenbank einrichten

01: Datenbank Passwort Als erstes muss eine neue Datenbank angelegt werden. Idealerweise sollte hier direkt auch ein sicheres Passwort für die XCA-Datenbank vergeben werden. Wer später Zugang zu diesen Daten erhält, kann sich beliebige Zertifikate ausstellen und so beispielsweise die Kommunikation unbemerkt mitlesen.

Wenn bereits eine CA mit OpenSSL erzeugt wurde und auch schon Zertifikate dieser CA im Umlauf sind, so können diese relativ einfach importiert werden. Ich gehe aber davon aus, dass wir hier von Null anfangen und alles neu generieren.

02| Templates anlegen

Zunächst empfehle ich mindestens zwei Templates anzulegen (Reiter Vorlagen  -> Button Neue Vorlage). Das ist zwar nicht zwingend erforderlich, aber spart eine Menge wiederkehrender Aufgaben und sorgt auch dafür, dass die Zertifikate immer ähnlich aussehen.

02a| Vorlage für die CA

Die Vorlage für die eigene CA sollte auf den Default-Vorlagewerten für CAs basieren. Dadurch wird sichergestellt, dass die richtigen Einstellungen für die Schlüsselverwendung ausgewählt werden.

Auf dem ersten Tab ( Inhaber ) werden die grundsätzlichen Zertifikatsinformationen eingetragen. Die Felder haben folgende Bedeutung:

Interner Name Der Wert in diesem Feld dient nur als interne Referenz und sollte das Template eindeutig identifizieren, damit es in der Übersicht schnell wiedergefunden wird. Das Feld wird nicht in das Zertifikat geschrieben.
countryName Hier sollte der Ländercode eingetragen werden (z.B. DE für Deutschland).
stateOrProvinceName Hier wird in der Regel das Bundesland eingetragen (z.B. NRW)
localityName In dieses Feld wird der Ort hinterlegt. In der Regel ist das der Ausstellungsort des Zertifikats.
organizationName Der Name der Organisation, die das Zertifikat ausgestellt hat.
organizationUnitName In der Regel wird hier ein Abteilungsbezeichner eingetragen.
commonName Hier kann ein allgemeiner Bezeichner hinterlegt werden. Teilweise hat dieser auch eine besondere Beduetung wie z.B. bei TLS-Server-Zertifikaten. Im Template sollte dieser Wert frei bleiben.
emailAddress Hier sollte eine valide E-Mail-Adresse hinterlegt werden, damit bei einem Zertifikatsfehler Kontakt aufgenommen werden kann.

Sind alle Felder ausgefüllt, kann mit den Einstellungen auf dem Reiter Erweiterungen weiter gemacht werden. Hier wird zunächst die Laufzeit des Zertifikats eingestellt. Für das CA-Template sollte eine Laufzeit von 10 Jahren in der Regel passen.

Darüber hinaus sollte eine oder mehrere URLs für eine Zertifikatssperrliste (Certificate Revokation List; CRL) eingetragen werden (Feld X 509v3 CRL Distribution Points). Unter dieser URL sollte ein Liste mit gesperrten Zertifikaten veröffentlicht werden können. So können Zertifikate nachträglich zurückgerufen werden.

Auf den anderen Reitern müssen in der Regel keine Änderungen vorgenommen werden. Wichtig ist, dass unter Schlüsselverwaltung die Punkte Certificate Sign  und CRL Sign  ausgewählt sind.

02b| Vorlage für die Server Zertifikate

In ähnlicher Weise wird anschließend ein Template für die Server-Zerifikate erstellt. Daher wird das neue Template auf Basis der Built-In Vorgabe für HTTPS-Server erstellt. Unter dem Reiter Schlüsselverwaltung sollten damit folgende Punkte ausgewählt werden: Digital Signature , Non Repudiation  und Key Encipherment.

Hier werden im Wesentlichen die Einstellungen auf dem Reiter Inhaber  ausgefüllt. Die Gültigkeitsdauer für ein Server-Zertifikat sollte geringer sein als das der CA. Ich habe mich hier für mehr als ein Jahr entschieden, damit ich nicht zu häufig die Zertifikate wechseln muss.

03| CA-Zertifikate erstellen

Als erstes muss das Zertifikat für die Root CA erstellt werden. Dazu wird im Reiter Zertifikate  ein neues Zertifikat erstellt und auf dem Reiter Herkunft im Abschnitt Unterschreiben der bereits Punkt “Erstelle ein selbst signiertes Zertifikat mit der Seriennummer”. Dabei solltet unbedingt der Signatur Algorithmus SHA256 oder Länger verwendet werden. SHA1 oder gar MD5 sollten deaktiviert werden. Da SHA256 allerdings nicht von Windows XP unterstützt wird ist hier in der Regel noch SHA1 vorausgewählt.

Im Abschnitt “Vorlage für das neue Zertifikat” erstellte CA Template ausgewählt und mit einem Klick auf Alles übernehmen  eingestellt.

Anmerkung: Der Standardwert für den Signaturalgorithmus kann im Menüpunkt Datei -> Optionen  gesetzt werden.

Im Reiter Inhaber  werden nun die Felder Interner Name  und commonName. Insbesondere für commonName  sollte ein sprechender Name verwendet werden, weil dies der Name des Zertifikats ist, der in der Zertifikatsverwaltung angezeigt wird.

Mit einem Klick auf den Button Erstelle einen neuen Schlüssel  unten Rechts kann ein neuer Schlüssel erstellt werden, für den das Zertifikat dann ausgestellt wird. Als Schlüsselparameter sollte z.B. RSA mit einer Schlüssellänge von mindestens 2048 Bit verwendet werden. Auch dem Schlüssel sollte ein sprechender Name gegeben werden, damit hinterher in der Schlüsselübersicht eindeutig erkennbar ist, welcher Schlüssel für welches Zertifikat verwendet wurde.

Auf den anderen Tabs muss hier eigentlich nichts mehr eingestellt werden. Ggf. kann die Zertifikatslaufzeit für die Root CA auf dem Reiter Erweiterungen  noch angepasst werden (Achtung: Nachdem der Gültigkeitszeitraum angepasst wurde unbedingt tauf übernehmen klicken.).

Mit einem Klick auf OK wird das Zertifikat dann erstellt und es könnten theoretisch die ersten Server-Zertifikate erstellt werden, die mit der Root CA signiert werden. Aber anstatt die Server-Zertifikate direkt von der Root-CA unterschreiben zu lassen, sollte idealerweise noch eine Zwischen-CA angelegt werden. In meiner Umgebung habe ich für jeden Aufgabenbereich eine eigene Zwischen-CA erstellt. Eine Sub-CA kümmert wird dabei ausschließlich für die HTTPS-Server-Zertifikate verwendet. Eine weitere Sub-CA könnte beispielsweise für die Verwaltung von VPN-Zertifikaten genutzt werden. Der Vorteil der Sub-CAs ist dabei, dass ein ganzer Zweig (z.B. alle VPN-Zertifikate auf einmal ungültig gemacht werden können, wenn das Zertifikat der entsprechenden Zwischen-CA zurückgerufen wird. Außerdem sind die Zertifikate auf diese Weise leichter nachzuhalten.

Zur Erstellung der Sub-CA wird eigentlich genauso vorgegangen wie bei der Root CA. Der einzige Unterschied: Auf dem Tab Herkunft wird im Abschnitt Unterschreiben Verwende dieses Zertifikat zum Unterschreiben  das Zertifikat der Root CA ausgewählt.

Nachdem alle CA-Zertifikate erstellt wurden, sollte für die CA Schlüssel im Nachgang noch ein Passwort eingegeben werden. Danach können dann nur noch Zertifikate von den CAs erstellt werden wenn das Passwort eingegeben wird. Dazu muss im Tab Private Schlüssel  lediglich im Kontext-Menü der Schlüssel die Option Passwort ändern ausgewählt werden.

Achtung: In der Regel werden immer nur die Zertifikate z.B. bei der Serverkonfiguration verwendet. Die privaten Schlüssel zu den CA-Zertifikate sollten unter allen Umständen unter Verschluss gehalten und niemals veröffentlicht werden. Werden also die CA-Zertifikate exportiert, dann immer nur der öffentliche Teil!

04| Server-Zertifikat erstellen

Ein typisches Beispiel für einen Server ist wohl der NAS-Server im eigenen Netzwerk. Daher werde ich im folgenden am Beispiel eines Synology NAS erläutern, wie ein eigenes Zertifikat für den Server erstellt und eingebunden werden kann.

Das Zertifikat wird im Wesentlichen genau so erstellt wie das CA-Zertifikat. Allerdings wird hier nicht das zuvor erstellte CA-Template sondern diesmal das Server-Template verwendet. Zur Unterschrift des Zertifikats sollte die zuvor erstellte Server-CA genutzt werden (Tab Herkunft ).

Auf dem Inhaber-Reiter  kann der Schlüssel zum Zertifikat wieder durch einen Klick auf Erstelle einen neuen Schlüssel  angestoßen werden. Dabei sollte der Schlüssel für das Server-Zertifikat diesmal nicht durch ein Passwort geschützt werden, da ansonsten der Web-Server der das Zertifikat später nutzen soll nicht mehr automatisch gestartet werden kann.

Für ein Server-Zertifikat hat das commonName-Feld eine besondere Bedeutung. Hier muss unbedingt der Name eingetragen werden unter dem das System im Browser aufgerufen wird (z.B. nas). Nur wenn der aufgerufene Server-Name mit diesem Wert übereinstimmt wird vom Browser später keine Fehlermeldung ausgegeben. Dies ist insbesondere dann ein Problem, wenn der Server über mehrere Namen erreichbar ist (z.B. über die IP-Adresse des Servers und über einen DNS-Namen). In diesem Fall kann auch ein sogenanntes Wildcard-Zertifikat erstellt werden. Ein Zertifikat mit dem Wert “*.fritz.box” im commonName-Feld sollte auf allen internen Systemen verwendet werden können, sofern eine Fritz!Box eingesetzt wird und die Server ausschließlich über die Domain-Namen angesprochen werden.

Alternativ kann aber auch das Feld X 509v3 Subject Alternative Name auf dem Reiter Erweiterungen genutzt werden, um das Zertifikat für mehrere Server-Namen auszustellen.  Hier können beliebig viele IP-Adressen und DNS-Name eingetragen werden unter denen das System erreichbar sein soll. So können dann auch serverspezifische Zertifikate erstellt werden und das Zertifikat wird auch dann noch als gültig erkannt, wenn der Server über seine IP-Adresse aufgerufen wird.

Zu guter letzt muss ggf. nochmal der Gültigkeitszeitraum des Zertifikats eingestellt werden. Abschließend muss nur noch überprüft werden, dass bei der Schlüsselverwendung die Optionen Digital Signature , Non Repudiation  und Key Encipherment aus dem Template korrekt übernommen wurden.

05| Root-CA importieren

Damit der Browser den Zertifikaten vertraut, die von der eben erstellten CA ausgestellt wurden, muss die CA zunächst eingebunden werden. Das muss in der Regel pro Betriebssystem oder Browser nur einmal durchgeführt werden. Danach sind für den Browser dann alle von der CA ausgestellten Zertifikate vertrauenswürdig.

Die Einbindung der Root CA ist abhängig vom Betriebssystem und im Folgenden erläutere ich das Vorgehen für Windows und Android.

05a| Windows

Unter Windows ist die erste Anlaufstelle die Zertifikatsverwaltung. Am einfachsten wird diese durch den direkten Aufruf des MSC-SnapIn aufgerufen ( Win+R > certmgr.msc). Hier kann dann das Zertifikat der Root CA zu den Vertrauenswürdigen Stammzertifizierungsstellen  hinzugefügt werden ( Kontextmenü > Alle Aufgaben > Importieren...). Das dabei zu importierende Zertifikat der Root CA muss aus XCA im PKCS #7 Format exportiert werden.

Danach sollte unter Chrome bzw. Chromium alle von der CA ausgestellten Zertifikate als vertrauenswürdig eingestuft werden. Ggf. ist der Browser anschließend nochmal neu zu starten.

Für Firefox muss die CA über den Firefox-eigenen Zertifikatsmanager nochmal gesondert installiert werden. Den Zertifikatsmanager von Firefox ist in den Einstellungen unter Erweitert > Zertifikate > Zertifikate anzeigen  versteckt. Hier kann über den Button Importieren... das Zertifikat ebenfalls im PKCS #7 Format importiert werden.

05b| Android

Für den Import in Android muss das Zertifikat im PEM-Format exportiert und auf das Smartphone kopiert werden. Anschließend kann in den Android Einstellungen unter dem Punkt Sicherheit im Abschnitt Anmeldedatenspeicher  über den Menüpunkt Von Speicher installieren  das Zertifikat installiert werden.

Die danach erscheinende Fehlermeldung “Das Netzwerk wird möglicherweise von einem unbekannten Dritten überwacht” in der Statuszeile kann auf ungerooteten Smartphone leider nicht so ohne weiteres deaktiviert, sondern nur quittiert werden. Mit jedem neuen Systemstart wird die Meldung in diesem Fall erneut auftauchen. Ein Regelmäßiger Blick in die Zertifikatsverwaltung nach einem Neustart durch einen Klick auf die Meldung bleibt da leider nicht erspart.

Wer auf seinem Android hingegen Root-Rechte hat, kann mit der Open Source App “Move Certs!” die User Zertifikate mit einem einfachen Klick in den Zertifikatsspeicher des Systems verschieben. Danach ist taucht die Fehlermeldung dann nicht wieder auf und auch die zwingend vorgeschriebene PIN-Sperre bei installierten User-Zertifikaten ist anschließend nicht mehr erforderlich.

Move Certs!
Move Certs!
Entwickler: Felix Ableitner
Preis: Kostenlos
  • Move Certs! Screenshot
  • Move Certs! Screenshot
  • Move Certs! Screenshot
  • Move Certs! Screenshot

06| Server Zertifikat installieren

Das erstellte Server-Zertifikat muss jetzt natürlich noch in die jeweilige Server-Konfiguration eingebunden werden. Wie da im einzelnen vorzugehen ist und in welchem Format das Zertifikat und ggf. auch die CAs zu exportieren sind, steht in der Regel der Dokumentation des jeweiligen HTTP-Servers. Bei dem Beispiel der oben genannten Synology NAS (DSM 5.2) ist dabei folgendermaßen vorzugehen:

  1. Das Zertifikat das für den Server erstellt wird im PEM-Format in eine Datei exportiert.
  2. Der private Schlüssel des Servers wird ohne Passwort-Schutz im PEM-Format in eine Datei exportiert.
  3. Das Zertifikat der Server-CA wird inklusive der kompletten Zertifikatskette eim PEM-Format exortiert.

Danach wird in der Synology-Admin-Oberfläche im “Control Panel” der Eintrag “Security” ausgewählt. Im Reiter Certificate können die oben exportierten Dateien über den Button Import Certificate im Synology NAS eingespielt werden. Dabei muss der Web-Server neu gestartet werden, so dass vorübergehend die Verbindung verloren geht.

Wenn das Zertifikat der Root CA korrekt installiert wurde (siehe Schritt 5), dann sollte die Verbindung jetzt als sicher angezeigt werden.

07| Schutz der XCA Datenbank

Zum Schluss noch einige Anmerkung der XCA-Datenbank. Wer Zugriff auf diese Datenbank und die darin gespeicherten CA-Schlüssel hat, kann beliebige Zertifikate erzeugen. Spätestens ab dem Zeitpunkt, wo das CA-Zertifikat in den Browser importiert wird, kann das kritisch werden und beispielsweise im Rahmen von Man-In-The-Middle Angriffen genutzt werden um den SSL-Tunnel aufzusplitten.

Daher sollte der Zugriff auf die XCA-Datenbank und die CA-Schlüssel so gut wie möglich abgesichert werden. Daher sollte die Datenbank  und die privaten CA-Schlüssel unbedingt mit unterschiedlichen Passwörtern geschützt werden.

Wer es noch sicherer will, der kann die XCA-Datenbank auch auf einen USB-Stick speichern und somit nach der Erstellung der Zertifikate Offline in der Schreibtischschublade verwahren. So wird zumindest der Zugriff über das Netzwerk zuverlässig unterbunden…