OPNsense Forum

International Forums => German - Deutsch => Topic started by: mzurhorst on August 31, 2022, 06:47:40 PM

Title: [gelöst] Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mzurhorst on August 31, 2022, 06:47:40 PM
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:


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?

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:

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

Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mt on August 31, 2022, 07:56:53 PM
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.
Title: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: micneu on August 31, 2022, 08:39:30 PM
@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
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: Patrick M. Hausen on August 31, 2022, 08:40:50 PM
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
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mzurhorst on September 01, 2022, 12:14:27 AM
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.  ;-)
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mzurhorst on September 01, 2022, 12:24:03 AM
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?
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mt on September 01, 2022, 04:35:19 PM
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.
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mzurhorst on September 01, 2022, 06:20:57 PM
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.  >:(

Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mzurhorst on September 02, 2022, 10:00:59 AM
Ich habe eine interessante Beobachtung gemacht zu HAProxy:

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.   :-\

Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mt on September 02, 2022, 12:58:07 PM
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.
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mzurhorst on September 02, 2022, 03:33:19 PM
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.
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: Patrick M. Hausen on September 02, 2022, 03:43:22 PM
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.
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mzurhorst on September 03, 2022, 08:57:02 AM
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)


Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: Patrick M. Hausen on September 03, 2022, 12:31:51 PM
Jag doch alles, auch von innen, durch den Proxy mit Letsencrypt. Das schadet doch nicht.
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mzurhorst on September 04, 2022, 01:36:59 PM
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.

Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: Patrick M. Hausen on September 04, 2022, 03:08:21 PM
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  ;)
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mzurhorst on September 05, 2022, 11:03:32 PM
Mal ganz langsam zum Mitmeißeln, weil ich hier langsam verrückt werde.
Ich habe eingerichtet:

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:


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:

Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: JeGr on September 08, 2022, 02:49:24 PM
@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 :)
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: Patrick M. Hausen on September 08, 2022, 04:52:55 PM
@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
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mt on September 09, 2022, 05:53:04 PM
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.
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mt on September 09, 2022, 06:10:11 PM
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.
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: Patrick M. Hausen on September 09, 2022, 06:16:58 PM
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 ;)
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mzurhorst on September 11, 2022, 12:07:04 PM
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:


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.
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: JeGr on September 13, 2022, 12:31:19 PM
> 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
Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mzurhorst on December 22, 2022, 07:30:08 PM
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:


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





Title: Re: Fragen zu Letsencrypt, FQDNs, HA Proxy
Post by: mzurhorst on January 02, 2023, 04:06:38 PM
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:


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