Lets Encrypt Zertifikat für internen namen geht nicht

[linuxdep]

Hallo

habe jetzt mal ein Zertifikat bei Let'e Encrypt erstellt, alles soweit gut, wenn ich aber intern mit meinem internen Namen auf die Box gehe, meint er das Zertifikat wäre falsch. Was ja eigentlich richtig ist, denn den internen Namen hatte ich nicht angegeben, also flux noch mal neu, jetzt als Alias den namen mit rein genommen.

Mööppp geht nicht, ungültiger Name... was ist das für ein sch...

Ohne geht es wieder... aber ich will ja intern auch ein gültiges Zertifikat angezeigt bekommen, sonst kann ich auch bei meinem selbst erstellten bleiben. Wollte ich eigentlich nicht, so muss nicht jedes Handy die CA beigebracht werden.

 

[geimist]

Auch der Alias muss über den öffentlichen DNS verifizierbar sein (gerade für Subdomains praktisch). Würde der Alias nicht verifiziert, so erstelle ich mir einen Alias mit deutschebank.de und was man dann damit machen könnte, kannst du dir ja selbst denken.
So wie du es also möchtest, geht es nicht.

 

[Fusion]

Du musst einfach intern auch die volle Domain sub.domain.de angeben.

 

[blurrrr]

aber ich will ja intern auch ein gültiges Zertifikat angezeigt bekommen, sonst kann ich auch bei meinem selbst erstellten bleiben. Wollte ich eigentlich nicht, so muss nicht jedes Handy die CA beigebracht werden.

Sorry, aber wenn Du schon das Kürzel CA in den Mund nimmst, sollte Dir eigentlich klar sein, dass das "so" nicht funktionieren "kann". Entweder machst Du es weiterhin intern und verteilst das eigene CA-Zertifikat, oder Du nutzt weiter LE und setzt für intern auch noch einen DNS-Server auf (dann hast Du dieses Problem nämlich nicht), damit die Hosts auch intern über den public FQDN angesprochen werden können, für welchen das LE-Zertifikat ausgestellt wurde.

EDIT: Eine "öffentliche" CA wird eher keine Zertifikate für interne TLDs ausstellen...

 

[linuxdep]

Ja, ist mir auch irgendwann klar geworden... war halt verwöhnt vom eigenen Zertifikat.

Aber mit der dyn-dns Adresse hat die Fritzbox, trotz dem Eintrag ab und an gezickt. Kann ich ja noch mal testen mit der aktuellen FW.

Mal sehen oder ich bleibe beim eigenen...dann brauche ich den Webserver nicht ins I-net stellen. Bin mir da noch nicht ganz sicher.

 

[himitsu]

Wenn die aber es erlauben würden auch Namen ohne Punkte ohne Verifizierung zu nutzen, dann gäbe es doch für offentliche Domains kein Sicherheitsrisiko, da man sowas nur im Intranet nutzen kann.

Und ja, sowas hatte ich mir auch schon gewünscht. Oder dass man z.B. bei den Sync-/Backupdiensten zwei Server angeben kann, damit das im Intranet den internen Namen/IP und außerhalb die öffentliche Domain/DynDNS/QuickConnect nutzen kann.
Teilweise ist es leider auch nicht möglich die "Warnung" zu ignorieren und kann dann intern nicht direkt auf die DS zugreifen.
Was dann halt blöd ist, dass der Trafik dann über das Internet läuft und somit ohne Internetzugang nicht geht und auch die Daten gehen dann zwei Mal durch das Kabel (raus und wieder rein), was daheim das Gigabit-Netz etwas unnütz macht.


PS: Aber du könntest im heimischen Router eine Umleitung/Namensauflösung einrichten, also wenn jemand vom Intranet aus auf deine öffentliche Domain zugreift, dann wird direkt auf das lokale NAS geleitet. (k.A. ob da das mit dem Zertifikat dann richtig funktioniert, aber ich denke es sollte)


Wäre auch schön, wenn der automatische Redirect zu HTTPS nur für Extern erfolgt, aber nicht wenn lokal.



Alternativ unterschiedliche Zertifikate für die einzelnen Synology-Services.
z.B. für DMS dein Eigenes und für öffentliche Dienste das von Let's Encrypt

 

[linuxdep]

...
Was dann halt blöd ist, dass der Trafik dann über das Internet läuft und somit ohne Internetzugang nicht geht und auch die Daten gehen dann zwei Mal durch das Kabel (raus und wieder rein), was daheim das Gigabit-Netz etwas unnütz macht.

Also bei der FB sollte das nicht ins I-Net gehen, zwar über die Box, aber die leitet es gleich wieder richtig nach intern, aber meine Links müssen dann alle neu werden

PS: Aber du könntest im heimischen Router eine Umleitung/Namensauflösung einrichten, also wenn jemand vom Intranet aus auf deine öffentliche Domain zugreift, dann wird direkt auf das lokale NAS geleitet. (k.A. ob da das mit dem Zertifikat dann richtig funktioniert, aber ich denke es sollte)

kann man in der FB DNS Einträge machen, habe ich noch nicht gesehen, was aber nix heißt

Wäre auch schön, wenn der automatische Redirect zu HTTPS nur für Extern erfolgt, aber nicht wenn lokal.

Extern kannst ja nur den https Port öffnen, dann brauchst den Redirect nicht machen.

Alternativ unterschiedliche Zertifikate für die einzelnen Synology-Services.
z.B. für DMS dein Eigenes und für öffentliche Dienste das von Let's Encrypt

Das geht doch mit 6.2 schon, für fast jeden Dienst ein eigenes Zertifikat, ganz klar ist mir nicht, was sich alles hinter Default Zertifikat alles an Diensten versteckt, denke mal aber nur der Zugriff auf den Webserver und DMS.

 

[linuxdep]

Ich noch mal...

So, jetzt habe ich mich entschieden, zertifikate von Let's Encrypt zu nutzen. Ports (80+443) geöffnet, Zertifikat erstellt, alles gut.
Eintrag in der FritzBox unter RebindSchutz ist drin.
Der Zugriff auf die DMS Oberfläche auf Port 5001 geht aber nicht, weil ich diesen Ja nicht per Portforwarding von aussen erreichbar gemacht habe, will ich ja nicht. Wenn ich diesen auch zum i-Net öffne, dann geht es intern.

Wie macht ihr das mit dem Zugriff von intern dann???

 

[Benares]

Du könntest dir vielleicht mit einem hosts-Eintrag mit dem externen Namen, aber der internen IP behelfen.

 

[linuxdep]

nee danke, dann akzeptiere ich jetzt das als Fehlerhafte Zertifikat, weil ja der intere Name nicht drin ist.
Aber warum die blöde FB das mit den ports nicht rafft.. mal bei AVM nachfragen

 

[Fusion]

DNS Rebind Schutz und NAT Loopback sind zwei verschiedene Sachen.
Das was hier zum Zuge kommt ist der NAT-Loopback. Das unterstützt die Fritzbox von Haus aus. Konfigurieren kann man da nichts.
Das heißt aber auch, dass eine Anfrage an deine Domain vom LAN zuerst auf die WAN Seite der Fritzbox gelangt und dann, weil sie ja schon am Ziel ist (deine öffentliche IP) wieder ins LAN zurück gesendet wird. Deshalb greifen dabei auch die Portfreigaben.
Dafür gibt es workarounds wie eine Host Datei auf den Clients, oder einen lokalen DNS Server, der die öffentlichen Domains intern direkt mit den lokalen IPs verknüpft (und Anfragen nicht mehr über das NAT laufen, sondern direkt ans interne Ziel)

 

[linuxdep]

Das mit dem DNS wollte ich auch mittels Pi-Hole im Docker angehen (Mehrwert), aber hier stolpert man von einer Baustelle zur nächsten...wer soll denn da noch durchsteigen, wenn mich der Bus überrollt.... das muss einen besseren WAF bekommen.
Na ja, das die FB das nicht intelligent macht..
Hosts Einträge pflegen auf alen möglichen Geräten ist auch blöd... da muss ich wohl beim Pi-hole dran bleiben erst mal.

 

[Fusion]

DNS Server kannst du auch auf der Syno laufen lassen. Der Pi-hole bietet natürlich noch etwas mehr Funktionalität.

Die Fritzbox hält sich an Standards und nicht an die "Intelligenz" (was könnte der Benutzer denn jetzt wollen...)

 

[NSFH]

Weil die blöde Syno genau das macht was sie soll um User wie dich vor sich selbst zu schützen.
Vielleicht solltest du dich mal intensiver mit der Materie beschäftigen, damit deine Support Anfragen nicht gleich am Witz-der-Woche Board beim Supporter landen.

 

[linuxdep]

Weil die blöde Syno genau das macht was sie soll um User wie dich vor sich selbst zu schützen.
Vielleicht solltest du dich mal intensiver mit der Materie beschäftigen, damit deine Support Anfragen nicht gleich am Witz-der-Woche Board beim Supporter landen.

Nur das dies nicht die Syno Box macht sonder die FB, also selber besser lesen...
Da aber die FB weiß, was von innen kommt (nutzt sie ja auch - Rebind Schutz), könnte sie diesen Traffic gleich als intern werten und routen.
So ist das Let's encrypt Zertifikat zwar nach aussen schön, aber von innen nicht zu gebrauchen. Nur, das immer mehr Apps auch auf die Zertifakate achten, was ich auch gut finde, aber damit intern nicht sauber mit diesen Zertifikaten umgehen können.

Nachtrag:
na ja woher soll dann aber die FB wissen zu welcher internen IP das ganze gehen soll... damit ist dann Zertifikat wirklich nur von extern zu gebrauchen... *grübel*

 

[Fusion]

DNS Rebind Schutz hat damit nichts zu tun.
Darum wo es hier geht ist NAT Loopback.
Die Fritzbox bekommt die Anfrage nach meine.domain.de. Wechsel von LAN nach WAN. Die Domain fragt sie im DNS an und bekommt darauf ihre eigene öffentliche IP zurück.
Also befragt sie sich selbst, was sie mit ankommendem Verkehr an port 80 zu machen hat, und wenn eine Portweiterleitung dafür existiert weiß sie auch an welches lokale Gerät dies dann zu gehen hat, Wechsel von WAN nach LAN. Deshalb NAT Loopback.
Hat man einen lokalen DNS server aufgesetzt, befragt die Fritzbox diesen, korrekt eingestellt, zuerst, oder auch schon der anfragende Client befragt direkt schon den DNS (wenn ihm dieser per DHCP oder ähnlich mitgeteilt wird). Dann kann die Verbindung direkt zur lokalen IP aufgebaut werden, sauber auch mit Zertifikat.

 

[linuxdep]

schon klar, aber erst durch eintragen des dyndns Namens beim rebind schutz könnte er ja wissen, welcher dyndns intern ist... aber wie oben geschrieben, weiß er dann ja nicht, welchen Port er zu welcher IP routen muss. Dazu braucht er ja die Freigaben...

Muss wohl doch ein PI-Hole her oder mal den Syno DNS ansehen...fürs erste sollte der es machen.

 

[linuxdep]

Pi-Hole war schnell auf dem Raspi wo die CCU und MQTT läuft im neuen LXC eingerichtet, das Teil ist ja echt genial. Zack alle die per DHCP dran sind an der FB gehen jetzt darüber, bei den festen IP's kann ich ja wählen.

Jetzt tut es so wie ich es gern hätte, dank der DNS Umleitung. Jetzt noch die anderen Baustellen, Webserver nach aussen dicht machen auf das nötigste für Let's Encrypt und mein Wiki & Cal & VPN