Hyper Backup Keine freigegebenen Ordner zur Auswahl beim Anlegen einer Sicherungsaufgabe

[patrickn]

.. was in meinem Fall die Lokale IP ist, richtig. Ändert aber Null an der Gültigkeit eines Zertifikats.

 

[ottosykora]

es gibt kein gültiges Zeirtifikat für eine IP

 

[patrickn]

Richtig, deshalb ja auch für die DDNS Adresse?!?

 

[ottosykora]

du hast hier aber zwei NAS.
die versuchst du zu verbinden
damit die beiden einen gültigen Zertifikat bekommen, müssen sie beide eine eigen Domain haben und zu diser Domain muss da Zertifikat gelöst werden. Die beiden müssen dann natürlich auch via ihren eigenen Anschluss zu dem diese Domain gehört angesprochen werden.

Wenn da irgednwo IP als Ziel verwendet wird, ist Zertifikat selbstverständlich nicht gültig weil niemand solche Zeritifikate signieren wird.

Signieren kannst du allenfalls selber, dann musst aber auch manuell das Vertrauen aussprechen.

 

[patrickn]

Falsch. Man kann den Synology DNS Dienst ganz offiziell auf die lokale IP lenken, wofür man auch ein gültiges Wildcard(!) Zertifikat direkt erstellen kann und bekommt. Und natürlich haben beide DS ihre eigene Adresse mit gültigem Zertifikat.

An welchem Anschluss die Kiste steht, und welche IP sie hat, ist für das Zertifikat irrelevant - da Zertifikate nicht IP bezogen sind.



ergo: Zertfikat gültig, HB moppert! Aber genug OT.

 

[ottosykora]

da Zertifikate nicht IP bezogen sind.

eben, darum kannst du es nicht einfach so auf alle internen IP verwenden und denken das wird gültig
wenn es auf eine interne IP erstellt wird, dann ist es zwar ein eigentlich gar nicht vorgesehenes Pfushc, aber das kann man machen, auch von Hand.



Aber dann kannst du nicht erwarten dass dies automatisch für alles gültig ist. Denn damit wäre der Sinn der Zertifikate ziemlich absurd. Würde ja hesissen dann ich kann den gleichen Zert für 1000 Geräte verwenden. Wie soll sich dann die Traffic überhaupt schützen, wer darf es mitlesen und wer nicht?
Dann würde so eine Transport Verschlüsselung nichts nutzen, weil es genau gleich wäre wie ohne Verschlüsselung.


Mir selber sind noch nie irgednwelche Probleme mit Zertfikaten und HB bekannt, es wird der gleiche Zertifikat Mechanismus verwendet wie für alles andere.

Klar, wenn man zum Bsp selber Zertifikate erstellt, dann macht es auch Sinn diese dem Dienst auch zuweisen

 

[ottosykora]

Und wenn man es intern verwendet: wozu überhaupt nach Zetifikaten fragen?

 

[patrickn]

Sorry aber ich muss dir da leider erneut widersprechen. Du hast offensichtlich keine Ahnung, wie Zertifikate funktionieren.

Einem Zertifikat ist es völlig wumpe, ob es lokal ist oder extern. Solange die Inhaber Schaft der Domain (!) verifiziert wird, ist das Ziel erst mal egal. Ein Zertifikat ist NICHT an eine IP gebunden!

Man kann das Zertifikat exportieren, wieder importieren und der DS eine neue IP geben - das ändert NICHTS an der Gültigkeit eines Zertifikats.

Auch kann man wenn man einen echten Server betreibt, einen Serverwechsel inkl. Neuer IP macht, die vorhandenen Zertifikate ohne Probleme mitnehmen. Da sie, ich wiederholen mich, nicht an eine IP gebunden sind. Solange die notwendigen Schlüssel vorhanden sind, und wieder korrekt implementiert werden, bleibt das Zertifikat gültig.

 

[ottosykora]

ja, in solchem Fall musst du aber zu jedem Server einen Zert haben
und die kopieren, na ja, gibt es, aber dann muss der Zert der CN auch transportiert werden, wer sol les sonst kontrolieren.
Ich kann doch nicht für alle Server den gleichen Zetifikat verwenden und auch noch erwarten dass dies auf alle IP funktionieren wird.

Wir haben für alle unsere öffentliche Adressen ein wildcard Zert und diesen auch den Dienste zugewiesen.

Aber garantiert funktiomniert es nicht von internen IP zu internen IP
Da müsste man schon die DDNS Adresse einsetzen damit diese auch verifiziert werden kann

 

[ottosykora]

wäre es so wie du meinst, dann könnte ich deinen Zeritifikat auf alle meine HW Geräte importieren und die von der Firma auch und...

dann bräuchten wir gar nciht mehr so viele Zertifikate in der ganzen Welt

 

[patrickn]

Es haben doch beide DS ihre eigene DNS Adresse eund zugehörigem eigenen Zertifikat, was gültig ist?!

Keine Ahnung wie du auf kopieren kommst. Da ist nix kopiert! Es ist ein legitimes Zertifikat das durch beide DS eigenständig erstellt wurde über letsencrypt.

Stell mich bitte nicht dümmer hin, als ich bin. Ich weiß wie Zertifikate funktionieren, ebenso DynDNS Dienste und Domains, da ich seit über 15 Jahren einen eigenen Server betreibe.
Und ich denke, nach fast 10 Jahren in der Synology Welt, bin ich auch da kein dummer Neuling mehr.

wäre es so wie du meinst, dann könnte ich deinen Zeritifikat auf alle meine HW Geräte importieren und die von der Firma auch und

Wäre nicht so, sondern ist so. Aber wenn du an meine privaten Schlüssel kommst, hab ich ein anderes Problem
Nur mit dem öffentlichen Zertifikat wird das natürlich nichts.

 

[Benie]

Also ich muß @ottosykora recht geben, ein Zertifikat kann nicht auf eine IP erstellt werden. Hierzu wird in jedem Fall eine DNS benötigt.
Daß ich eine DynDNS auch auf die Interne IP auflösen lassen (netzextern mit VPN) kann, daß steht dann auf einer anderen Seite des Buches.
Was die Geschichte HyperBackup angeht, HyperBackup lässt die Anmeldung mit DynDNS nur zu wenn das auf der Ziel DS vorhandene Zertifikat echt und von LE Zertifiziert ist.
Erfolgt die Verbindung über die IP kommt quasi eine Warnmeldung der man zustimmen kann oder auch nicht, dann geht aber auch nichts.
Letzteres funktioniert aber nur mit einer internen oder via Internet mit einer VPN/Wireguard Verbindung.

Ohne dem, Über DynDNS und geöffneten Ports.

Es liegt jedenfalls nicht an HyperBackup, wenn es Probleme mit dem Zertifikat gibt. Im Gegenteil, wenn die Verbindung nicht funktioniert wegen dem Zertifikat, dann macht HyperBackup alles richtig.

Ich denke @ottosykora arbeitet lange, und mit Dutzenden DS die über die ganze Welt verteilt sind, als System Admin und weiß hierdurch auch von was er spricht.
Vielleicht wird, wurde etwas aneinander vorbei geredet.

 

[patrickn]

Ehrlich gesagt, keine Ahnung, wie ihr darauf kommt, dass ich ein Zertifikat auf eine IP ausgestellt habe. Ich hab deutlich und mehrfach DDNS gesagt.

Also ich muß @ottosykora recht geben, ein Zertifikat kann nicht auf eine IP erstellt werden.

Hab ich irgendwie auch nie behauptet?

 

[Benie]

DS223 DSM 7.2 > DS116 DSM 6.2 mecker

An DSM 6.x liegt es normalerweise nicht.

darum kannst du es nicht einfach so auf alle internen IP verwenden und denken das wird gültig
wenn es auf eine interne IP erstellt wird, dann ist es zwar ein eigentlich gar nicht vorgesehenes Pfushc, aber das kann man machen, auch von Hand.

Hier versteht ihr Euch falsch, @patrickn hat ein Zertifikat auf eine DynDNS über LE ausstellen lassen.
Die interne Auflösung der DynDNS auf der DS erfolgt dann aber auf die Interne IP bei aktiviertem RebindSchutz. Das funktioniert aber nur über eine VPN Verbindung.
Blank über das Internet muss man auf die öffentliche IP auflösen und den entsprechenden Port öffnen. Ohne VPN Verbindung funktioniert das nicht mit der internen IP, aber eben mit VPN/Wireguard.

Deshalb wurde hier die interne IP ins Spiel gebracht.

Aber garantiert funktiomniert es nicht von internen IP zu internen IP
Da müsste man schon die DDNS Adresse einsetzen damit diese auch verifiziert werden kann

Aufgrund dem wie ich es oben beschrieben habe funktioniert das dann normalerweise schon.
Die DynDNS ist ja dann im Spiel.

 

[Benares]

Einigt euch doch einfach darauf, dass ein Zertifikat für all die Namen gilt. die unter "Alternativer Name für den Zertifikatsinhaber" aufgeführt sind (s. Beispiel vom Forum hier). Hier wären sogar auch IPs möglich, was aber eher unüblich ist.

 

[patrickn]

Korrekt, IP Adressen lässt letsencrypt meines Wissens nach aber nicht zu.
Spielt aber alles keine Rolle, da es um eine FQDN geht.