Verschlüsselte Kommunikation mit Zertifikaten in Milestone XProtect einrichten

Lesezeit: 6 Minuten

Die Verbindungen zwischen den verschiedenen Serverdiensten sowie auch von den Clients zu den Serverdiensten können durch den Einsatz von Zertifikaten gegen Abhören und Manipulation geschützt werden. Außerdem kann damit die Identität des Servers sichergestellt werden. Im Folgenden wird die grundlegende Funktionsweise der Verschlüsselung und die Konfiguration in Milestone XProtect 2021 R1 erklärt.

Die Funktionsweise kann auch auf praktisch alle anderen Anwendungen, die mit per HTTPS bzw. TLS kommunizieren, angewandt werden.


Grundlagen

Ein Zertifikat hat zwei grundlegende Zwecke:

  • Es bestätigt die Identität seines Inhabers mittels digitaler Signatur
  • Es beinhaltet den öffentlichen Schlüssel des Servers

Als Identität steht in einem Zertifikat mindestens der Common Name, was üblicherweise der vollständige Domainname des Servers ist, also zum Beispiel maps.google.com. Zusätzlich kann ein Zertifikat noch weitere Daten wie Land, Gültigkeitsdatum usw. enthalten.

Identität

Wird ein Zertifikat von einer CA (Certificate Authority) signiert, so bestätigt diese damit die Identität des Zertifikatinhabers, da dieser beim Signieren die Herrschaft über den Webserver oder die Domain nachweisen muss. Das geschieht üblicherweise so, dass man von der CA eine kleine Datei bekommt, die man dann am Webserver ablegen muss oder dass man einen Datensatz bekommt, den man im DNS der eigenen Domain eintragen muss.
Ist man dazu in der Lage, hat man bewiesen, dass man die Gewalt über den Server bzw. die Domain hat.

Damit ein Client einem signierten Zertifikat vertraut, muss er der jeweiligen CA vertrauen. Eine Liste der als vertrauenswürdig eingestuften CAs ist in jedem Betriebssystem enthalten und wird von dessen Hersteller gepflegt. Manche Browser bringen auch ihre eigene Liste mit.
In Windows findet man diese zum Beispiel unter Win+R –> certlm.msc –> Vertrauenswürdige Stammzertifizierungsstellen.

Bei einem selbstsignierten Zertifikat ist dieses Vertrauen nicht gegeben, da die signierende CA nicht in dieser Liste enthalten ist.

Öffentlicher Schlüssel

Um eine Verbindung zu verschlüsseln, kommt zu Beginn meistens eine asymmetrische Verschlüsselung zum Einsatz. Deren Funktion basiert auf einem Schlüsselpaar, das vom Server generiert wird.
Es besteht aus zwei Zeichenketten (Schlüsseln), die eine besondere Eigenschaft haben:

Daten, die mit dem einen Schlüssel verschlüsselt wurden, können nur mit dem anderen Schlüssel entschlüsselt werden.

Einer der beiden Schlüssel wird als privater Schlüssel definiert und verbleibt am Server. Er wird also geheim gehalten. Der andere ist somit der öffentliche Schlüssel, der in einem Zertifikat hinterlegt wird.

TLS-Verschlüsselung

Die Verschlüsselung läuft bei TLS in etwa so ab:

  1. Client bittet Server um dessen Zertifikat
  2. Server sendet sein Zertifikat (inkl. öffentlichem Schlüssel) an Client
  3. Client prüft die Identität wie oben beschrieben
  4. Client generiert einen zufälligen Schlüssel (Session Key)
  5. Client verschlüsselt diesen mit dem öffentlichen Schlüssel des Servers
  6. Client sendet den verschlüsselten Schlüssel an den Server
  7. Server kann den Schlüssel mit seinem privaten Schlüssel entschlüsseln
  8. Jetzt haben Client und Server einen gemeinsamen Session Key, der ab diesem Zeitpunkt zur symmetrischen Verschlüsselung* der Verbindung eingesetzt wird

*) Asymmetrische Verschlüsselung hat zwar den Vorteil, dass eine sichere Verbindung aufgebaut werden kann, ohne dass die beiden Verbindungspartner ein gemeinsames Geheimnis haben. Sie hat jedoch den Nachteil, dass sie viel Rechenleistung benötigt. Daher wird sie nur verwendet, um zu Beginn einer Verbindung ein gemeinsames Geheimnis (Session Key) auszutauschen. Dieser Session Key wird dann für eine symmetrische Verschlüsselung benutzt, wo es also nur einen Schlüssel gibt, mit dem Daten sowohl ver- als auch entschlüsselt werden können.

Digitale Signatur

Das Signieren eines Zertifikats und die Prüfung der Signatur funktionieren ebenfalls mit asymmetrischer Verschlüsselung.
Zuerst wird am Server das Schlüsselpaar erstellt und der öffentliche Schlüssel sowie die gewünschten zusätzlichen Informationen in ein Zertifikat gepackt. Dieses wird dann als CSR (Certificate Signing Request) an eine CA gesendet.

Wird das Zertifikat dann von der CA signiert, passiert folgendes:

  1. CA bildet einen Hash (Eine Art Prüfsumme) über den gesamten Inhalt des Zertifikats
  2. CA verschlüsselt diesen Hash mit ihrem eigenen privaten Schlüssel
  3. CA fügt den verschlüsselten Hash dem Zertifikat hinzu

Die Prüfung durch den Client erfolgt dann so:

  1. Client bekommt Zertifikat (inkl. verschlüsseltem Hash) vom Server
  2. Client entschlüsselt den Hash mit dem öffentlichen Schlüssel der CA, welcher wie oben beschrieben in den vertrauenswürdigen Stammzertifizierungsstellen vorliegt
  3. Client bildet selbst den Hash über das Serverzertifikat
  4. Client vergleicht diesen mit dem entschlüsselten Hashwert. Stimmen die beiden Hashes überein, weiß der Client, dass die Daten im Zertifikat nicht verändert wurden und kann somit die Echtheit des Zertifikats bestätigen

Selbstsignierte Zertifikate

Diese Prüfung der Signatur ist bei Zertifikaten, die man sich selbst signiert hat, natürlich nicht sinnvoll. Daher eignen sich selbstsignierte Zertifikate nicht zur Sicherstellung der Identität des Servers. Das ändert jedoch absolut nichts an der Sicherheit der Verschlüsselung, die ja nur auf dem Schlüsselpaar beruht.

Man kann also festhalten:

Verbindungen mit selbstsignierten Zertifikaten sind genauso gut vor Abhören und Manipulation geschützt wie jene mit CA-signierten Zertifikaten, man kann aber nicht sicher sein, dass der Server auch derjenige ist, der er vorgibt zu sein.


Konfiguration in Milestone

Es wird hier von einer bereits in Betrieb befindlichen Installation ausgegangen, wo noch keine Verschlüsselung aktiv ist. Bei einer Neuinstallation kann man die Anleitung aber sinngemäß genauso verwenden, wobei eine Nachträgliche Aktivierung unter Umständen einfacher sein könnte.

Vorbereitung

Um mit Zertifikaten arbeiten zu können, ist es erforderlich, dass alle Server einen Domainnamen haben und dieser im Netzwerk auch korrekt vom DNS zu IP-Adressen aufgelöst wird. Bei Servern, die aus dem Internet erreichbar sein sollen, ist somit auch eine offiziell registrierte Domain erforderlich.

CSR (Zertifikatsanforderung erstellen)

Die folgenden Schritte sind auf jedem Server auszuführen. Also einmal pro Hostname.

  • IIS-Manager öffnen (inetmgr ausführen)
  • Server auswählen
  • Serverzertifikate öffnen
  • Rechts auf Zertifikatsanforderung erstellen klicken
  • Vollständigen Domainnamen des Servers bei Gemeinsamer Name (Common Name)
  • Restliche Felder befüllen
  • Weiter
  • Schlüssellänge (Bitlänge) auf 2048 oder höher setzen
  • Weiter
  • Dateiname und Speicherort wählen (z.B. milestoneserver-1.example.com)
  • Fertig stellen

Zertifikat signieren lassen

Die erstellte(n) Datei(en) müssen jetzt durch eine offizielle CA signiert werden. Diese kann manche Parameter, wie beispielsweise die Gültigkeitsdauer, vor dem Signieren noch ändern.

Wenn man möchte, kann man auch selbst eine CA betreiben. Wie das geht, habe ich hier beschrieben.

Das signierte Zertifikat bekommt man dann (meist als .crt-Datei) zurück.

Signiertes Zertifikat installieren

  • Im IIS-Manager im selben Fenster wie vorhin auf Zertifikatsanforderung abschließen klicken
  • Signiertes Zertifikat wählen
  • Sinnvollen Namen vergeben (z.B. Milestone_2021)
  • OK

Damit Milestone anschließend das Zertifikat verwenden kann, muss der Benutzer, unter dem die Milestone-Dienste laufen Zugriff auf den privaten Schlüssel bekommen:

  • certlm.msc ausführen
  • Eigene Zertifikate öffnen
  • Rechtsklick auf das Zertifikat –> Alle Aufgaben –> Private Schlüssel verwalten
  • Benutzer hinzufügen (meistens Netzwerkdienst)
  • Berechtigung Lesen zulassen
  • OK

Zertifikat in Milestone einrichten

  • Rechtsklick auf eines der Milestone-Tray-Icons
  • Server Configurator...
  • Alle drei Schalter aktivieren
  • Jeweils das neue Zertifikat auswählen
  • Ausführen
  • Ausführen

Die Konfiguration wird jetzt angewendet. Dabei werden alle Milestone-Dienste neu gestartet, was eine Weile dauern kann.

Wie vorhin schon erwähnt, müssen alle Verbindungen ab sofort per Domainnamen erfolgen. Bei allen Clients muss dieser als Serveradresse eingetragen werden. Das gilt auch für die Clients am Server selbst, nachdem localhost nicht mehr funktioniert, da das Zertifikat ja beispielsweise für milestoneserver-1.example.com ausgestellt wurde.


Problembehandlung

Erscheint beim Ausführen der Änderungen im Server Configurator eine Fehlermeldung, kann der Vorgang trotzdem erfolgreich gewesen sein. Hierzu einfach prüfen, ob alle Dienste laufen oder den Server Configurator schließen und erneut öffnen.

Sollte das Speichern tatsächlich fehlschlagen, wurde die Leseberechtigung für den privaten Schlüssel wahrscheinlich für den falschen Benutzer vergeben. Hierzu in Den Diensten (services.msc) nachsehen, unter welchem Benutzer die Milestone-Dienste laufen.


Wenn du Feedback loswerden möchtest, nutze bitte das Kontaktformular. Falls dir mein Beitrag weitergeholfen hat, würde ich mich sehr über einen kleinen Kaffee freuen. Mit meinem Empfehlungslink für die Hetzner Cloud bekommst du 20€Guthaben geschenkt, und wenn du einen elektrischen Mietwagen suchst, kannst du hiermit 30€ bei Ufodrive sparen.