Hallo zusammen,
ich fräse mich seit vielen Wochen erfolglos durch Beiträge, Tutorials und Youtube-Videos, und ich bekomme bei mir Letsencrypt einfach nicht gescheit ans Laufen. Irgendwo habe ich evtl. einen Denkfehler.
Was ich habe:
- OPNsense 22.7.2 verbunden mit dem Internet
- meine dynamische IP wird korrekt bei DuckDNS aktualisiert
- Intern verwende ich eine Domain (zurhorst.baerl).
- Extern habe ich eine Domain (die-zurhorsts.de)
- Da habe ich eine Subdomain (baerl.die-zurhorsts.de) eingerichtet; CNAME zeigt auf DuckDNS
Was ich möchte:Die OPNsense selbst sowie diverse Server hinter der Firewall möchte ich mit Letsencrypt Zertifikaten absichern.
Manche Dienste sind rein intern, wenige andere sollen auch von extern erreichbar sein.
Problem 1:Was sind geeignete Hostnamen für mein internes Netwerk?
- Ich habe begonnen mit zurhorst.baerl. Die Maschinen heißen dann opnsense.zurhorst.baerl, database.zuhorst.baerl, ... Alle Maschinen werden über den Unbound DNS aufgelöst und das klappt alles.
- Dann habe ich die Maschinen umbenannt in FQDNs: opnsense.baerl.die-zurhorsts.de, database.baerl.die-zurhorsts.de, ... etc., weil ich dachte, dass ich nur so ein LE Zertifikat erhalten könnte. Das hat aber nicht geklappt.
- Ich habe wieder alles zurück geändert per Rat aus dem administrator.de Forum, und bin nun wieder bei der zurhorst.baerl internen Domain. Aber egal wie ich es mache, ich bekomme die LE Zertifikate nicht hin.
- Nach noch mehr lesen glaube ich inzwischen auch, dass ich doch nochmal auf die FQDNs umbauen muss. Aber das möchte ich wirklich erst machen, wenn ich sicher weiß, dass das nötig ist. Zumal die Namen dann unpraktisch lang werden.
Gibt es da noch einen Trick, wie ich intern mit den LE Certs arbeiten kann, und gleichzeitig die Namen kurz sind? -- Evtl. eine Umschreibung im Unbound DNS?
Problem 2:LE Zertifikat-Erzeugung mit DNS-01 Challenge oder HTTP-01 Challenge?
Hier habe ich inzwischen eine Idee, aber ich bin auch hier verunsichert inzwischen:
- Für nur interne Server würde ich wohl die DNS-01 Challenge benötigen, um den TXT-Record bei DuckDNS per API zu ändern.
- Für von extern erreichbare Server kann ich nun entweder:
- OPNsense alles erledigen lassen und SSL Offloading im HA Proxy nutzen.
- Oder ACME-Client direkt auf dem Server laufen lassen. (evtl. bei Bitwarden vorteilhaft, damit die "letzte Meile" auch noch verschlüsselt ist)
- Ich denke, dass ich doch umbedingt auf die FQDN Benennung zurück muss, damit LE-Zertifikate ausgestellt werden können. Es gibt viele Tutorials zum Thema "LE für interne Server", aber die sagen nicht explizit, dass es nur mit einem FQDN klappt.
Was ich hier nicht verstehe: wenn OPNsense die Zertifikate zentral besorgt: wie bekomme ich diese auf die jeweiligen Server drauf?
Und stimmt das so, was ich hier zusammen gesammelt habe?
Problem 3:Ich habe einen Apache laufen unter testweb.baerl.die-zurhorsts.de. Der antwortet sowohl auf http als auch https://
Allerdings fällt mir auf, dass er trotz SSL-Verschlüsselung (mit der LE Test CA) nur die unverschlüsselte Webseite anzeigt. (Ich habe die index.html geändert, da steht "Port 80" im Text; und für https eine zweite Datei angelegt.)
Meine Interpretation: das SSL-Offloading im HA-Proxy verschlüsselt die Verbindung nur bis zum HA-Proxy, und von da aus geht es über :80 weiter zum Server.
Wie würde ich das Zertifikat nun bis auf den Webserver drauf bekommen?
Problem 4:Ich suche noch einen Weg, wie ich die OPNsense gerne weiterhin per Port 443 erreichbar halten könnte, ausschließlich aus dem LAN heraus, aber nicht über WAN.
Das Umbenennen des Ports gefällt mir nicht.
Kann ich im HA Proxy eine Regel einrichten, welche mich weiterleitet zum Web Interface auf der Firewall selbst? -- Oder muss ich wirklich bei dem "umgebogenen" Port bleiben, sobald der HA-Proxy sich für den Port 443 verantwortlich fühlt? -- Die OPNsense soll auf keinen Fall von extern erreichbar sein.
Jeder Tipp ist willkommen. Ich würde das Thema so gerne hinter mir lassen, aber je länger ich mich damit auseinander setze, desto verwirrter bin ich nur noch.
Herzlichen Dank und viele Grüße,
Marcus
Ich les mal gespannt mit, das Thema kommt auf mich auch noch zu. Ich hab leider noch keine großartige Erfahrung diesbezüglich, mit OPNSense, kann dir aber allgemein ein paar Fragen beantworten, wie das allgemein oder bei meinem jetzigen, strukturell ähnlichen System funktioniert.
Vorweg: Die LE Zertifikate sollen dem Client/Browser bestätigen, dass Domainname und Seitenbetreiber zusammengehören. Wenn sie das nicht mehr tun, wird dein Browser das für ungültig/Betrug halten. Du kannst z.B. nicht ein Zertifikat für hanswurst.de beantragen und dich dann als Sparkasse-Hamburg.de bezeichnen.
Insofern sollten die internen Maschinen unter den Domains, die in ihren Zertifikaten stehen, erreichbar sein.
Ausschlaggebend ist, was im DNS steht, nicht der Hostname der Maschine.
Zu Problem 1 und 2:
Es gibt (meiner Meinung nach mindestens) 2 Wege, um den Traffic bis zu den Internen zu verschlüsseln:
1. Alles mit FQDN (intern und extern gleich) und die Zertifikate vom Proxy aus bei LE anfordern und auf die Internen kopieren (Cron-Job). Pro: Alle Clients akzeptieren auch intern automatisch die Zertifikate. Con: Cron-Jobs nicht immer möglich, dann muss man Zertifikate kopieren und je nach Vertrauenswürdigkeit der internen Maschinen auch den Zugriff auf andere Zertifikate unterbinden usw.
2. eigene Domain intern lassen und selbst CA erstellen, selbst für die Internen Zertifikate erstellen und mit der CA signieren (z.B mit XCA). CA-Cert bei OPNSense hinterlegen. Von Proxy dann LE Certs für Verbindungen nach außen anfordern.
Pro: Keine Kopiererei, Zertifikate länger gültig (einstellbar). Zertifikate auch für nur interne Server erhältlich. Con: Alle Clients/Browser müssen erstmal einmalig das CA-Zertifikat importieren, bevor sie die damit signierten Zertifikate akzeptieren.
Zu 3: Das wäre jetzt raten. Hast du https:// genommen? Fehlt ein redirect 80->443? Hast du mod_ssl aktiviert? Was sagen die Logs, ist das hier überhaupt das richtige Forum?
Zu 4: Ohne das je mit OPNSense gemacht zu haben, würde ich behaupten: Ja das geht, sofern du darauf verzichten kannst, den Proxy am LAN Interface lauschen zu lassen. Deine OPNSense bekommt einen Namen und ein zugehöriges Zertifikat, einen internen DNS-Eintrag und eben keine Regel im Proxy. Wenn du die Admin-Seite aus dem LAN besuchen willst, antwortet OPNSense, von WAN kommt keiner dran, weil es keine Proxy Regel gibt. Du solltest beim Admin Interface einstellen, dass es nur aus dem LAN erreichbar ist. Sicherheitshalber von außen (Handy...) mit an- und abgeschaltetem Proxy prüfen.
@mzurhorst ich hatte vor ein paar jahren ein gutes howtoo über google gefunden wie man LE & HAProxy einrichtet (einfach googlen mit den richtigen schlüssel worten) das ding war sogar in deutsch.
zu der frage wie du die zertifikate von LE auf deinen webserver bekommst: garnicht da kümmert sich der HAProxy drum, denn der macht das alles (selbst den redirect von 80 —> 443
ich denke du hast das Konzept dahinter noch nicht verstanden
zu den host fqdn ist bei mir so gelöst:
intern: in.meine.de
extern: so wie es für mich sinnvoll war .meine.de
und dienste die intern und extern sind habe einen
host overwrite angelegt der auf die interne ip zeigt
Gesendet von iPad mit Tapatalk Pro
Man kann auch für interne Hosts ohne Verbindung nach außen Let's Encrypt automatisieren. Dazu sind zwei Dinge nötig:
1. Man muss DNS-01 verwenden, da es ja keine Verbindung zu dem internen Host gibt.
2. Für den FQDN des internen Hosts muss es einen Eintrag im Internet geben, der z.B. auf einen selbstbetriebenen acme-dns Server zeigt.
Machen wir in der Firma so. Es gibt jede Menge Einträge unter punkt.hosting im weltweiten DNS, die nur einen CNAME-Eintrag auf den acme-dns haben.
Zuletzt: ich empfehle für private Domains nicht irgendwelche Fantasie-TLDs zu benutzen. Man weiß ja nie, wann die ICANN mit .baerl als neuer Toplevel-Domain um die Ecke kommt.
Besser man nimmt eine Domain, die man tatsächlich besitzt, bei meiner Firma z.B. punkt.de - und packt dann alles im Hausnetz und das Windows-AD etc. pp. in die Domain intern.punkt.de - da gibt es nie einen Konflikt und die kommt im Internet garantiert nicht vor.
HTh,
Patrick
Ok, das habe ich fast befürchtet. Das bedeutet, ich ändere die Hostnamen nochmal alle in FQDNs um.
Die Frage, ob oder ob nicht ein Dienst dann erreichbar ist von außen, das hängt dann ja lediglich an der HA Prox Konfiguration, welcher eben drauf reagiert oder es nicht tut.
Dann fange ich mal an. ;-)
Quote from: mt on August 31, 2022, 07:56:53 PM
Insofern sollten die internen Maschinen unter den Domains, die in ihren Zertifikaten stehen, erreichbar sein.
Ausschlaggebend ist, was im DNS steht, nicht der Hostname der Maschine.
Hi mt, diesen Satz verstehe ich nicht.
Der Hostname ist "database", und er wird doch dann ergänzt um eine Domain.
Meine Fantasie-Domain zuhorst.baerl, die wird doch von meinem Unbound DNS Server beantwortet. Im Falle der echten Subdomain baerl.die-zurhorsts.de wäre der DNS Server von Netcup zuständig.
Wie kann da der Hostname nicht relevant sein?
Ok, das liegt an der Mehrfachbelegung des Begriffs "Hostname".
Irrelevant ist, was der Befehl hostname oder hostname -fqdn auf dem Host ausgibt (macht es aber übersichtlicher). Wichtig ist, dass der DNS-Eintrag für den Host mit dem FQDN im Zertifikat übereinstimmt. Sowohl intern als auch extern.
Zu dem weiteren Teil meiner Aussagen, muss ich einschränken, dass ich von einem Szenario ausgegangen bin, wo der Traffic aus dem LAN nicht über den HAProxy läuft. Folglich kann auch der HA-Proxy nicht auf magische Weise gültige Schlüssel an die Server verteilen.
Wer spricht mit wem:
WAN
|
OPNSEnse und HAProxy
| |
Clients----Server
Was micneu mit
Quote from: micneu on August 31, 2022, 08:39:30 PM
wie du die zertifikate von LE auf deinen webserver bekommst: garnicht da kümmert sich der HAProxy drum, denn der macht das alles (selbst den redirect von 80 —> 443
glaube ich meinte würde eher so aussehen
WAN
|
OPNSEnse und HAProxy
| |
Clients Server
Der Unterschied ist, ob dein lokales DNS die FQDN vom LAN aus auf den HAProxy auflöst oder auf deine Server.
Wenn auf HAProxy, pro: musst dir um anerkannte Schlüssel auf den Servern keine Gedanken machen, machst CA, signierst selbst Certs und importierst CA-Cert im Proxy. Con: gesamter HTTPS-Traffic aus LAN über Proxy.
Wenn du FQDN auf die Server auflöst, dann brauchen die alle ein gültiges Zertifikat, dafür LAN HTTPS Traffic direkt zwischen Client und Server.
Oh weh, nun hast du mich komplett abgehängt. :o
Ich muss da langsamer ran gehen, damit ich mit komme.
Ich habe nun erst mal meine VMs alle umbenannt auf <hostname>.baerl.die-zurhorsts.de
Das hat auch einigermaßen zügig geklappt, und die Verbindungen untereinander nutzen nun die neuen FQDNs.
Dann habe ich HA Proxy konfiguriert. Dieser ist aber insgesamt sehr zickig. Ich hatte mindestens 2x das Problem, dass er die Konfig zerschossen hat, und ich das auch nicht mehr gelöst bekommen habe im Webfrontend.
Aber jedenfalls habe ich nun erfolgreich zwei VMs auf Port 80 erreichbar.
Die OPNsense ist aber "leider" ebenfalls von außen erreichbar. Das möchte ich ganz sicher nicht!
Kann ich die OPNsense selbst auf einen anderen Port legen, und dann über den HA Proxy darauf zugreifen, so dass ich mir den Port nicht merken muss? --- Oder klappt das nur mit Weiterleitungen an externe Services?
Und sobald ich Letsencrypt nutzen möchte, dann klappt jedes Mal gar nichts mehr.
Da werde ich nicht schlau draus. Selbst eine vermeintlich einfachere HTTP-01 Challenge klappt nicht für diese VMs, obwohl sie ja aus dem Internet schon erreichbar sind. >:(
Ich habe eine interessante Beobachtung gemacht zu HAProxy:
- Aus dem Internet ist mein EVCC Server direkt erreichbar ohne Portangabe: evcc.baerl.die-zurhorsts.de. HAProxy leitet dass dann an mein Backend an den Port 7070 weiter.
- Aber hier daheim im Netzwerk klappt das nicht, da muss ich noch :7070 dahinter hängen.
Das bedeutet wohl, dass mein Netzwerk am HAProxy vorbei kommuniziert.
Und das ist extrem verwirrend, weil ich nun mit dem Namen durcheinander komme. Bei diesem Namensschema bin ich auf einem Holzweg, scheint mir. :-\
Quote from: mzurhorst on September 01, 2022, 06:20:57 PM
Oh weh, nun hast du mich komplett abgehängt. :o
Du hast ja auch mit einer ganzen Liste von Problemen mit vielen unbekannten Faktoren losgelegt.
Quote from: mzurhorst on September 01, 2022, 06:20:57 PM
Die OPNsense ist aber "leider" ebenfalls von außen erreichbar. Das möchte ich ganz sicher nicht!
Kann ich die OPNsense selbst auf einen anderen Port legen, und dann über den HA Proxy darauf zugreifen, so dass ich mir den Port nicht merken muss? --- Oder klappt das nur mit Weiterleitungen an externe Services?
Schau doch als erstes mal unter System->Settings->Administration nach, ob Listen Interface auf LAN gesetzt ist.
Als nächstes entscheidest du dich, ob deine Clients aus dem LAN direkt auf die Server zugreifen sollen oder über HA Proxy.
Ok. Das Listen Interface steht auf "All (Recommended)" in der Voreinstellung. Hier habe ich jetzt die DMZ und das WAN-Interface ausgeklammert. Das funktioniert schon mal.
Mir scheint, dass intern ein Zugriff ohne HAProxy sinnvoller ist, damit dieser sich ausschließlich um eingehenden WAN-Traffic kümmert und es nicht noch komplizierter wird.
Dann hast du intern und extern aber unterschiedliche URLs, da du intern die Portnummern dran kleben musst. Gibt es einen speziellen Grund dafür? Weshalb betreibst du deine Anwendungen nicht intern wie extern auf 80/443?
Ich habe meine ganzen Anwendungen übrigens ohne SSL auch auf jeder Menge verteilter Ports und greife auch von intern über einen Reverse-Proxy auf Port 443 zu. Die OPNsense unterstützt im "Hairpin NAT", d.h. du greifst von intern auf die externe Adresse zu und wirst wieder nach innen geleitet.
Du kannst also beides tun. Ich würde im LAN dann aber gucken, die "komischen" Ports wegzukriegen, wenn das ohne HA-Proxy laufen soll.
Das ist ein guter Punkt.
Das Thema ist beliebig komplex und wächst mir gerade über den Kopf.
Habe mich gestern Abend nochmal hin gesetzt und überlegt, wozu ich überhaupt die ganze Gymnastik machen wollte. Im Grunde störe ich mich in allererster Linie an der Warnung des selbst erzeugten Zertifikats.
Aber nun wird die Baustelle immer größer, nur weil ich zu bequem bin, um mir das Root-Zertifikat meiner CA auf eine handvoll Geräte zu packen.
Scheint irgendwie kein guter Deal zu sein wenn die Zeit ein kostbares Gut ist ;D
Gibt es einen Weg, wie man diese Zertifikate in der Kommunikation "anbieten" kann? -- So nach dem Motto: "Mein Service --> meine Regeln!" --- Dann könnte man auf den Endgeräten selbst entscheiden, ob oder ob nicht man meiner CA vertrauen möchte.
(ich betreibe ja nichts kommerzielles mit vielen Kunden, sondern was privates mit einer handvoll Besucher auf einem Web-Service)
Jag doch alles, auch von innen, durch den Proxy mit Letsencrypt. Das schadet doch nicht.
Mir ist noch nicht mal klar, wo genau ich das einstelle, ob oder ob nicht etwas durch den HA Proxy durch geht.
Ein Listening Interface hat der ja in seinen Settings nicht.
Würde ich dann weitere Conditions und Rules auf das gleiche Backend routen?
Insgesamt ist mir der HA Proxy auch etwas "wackelig". Gerade funktionierten meine beiden Test-Server nicht, ohne dass ich was aus dem Log entnehmen konnte. Einmal abschalten, wieder anschalten, alles klappt wieder.
Die Server waren aber parallel mit ihrer "komischen" Adresse + Port erreichbar.
Wenn der DNS-Eintrag für someservice.beim-horst-zuhause.de auf die externe IP-Adresse deiner Firewall zeigt, dann verbinden sich auch Clients von intern mit dieser. Und damit mit dem HA-Proxy und seinem Letsencrypt-Zertifikat, wenn alles stimmt. Das wird alles nur von der Namensauflösung und den daraus folgenden Ziel-IP-Adressen geregelt. Eigentlich logisch ;)
Mal ganz langsam zum Mitmeißeln, weil ich hier langsam verrückt werde.
Ich habe eingerichtet:
- Subdomain bei Netcup: weewx.die-zurhorsts.de --> CNAME: weewx-die-zurhorsts.duckdns.org
- In OPNsense ist DuckDNS mit dem Token konfiguriert. --> Die IP bei DuckDNS ist meine zugewiesene IP, die stimmt.
- Im HAProxy sind Condition, Rule, Backend Pool, Public Service und Real Server konfiguriert für Port 80. --> ich komme mit weewx.die-zurhorsts.de auf meinen Server drauf
Soweit alles easy, und an diesem Punkt verharre ich seit einigen Tagen.
Bis hierher funktioniert alles, und ich denke auch, dass da kein Fehler drin ist.
Aber nun ACME.sh / Letsencrypt:
- ACME Client aktiviert; keine HAProxy Integration, da ich DNS-01 verwenden möchte mit dem DuckDNS Token
- LetsEncrypt TEST Account erfolgreich aktiviert
- Challenge: DNS-01 mit DuckDNS als Service; API-Token von DuckDNS eingegeben
- _Zertifikat: Common Name: weewx.die-zurhorsts.de; kein Alt Name; Account und Challenge gewählt. ---> Einziger Wackelkandidat: "DNS Alias Mode" ganz unten; der steht auf "not using DNS alias mode".
- Es kommt jedes einzelne Mal zu einer Fehlermeldung: Error extracting the domain. gefolgt von: Error add txt for domain:_acme-challenge.weewx.die-zurhorsts.de
Google spuckt bei dieser Fehlermeldung auch Treffer aus:
https://github.com/acmesh-official/acme.sh/issues/2933
Kann es sein, dass DuckDNS einen weg hat? -- Läuft das bei euch?
Muss ich bei Netcup noch zusätzlich eine SubSubdomain "_acme-challenge.weewx.die-zurhorsts.de" auf DuckDNS zeigen lassen mit CNAME? -- Oder eine *.weewx.die-zurhorsts.de?
Ich packe hier mal eine Reihe Screenshots rein der Vollständigkeit halber. Evtl. übersehe ich ja etwas:
@pmhausen
2. Für den FQDN des internen Hosts muss es einen Eintrag im Internet geben, der z.B. auf einen selbstbetriebenen acme-dns Server zeigt.
Vielleicht lese ichs falsch, aber mit Domain-Alias via ACME-Challenge ist das doch nicht mehr der Fall?
@mzruhorst
Ich denke daran scheitert es bei dir nämlich. Setze doch mal bitte folgendes:
* Subdomain bei Netcup: _acme-challenge.weewx.die-zurhorsts.de --> CNAME: _acme-challenge.weewx-die-zurhorsts.duckdns.org
* "DNS Alias Mode" ganz unten dann konfigurieren auf weewx-die-zurhorsts.duckdns.org
* mit Staging von Letsencrypt testen, damit man nicht aus Versehen gesperrt wird :)
Damit sollte das eigentlich klappen :)
@JeGr
Etwas verkürzt, zugegeben.
Es muss einen Eintrag _acme-challenge.mein.interner.fqdn geben mit CNAME mein.acme-dns.extern.
Oder für die ganze interne Domain: _acme-challenge.interne.domain CNAME mein.acme-dns.extern.
Aber Einträge für den internen Host im externen DNS - so nenne ich das zumindest.
Gruß
Patrick
Quote from: pmhausen on September 03, 2022, 12:31:51 PM
Jag doch alles, auch von innen, durch den Proxy mit Letsencrypt. Das schadet doch nicht.
Ansichtssache. Entweder man ver- und entschlüsselt doppelt so oft, das kostet dann Rechenleistung, vor allem, wenn der Proxy etwas älter ist und kein AES-Support im Prozessor hat. Das wird das bei entsprechendem Traffic im LAN schnell zum Flaschenhals, z.B. für Nextcloud o.Ä., wo ordentlich Daten durchgeschaufelt werden.
Oder man hat alles zwischen Proxy und Host unverschlüsselt, incl. Logindaten usw. Wenn dann mal eine Komponente hochgenommen wird, kommt der Angreifer auch anschließend wirklich überall dran.
Quote from: mzurhorst on September 03, 2022, 08:57:02 AM
Im Grunde störe ich mich in allererster Linie an der Warnung des selbst erzeugten Zertifikats.
Aber nun wird die Baustelle immer größer, nur weil ich zu bequem bin, um mir das Root-Zertifikat meiner CA auf eine handvoll Geräte zu packen.
Scheint irgendwie kein guter Deal zu sein wenn die Zeit ein kostbares Gut ist ;D
Gibt es einen Weg, wie man diese Zertifikate in der Kommunikation "anbieten" kann? -- So nach dem Motto: "Mein Service --> meine Regeln!" --- Dann könnte man auf den Endgeräten selbst entscheiden, ob oder ob nicht man meiner CA vertrauen möchte.
Das ist schonmal sehr gut, dass du dich daran störst, es gibt nichts schlimmeres als sich anzugewöhnen, da Ausnahmen hinzuzufügen. Dann merkt man nämlich nicht, wenn jemand dazwischen sitzt.
Es ist kein Riesenaufwand, das Root-Cert auf Geräte zu packen. Bei Windows geht das sogar per Gruppenrichtlinie, falls du AD hast. Aber auch sonst, du legst es irgendwo zugänglich ab, z.B. in einem Netzlaufwerk, USB-Stick oder auf einem Webserver und man importiert es eben einmal in den Browser oder wo auch immer man es braucht. Dauert keine 2 Minuten.
Quote from: mt on September 09, 2022, 05:53:04 PM
Ansichtssache. Entweder man ver- und entschlüsselt doppelt so oft, das kostet dann Rechenleistung, vor allem, wenn der Proxy etwas älter ist und kein AES-Support im Prozessor hat.
Welche CPU der letzten 10 Jahre hat das nicht? Ich meine, die absolute Low-End Plattform für die Sense ist sowas wie ein APU. Und selbst die kann das.
Meine Ansicht ;)
Quote from: JeGr on September 08, 2022, 02:49:24 PM
@mzruhorst
Ich denke daran scheitert es bei dir nämlich. Setze doch mal bitte folgendes:
* Subdomain bei Netcup: _acme-challenge.weewx.die-zurhorsts.de --> CNAME: _acme-challenge.weewx-die-zurhorsts.duckdns.org
* "DNS Alias Mode" ganz unten dann konfigurieren auf weewx-die-zurhorsts.duckdns.org
* mit Staging von Letsencrypt testen, damit man nicht aus Versehen gesperrt wird :)
Damit sollte das eigentlich klappen :)
So ganz 100% verstehe ich es noch immer nicht. Aber ich habe nun ein Zertifikat.
Meine Änderungen:
- Bei Netcup ein zweiter CNAME: _acme-challenge.weewex --> _acme-challenge.die-zurhorsts.desec.io* (ohne .weewx!)
- Bei desc.io eine neue Domain angelegt: _acme-challenge.die-zurhorsts.desec.io
- Zertifikat: DNS Alias Mode steht nun auf "Automatic (use DNS lookups)"
So hat es geklappt. Was ich aber nicht verstehe:
Ich habe nun unter der ursprünglichen DynDNS Domain "die-zurhorsts.desec.io" unten drunter einen TXT Record mit dem Namen _acme-challenge. Wie unterscheidet sich der nun wieder von der "Subdomain "_acme-challenge.die-zurhorsts.desec.io"?
Aus der Sicht von Netcup heißen die beiden ja anscheinend gleich. Da die "Subdomain" nicht benutzt ist, habe ich diese erst mal wieder entfernt.
Tausend Dank für den Tipp. Das hat mich auf die richtige Fährte gebracht.
(nur leider nie in Tutorials gesehen, dass man bei (z.B.) Netcup dann *.weewx weiterleiten müsste auf den DynDNS-Provider).
*: Ich bin zu desec.io gewechselt, weil ich befürchtete, es würde an DuckDNS liegen.
> Ich habe nun unter der ursprünglichen DynDNS Domain "die-zurhorsts.desec.io" unten drunter einen TXT Record mit dem Namen _acme-challenge.
Sieht wie aus? Sorry, da sind jetzt so viele Namen im Spiel, dass ich nicht mehr verstehe, welcher welcher ist :)
DU selbst legst normalerweise gar keine TXT Records an, sondern nur bei Netcup einen CNAME(!), der das Acme Challenge von dort eben zu einem anderen Anbieter -> jetzt eben desec - rüberschubst und DORT wird dann der TXT Record für das Challenge erzeugt und verifiziert. Das ist alles. Der TXT wird aber von acme.sh erstellt und wieder aufgereäumt, hinterher sollte also keiner mehr da sein wenn alles sauber durchgelaufen ist oder du hast einen zusätzlichen angelegt der nicht gebraucht wird :)
Zudem eh eine Empfehlung und ein Shoutout: deSEC.io (und ihr DynDNS Part) lohnen sich wirklich auch wenn man den DNS seiner eigenen Domain sinnvoll verwalten will. Jetzt auch mit 2FA Absicherung durch multiple Tokens, Tokenbasierte API die man sehr gut nutzen kann, etc. - kann ich nach Kontakt und Korrespondenz mit den Kollegen dort bislang nur empfehlen. Bessere Alternative IMHO als die Domain bei Cloudflare o.ä. zu parken um ein ordentliches DNS Interface zu haben und man darf bis zu 15 Domains pro Account (auf Anfrage auch mehr) hinpacken. Definitiv Toller Service, der _keine_ Firma ist (haben sich als .e.V. gegründet um das unabhängig betreiben zu können). Daumen hoch!
Cheers
Hallo zusammen.
Lange ist das Ganze her, und ich bin natürlich immer noch nicht weiter gekommen.
Es nervt mich unglaublich, dass ich das nicht hin bekomme. Ich möchte gerne das endlich abschließen und buddele es daher nochmal aus.
Hier nochmal einige Screenshots im Anhang, nützt ja nichts:
- Netcup. Ich habe mehrere Einträge für Subdomains (weewx, vpn, ...). --> Diese zeigen alle auf die-zurhorsts.dedyn.io
- deSEC.io. Hier funktioniert die automatische Aktualisierung der IP-Adresse. Der Wildcard-CNAME klappt auch.
- OPNsense. Sowohl das Zertifikat für "die-zurhorsts.dedyn.io" als auch die Zertifikate für eine "Sub-Subdomain" werden erzeugt. Aber wenn ich meine die-zurhorsts.de Domain nutze, dann klappt es partout nicht, und ich finde den Fehler nicht. Missverstehe ich hier denn etwas, und das kann gar nicht klappen?
- Zertifikat-Einstellungen. Hier habe ich unten alle vier Optionen ausprobiert. Alle scheitern leider.
- DNS. Wenn ich mit "dig weewx.die-zurhorsts.de" den DNS-Eintrag prüfe, dann wird der mir korrekt auf meine dynamische IP aufgelöst.
Ich habe nun so viele Tutorials durch, und im Grunde sieht das alles straight-forward aus.
Wo liegt mein Fehler?
Danke sehr und viele Grüße,
Marcus
Ein frohes neues Jahr wünsche ich euch!
Ich kann es kaum glauben, aber ich hab den HAProxy mit Letsencrypt endlich eingerichtet bekommen. ;D
Der Durchbruch kam im Endeffekt daher, dass ich für die Letsencrypt-Zertifikate die Challenge auf HTTP-01 geändert habe. Damit klappen nun Wildcard-Zertifikate nicht mehr, aber das ist verschmerzbar.
Gelöst habe ich es nun so:
- Netcup: für meine Domain einen CNAME-Eintrag *.baerl auf DeSec.io
- So werden alle "Sub-Sub-Domains" auf die OPNsense geleitet
- der ACME Client erzeugt nun für jeden Dienst ein separates Zertifikat (z.B. weewx.baerl.die-zurhorsts.de
- HAProxy hat nun jeweils Regeln, um den Host zu erkennen und an die entsprechende VM weiterzuleiten
Home Assistant war als einziges nun noch etwas zickig, da musste ich im Frontend das HTTP/2 raus nehmen, damit ich einen "Error 400: bad request" ausgemerzt bekomme.
Viele Grüße,
Marcus