Zertifikatserneuerung via Let's Encrypt funktioniert nur dann, wenn ich die Reverse-Proxy Ports ändere

[Aardyena]

Hallo liebe Community!

Ich habe schon länger ein nerviges Problem und dachte, es handelt sich um einen Fehler seitens Synology - doch langsam vermute ich, dass das Problem doch eher vor dem Bildschirm zu suchen ist, denn auch ein Upgrade auf DSM 7 hat keine Abhilfe geschafft. Konkret geht es um das leidige Thema der Zertifikatserneuerung.

Setup:
Ich habe eine eigene Domain und nutze ddnss - die DynDNS-Adresse ist in meiner Fritz Box hinterlegt. Port 80 & Port 443 sind dort Richtung Synology NAS freigegeben. Auf dem NAS betreibe ich z. B. Plex und im Docker Container auch mein eigenes Wiki. Die Dienste werden innerhalb des NAS über das Reverse Proxy erreicht. Es funktioniert auch alles wunderbar und ohne Probleme - und das schon seit einer ganzen Weile.

Problem:
Für jeden meiner Dienste habe ich eine eigene SubDomain: z. B. "wiki.domain.de" - damit ich - wenn ich auf diese Seite gehe auch eine SSL-Verschlüsselung erreiche, arbeite ich mit Let's Encrypt Zertifikaten. Möchte ich diese erneuern, kommt die bekannte Error-Meldung: "Bitte überprüfen Sie, ob der Port 80 und der Port 443 freigegeben ist."

Workaround:
Gehe ich nun in meine Reverse-Proxy Einstellungen und ändere den Quellport auf etwas unsinniges (z. B. von 443 auf 442) kann ich das Zertifikat problemlos über die Oberfläche erneuern. Anschließend muss ich den Quellport wieder zurück auf 443 stellen, damit ich z. B. das Wiki wieder erreichen kann.

Hat jemand eventuell eine Idee, was in meiner Konfiguration daneben gegangen sein könnte? Ich würde gern meinen Renew Certificates Task nutzen, der via des OS-Befehls "/usr/syno/sbin/syno-letsencrypt renew-all -v" die Zertifikate selbstständig aktualisiert.

Viele Grüße
Aard

 

[Benares]

Lies mal hier unter "HTTP01 challenge". Ich vermute, dass einer deiner Reverse-Einträge dazu führt, dass die Token-Datei nicht mehr abgerufen werden kann. Durch die temporäre Änderung des Quellports deaktivierst du quasi den zugehörigen Reverse Proxy.

Wie viele Zertifikate hast du? Eines für jede Sub-Domain oder eines für die Haupt-Domain mit den Sub-Domains als Alternate Names?
Wenn ersteres, solltest du es mal mal über den zweiten Weg probieren, denn für die Haupt-Domain gibt es vermutlich keinen Reverse Proxy.

 

[Aardyena]

Danke, habe ich mir direkt mal durchgelesen. Ich habe fünf Sub-Domains, für meine Haupt-Domain habe ich kein Zertifikat und sie zeigt auch gar nicht auf das NAS. Die Sub-Domain als Alternative Names unter die Hauptdomain zu hängen wäre natürlich elegant, dann hätte ich nur noch ein Zertifikat das erneuert wird - ich habe allerdings keine Idee wie man das bewerkstelligen kann.

Der im Link erwähnte Ordner befindet sich bei mir auf dem System unter /var/lib/letsencrypt/.well-known/acme-challenge
Wenn ich ein Zertifikat anfordere fährt das auch nicht dazu, dass ein Token in den Ordner geschrieben wird.

 

[Benares]

Also ich habe z.B. nur ein Zertifikat für die Haupt-Domain (z.B. example.com) mit den Sub-Domains www.example.com, wiki.example.com usw. als Alternate Names. Reverse Proxies gibt es nur für die Sub-Domains. Damit funktioniert die Aktualisierung einwandfrei.

 

[Aardyena]

Das klingt super, und da meine Hauptdomain ohnehin auf nichts sinnvolles zeigt, könnte ich mir auch vorstellen diese dafür einzusetzen. Wie genau muss ich da vorgehen, damit er dann unter meinedomain.de/.well-known/acme-challenge/<TOKEN> das Token erreichen kann und die acme-challenge erfolgreich ist? Ich vermute ich muss meinedomain.de über die dyndns-adresse von ddnss auf mein NAS zeigen lassen. Muss ich die Domain unter "Anmeldeportal --> Benutzerdefinierte Domain" bekannt machen? Und wie bekomme ich die Alternative Names in das Zertifikat? Am Ende muss ich dann bei den Zertifikaten wahrscheinlich unter "Einstellungen" das meinedomain.de Zertifikat auswählen?

 

[Benares]

Dass es an der Token-Datei liegt, war nur so eine Idee von mir, sicher bin ich mir da nicht.

Also ich habe nur eine Domain example.com bei Strato, die ich über DDNS aktuell halte. Alle anderen Namen sind CNAMEs. So verweisen all diese Namen auf die gleiche IP. Das LE-Zertifikat habe ich über DS erzeugt und alle anderen Namen bei "Betreff Alternativer Name" eingetippt (example.com selbst dabei weglassen, das ist automatisch mit dabei)



Die Reverse Proxies konfigurierst du dann unter Systemsteuerung->Anmeldeportal, entweder indem du "Domain" unter "Anwendungen" setzt (Audio Station, File Station, Drive, Synology Photos) oder über Erweitert, Reverse Proxy Dinge hinzufügst.

"Anmeldeportal --> Benutzerdefinierte Domain" würde ich leer lassen, das nagelt nur die Link-Erstellung in der Filestation oder Synology Photos auf diesen Namen fest. Ohne diese Einstellung wird für die Links der Hostname verwendet, den du selbst zum Zeitpunkt der Erstellung in der URL verwendest.

PS: Verwende besser example.com bei solchen Beiträgen als Platzhalter, bei meinedomain.de gab's schonmal Ärger, da die jemandem gehört.

 

[Aardyena]

Stimmt, aber einen Token benötigt LE ja um meinem NAS grundsätzlich ein Zertifikat ausstellen zu dürfen - zumindest wenn ich das ganze automatisieren möchte.

Ich habe eine Domain bei united-domains und die habe ich nun auf meine ddnss Adresse umgeleitet. Sprich: example.com --> example.ddnss.de (Danke für den Hinweis mit example.com, als konfliktscheues Wesen verwende ich in Zukunft dann lieber das)

Wenn ich nun example.com aufrufe, dann komme ich hier an: example.ddnss.de:5001

Meine Sub-Domains habe ich nicht explizit angelegt, sondern ich habe einen A-Record mit *.example.com auf example.ddnss.de - Der Reverse Proxy erkennt anhand der URL wo ich hinmöchte und leitet die Adressen auf den korrekten Port um. Benötige ich einen neuen Dienst, muss ich nicht an die DNS-Einstellungen meines Domain-Providers sondern kann einfach beliebig neue Subdomains im DSM definieren.

Meine Idee war nun: Ich füge ein Zertifikat hinzu so wie beim Screenshot von dir beschrieben und hacke alle meine Subdomains in das Feld für den Alternative Name. Anschließend wenn ich das Zertifikat habe, lasse ich alle meine Adressen auf das Hauptdomain-Zertifikat zeigen. Das kann sich dann auch automatisch aktualisieren weil es keinen Reverse-Proxy-Eintrag hat.

Sobald ich jedoch auf "Fertig" gehe sagt er mir: "Kontrollieren Sie, ob die IP-Adresse, Reverse Proxy-Regeln und Firewall-Einstellungen korrekt konfiguriert sind, und versuchen Sie es erneut."

 

[Benares]

Benötige ich einen neuen Dienst, muss ich nicht an die DNS-Einstellungen meines Domain-Providers ...

Bedeutet: Du hast eine Wildcard-Domain? Also <irgendwas>.example.com löst immer auf die IP von example.com auf?

Am schönsten wäre dann natürlich auch ein Wildcard-Zertifikat, sprich ein Zertifikat für example.com, das auch für *.example.com als Alternate Name gilt, so dass man auch an das Zertifikat nicht mehr ran muss, wenn ein Dienst hinzu kommt. Mit Bordmitteln geht das aber auf der DS leider nicht (s. Hinweis im Screenshot) bzw. nur bei Synology als (D)DNS-Provider. Aber mit ACME und einem Script habe ich das schon hinbekommen.

Wenn ich nun example.com aufrufe, dann komme ich hier an: example.ddnss.de:5001

Das passiert, wenn du keine "Web Station" installiert hast. Dann werden solche Zugriffe auf den DSM umgeleitet. Dazu müsste aber auch eine Portweiterleitung für 5001 existieren, es sei denn, man konfiguriert auch einen Reverse Proxy dafür (dsm.example.com:443 -> localhost:5001)

Sobald ich jedoch auf "Fertig" gehe sagt er mir: "Kontrollieren Sie, ob die IP-Adresse, Reverse Proxy-Regeln und Firewall-Einstellungen korrekt konfiguriert sind, und versuchen Sie es erneut."

Bedeutet? Es klappt doch nicht?

 

[Aardyena]

Bedeutet: Du hast eine Wildcard-Domain? Also <irgendwas>.example.com löst immer auf die IP von example.com auf?

Genau, alle Subdomains verweisen auf meine DDNSS-Adresse - auch wenn diese nicht explizit definiert wurden.

Am schönsten wäre dann natürlich auch ein Wildcard-Zertifikat, sprich ein Zertifikat für example.com, das auch für *.example.com als Alternate Name gilt, so dass man auch an das Zertifikat nicht mehr ran muss, wenn ein Dienst hinzu kommt. Mit Bordmitteln geht das aber auf der DS leider nicht (s. Hinweis im Screenshot) bzw. nur bei Synology als (D)DNS-Provider. Aber mit ACME und einem Script habe ich das schon hinbekommen.

Das wäre definitiv am schönsten, aber leider gibt es dafür bei United-Domains keine API für. Um das zu erreichen müsste ich mich entweder händisch beim Domain-Provider alle 2-3 Monate anmelden um die ACME Prozess zu durchlaufen, oder den Provider wechseln.

Das passiert, wenn du keine "Web Station" installiert hast. Dann werden solche Zugriffe auf den DSM umgeleitet. Dazu müsste aber auch eine Portweiterleitung für 5001 existieren, es sei denn, man konfiguriert auch einen Reverse Proxy dafür (dsm.example.com:443 -> localhost:5001)

Okay, eine Web Station habe ich in der Tat nicht installiert. Ich vermute mal wenn ich wieder mit Reverse-Proxy arbeite stehe ich anschließend wieder vor dem gleichen Problem wie jetzt.

Bedeutet? Es klappt doch nicht?

Leider nein.

 

[Benares]

Leider nein.

Ist es immer noch so, dass es nur geht, wenn die Reverse-Proxies ausschaltest (bzw. temporär umkonfigurierst)? Immerhin hattest du ja schon ein Zertifikat, also muss es ja irgendwie gegangen sein. Port 80 und 443 1:1 auf die DS weitergeleitet?

 

[Aardyena]

Ich habe ja bislang an meiner Grundkonfiguration noch nichts geändert, nur eben versucht mein example.com Zertifikat auf meine DynDNS-Adresse zeigen zu lassen und ein Zertifikat mit SubAltNames meiner Subdomains anzulegen die ich für meine Dienste verwende. Das hat ja leider nicht funktioniert, weil schon bei der erstmaligen Einrichtung ein "Kontrollieren Sie, ob die IP-Adresse, Reverse Proxy-Regeln und Firewall-Einstellungen korrekt konfiguriert sind, und versuchen Sie es erneut."-Hinweis erscheint.

 

[Benares]

Lösen example.com und alle subx.example.com wirklich alle auf deine externe IP auf. Kontrollier das nochmal mit "nslookup ..."

 

[Aardyena]

Das mit nslookup war ein super Hinweis - dort schien etwas krumm zu sein, ich habe daraufhin United-Domains nochmal geprüft. Der *.example.com Eintrag geht tatsächlich auf deren Server und ist ein Standardeintrag. Der nas.example.com Eintrag war ein CNAME.

Ich habe nun den Proxy für nas.example.com gelöscht und ein Zertifikat mit SubjectAltNames für nas.example.com ausgestellt. Meine Dienste brauchten daraufhin nun auch alle einen CNAME Eintrag. Aber nun scheint es genau so zu funktionieren, wie ich mir das wünsche - ich hoffe auch für den Renewal Task - das sehe ich dann aber wohl erst, wenn das Zertifikat kurz vor dem ablaufen ist, oder gibt es eine Möglichkeit die Erneuerung über diesen Befehl zu erzwingen? In dem Fall kann ich das ja morgen anhand des Datums sehen, ob das Zertifikat erfolgreich erneuert wird:
"/usr/syno/sbin/syno-letsencrypt renew-all -v"

 

[Benares]

Du kannst dein Zertifikat auch jederzeit über die DSM-Oberfläche erneuern. Kann nur sein, dass das nicht geht, wenn es noch zu neu ist. Ein paar Tage solltest du schon warten.
Übrigens: Wenn die Aktualisierung scheinbar klappt, aber das Ablaufdatum nicht hoch geht, einfach die Systemsteuerung schließen und nochmal öffnen.

 

[Aardyena]

Hallo,
offenbar habe ich die Lösung doch nicht gefunden. Einmal hat er mir am 21. alle Zertifikate über die Oberfläche erneuert und ich dachte mit dem Cronjob wäre der Fisch jetzt gegessen, muss aber feststellen, dass mir in 25 Tagen das Zertifikat abläuft und er es schon hätte erneuern müssen. Ich habe daher den syno-letyencrypt renew-all -v-Befehl mal händisch durchgeführt. Dabei kam folgende Ausgabe bei heraus:

DEBUG: Issuer name of certificate. [Let's Encrypt]->[/usr/syno/etc/certificate/_archive/sDys4L/cert.pem] DEBUG: start to renew [/usr/syno/etc/certificate/_archive/sDys4L]. DEBUG: setup acme url https://acme-v02.api.letsencrypt.org/directory DEBUG: GET Request: https://acme-v02.api.letsencrypt.org/directory DEBUG: GET Request: https://acme-v02.api.letsencrypt.org/acme/new-nonce DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/new-order DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/new-order DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/91816073251 DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/91816073251 DEBUG: dns-01 is not support for vault.example.com DEBUG: Setup challenge for vault.example.com with type http-01 DEBUG: Incorrect port map rules result DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/chall-v3/91816073250/vrYhIQ DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/chall-v3/91816073250/vrYhIQ DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/91816073251 DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/91816073251 DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/91816073251 DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/91816073251 DEBUG: Failed to do challenge for vault.example.com with type http-01. DEBUG: close port 80. {"error":110,"file":"client_v2.cpp","msg":"Invalid response from https://vault.example.com/.well-known/acme-challenge/m9IVMYH3XkshS5uMqacTgOdUSauW-PQRwh1ZWeXwJDc [192.196.192.228]: 404"}

Was er also macht: Er liest das Zertifikat ein und erkennt: Das muss erneuert werden. Er liest den Aussteller aus und sieht: Okay, kann ich machen. Dann kontaktiert er die Let's Encrypt-Server und bekommt eine Datei bereitgestellt, die dann auf dem NAS abgelegt und von dem Aussteller abgerufen werden muss. Merkwürdigerweise geht er offenbar relativ beliebig auf einen der Subject-Alternative-Names, denn vault.example.com ist nur eine der Anwendungen die ich habe. Momentan habe ich das ja so eingerichtet:

nas.example.com --> Verweist auf das Synology DSM und ist im Common Name des Zertifikats eingetragen.
vault.example.com --> Mein Passwort-Safe als Subject-Alternative-Name.
app2.example.com --> z. B. mein Wiki das auch als Subject-Alternative-Name eingetragen ist.

Das Zertifikat sieht auch super aus und alles haut soweit hin momentan, nur das Erneuern macht (leider wieder einmal) Probleme.

 

[Benares]

Sowas ähnliches hatte ich kürzlich auch. Der Fehler war, dass über DDNS neben der IPv4 auch die IPv6 der Fritzbox aktualisiert wurde. Die IPv6 zeigt aber auf die Fritzbox und NAT und Portweiterleitungen gibt es unter IPv6 nicht mehr. Somit landet man über die IPv6 auf der Fritzbox und nicht auf der DS. Seit ich nur nur noch die IPv4 aktualisiere klappt es wieder.

 

[Aardyena]

Hallo, danke für den Hinweis, aber der Haken bei Dual-Stack ist in den Einstellungen meines DDNS-Providers nicht gesetzt - auch ich aktualisiere ausschließlich meine IPv4-Adresse. Man sieht ja im Log auch ganz unten, dass er die IPv4-Adresse anzusprechen versucht.

 

[Benares]

Mmh, hast du mal probiert
https://vault.example.com/.well-known/acme-challenge/m9IVMYH3XkshS5uMqacTgOdUSauW-PQRwh1ZWeXwJDc
direkt im Browser aufzurufen? Wo landet die Abfrage, auf der DS?

 

[Aardyena]

Ich denke das wird immer nur für die Zeit des Renewal-Prozesses dort abgelegt und danach direkt wieder gelöscht. Wenn ich es jetzt aufrufe kommt einfach: "404: Not Found" - es wundert mich eben auch, dass er bei meinem Zertifikat dass ja vault.example.com nur als eines von mehreren SAN Namen eben genau diesen raussucht, anstatt über den Common-Name nas.example.com zu gehen. Leider kann ich auch nicht unbegrenzt Testen, für heute habe ich leider schon zu viele Anfragen Richtung Let's Encrypt geschickt.

 

[Aardyena]

Nochmal kurz meine aktuelle Struktur nachvollziehbar erklärt:
Ich habe folgende Domain: example.com

Dort habe ich einen CNAME-Eintrag hinterlegt:
nas.example.com auf example.ddnss.de

example.ddnss.de ist in meiner Fritz.Box hinterlegt inkl. Anmeldedaten damit diese die aktuelle IP-Adresse immer an den DynDNS Service weiterleitet.
Auch die entsprechenden Ports zu meinem NAS in meiner Fritz.Box sind geöffnet.

Ich nutze via Docker unterschiedliche Applikationen und verknüpfe diese via Reverse-Proxy auf die internen Ports des Docker-Containers, so dass ich mit unterschiedlichen Subdomains arbeiten kann.

Damit ich nicht für jede Subdomain ein eigenes Zertifikat benötige, habe ich das nas.example.com Zertifikat mit meinen unterschiedlichen Subdomains (die ja per Reverse-Proxy auf die Docker-Applikationen zeigen) als SubjectAlternativeName (SAN) im Zertifikat hinterlegt.

Es geht also: nas.example.com --> example.ddnss.de --> (Hat die aktuelle IP-Adresse von der Fritzbox erhalten und geht dort drauf) --> Die Ports sind entsprechend geöffnet, so dass der Zugriff auf die DiskStation erfolgen kann --> Der Reverse-Proxy ordnet die eingehende Subdomain der entsprechenden Anwendung und damit auch dem passenden internen Port zu.

Einmal so eingerichtet hat es auch wunderbar funktioniert. Was jetzt nicht klappt, ist leider das Erneuern des Zertifikats. Irgendwo muss es doch Haken oder ich muss einen Denkfehler haben. Ich komme nur nicht drauf, wo.