Hallo zusammen
ich habe nach der der “alten” Anleitung meinen Server mit einem Zertifikat ausgestattet.
https://www.linuxmuster.net/wiki/anwenderwiki:server:ssl-tls-letsencrypt-alt
Sollte man auf die Anleitung mit cerbot umsteigen?
https://www.linuxmuster.net/wiki/anwenderwiki:server:ssl-tls-letsencrypt
Muss man dabei etwas beachten?
Oder linuxmuster-dehydrated verwenden?
Was würdet Ihr machen?
Grüße Rainer
Hi. Ich habe kürzlich linuxmuster-dehydrated verwendet. Der Grund war aber nur, weil es sehr klein ist und bereits “perfekt” auf dem Server eingebunden ist.
Wenn ich darüber nachdenke, wird es bei uns aber doch eher so sein, dass ich Wildcard-Zertifikate benötigen werde. Daher muss ich mich wohl oder übel nochmal genauer mit Pound und der dns01-challenge auseinander setzen müssen.
https://www.linuxmuster.net/wiki/anwenderwiki:webapps:ipfire_pound#dokuwiki__content
Schöne Grüße
Michael
Hallo,
für die DNS Challenge brauchst du eigentlich zwingend eine API zu deinem DNS Provider, sonst musst du alle drei Monate den TXT Record von Hand eintragen. Ich erzeuge halt mit dehydrated 20 Zertifikate für alle Hostnamen, ob in der donains.txt einer oder 50 Hosts stehen ist ja wurscht.
VG
Frank
Hallo,
für den linuxmuster Server würde ich das empfehlen - up and running in 5 Minuten (ohne Geoblocking auf dem IPFire…)
VG
Frank
Ja, versucht hatte ich das auch. Ich sehe das richtig, dass du dann auch 20 CNAME Einträge auf den gleichen lml-Server zeigen lassen musst; und dass du die Zertifikate 20 mal an die richtige Stelle kopieren & 20 mal Apache-reload erledigen lassen musst? Alles via Pub.key.Auth und SSH bei dir?
Die Sache mit dem GeoIP-Block sollte unbedingt in die Anleitung, meine ich… 
Michael
Nee. Das mit dem SSH brauch ich ja nur bei Servern, die von außen nicht erreichbar sind. Alle Server, die von außen erreichbar sind können sich ihr Zertifikat ja einfach mit dehydrated selber machen.
Um beurteilen zu können, ob das bei dir Sinn macht, müsste ich deine Servertopologie kennen.
VG
Frank
Also als Beispiel:
Bei uns läuft der Nextcloud-Server zZ intern – d.h. den kann ich im Schulnetz unter
https://nextcloud.intern.example.org erreichen und öffentlich unter
https://schule.example.org (was noch zu ändern ist).
Für diesen Server wäre ein Zertifikat auf jeden Fall sinnvoll. Das geht aber vermutlich nur zusammen mit Pound, wenn sowohl der linuxmuster-Server als auch der NextCloud-Server auf Port 80 erreichbar sein müssen.
Michael
Hallo,
Das mache ich nie. Ein Dienst hat einen „Namen“, und unter diesem ist er zu erreichen. Wenn die IPs innen/außen unterschiedlich sind, löse ich das im DNS. Das ist auch aus Benutzersicht das einzig sinnvolle Vorgehen: Deine Benutzer verstehen das letztlich nicht, warum sie intern dienst.intern.blubber brauchen und extern was anderes. Wenn du denen sagst: Die Cloud ist unter wolke.yxz.nirgendwo, und dann selbst dafür sorgst, dass das korrekt resolved hast du alle Probleme gelöst.
VG
Frank
Nicht unbedingt, es gibt dafür mehrere Lösungen wie Route 53 oder Lexikon :
https://id-rsa.pub/post/certbot-auto-dns-validation-with-lexicon/
Hai,
Das verlängert doch letztlich auch nur die API des DNS Providers, wenn du deine Domains jetzt halt bei Hetzner oder der Telekom oder bei BelWue hast, gehts halt auch nicht.
VG
Frank
Klar, prinzipiell hast du natürlich recht … ich habe das auf der Startseite index.html unseres linuxmuster-Servers direkt über die interne IP in orange verlinkt, weil ich mir dachte, dass ich dann auf jeden Fall volle 1GBit Geschwindigkeit habe.
Wenn die Route zunächst raus geht auf den vServer und von dort wieder zurück über den IPFire usw läuft, bin ich mir nicht so sicher, ob das auch mit voller Geschwindigkeit laufen würde — lasse mich aber gerne eines besseren belehren
Aber ansonsten will ich natürlich die Cloud unter einem Namen erreichbar machen. Das ändert aber nichts daran, dass ich POUND nutzen muss, wenn z.B. der linuxmuster-Server die Zertifikate erneuern soll (im Moment noch auf Port 80 – ab der Erneuerung auf 443) und die Cloud ebenfalls unter 443 erreichbar sein soll.
Michael
Hallo Michael,
das kannst Du ebensogut erreichen, indem Du intern den DNS-Server so konfigurierst, dass er die interne IP zurückgibt.
Viele Grüße
Jörg
Hi Jörg.
Dann meinst du aber jetzt den internen DNS-Server, ja (also auf dem lml-Server selbst)?! Es nützt mir ja nix, wenn ich dem DNS-Server auf unserem vServer einer IP zuordne, die gar nicht aus außen geroutet wird.
Michael
Hallo Michael,
klar, genau so. Dann verbinden sich die Rechner aus dem Schulnetz direkt und die aus dem Internet über den IPFire.
Beste Grüße
Jörg
Hi. OK. Das geht natürlich. Kleiner Haken: Eine Stelle mehr, an die man denken muss: bind9 auf dem Server wollte ich eigentlich in Ruhe lassen 
… was mir noch einfiel: POUND will selbst ja auch ein gültiges Zertifikat haben, damit es regulär startet – also muss man sich offenbar neben dem Server und der NextCloud auch noch eins für den IPFire besorgen. Macht ihr das trotzdem auf dem lml-Server und kopiert es rüber oder lasst ihr den IPFire das selbst erledigen?
Michael