Homeserver mit reverse Proxy mit Let's Encryp über Webhostingpacket nicht sicher

  • Hallo in die Runde,


    ich bin von Host**rope mit meinen drei Domains und einer Webseite zu Netcup umgezogen. Das Webhosting 2000SE reicht mit den drei inkl. Domains.

    EMail und Webseite laufen soweit. Nun komme ich mit meinem Wissen aber nicht mehr wirklich voran.


    Ich habe eine feste IPv4 hier zu Hause, im Keller läuft ein Server welcher div. Dienste (Nextcloud, Bitwarden usw.) für meine Familie zur verfügung stellt - bzw. stellte.

    Der Zugriff auf diese Dienste läuft über nginx als reverse Proxy, dieser kümmerte sich auch um die Let´s Encryp Zertifikate für die jeweiligen Dienste (jeder Dienst eine Sub-Domain).

    Nun werden die Zertifikate aber nicht mehr erstellt, bzw. enden mit einem "internal Error" und die Dienste sind nicht erreichbar.

    Bei meinem "alten Hoster" habe ich einfach nur die A und AAAA Records auf meine IP umgebogen und es ging ohne Probleme. Ports sind in der Fritte offen, da wurde nichts geändert.

    Die Sub-Domains sind auch erreichbar, nur eben ohne HTTPS und versagen so die Arbeit. Ich nutze eine eigene Domain dafür - ich bräuchte also kein Hosting sondern nur die DNS weiterleitung, kann es daran schon liegen? Oder muss ich meine nginx Manager Config aus DNS Challange umstellen? Wenn ja wie geht das? Steht was von API und sowas - da bin ich aber raus ;(


    Boah, ich sitze nun schon seit 12 Stunden davor und komme nicht weiter. Wenn es jemanden gibt, welcher mir helfen mag und noch Infos benötigt, dann bitte bescheid geben.

    Danke schonmal!


    VG Mario

  • Gibt es vielleicht in irgendwelchen Logs eine genauere Fehlermeldung? "Internal Error" ist halt leider relativ nichtssagend :)


    Prinzipiell gibt es bei Let's Encrypt mehrere Challenge-Typen: https://letsencrypt.org/de/docs/challenge-types/

    • Ich gehe mal davon aus, dass Du aktuell HTTP-01 verwendest? Ist Port 80 von überall aus erreichbar?
    • Lösen die A/AAAA Records der betroffenen Subdomains wirklich korrekt auf, auch mit DNSSEC? (Dafür gibt es einige Test-Tools im Internet.)
    • Verwendest Du bei den DNS-Records Wildcard-Einträge mit einem *?

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Gibt es vielleicht in irgendwelchen Logs eine genauere Fehlermeldung? "Internal Error" ist halt leider relativ nichtssagend :)


    Prinzipiell gibt es bei Let's Encrypt mehrere Challenge-Typen: https://letsencrypt.org/de/docs/challenge-types/

    • Ich gehe mal davon aus, dass Du aktuell HTTP-01 verwendest? Ist Port 80 von überall aus erreichbar?
    • Lösen die A/AAAA Records der betroffenen Subdomains wirklich korrekt auf, auch mit DNSSEC? (Dafür gibt es einige Test-Tools im Internet.)
    • Verwendest Du bei den DNS-Records Wildcard-Einträge mit einem *?

    Ok ich merke schon, langsam komme ich als "Hobby Admin" nicht mehr weiter. Die Ports für den nginx reverse Proxy sind frei - also 80 und 443 sind erreichbar.

    Und ja somit nutze ich HTTP-01.

    Ich habe nun nginx neu gestartet - jetzt wurden für die Dienste auch neue Zertifikate erstellt - liegen auf dem Server.

    Die A/AAAA Records scheinen zu passen, wie ich die DNSSEC teste - da bin ich noch nicht weiter.

    Ich hatte noch Wildcard-Einträge zur Domain. Was ich nun aber gelöscht habe. Ich zeige direkt mit den Sub-Domanins auf meine fest IPv4.

    Im Browser werden die Seiten als "nicht Sicher" angezeigt, was mich wundert, wenn ich mir das Zertifikat ansehe, steht da was von Plesk und

    eine Gültigkeit bis 2019 - also ob die Zertifikate nicht gelesen werden und etwas von Netcup verwendet wird.


    Der "Internal Error" ist weg, ich kann also Zertifikate erstellen und diese sind auch der Sub-Domain zugeordnet werden aber nicht nach außen genutzt, wenn ich das so beschreiben kann.

    Oh man, muss ich im ccp noch die Sub-Domains erstellen und dort dann ein Zertifikat erstellen lassen? Eigentlich sollte das ja mein proxy bereitstellen.


    Nachtrag: EIn PING auf die URL gibt die Adresse des Hostingspackets aus... hmm warum nur?


    Vielen Dank für Deine Mühen!

    VG Mario

  • steht da was von Plesk

    Dann landest du doch beim Aufruf im Browser vermutlich eher irgendwo auf deinem Webhosting von Netcup (dort ist das fehlerhafte Plesk-Zertifikat leider üblich) und nicht bei dir zuhause - oder?! Und wenn bis eben auch ein DNS-Wildcard-Record hinterlegt war, ist das gar nicht so unwahrscheinlich.

    Hast du schon sichergestellt, dass die entsprechenden (Sub)Domains wirklich die korrekte IP von zuhause liefern? Klingt als wäre irgendwo noch ein alter/falscher Wert in einem Cache und zeigt noch auf dein Webhosting. Fakt ist zumindest, ein Plesk-Zertifikat sollte dir nicht ausgeliefert werden, wenn auch kein Plesk im Einsatz ist.


    Ansonsten habe ich sehr gute Erfahrungen mit dem acme.sh Cient gesammelt - unterstützt von Hause auch die Netcup-API - dann müssen auch keine Ports in der Firewall aufgerissen werden. Damit einfach WIldcard-Zertifikate (*.deinedomain.de) oder eben Multisite-Zertifikate (bla1.deinedomain.de, bla2.deinedomain.de, usw) anfordern und fertig.

  • Dann landest du doch beim Aufruf im Browser vermutlich eher irgendwo auf deinem Webhosting von Netcup (dort ist das fehlerhafte Plesk-Zertifikat leider üblich) und nicht bei dir zuhause - oder?! Und wenn bis eben auch ein DNS-Wildcard-Record hinterlegt war, ist das gar nicht so unwahrscheinlich.

    Hast du schon sichergestellt, dass die entsprechenden (Sub)Domains wirklich die korrekte IP von zuhause liefern? Klingt als wäre irgendwo noch ein alter/falscher Wert in einem Cache und zeigt noch auf dein Webhosting. Fakt ist zumindest, ein Plesk-Zertifikat sollte dir nicht ausgeliefert werden, wenn auch kein Plesk im Einsatz ist.


    Ansonsten habe ich sehr gute Erfahrungen mit dem acme.sh Cient gesammelt - unterstützt von Hause auch die Netcup-API - dann müssen auch keine Ports in der Firewall aufgerissen werden. Damit einfach WIldcard-Zertifikate (*.deinedomain.de) oder eben Multisite-Zertifikate (bla1.deinedomain.de, bla2.deinedomain.de, usw) anfordern und fertig.

    Hallo DerRené,


    ich hoffe Du hast recht, ich habe einen Ping auf die Sub-Domains gestartet und lande damit immer auf dem Hosting von Netcup=O

    Nun habe ich die DNS EInstellungen noch einmal angesehen.... ich denke man sollte den DNS Eintrag nicht so machen wie ich.... ich habe

    die gesamte Sub-Domain eingetragen also s9.testdomain.de - A - Destination ;(


    Habe das nun geändert, mal schaun wenn die Aktuallisierung durch ist, was dann passiert. Dann kann mein nginx aber auch eigentlich kein

    Zert. empfangen haben:rolleyes:.


    Ich gebe dann mal Rückmeldung wenn DNS passt - oh man...

  • Hallo, ich nochmal. Also der DNS war total falsch. Nun komme ich auch mit PING auf die richtige IP zu Hause.

    Leider laufe ich jetzt durch meine Versuche in ein Limit von Lets Encrypt. Zumindest interpretiere ich das aus dieser Meldung:

    Code
    Error: Command failed: certbot certonly --non-interactive --config "/etc/letsencrypt.ini" --cert-name "npm-7" --agree-tos --authenticator webroot --email "npm@dddddd.de" --preferred-challenges "dns,http" --domains "dd.dddddd.de" Saving debug log to /var/log/letsencrypt/letsencrypt.log
    
    An unexpected error occurred:
    There were too many requests of a given type :: Error creating new order :: too many certificates (5) already issued for this exact set of domains in the last 168 hours: dd.dddddd.de: see https://letsencrypt.org/docs/rate-limits/
    Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
    at ChildProcess.exithandler (node:child_process:397:12)    at ChildProcess.emit (node:events:394:28)    at maybeClose (node:internal/child_process:1064:16)    at Process.ChildProcess._handle.onexit (node:internal/child_process:301:5)

    Ich kann die Seiten ohne HTTPS erreichen. Da diese aber unbedingt HTTPS brauchen, funktioniert das erstmal nicht.

    Der "internal Error" ist wohl das Limit von Let´s Encrypt.


    Nur noch für mich zum Verständnis, die Zertifikate usw. welche ich für die Domain im CCP erstellen kann, haben doch keine Bewandnis, da ich ja durch die DNS auf meinen Server verweise oder?


    Das macht ja echt Arbeit - never change a running system, das passt mal wieder.


    Wenn ich meinen Server nicht mehr zu HTTPS bewegen kann, dann melde ich mich nochmal :S


    VG Mario

  • Ja leider bist du bei Letsencrypt mit deiner Domain durch die vermutlich vielen Versuche nun in ein Rate Limit gerannt:


    Zitat

    too many certificates (5) already issued for this exact set of domains in the last 168 hours

    Es bietet sich daher immer an zuerst mit den Staging-/Testserver von LE den Zertifikatsantrag durchzuspielen bis alles klappt. Bei acme.sh geht dies mit dem Schalter --test, certbot nutze ich nicht, gibt es dort aber sicherlich auch.


    Ist natürlich jetzt im Nachhinein etwas doof... ich weiß auch nicht ob es Möglichkeiten gibt dieses Limit zu umgehen, vermutlich aber nicht.


    die Zertifikate usw. welche ich für die Domain im CCP erstellen kann

    DIe im WCP erstellten LE-Zertifikate bringen dir zuhause nichts, richtig. Die werden im WCP am Webserver für dich hinterlegt. Davon hast du ja leider zuhause dann recht wenig. Also: richtig verstanden. :)

  • OK dann ist bei mir noch nicht alles verloren :)

    Aber ich stehe mit dem DNS Einträgen echt auf dem Kriegsfuß. Da ich mit meinem Homeserver nicht weiter komme, ich aber unbedingt Bitwarden_RS am laufen haben will, dachte ich mir eben - hey der VPS 1000 9G ist zwar nur zum testen gemietet aber Bitwarden kann der eben auch. Gesagt getan, ich habe unter der zweiten Domain einen DNS Eintrag eingetragen "s3.meinserver.de" und zeige auf die IP bei Netcup 94.16.xxx.xxx

    So und nun dreht sich mein kopf - auf dem VPS alles mit Docker und Bitwarden eingerichtet. Gewartet bis ich den VPS mit der Sub-Domain anpingen kann (45 Minuten). Dann Bitwarden script gestartet, hier Domain eingetragen, das Zert erstellen lassen und nun... ich gebe die Sub-Domain in meinen Browser und was kommt... ??? "Die Aufgerufende Seite ist nicht sicher" - ich dreh durch. Das Zert ist erstell und liegt auch auf dem Server im entsprechenden Order. Was auch lustig ist, wenn ich jetzt die SUB anpinge, bin ich wieder auf dem Netcup Domain Bereich. Warum geht kurz der DNS und dann ist er wieder weg? Auf dem Hosting läuft eine Webseite von mir, ich kann also nicht alle Einträge im DNS löschen. Hier sind noch die Wildcard-Einträge vorhanden, damit ich auf die Webseite komme.

    Ich glaub ich mach Feierabend... aua.


    VG Mario

  • "s3.meinserver.de" und zeige auf die IP bei Netcup 94.16.xxx.xxx

    Nur um sicherzugehen, dass wir nicht wieder in denselben Fehler laufen: eingetragen im CCP hast du folglich nur sub   A   94.x.x.x, also links nicht den gesamten FQDN, sondern nur den Hostteil? :) Wie sieht denn ein Check bei https://dnschecker.org/ aus? Liefern alle DNS-Server die gewünschte IP? Gut möglich dass dir zuhause irgendein Gerät (Client, Router, etc) noch aus dem Cache noch falsche Werte liefert.


    "Die Aufgerufende Seite ist nicht sicher"

    Rufst du die Seite explizit mit https davor auf? Ansonsten muss im Webserver noch eine 301-Weiterleitung eingetragen werden, damit automatisch von http auf https weitergeleitet wird. (auch gut möglich, dass dein Bitwarden-Docker-Dings das bereits implementiert hat, keine Ahnung, ich installier sowas immer händisch - dann weiß ich auch welche Config da wirklich aktiv ist). Lauscht der Webserver auf dem Port 443? ss -tlpen Welches Zertifikat wird ausgegeben - das von Letsencrypt? Lässt sich auch über die CLI auslesen: openssl s_client <HOST>:443


    Die Frage ist aber, ob du wirklich auf deinem Server landest. Liest sich ja so, alls ob du stattdessen wieder im Webhosting von Netcup gelandet bist. Zuerst sollte also wirklich sichergestellt werden, dass die IP Adresse stimmt. Sonst gehen wir Fehlern nach, die womöglich gar keine sind.

  • Zitat

    Nur um sicherzugehen, dass wir nicht wieder in denselben Fehler laufen: eingetragen im CCP hast du folglich nur sub   A   94.x.x.x, also links nicht den gesamten FQDN, sondern nur den Hostteil? :) Wie sieht denn ein Check bei https://dnschecker.org/ aus? Liefern alle DNS-Server die gewünschte IP? Gut möglich dass dir zuhause irgendein Gerät (Client, Router, etc) noch aus dem Cache noch falsche Werte liefert.

    Hehe ja das hat diesmal geklappt - bin noch lernfähig :)

    Der Tip mit dem dnschecker hat mich aber weiter gebracht, ich bin wohl zu ungeduldig. Es waren gestern nur 3 DNS Resolver die meine richtige IP zurückgemeldet haben. Heute Morgen melden sich alle aufgeführten mit der richtigen IP.


    Zitat

    Rufst du die Seite explizit mit https davor auf? Ansonsten muss im Webserver noch eine 301-Weiterleitung eingetragen werden, damit automatisch von http auf https weitergeleitet wird. (auch gut möglich, dass dein Bitwarden-Docker-Dings das bereits implementiert hat, keine Ahnung, ich installier sowas immer händisch - dann weiß ich auch welche Config da wirklich aktiv ist). Lauscht der Webserver auf dem Port 443? ss -tlpen Welches Zertifikat wird ausgegeben - das von Letsencrypt? Lässt sich auch über die CLI auslesen: openssl s_client <HOST>:443


    Und auch da hast Du den richtigen "Richer" gehabt, eben mal nachgesehen, die 301-Weiterleitung macht das Docker-Image nicht automatisch X(

    Wenn ich exakt mit https://s3.dddddd.de aufrufe, komme ich auch auf die Seite - oh man es könnte so einfach sein ;)

    Zitat


    Die Frage ist aber, ob du wirklich auf deinem Server landest.

    Ja hier frage ich mich, was bei mir im Netz die DNS so lange im Cache hält. Gestern Nacht wollte ich noch mal mit meinem IPhone die Nextcloud auf meinem "Kellerserver" ansprechen, also die App aufgerufen und die war der Meinung - Server gefunden, aber Zertifikat ungültig. Hier war das Handy im WLan. Ok also mal WLan aus - und siehe da, der Server ist erreichbar und auch das Zertifikat wurde "anerkannt". Ja wie gehts sowas? - Dann wieder WLan an und das Zertifikat wurde als nicht vertrauenswürdig gemeldet. - Und durch dieses Thema hier im Forum - gleich nochmal die Zerts angesehen, wenn das Handy im WLan war, wurde das "Plesk" Zert. ausgeliefert - also stimmte im WLan was mit dem DNS noch nicht. Über Nacht wurde dann wohl der DNS Cache geleert und siehe da - alles so wie es sein soll. -> Bin mal gespannt wie lange 8o


    Also Router habe ich hier eine FritzBox - keine Ahnung wie lange die DNS Anfragen im Cache hält.


    Aber erstmal herzlichen Dank an Deine und KB19´s Hilfe!

    Ich bin nicht aus der IT - mein ergeiziges Hobby eben, leider der einzige in meinem Bekantenkreis mit diesem Hobby.


    Gibt es NetCup bei Discord? - Oder einen Chat oder sowas 8) da könnte ich dann auch "nerven" ;)


    VG Mario

  • Du könntest zukünftig bei Deiner Domain im CCP auch die TTL reduzieren. Der Standardwert von 86400 Sekunden (24 Stunden) ist meistens nur hinderlich. Persönlich verwende ich überall 3600 Sekunden (1 Stunde), dann sind die Caches schneller ungültig.


    Es gibt übrigens einen inoffiziellen IRC-Chat: https://huepf.net/nc-kunden

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)