Selbst unterzeichnetes Zertifikat: Alternativer Name und DDNS

Status
Für weitere Antworten geschlossen.

Favi

Benutzer
Mitglied seit
19. Okt 2015
Beiträge
59
Punkte für Reaktionen
0
Punkte
6
Hallo liebe Synology- und SSL-Experten,

heute habe ich einige Fragen zum Thema selbst erstelltes Zertifikat auf der Synology DS an Euch. Ich habe mich mittlerweile in einiges eingelesen, das ich hier und an anderen Stellen im Netz gefunden habe, zu befriedigenden Antworten bin ich aber bisher nicht gekommen - insbesondere bin ich mir nicht sicher, ob ich alles richtig verstanden habe - und bitte deshalb Euch um Hilfe und Antworten. Ich mache es etwas ausführlicher, weil Ihr dann vielleicht meine (Denk-)Fehler erkennen könnt und möglicherweise andere Hilfesuchende aus diesem Thread so besser Informationen ziehen können.

Mein Anwendungsszenario ist m.E. nicht allzu ungewöhnlich: Ich möchte meine DS hauptsächlich innerhalb meines LANs, ausgewählte Dienste (CardDAV, CalDAV und Mail Server IMAP) auch von außerhalb via Internet, DDNS (ich nutze MyFritz) und Portfreigaben auf meiner FRITZ!Box nutzen. Das heißt, ich habe gezwungenermaßen zwei Adressen: intern die lokale IP bzw. den Namen der NAS, außerhalb die DDNS-Adresse xyz.myfritz.net.
Mittlerweile habe ich gelesen, dass die FRITZ!Box zwar NAT-Loopback beherrscht, aber nach meinem Verständnis müsste ich trotzdem auch für die rein lokale Verbindung unter dem DDNS-Namen die gesamte Reihe an dafür notwendigen Ports weiterschalten. Das möchte ich ja gerade vermeiden.
Folglich muss ich auf allen meinen mobilen Geräten, die das heimische Netz auch verlassen, für Mailserver und DAV-Dienste die DDNS-Adresse hinterlegen. Für Dienste, die ich nur per VPN oder im lokalen Netz nutzen und nicht per Portweiterleitung nach außen öffnen möchte, muss ich die lokale Server-IP hinterlegen. Auf ausschließlich lokal genutzten Geräten kann ich auch für den Mailserver und die DAV-Dienste die lokale Server-IP hinterlegen.

Nun beginnt mein Problem: Ich möchte alle Verbindungen - lokal und von außerhalb - per SSL absichern. Hierfür würde mir ein selbst unterzeichnetes Zertifikat genügen, da ich dieses ja bei einer Erstverbindung auf dem jeweiligen Gerät anzeigen und bestätigen kann. Die Bestätigung durch eine externe Stelle (StartSSL o.ä.) brauche ich deshalb nicht und sie ist ja auch für eine lokale IP und eine DDNS-Adresse nicht zu bekommen.

Um Verständnisprobleme meinerseits auszuschließen, beschreibe ich kurz, wie ich die Funktionsweise von SSL-Zertifikaten begreife und bitte um Hinweise, wenn das so nicht stimmt:
  1. Eine übergeordnete CA stellt ein Zertifikat für einen Server unter einer bestimmten Domain aus. Dass sie hierfür u.a. bestimmte Dateien des Servers braucht, lasse ich mal außen vor, da ich ja kein extern signiertes Zertifikat erstellen möchte.
  2. Ist diese CA in meinem Gerät als vertrauenswürdige Stammzertifizierungsstelle hinterlegt, vertraut mein Gerät jedem Server, der ein Zertifikat vorweist, das in der Zertifikatskette auf das Stammzertifikat zurückzuführen ist und das für den Domainnamen ausgestellt ist, unter dem der Server angesteuert wird.
  3. Alternativ kann ich z.B. in meinem iPhone auch ohne Stammzertifikat dem jeweiligen Server-Zertifikat vertrauen, wodurch genau dieses Zertifikat einer Ausnahmeliste hinzugefügt wird (die seit iOS 7 oder 8 nicht mehr zu ändern ist außer durch Zurücksetzen der Netzwerkeinstellungen, aber das ist ein anderes leidiges Thema und betrifft Apple...)
  4. Das von der Synology DS selbst erstellte Server-Zertifikat server.crt wird gemeinsam mit seinem Schlüssel automatisch auf dem Server hinterlegt. Das übergeordnete Stammzertifikat, mit dem sich die DS das Server-Zertifikat selbst signiert hat, lässt sich als ca.crt exportieren und als vertrauenswürdige Stammzertifizierungsstelle auf dem jeweiligen Client-Gerät hinterlegen. Danach funktioniert auf diesem Gerät alles so, als ob der Server von einer anerkannten externen Stelle zertifiziert worden wäre.

Ich lege auf dieser Wissensbasis also los und erstelle im DSM ein selbst signiertes Zertifikat:
  1. Als Common Name gebe ich die lokale IP-Adresse meiner DS an. Das habe ich bereits vor Wochen bei der Erstinbetriebnahme so gemacht (bisher habe ich die DS nur über das LAN genutzt). Alternativ habe ich auch probiert, den internen Servernamen (angegeben unter Systemsteuerung > Netzwerk > Allgemein) hier anzugeben.
  2. Nach Erstellung des Zertifikats exportiere ich die ca.crt und füge diese den vertrauenswürdigen Stammzertifizierungsstellen in meinem Windows 10 hinzu (um keine Verwirrung zu stiften, lösche ich immer alle vorher zu Testzwecken auf der Diskstation erstellten ca.crt aus diesem Verzeichnis, dort befindet sich also immer nur das aktuelle Stammzertifikat).
  3. Beide Varianten bei der Auswahl des Common Name (IP oder Servername) führen dazu, dass die DS ausschließlich unter der jeweils angegebenen Adresse mit zusätzlicher Eingabe des Ports 5001 (obwohl die automatische Weiterleitung von http auf https aktiviert ist, aber das ist nur eine kleine andere Baustelle) erreichbar ist. Bei Eingabe der jeweils anderen Netzwerkadresse hätte ich ja einfach eine Meldung über das nicht passende Server-Zertifikat erwartet, Microsoft Edge sperrt den Zugriff aber komplett. It's not a bug, it's a feature!

Soweit, so ausreichend für die lokale Anwendung und Ansteuerung des Servers über eine interne Adresse.
Nun dachte ich mir, für die SSL-Verbindung auf meine DS via Internet müsste ich doch auch meine DDNS-Adresse beim Erstellen des Zertifikats angeben können. Im Gegensatz zu externen Zertifizierungsstellen überprüft die DS die Adresse bei der Zertifikatserstellung ja nicht und die angegebene Adresse dient ja nur der Prüfung durch das Client-Gerät, ob das Zertifikat des antwortenden Servers für die jeweilige Adresse auch das richtige sein kann. Dass die TLD myfritz.net komischerweise ;) nicht mir gehört, sollte bei einem selbst signierten Zertifikat also keine Rolle spielen. Meine Vermutung wird auch durch diesen Thread bestätigt: http://www.synology-forum.de/showthread.html?40141-Wie-erstelle-ich-ein-g%C3%BCltiges-SSL-Zertifikat-f%C3%BCr-synology-me-DDNS-ohne-eigene-Dom%C3%A4ne (leider funktioniert der Link in Post #3 nicht mehr).

Allerdings möchte ich ja, dass sowohl meine interne Server-Adresse als auch meine DDNS-Adresse durch das SSL-Zertifikat abgedeckt werden, da sich sonst die über die jeweils andere Adresse per SSL eingewählten Clients über den falschen Namen beschweren und leider in einem Fall von Drittsoftware (CalDAV Synchronizer) ohne Auswahl durch den Nutzer ganz sperren. Zwei Zertifikate für einen Server sind nach Aussage einiger Quellen denklogisch nicht möglich, weil die Verschlüsselung bereits stattfindet, wenn der Server noch nicht weiß, über welche Adresse er angesteuert wurde (Zwischenfrage: stimmt das so?)
Im Netz habe ich hierzu nach einigem Recherchieren das Stichwort "Multidomain SSL-Zertifikat" gefunden. Die dort angegeben Begriffe haben mich an einen Punkt in der Zertifikatserstellung in der DS erinnert: Betreff alternativer Name. Unter diesem habe ich also für einen ersten LAN-internen Test den Servernamen als Alternative zur unter Common Name eingegebenen IP-Adresse des Servers eingegeben. Das Ergebnis: Mein Browser akzeptiert eine SSL-Verbindung nur noch unter dem als Betreff alternativer Name angegebenen Servernamen und ignoriert anscheinend den Common Name. Ist das Verhalten so richtig? Muss ich also bei Nutzung des Eintrags Betreff alternativer Name alle gewünschten Adressen dort eingeben und der Common Name wird bedeutungslos?

Wer bis hier gelesen hat: vielen Dank allein dafür :D. Ich wäre dankbar für folgende Antworten:
  • Stimmen meine Annahmen zur groben Funktionsweise von SSL-Zertifikaten?
  • Handelt es sich beim Feld Betreff alternativer Name bei der Zertifikatserstellung im DSM um eine Möglichkeit, ein "Multidomain SSL-Zertifikat" zu erstellen?
  • Wenn der zweite Punkt mit ja zu beantworten ist: Was genau muss ich dann in dieses Feld eingeben, um das Zertifikat sowohl für die Ansteuerung meiner DS unter ihrer lokalen IP, als auch unter ihrer DDNS-Adresse zu nutzen?

Viele Grüße und ein schönes Restwochenende
Favi
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
13.804
Punkte für Reaktionen
3.761
Punkte
468
Das ist mir jetzt zu viel Text - ich hab nur grob überflogen.
Im Wiki ist ein Artikel über die Erstellung eigener Zertifikate zu finden. Der ist veraltet, das geht im DSM inzwischen wesentlich komfortabler. Aber das Prinzip ist das gleiche.

Ich habe beispielsweise meinen DDNS-Namen als Common Name verwendet und die lokalen Namen und IP-Adressen meiner DSen als alternative Adressen angegeben. So kann ich mit dem gleichen Zertifikat über DDNS als auch mit Namen oder IP auf beide DSen zugreifen.

Auf Geräten, die ich auch auch extern nutze (Handies, iPad), verwende ich den DDNS-Namen, das funktioniert dank Loopback der Fritzbox auch intern (WLAN).
 
Zuletzt bearbeitet:

Favi

Benutzer
Mitglied seit
19. Okt 2015
Beiträge
59
Punkte für Reaktionen
0
Punkte
6
Hallo Benares,

Du hast natürlich recht, das war für ein Forum eigentlich zuviel Text. Ich wusste bloß nicht, was ich weglassen sollte - nachdem ich von Zertifikaten bisher wenig Ahnung hatte, wollte ich einfach ausschließen, ein wesentliches Detail in meiner Vorgehensweise auszulassen.

Trotzdem hast Du mir mit Deiner Antwort sehr weitergeholfen. So wusste ich, dass meine Überlegungen in die richtige Richtung gehen.
Ich habe dann mit einem anderen Browser (MS Edge zeigt bei Zertifikatfehlern noch nicht einmal das fehlerhafte Zertifikat an) dann herausgefunden, dass meine verbleibenden Probleme mit den SSL-Verbindungen über verschiedene Adressen an einem alten Zertifikat lagen, das vom WebDAV-Server der NAS noch benutzt wurde, obwohl ich das Zertifikat im DSM bereits geändert hatte und die DSM-Oberfläche selbst sich auch schon mit dem neuen Zertifikat identifiziert hat. Darauf habe ich die NAS neu gestartet und voila: nun wird überall das neue Zertifikat benutzt und ich kann über alle Adressen wunderbar mit SSL arbeiten.

Dieser Hinweis hilft vielleicht dem ein oder anderen, der das Zertifikat ändert und sich wundert, weshalb es Probleme bei der geschützten Verbindung gibt...

Viele Grüße
Favi
 

OdinsAuge

Benutzer
Mitglied seit
12. Nov 2015
Beiträge
377
Punkte für Reaktionen
36
Punkte
34
Hi, ihr scheint das ja ganz gut mit mehreren Adressen und DDNS hinbekommen zu haben.
Ich habe über die DSM ein Zertifikat generiert, ich habe dabei meine name.synology.me Adresse als CN und meine interne IP als alternative Angegeben.
Allerdings bekomm ich jetzt sowohl extern über die DDNS Adresse als auch intern über die IP im Browser den Fehler, der Name würde nicht passen.
Auch SSLLabs meint der Name passt nicht und listet mir dann aber genau die Namen auf:
Capture.jpg

Wisst ihr vll was ich da falsch mache?
 

Favi

Benutzer
Mitglied seit
19. Okt 2015
Beiträge
59
Punkte für Reaktionen
0
Punkte
6
Hallo,

@OdinsAuge: leider konnte ich Dir mit Deiner Frage nicht weiterhelfen, deshalb habe ich auch nicht geantwortet. Tut mir Leid!


@all: ich habe eine weitere Frage zu Zertifikaten, die hier noch ganz gut dazu passt, also mache ich mal keinen neuen Thread auf und hoffe auf kundige Hilfe.

Nach dem Update meiner DS716+ auf DSM6.0 (läuft bei mir sonst bisher ohne erkennbare Probleme, trotz erster Generation der DS716+, toi toi toi) habe ich letztens ein neues selbstgeneriertes Zertifikat mit DSM erstellt, um neben der netzwerkinternen IP-Adresse und den bisherigen Alternativnamen einige weitere alternative DNS-Namen aufzunehmen (m.E. kann man ein bestehendes Zertifikat ja nicht einfach um diese Einträge erweitern).
Es fiel mir schon beim Abschluss im Zertifikats-Assistenten der DS auf, dass statt der IP-Adresse in der Übersicht der Zertifikatsdaten nur drei Fragezeichen in schwarzen Rauten angezeigt wurden, die anderen DNS-Einträge ("diskstation", "xyz.myfritz.net" etc.) aber ohne Fehler erschienen. Das war m.E. in DSM 5.2 nicht so.

Das Server-Zertifikat enthält neben den verschiedenen Einträgen, die mit "DNS-Name=" beginnen, bei der IP-Adresse stattdessen den Eintrag "IP-Adresse=" mit der korrekten IP dahinter. Ich könnte schwören, dass es diesen Unterschied in der Bezeichnung bei dem mit DSM 5.2 erstellten Zertifikat nicht gab. Trotzdem kann ich nach Integration des neuen Root-Zertifikats in meinem Zertifikat-Speicher den Server auch über seine IP aufrufen und das Server-Zertifikat wird akzeptiert, der Eintrag funktioniert dort also grundsätzlich wie er soll.

Leider scheint mein Outlook 2013 damit im Gegensatz zum Browser nicht zurechtzukommen, wenn ich als Mailserver die IP angebe, meldet es, das Sicherheitszertifikat des Servers könne nicht überprüft werden - "der Zielprinzipalname ist falsch". Meine Suche über Google brachte immer nur den Hinweis, dass dann der Name des angewählten Servers nicht zum SSL-Zertifikat passt. Das stimmt wie gesagt nicht, ich habe genau die IP-Adresse, die ich als Server eingebe mit im Zertifikat angegeben. Gebe ich stattdessen als Server einen der intern erreichbaren Namen ein, die in den mit "DNS-Name=" gekennzeichneten Einträgen im Zertifikat erfasst sind, funzt die Sache. Outlook scheint also einen Eintrag im Server-Zertifikat, der mit "IP-Adresse=" beginnt, nicht verarbeiten zu können.

Sorry für viel Text, konnte die Fehlerbeschreibung nicht kürzer fassen. Kann mir jemand erklären,
- weshalb anscheinend selbst der DSM-Assistent seine eigenen Zertifikate nicht richtig auslesen kann und statt IP-Adresse komische Sonderzeichen anzeigt?
- ob der Eintrag "IP-Adresse=" grundsätzlich in einem Zertifikat korrekt ist (und ich also weiter in Richtung Outlook-Bug recherchieren muss) oder DSM 6.0 an der Stelle schon einen Fehler einbaut, der Outlook dann verwirrt?

Verständnisfrage am Rande: wie schafft die DS es eigentlich, dass sie unter dem selbstgewählten Namen im Netzwerk erreichbar ist? Schließlich kann sie ja keinen entsprechenden DNS-Eintrag im Router vornehmen...

Viele Grüße
Favi
 

fero

Benutzer
Mitglied seit
01. Nov 2016
Beiträge
11
Punkte für Reaktionen
0
Punkte
1
Moin zusammen,

kann hier jemand mal genauer auf die Erstellung eines selbst bestätigten Zertifikates eingehen? Vermutlich ist es ganz leicht aber ich raffe nicht, was ich in die Felder eingeben muss. OdinsAuge scheint ein ähnliches Problem zu haben. Deswegen schreibe ich hier.
Unter DSM6.2 / Systemsteuerung / Sicherheit / Zertifikate kann ich ein neues Zertifikat hinzufügen. Wähle ich dann selbst-signiertes Zertifikat erstellen kommen 2 Eingabemasken:

1. Die erste nennt sich "Root Certificate erstellen". Bei common name gebe ich meinen DynDNS hostnamen ein, also bspw. xy.selfhost.eu.
2. Bei der zweiten Eingabemaske ist dann ein anderer Common Name erforderlich. Ich habe nur leider keinen Schimmer, was ich hier eingebe.

Ich habe im Netz nichts gefunden, dass mir weiter geholfen habe. Ich vermute, dass danach dann das Zertifikat erstellt wird. Mich würde interessieren, ob ich das Zertifikat dann noch unter Windows 10 irgendwo einbinden muss (den privaten Schlüssel), damit der PC mit der DiskStation abgeglichen werden kann. Falls ja, bräuchte ich auch Hilfe, wie das geht.

Besten Dank
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat