Hallo Gemeinde. Ich bin vor kurzes von noip auf ipv64 umgestiegen. Ich habe nun allerdings das Problem das ich keine Zertifikate über Cloudpanel erstellt bekomme trotz Wildcard Domain.
Cloudpanel nutze ich weil ich mit dem nginx Revers Proxy immer Error 500 bekommen habe. Bei Cloudpanel lief alles bisher sofort ohne Probleme als Revers Proxy.
Nutze eine opnsense mit einem dahinter liegendem UnraidServer.
Cloudpanel läuft auf einer VM im Unraid.
Muss ich beim ipv64 dienst etwas bestimmtes einstellen damit die Zertifikate durchkommen? Port 80 und 443 werden auf den Cloudpanel RV Proxy durchgeleitet.
Der DynDNS Anbieter hat in Erster Linie mit den Lets Encrypt Zertifikaten nichts zu tun.
Der DynDNS Anbieter macht DNS und keine Zertifikate.
Außer es wird für das Ausstellen der Zertifikate eine DNS Challenge genutzt.
Error 500 hinter dem Reverse Proxy heißt irgendwas kann nicht erreicht werden.
Wir brauchen leider mehr Infos um dir helfen zu können.
Ich erhalte beim erstellen einen SSL Zertifikates unter Cloudpanel folgende Meldung
subdomain.domain.ipv64.net: Domain could not be validated, error message: error type: urn:ietf:params:acme:error:connection, error detail: xx.xxx.xxx.xxx: Fetching http://subdomain.domain.ipv64.net/.well-known/acme-challenge/r4nsj1dPInZIr3SaYP87Fflr90gKd42ZZv3W0W63O2o: Error getting validation data
Habe eben nochmal das gleiche Reverse proxy Ziel auf eine DynDNS Domain von nopp gemapped, da hat es sofort funktioniert. Da ich an meinem System nicht geändert habe muss es nach meiner Einschätzung als etwas mit dem DNS Dienst zu tun haben. Die Subdomains kommen alle bei mir auf dem System an durch die WIldcard Option. Aber sind halt selbst signierte Zertifikate.
Wie du geschrieben hast scheine ich das über DNS Challenge zu machen. Muss ich da gesondert etwas einstellen? Ich kann ja bei Cloudpanel nicht die Option anpassen mit welcher Methode er die Zertifikate erstellen tut.
EDIT:
Ich vermute es hat was mit der Option zu tun das ich http beim ipv64 Dienst bereits auf https umleite und dadurch der http Aufruf für das Zertifikat gar nicht auf Port 80 ankommt. Wo kann ich das einstellen?
Du machst keine DNS Challenge mit Cloudpanel. Oder trägst du irgendwo deinen IPv64 API Key ein?
Cloudpanel macht eine HTTP Challenge, die wiederum mit IPv64 nichts zu tun hat. Hat dein Server mit Cloudpanel denn Port 80 und 443 offen und ist erreichbar?
Nein den Key trage ich nirgends ein.
Ja beide Ports sind auf den Cloudpanel Reverse Proxy umgeleitet.
Du verwirrst mich. Cloudpanel Reverse Proxy? Cloudpanel ist ja nix anderes als ein NGINX.
Jetzt kann ich trotzdem nicht weiter helfen, weil wenn der DNS (ipv64) stimmt, dann liegt es nicht daran. Ist da ggf, ein IPv6 Problem oder so?
Liegt das Zeug bei dir zuhause oder wo?
Ich nutze keine ipv6 also zumindest nicht bewusst. Ja liegt alles auf meinem unraid Server. Cloudpanel ist auf einer Vm installiert. Ich habe mit dem Docker NGINX Reverse Proxy immer Probleme. Bisher lief Cloudpanel tadellos.
Okay, also du machst über einen Router mit einem Portforwarding das Cloupanel von außen über IPv4 erreichbar. Wenn du nackt die IPv4 im Browser eingibst dann kommt da auch was… ?
Es ist KEIN Nginx proxy manager im Einsatz.
Na noch viel schlimmer. Exposee Host auf die OPNSense. Dort NAT Port 80 und 443 auf die VM Cloudpanel.
Wenn ich die IP eingeben kommt nichts. Die Aufrufe erscheinen aber alle mit einer RDR Rule im Log der Firewall
gebe ich meine ganzen Subdomains ein welche in Clouppanel konfiguriert sind leitet Cloudpannel alles schön weiter und die Webinterfaces gehen auf.
Sobald ich manuell einen A Record für die Subdomain auf ipv64.net hinterlege, funktioniert es. Ist das so gewollt oder sollte das auch mit der Wildcard Option generell funktionieren?
Das sollte auch mit dem Wildcard Häkchen gehen. Ggf. setzt du nochmal die A Records neu.
Du meinst die beiden Standard Einträge
domain.ipv64.net TYPA A und AAAA löschen und einfach neu erstellen?
Hat nicht funktioniert. ich hab Einzeleinträge je Subdomain erstellt.
Das muss aber eigentlich auch so klappen. Sehr sehr komisch.