Business Agent-Dienst stoppt wegen geändertem Zertifikat bei Zugriff auf NAS via LAN-IP

[RT17]

Das Problem war hier schon mehrfach Thema und ich habe die anderen Threads dazu bereits gelesen, zum Beispiel hier:
https://www.synology-forum.de/threa...enst-wegen-geaendertem-zertifikat-ein.108084/

So 100%ig wurde es aber nie beantwortet. Hier nochmal das Problem erklärt:

ABFB (Active Backup for Business) wird über eine Domain mit Zertifikat von außen über das Internet genutzt (DynDNS-Dienst von Synology), aber auch hausintern über die interne LAN-IP, damit der Traffic nicht das LAN verlässt. Wie schon andere beschrieben haben, stoppt der ABFB Client nach einigen Monaten seine Arbeit, weil er sich nicht mehr mit dem NAS verbinden kann, da sich das Zertifikat dort geändert hat. Am Client erscheint eine Fehlermeldung.

Zwei Lösungen wurden bisher vorgeschlagen:

1. Eine extra Domain im DNS anzulegen für den internen LAN-Zugriff z.B. nas.firma.de mit der internen IP z.B. 192.168.0.12, dafür ein Zertifikat erstellen und im LAN dann als Hostadresse im ABFB-Client nas.firma.de zu verwenden. Nachteil: DNS-Scanner könnten die im öffentlichen DNS-Server eingetragene Subdomain finden, letztendlich egal, weil Zugriff nicht möglich. Eigener interen DNS-Server nur dafür macht keinen Sinn, ebenso nicht der Vorschlag die HOSTS-Datei zu ändern.

oder

2. im DSM unter Systemsteuerung/Sicherheit/Zertifikate/Einstellungen bei Dienst "Active Backup for Business" die alte Domain (für den Zugriff aus dem Internet) durch "synology.com" (das Standard-Zertifikat) zu ersetzen (alte DynDNS-Domain raus).

Frage zu 2: Können dann die externen Clients über die extern DynDNS-Domain weiterhin zugreifen oder stoppen die dann ebenfalls ihre Verbindung, weil die Domain nicht mit der DynDNS-Domain übereinstimmt?

Frage: Welche Lösung ist besser? 1. oder 2.? Einfacher wäre ja 2.

Frage zu 1: Kann das DSM überhaupt ein Zertifikat von Letsencrypt erstellen lassen, wenn die Domain eine interne IP hat, weil dann die HTTP-Überprüfung ja nicht geht. Dann müsste man vermutlich eine Verifizierung per DNS machen. Mann-o-Mann...

 

[RT17]

Keiner weiß eine Lösung für mein Problem?

 

[mayo007]

https://kb.synology.com/de-de/DSM/t...roper_connection_between_ABB_agent_and_server

 

[Hagen2000]

Während man beim Zugriff mit IP-Adresse meistens eine Ausnahme für auftretende Zertifikatsfehler erstellen kann, ist dies bei Namensfehlern - abhängig vom verwendeten Client - oft gar nicht möglich. Das Problem mit den Ausnahmen bei Let's Encrypt-Zertifikaten ist aber, dass diese nach spätestens drei Monaten ablaufen, denn dann wird ein neues Zertifikat ausgestellt und für dieses muss dann erneut eine Ausnahme erstellt werden.

Um aus diesem Dilemma auszubrechen gibt es m.E. folgende Möglichkeiten:

• Umstellung auf IPv6: Dann ist die externe IP-Adresse des NAS gleich der internen IP-Adresse und man kann ein offzielles Zertifikat problemlos intern und extern nutzen, denn es wird auch nur ein DDNS-Eintrag benötigt. DDNS muss dann auf dem NAS laufen und es muss der Synology-DDNS benutzt werden, da nur für diesen IPv6 unterstützt wird.
• Zugriff von außen über VPN: Dann könnte man problemlos das Standard-Zertifikat verwenden, für das dann eben einmalig eine Ausnahme erstellt werden muss.
• Betrieb eines lokalen DNS-Servers, der die Anfrage nach dem Domain-Namen abfängt und die interne IPv4-Adresse liefert.
• Einrichten einer eigenen CA. Diese erlaubt dann das - wenn auch unschöne - Ausstellen von Zertifikaten, die neben dem Domännamen auch die interne IPv4-Adresse enthalten. Dieser Weg ist aufwändig und erfordert außerdem das Verteilen des eigenen Stammzertifikats auf alle Clients, die für den Zugriff auf das NAS bzw. ABFB benötigt werden. Diese Lösung ist also nur für eine begrenzte Anzahl von Geräten sinnvoll.

ad 1) Hier sehe ich das Problem, dass Du diese extra Domain gar nicht anlegen kannst, da ja der Name nas.firma.de bereits vergeben ist und das Domain-Name-System ja Eindeutigkeit gewährleistet. Falls nas.firma.de jedoch ein neuer Domain-Name ist, würdest Du eben auch ein dazu passendes Zertifikat benötigen, kannst aber vermutlich nicht festlegen, wann der ABFB-Server welches Zertifikat liefert.

 

[patrickn]

Synology ne Mail schreiben, dass sie mit diesem Quatsch aufhören, oder es zumindest deaktivierbar machen

 

[Hagen2000]

Das zugrunde liegende Problem liegt doch nicht bei Synology sondern am Prinzip der Transport Layer Security (TLS) und der Funktionsweise von Zertifikaten.

 

[patrickn]

Klar liegt es an Synology, ein gültiges Zertifikat ist gültig, fertig. Da gibt es kein Grund darauf hinzuweisen, dass sich das Zertifikat geändert hat, solange es gültig ist

 

[Kachelkaiser]

deshlab nehme ich für ABfB auch das zugehörige 10-Jahres-Zertifikat, dann ist erstmal Ruhe

 

[Hagen2000]

Klar liegt es an Synology, ein gültiges Zertifikat ist gültig, fertig. Da gibt es kein Grund darauf hinzuweisen, dass sich das Zertifikat geändert hat, solange es gültig ist

Das Problem tritt doch nur auf, wenn man - wie der TE - mit einer IP-Adresse auf den entsprechenden Dienst zugreift und dann eine Ausnahme für das - logischerweise nicht stimmende - Zertifikat hinzufügt. Diese Ausnahme muss man bei Let's Encrypt-Zertifikaten dann spätetestens alle drei Monate wiederholen: Neues Zertifikat - neue Ausnahme. Man kann das in ferne Zukunft schieben mit einem selbstsignierten Zertifikat, was Synology ja auch vorschlägt, bzw. was der Lösung von @Kachelkaiser entspricht.

Das Problem tritt ja nicht auf, wenn man korrekt über einen Domain-Namen mit einem dazu passenden Zertifikat zugreift. Nur ist das eben nicht in allen Fällen so einfach für jedermann umsetzbar.