Text only | Text with Images

OPNsense Forum

International Forums => German - Deutsch => Topic started by: Anderer on October 01, 2025, 10:20:11 PM

Title: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 01, 2025, 10:20:11 PM
Guten Abend zusammen,

für Nextcloud AIO wollte ich HAProxy als Reverse Proxy mit Wildcard-Zertifikat von Let's Encrypt und "SUBDOMAIN.dedyn.io" von deSEC installieren. Vorgehen analog Tutorial mit Adaption an aktuelle Felder und Einstellungen:
https://forum.opnsense.org/index.php?topic=23339.0

A) Plugin-Installation
B) DynDNS configuration
        => Verlust: 100%, Fehler: sendto: Host is down

Ich habe dann zunächst lange gesucht und dann versucht, HAProxy zu konfigurieren, aber es blieb - vermutlich - bei diesem Fehler.


Nachfolgend noch meine Konfiguration (anonymisiert), Protokoll und Topologie.

Dankeschön & herzliche Grüße,

Rico

Dienste: HAProxy: Konfigurationsexport

Code Select
[pre]#
# Automatically generated configuration.
# Do not edit this file manually.
#
global
    uid                         80
    gid                         80
    chroot                      /var/haproxy
    daemon
    stats                       socket /var/run/haproxy.socket group proxy mode 775 level admin
    nbthread                    6
    hard-stop-after             60s
    no strict-limits
    maxconn                     10000
    ocsp-update.mindelay 300
    ocsp-update.maxdelay 3600
    httpclient.resolvers.prefer   ipv4
    tune.ssl.default-dh-param   4096
    spread-checks               2
    tune.bufsize                16384
    tune.lua.maxmem             0
    log                         /var/run/log local0 info
    lua-prepend-path            /tmp/haproxy/lua/?.lua
defaults
    log     global
    option redispatch -1
    maxconn 5000
    timeout client 30s
    timeout connect 30s
    timeout server 30s
    retries 3
    default-server init-addr last,libc
    default-server maxconn 50000
# autogenerated entries for ACLs
# autogenerated entries for config in backends/frontends
# autogenerated entries for stats
# Frontend: 0_SNI_frontend (Listening on 0.0.0.0:80, 0.0.0.0:443)
frontend 0_SNI_frontend
    bind 0.0.0.0:443 name 0.0.0.0:443
    bind 0.0.0.0:80 name 0.0.0.0:80
    mode tcp
    default_backend SSL_backend
    # logging options
# Frontend: 1_HTTP_frontend (Listening on 127.4.4.3:80)
frontend 1_HTTP_frontend
    bind 127.4.4.3:80 name 127.4.4.3:80 accept-proxy
    mode http
    option http-keep-alive
    default_backend Fallback_Backend
    # logging options
    # ACL: NoSSL_condition
    acl acl_74z5hhgd42d038.47994567 ssl_fc
    # ACTION: HTTPtoHTTPS_rule
    http-request redirect scheme https code 301 if !acl_74z5hhgd42d038.47994567
# Frontend: 1_HTTPS_frontend (Listening on 127.4.4.3:443)
frontend 1_HTTPS_frontend
    http-response set-header Strict-Transport-Security "max-age=6307200; includeSubDomains; preload"
    bind 192.168.50.1:443 name 192.168.50.1:443 accept-proxy ssl curves secp384r1  ssl-min-ver TLSv1.3 ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 alpn h2,http/1.1 crt-list /tmp/haproxy/ssl/74z5hhgd42d038.47994567.certlist
    mode http
    option http-keep-alive
    default_backend Fallback_Backend
    # logging options
    # ACL: PUBLIC_SUBDOMAINS_condition
    acl acl_74z5hhgd42d038.47994567 hdr_reg(host) -i .*\.SUBDOMAIN\.dedyn\.io
    # ACTION: PUBLIC_SUBDOMAINS_rule
    use_backend %[req.hdr(host),lower,map_dom(/tmp/haproxy/mapfiles/4z5hhgd42d038.47994567.txt)] if acl_74z5hhgd42d038.47994567.53560960
# Backend: SSL_backend (Backend für SSL Offloading)
backend SSL_backend
    # health checking is DISABLED
    mode tcp
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    server SSL_server 127.4.4.3:443 send-proxy-v2 check-send-proxy
# Backend: Nextcloud_Backend (Backend für Nextcloud Service)
backend Nextcloud_Backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    http-reuse safe
    server Nextcloud_Server 192.168.50.48:8080
# Backend: Fallback_Backend (Fallback Backend, falls Subdomain nicht vorhanden ist)
backend Fallback_Backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    http-reuse safe
    server Fallback_Server 127.4.4.3:80
# Backend: UgreenNAS_Backend (Backend für UGREEN DXP480T Plus)
backend UgreenNAS_Backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    http-reuse safe
    server UgreenNAS_Server 192.168.50.48:9443 ssl alpn h2,http/1.1 verify none
# Backend: OPNsense_Backend (Backend für OPNsense Mini-PC)
backend OPNsense_Backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    http-reuse safe
    server OPNsense_Server 192.168.50.1:55443 ssl alpn h2,http/1.1 verify none
# Backend: AsusRouter_Backend (Backend für ASUS GT-BE98)
backend AsusRouter_Backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    http-reuse safe
    server AsusRouter_Server 192.168.50.2:8398 ssl alpn h2,http/1.1 verify none
# statistics are DISABLED[/pre]





Dienste: HAProxy: Protokolldatei
=> hat immer wieder den gleichen Eintrag mit unterschiedlichen "from" Ports - sonst alles gleich.
Code Select
2025-10-01T22:04:52
Informational
haproxy
Connect from 127.4.4.3:35006 to 127.4.4.3:443 (0_SNI_frontend/TCP)


Topologie:

Code Select
WAN / Internet                        Telekom
     |
     |      VDSL
     |
   .-+-------------.
   |   FritzBox    |                   172.168.178.1      Modem
   '-+-------------'
     |
     |     WiFi-5
     |
   .-+-------------.
   | FritzRepeater |                   172.168.178.17     Access-Point
   '-+-------------'
     |
     |     1G LAN
     |
   .-+-------------.                .- 172.168.178.5      Exposed Host
   |   OPNsense    |                |
   '-+-------------'                '- 172.168.50.1/24    FW, DHCP-Server, später: VPN, Reverse Proxy
     |
     |   2.5G LAN
     |
   .-+-----+-------.
   | ASUS GT-BE98  |                   172.168.50.2       Access-Point, keine FW, kein DHCP-Server, kein VPN
   '-++++----------'
     ||||
     |||| 10G LAN
     ||||           .---------------.
     |||+-----------+ DXP-480T NAS  |  172.168.50.48      Netzlaufwerke, Nextcloud, Home Assistant etc.
     |||            '---------------'
     |||  10G LAN
     |||            .---------------.
     ||+------------+   Notebook    |  172.168.50.4       Windows 11
     ||             '---------------'
     ||  2.5G LAN
     ||             .---------------.
     |+-------------+    Clients    |  172.168.50.x       Mini PC, Notebook, NAS
     |              '---------------'
     |     WiFi-7
     |              .---------------.
     +--------------+    Clients    |  172.168.50.x       Tablet, Notebook, Smartphones, IoT (später: VLAN)
                    '---------------'


Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 03, 2025, 02:20:17 PM
OK, es gab 2 A records. Nachdem Löschen des A records mit Wildcard, konnte ich CNAME mit Wildcard anlegen. Leider bleibe ich trotzdem bei 9.) hängen, da OPNsense > Schnittstellen > Diagnose > Ping > SUBDOMAN.dedyn.io (mit oder ohne "any_string") nicht auflöst, sondern weiterhin 100% Verlust, sendto: Host is down.

https://dnschecker.org/#CNAME mit any_string.SUBDOMAIN.dedyn.io zeigt propagated, aber nur SUBDOMAIN.dydyn.io (ohne any_string) ist nicht propagated. Ich nehme an, dass das korrekt ist, oder nicht?

https://dnschecker.org löst mit Erfolg zur korrekten IP auf.

https://www.ssllabs.com/ssltest/analyze.html löst zur korrekten IP auf, aber scheitert beim SSL Zertifikat.

https://www.ssllabs.com/ssltest/analyze.html scheitert, während
https://crt.sh/ die crt.sh.IDs mit korrektem Erstell- und Verfallsdaten zeigt.
=> mit Klick auf crt.sh.ID Link, sehe ich Details, wie Serial Number, Public Key, DNS usw. sowie:
OCSP check => mit Klick: No OCSP URL available
CRL, CRLSet, disallowedcert, OneCRL - all "Not Revoked".

OPNsense > Schnittstellen > Diagnose > Ping > SUBDOMAIN.dedyn.io (mit oder ohne any_string) weiterhin 100% Verlust, sendto: Host is down

Liegt das an der HAProxy Konfiguration oder müsste es zuvor noch einen Fehler geben, da bei 9.) der Ping-Test auflösen müsste?

Ping 8.8.8.8 führt ebenfalls zu 100% Verlust, sendto: Host is down, obwohl
Firewall: Protokolldateien: Liveansicht zeigt GRÜN:
WAN   192.168.178.5:5993   8.8.8.8:53   udp   let out anything from firewall host itself (force gw)
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: viragomann on October 03, 2025, 03:19:33 PM
Quote from: Anderer on October 01, 2025, 10:20:11 PMVorgehen analog Tutorial mit Adaption an aktuelle Felder und Einstellungen:
https://forum.opnsense.org/index.php?topic=23339.0 (https://forum.opnsense.org/index.php?topic=23339.0)
Das hatte ich mir auch durchgesehen, hatte es aber nicht so gelöst.
Einen Sinn des TCP frontends konnte ich für mich nicht erkennen.
Ich habe eines, das auf Port 80 lauscht und jegliche Anfragen auf https redirektet, und mehrer auf Port 443.

Mir fällt dazu in deiner HAproxy Konfig auf, dass da beim Frontend: 1_HTTPS_frontend zwar "(Listening on 127.4.4.3:443)" in der Bezeichnung seht, die Bind Adresse aber tatsächlich 192.168.50.1 ist.
Aber wie gesagt, mit diesem Konfigurationsvorschlag habe ich mich nicht auseinandergesetzt.

Quote from: Anderer on October 03, 2025, 02:20:17 PMaber nur SUBDOMAIN.dydyn.io (https://subdomain.dydyn.io/) (ohne any_string) ist nicht propagated. Ich nehme an, dass das korrekt ist, oder nicht?
Ist wohl auch keine CNAME, oder?

Quote from: Anderer on October 03, 2025, 02:20:17 PMhttps://www.ssllabs.com/ssltest/analyze.html (https://www.ssllabs.com/ssltest/analyze.html) scheitert, während
https://crt.sh/ (https://crt.sh/) die crt.sh.IDs mit korrektem Erstell- und Verfallsdaten zeigt.
=> mit Klick auf crt.sh.ID (https://crt.sh.id/) Link, sehe ich Details, wie Serial Number, Public Key, DNS usw. sowie:
OCSP check => mit Klick: No OCSP URL available
CRL, CRLSet, disallowedcert, OneCRL - all "Not Revoked".

Das heißt, die Analyze bricht komplett ab?
Dann würde ich vermuten, dass der Host keine Zertifikat liefert. Zeigt SSLLabs eines an?

Quote from: Anderer on October 03, 2025, 02:20:17 PMOPNsense > Schnittstellen > Diagnose > Ping > SUBDOMAIN.dedyn.io (https://subdomain.dedyn.io/) (mit oder ohne any_string) weiterhin 100% Verlust, sendto: Host is down
Liegt das an der HAProxy Konfiguration oder müsste es zuvor noch einen Fehler geben, da bei 9.) der Ping-Test auflösen müsste?
Ping müsstest du am WAN mit einer FW-Regel erlauben.
HAproxy lauscht auf einen oder mehrer Ports. Ping (ICMP) kennt keine Ports. Pings landen demnach nicht auf HAproxy.

Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: meyergru on October 03, 2025, 04:01:57 PM
Man kann keine ACME Wildcard-Zertifikate für Subdomains erstellen - so einfach ist das.

Schaut mal in die Vergaberichtlinien.
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 03, 2025, 05:04:54 PM
Quote from: viragomann on October 03, 2025, 03:19:33 PMMir fällt dazu in deiner HAproxy Konfig auf, dass da beim Frontend: 1_HTTPS_frontend zwar "(Listening on 127.4.4.3:443)" in der Bezeichnung seht, die Bind Adresse aber tatsächlich 192.168.50.1 ist.
Das ist richtig. Danke. Ich hatte es geändert, um zu testen, wenn direkt auf OPNsense umgeleitet wird. Es ändert jedoch nichts, wenn ich zwischen den beiden IP wechsle.

Quote from: viragomann on October 03, 2025, 03:19:33 PMDas heißt, die Analyze bricht komplett ab?
Dann würde ich vermuten, dass der Host keine Zertifikat liefert. Zeigt SSLLabs eines an?
SSLLabs schreibt 2x  Unable to connect to the server
Ich vermute, dass ich gar nicht so weit komme, da der Ping schon nicht funktioniert.

Quote from: viragomann on October 03, 2025, 03:19:33 PMPing müsstest du am WAN mit einer FW-Regel erlauben.
HAproxy lauscht auf einen oder mehrer Ports. Ping (ICMP) kennt keine Ports. Pings landen demnach nicht auf HAproxy.
Ich habe zunächst noch eine ICMP Regel eingerichtet und dann testweise WAN, incoming, pass, komplett freigegeben. Im Log ist jetzt auch alles grün - keine rote Zeile mehr, z. B. für Ping 8.8.8.8:
Ping geht trotzdem nicht.100% Verlust, sendto: Host is down
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: viragomann on October 03, 2025, 05:18:07 PM
Deine OPNsense sitzt demnach ja hinter einem anderen Router. Ist da alles weitergeleitet, was du testest, also hier mal ICMP und TCP 80 u. 443?

Wenn ja, geh mal auf Interfaces: Diagnostics: Packet Capture, selektiere WAN Interface und ICMP Protokoll, ggf. setze noch deine Quell-IP bei Host und starte das Capture.
Dann starte einen Ping und schau anschließend, ob da Pakete zu sehen sind.

Ich nehme an, du pingst aus dem Internet.

Wenn da nichts ist, hat es was mit der Weiterleitung, oder du bekommst schon von deinem ISP nichts weitergeleitet.
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 03, 2025, 05:19:06 PM
Quote from: meyergru on October 03, 2025, 04:01:57 PMMan kann keine ACME Wildcard-Zertifikate für Subdomains erstellen - so einfach ist das.
Danke für den Hinweis, aber mir mangelt es am Verständnis für die Umsetzung.
Im Tutorial wird das Wildcard Zertificat mit CNAME record empfohlen:
https://forum.opnsense.org/index.php?topic=23339.0 (https://forum.opnsense.org/index.php?topic=23339.0)

Quote
  • Why are we using wildcard certificates and not just regular certificates?
    For me the main reason is simplicity, there is no need to set up multiple certificates for multiple subdomains.
    Also you don't need to add any rules in HAProxy or your firewall for the ACME plugin to function correctly as the DNS challenge doesn't need this.
    If you want to read more about the differences follow the links below.
    https://sectigostore.com/page/ssl-vs-wildcard-ssl-certificate/ (https://sectigostore.com/page/ssl-vs-wildcard-ssl-certificate/)
    https://comodosslstore.com/resources/whats-the-difference-wildcard-certificate-vs-regular-ssl-certificate/ (https://comodosslstore.com/resources/whats-the-difference-wildcard-certificate-vs-regular-ssl-certificate/)

In deinem Kommentar vom 29.09.25 lese ich ebenfalls heraus:
https://forum.opnsense.org/index.php?topic=23339.msg248393;topicseen#msg248393 (https://forum.opnsense.org/index.php?topic=23339.msg248393;topicseen#msg248393)
QuoteAlso, you can (and should) use wildcard certificates if ever possible, because named certificates will be published and can be used to scan for IPv6-based services where a normal port scan is infeasible.

Ich habe jetzt einen CNAME record mit Wildcard auf SUBDOMAIN.dedyn.io sowie CAA mit issue und issuewild "letsencrypt.org". Falls das gar nicht geht, aber sinnvoll ist, könnte ich auch eine eigene Domain dafür nehmen, aber mit dedyn.io war es im Tutorial beschrieben.

Ich vermute allerdings, dass noch ein ganz anderes Problem zugrunde liegt, da auch Ping 8.8.8.8 nicht möglich ist, obwohl das FW-Log nun nur noch grüne Zeilen hat.
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 03, 2025, 05:37:04 PM
Quote from: viragomann on October 03, 2025, 05:18:07 PMDeine OPNsense sitzt demnach ja hinter einem anderen Router. Ist da alles weitergeleitet, was du testest, also hier mal ICMP und TCP 80 u. 443?
In der FritzBox ist "Exposed Host" eingestellt, aber fritz.box oder 192.168.178.1 erreiche ich ebenfalls nichtmehr, obwohl das FW-Log auch hier grün ist:
Quote from: viragomann on October 03, 2025, 05:18:07 PMWenn ja, geh mal auf Interfaces: Diagnostics: Packet Capture, selektiere WAN Interface und ICMP Protokoll, ggf. setze noch deine Quell-IP bei Host und starte das Capture.
Dann starte einen Ping und schau anschließend, ob da Pakete zu sehen sind.
Bei Schnittstellen: Diagnose: Paketaufzeichnung kommt gar kein Eintrag, selbst wenn ich WAN+LAN auswähle sowie Adressfamilie und Protokoll beliebig. Ich habe dann Schnittstellen: Diagnose: Ping 8.8.8.8 getestet, Webseiten aufgerufen und Ping über CMD und über wieistmeineip.de getestet.

Quote from: viragomann on October 03, 2025, 05:18:07 PMWenn da nichts ist, hat es was mit der Weiterleitung, oder du bekommst schon von deinem ISP nichts weitergeleitet.
Ping-Test über wieistmeineip.de ist grün und bei cmd vom Notebook bekomme ich:
Code Select
Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Antwort von 8.8.8.8: Bytes=32 Zeit=11ms TTL=119
Antwort von 8.8.8.8: Bytes=32 Zeit=12ms TTL=119
Antwort von 8.8.8.8: Bytes=32 Zeit=11ms TTL=119
Antwort von 8.8.8.8: Bytes=32 Zeit=11ms TTL=119

Ping-Statistik für 8.8.8.8:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 11ms, Maximum = 12ms, Mittelwert = 11ms

Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: viragomann on October 03, 2025, 05:58:38 PM
Quote from: Anderer on October 03, 2025, 05:37:04 PMIn der FritzBox ist "Exposed Host" eingestellt, aber fritz.box (https://fritz.box/) oder 192.168.178.1 erreiche ich ebenfalls nichtmehr, obwohl das FW-Log auch hier grün ist:
    • LAN2025-10-03T17:20:19192.168.50.4:57262192.168.178.1:80tcplet out anything from firewall host itself
    • LAN2025-10-03T17:20:12192.168.50.1:58177192.168.178.1:53udplet out anything from firewall host itself
    • WAN2025-10-03T17:20:20192.168.178.5:214034.999.8.122:443tcplet out anything from firewall host itself (force gw)
    • WAN2025-10-03T17:20:20192.168.178.5:6548552.19.999.51:443tcplet out anything from firewall host itself (force gw)
Das sollte schon funktionieren.

Allerdings gehen die Pakete bei dir offenbar LAN Interface ruas, wie die ersten beiden Regeln zeigen. Die FritzBox hängt doch am WAN?
Ich frag mich auch, wo sie reinkommen.
Vielleicht solltest du mal deine Routingtabelle offenbaren.

Quote from: Anderer on October 03, 2025, 05:37:04 PMPing-Test über wieistmeineip.de (https://wieistmeineip.de/) ist grün
Bei mir auch, allerdings habe ich keine ICMP von außen erlaubt und das Firewall Log zeigt die Pings auch als geblockt. Die OPNsense hat selbt die öffentliche IP am WAN.
Da frag ich mich, wie die zu dem erfreulichen Ergebnis kommen.[/list]
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 03, 2025, 06:47:16 PM
Quote from: viragomann on October 03, 2025, 05:58:38 PMAllerdings gehen die Pakete bei dir offenbar LAN Interface ruas, wie die ersten beiden Regeln zeigen. Die FritzBox hängt doch am WAN?
Ich frag mich auch, wo sie reinkommen.
OPNsense hängt mit Sicherheit über WAN (igc0) an der FritzBox und am LAN (igc1) hängt der ASUS Router, an dem alle Clients hängen. So sind auch die LAN-Kabel eingesteckt. Das habe ich gerade nochmals überprüft.


Quote from: viragomann on October 03, 2025, 05:58:38 PMVielleicht solltest du mal deine Routingtabelle offenbaren.
Schnittstellen: Diagnose: Routenverfolgung 8.8.8.8, IPv4, UDP (ICMP analog) ergibt:
 traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets traceroute: sendto: Host is down..., timeout reached

Es sei nochmals erwähnt, dass ich Newbie bin und OPNsense auf einem neuen Mini-PC frisch installiert habe. Ich kann mit den FW-Regeln jetzt normal arbeiten (Internet, E-Mails etc.). Ich erreiche OPNsense, den ASUS Router, NAS und Clients, aber nicht fritz.box oder fritz.repeater - auch nicht über deren IP. Ich kann - meine ich - zu Testzwecken, die Regeln komplett öffnen, damit dort nichts hängen bleibt. Falls aber noch eine Verbindung, Mapping, Regel o. ä. fehlt, welche das Tutorial für HAProxy voraussetzt, dann weiß ich vermutlich garnicht, auf was ich schauen oder wonach ich suchen soll.


Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: viragomann on October 03, 2025, 07:23:00 PM
Quote from: Anderer on October 03, 2025, 06:47:16 PMOPNsense hängt mit Sicherheit über WAN (igc0) an der FritzBox und am LAN (igc1) hängt der ASUS Router, an dem alle Clients hängen. So sind auch die LAN-Kabel eingesteckt. Das habe ich gerade nochmals überprüft.
Viele Router für den Anfang.
Aber gut, wenn die OPNsense als Exposed Host an der FB hängt, sollte sie von außen erreichbar sein, sofern das überhaupt was reinkommt.
Hast du schon irgendwann mal erfolgreich Zugriff aus dem Internet auf dein Netzwerk gehabt?

Die Routing Tabelle ist über System: Routes: Status abrufbar.
Bitte auch die Gateway Konfiguration dazu: System: Gateways: Configuration

Mich stört das "let out anything from firewall host itself" im Regel-Log am LAN:
QuoteLAN      2025-10-03T17:20:19   192.168.50.4:57262   192.168.178.1:80   tcp   let out anything from firewall host itself

Was ist da die Quell-IP?
Wenn du die involvierten IPs erklären würdest, würde eine Analyse leichter fallen.

Ziel ist auf jeden Fall die FritzBox, und ein Paket zu dieser sollte nicht am LAN raus gehen, wenn sie am WAN angeschlossen ist.
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Patrick M. Hausen on October 03, 2025, 10:13:01 PM
Quote from: meyergru on October 03, 2025, 04:01:57 PMMan kann keine ACME Wildcard-Zertifikate für Subdomains erstellen - so einfach ist das.

Sehe ich anders. Ich habe hier aktive Wildcard-Zertifkate über Letsencrypt mit DNS-01 für:

- *.meinedomain.de
- *.meinwohnort.meinedomain.de

Läuft einwandfrei, zeige ich dir gerne beim nächsten Stammtisch 😉

Was nicht geht ist

- *.*.meinedomain.de

Die Wildcard umfasst immer nur genau eine Hierarchieebene.
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 03, 2025, 10:45:48 PM
Quote from: viragomann on October 03, 2025, 07:23:00 PMHast du schon irgendwann mal erfolgreich Zugriff aus dem Internet auf dein Netzwerk gehabt?
Nein, von außen komme ich nicht auf mein Netwerk, jedenfalls nicht z. B. auf den Router - selbst wenn ich LAN/WAN alles beliebig mit pass freigebe. Da gibt es wohl automatische Regeln (Default deny / state violation rule, Quellports: 39440, 80, Zielports: 443, 61855), die den Zugriff trotzdem blockieren. Die wollte oder kann ich nicht anfassen.

Mein angedachtes Vorgehen war auf OPNsense HAProxy und LE-Zertifikate einzurichten, dort dann auch Nextcloud AIO und danach Wireguard zu installieren, um von außen Zugriff zu bekommen. Im Anschluss sollten auch NAS, OPNsense und Router oder weitere Apps wie Home Assistant über VPN erreichbar sein. Bei HAProxy stecke ich aber schon fest.

Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 03, 2025, 10:52:04 PM
System: Routen: Status
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 03, 2025, 10:53:14 PM
System: Gateways: Konfiguration

Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 03, 2025, 10:57:54 PM
Quote from: viragomann on October 03, 2025, 07:23:00 PMMich stört das "let out anything from firewall host itself" im Regel-Log am LAN:

Firewall: Regeln: LAN
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 03, 2025, 10:58:39 PM
Firewall: Regeln: WAN

Firewall: Regeln: Global

Quote from: viragomann on October 03, 2025, 07:23:00 PMWas ist da die Quell-IP?
Wenn du die involvierten IPs erklären würdest, würde eine Analyse leichter fallen.
192.178.50.4 ist mein Windows-Notebook. Topologaie habe ich im Hauptbeitrag eingefügt. Andere IPs verwende ich von meiner Seite eigentlich nicht, außen zum Testen vom Mobilfunknetz aus - da hat mein Smartphone 192.178.50.175

Quote from: viragomann on October 03, 2025, 07:23:00 PMZiel ist auf jeden Fall die FritzBox, und ein Paket zu dieser sollte nicht am LAN raus gehen, wenn sie am WAN angeschlossen ist.
Kann es sein, dass die Pakete falsch gesteuert werden bzw. kann ich das nochmals zurücksetzen, da ich schon viel gesucht und womöglich auch etwas verstellt habe, als ich gleich zu Beginn wegen einer falschen Einstellung bei der WAN-Schnittstelle nicht ins Internet kam?
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: viragomann on October 03, 2025, 11:01:21 PM
Sieht aus, als ob du in den LAN Interface Einstellungen die FritzBox als Gateway angegeben hättest.
Am LAN ist kein Gateway zu setzen!
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 03, 2025, 11:10:54 PM
Quote from: viragomann on October 03, 2025, 11:01:21 PMSieht aus, als ob du in den LAN Interface Einstellungen die FritzBox als Gateway angegeben hättest.
Am LAN ist kein Gateway zu setzen!
Im LAN ist 192.168.50.1/24 (OPNsense) eingegeben. Regeln sind deaktiviert. FritzBox hat 192.168.178.1

Oder verstehe ich etwas falsch?

Eingesteckt ist FritzBox in Port 0 und ASUS Router in Port 1
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 03, 2025, 11:13:42 PM
System: Routen: Konfiguration
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: viragomann on October 03, 2025, 11:18:59 PM
In Interfaces: LAN
Bei dir wahrscheinlich Schnittstellen: LAN

Hast du da ein Gateway eingetragen??
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 03, 2025, 11:20:56 PM
Ist das der Fehler?

Aber wenn ich auf "Settings" gehe, dann steht dort nirgends die IP der FritzBox. Ich habe nochmals gespeichert und übernommen, aber die IP geht nicht weg...
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: viragomann on October 03, 2025, 11:23:13 PM
Da steht die FB IP bei WAN und bei LAN.
Nachdem du LAN statisch konfiguriert hast, musst du auch die Gateway IP manuell gestetzt haben.
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 03, 2025, 11:25:30 PM
Quote from: viragomann on October 03, 2025, 11:18:59 PMIn Interfaces: LAN
Bei dir wahrscheinlich Schnittstellen: LAN

Hast du da ein Gateway eingetragen??
Ich denke nicht.
Hier nochmals der gesamte Screen.
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: viragomann on October 03, 2025, 11:28:36 PM
Okay, dann ist es vermutlich in den System > Gateway Einstellungen zu finden. Dann kann es da einfach gelöscht werden.
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 03, 2025, 11:47:00 PM
Quote from: viragomann on October 03, 2025, 11:28:36 PMOkay, dann ist es vermutlich in den System > Gateway Einstellungen zu finden. Dann kann es da einfach gelöscht werden.
Ja, dort steht die IP drin, aber ich kann nicht speichern, nachdem sie gelöscht wurde.
Ich habe LAN_GW zunächst mal DEAKTIVIERT.


Wenn ich eine floating Regel in/out, pass, IPv4+6, beliebig zum Testen aktiviere, dann funktionieren alle PING (8.8.8.8 - SUBDOMAIN.dedyn.io oder any_string.SUBDOMAIN.dedyn.io

Wenn ich diese floating Regel aber deaktiviert lasse, ist wieder 100% Verlust, sendto: Host down, obwohl in FW-Live die 8.8.8.8 grün nach draußen im WAN steht.

Eine "Allow Ping" Regel hatte ich aber schon gesetzt:
pass, WAN, in, IPv4+6, ICMP, WAN Adresse, Rest *

In FW-Live sehe ich 192.168.178.5 (OPNsense im FritzBox Netzwerk) und 192.168.178.255 mehrfach blockiert:

WAN2025-10-03T23:37:25192.168.178.59:59624192.168.178.255:58866udpDefault deny / state violation rule
WAN2025-10-03T23:37:25199.21.149.124:41941192.168.178.5:60558tcpDefault deny / state violation rule
WAN2025-10-03T23:37:25104.255.154.159:41911192.168.178.5:50877tcpDefault deny / state violation rule
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: viragomann on October 04, 2025, 12:06:31 AM
Quote from: Anderer on October 03, 2025, 11:47:00 PMEine "Allow Ping" Regel hatte ich aber schon gesetzt:
pass, WAN, in, IPv4+6, ICMP, WAN Adresse, Rest
"WAN Adresse" ist da hoffentlich nicht als Quelle gesetzt?

Quote from: Anderer on October 03, 2025, 11:47:00 PMWenn ich eine floating Regel in/out, pass, IPv4+6, beliebig zum Testen aktiviere, dann funktionieren alle PING (8.8.8.8 - SUBDOMAIN.dedyn.io (https://subdomain.dedyn.io/) oder any_string.SUBDOMAIN.dedyn.io
Könnte bedeuten, dass die andere WAN Regel nicht zutrifft.

Quote from: Anderer on October 03, 2025, 11:47:00 PMIn FW-Live sehe ich 192.168.178.5 (OPNsense im FritzBox Netzwerk) und 192.168.178.255 mehrfach blockiert:

WAN2025-10-03T23:37:25192.168.178.59:59624192.168.178.255:58866udpDefault deny / state violation rule
WAN2025-10-03T23:37:25199.21.149.124:41941192.168.178.5:60558tcpDefault deny / state violation rule
WAN2025-10-03T23:37:25104.255.154.159:41911192.168.178.5:50877tcpDefault deny / state violation rule
192.168.178.5 sehe ich da nur als Ziel mit irgendwelchen Ports, du du wohl nicht erlaubt hast.
192.168.178.255 ist die Broadcast Adresse. Pakete an diese empfängt jedes Gerät im Subnetz.
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 04, 2025, 12:21:54 AM
Quote from: viragomann on October 04, 2025, 12:06:31 AM"WAN Adresse" ist da hoffentlich nicht als Quelle gesetzt?
Nein, WAN Adresse ist Ziel, aber ist das so richtig?
=> Firewall - Regel - WAN (Anhang)

Soll ich mal einen ganzen Screen von FW-Live anhängen, wenn Ping geblockt wird?
Sieht man dort, weshalb geblockt wird?
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: viragomann on October 04, 2025, 12:34:56 AM
Die Regel sieht gut aus.
Falls OPNsense das dennoch blockiert, wäre interessant, welche Regel dafür verantwortlich ist.

Dazu das Loggiing jeder Regel aktivieren und auch das der Standard Block-Regel in den erweiterten Firewall Einstellungen.
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 04, 2025, 01:06:11 AM
Quote from: viragomann on October 04, 2025, 12:34:56 AMDazu das Loggiing jeder Regel aktivieren und auch das der Standard Block-Regel in den erweiterten Firewall Einstellungen.
ich habe bei allen Regeln das Logging aktiviert und dann Ping 9.9.9.9 ausgeführt.

Quote from: viragomann on October 04, 2025, 12:34:56 AMFalls OPNsense das dennoch blockiert, wäre interessant, welche Regel dafür verantwortlich ist.
Kann man daraus erkennen, von welchen Regeln das kommt, oder was ich ändern müsste?

Ergänzung:
192.168.178.27 und  192.168.178.43 sind z. B. Saugroboter, die über WAN sicher blockiert werden sollen.
192.168.178.59 ist auch ein Saugroboter, aber nicht aktiv. Weshalb so viele Saugroboter in dem LAN sind, weiß ich nicht.
199.167.138.119 scheint ebenfalls ein LAN zu sein, aber nicht von mir!
=> Also eigentlich werden alle zurecht geblockt.

Ich sehe gar nicht, weshalb ICMP rausgeht, aber nicht mehr reinkommt. Das war mir nicht sofort klar.
Wie kann ich das bitte feststellen oder protokollieren? Ich habe nichts mehr gefunden.
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: viragomann on October 04, 2025, 01:21:16 AM
Quote from: Anderer on October 04, 2025, 01:06:11 AMKann man daraus erkennen, von welchen Regeln das kommt
Was kommt?

Die Blocks kann ich nicht zuordnen. Einer geht sufauf die OPNsense auf Port 39833, der mir nicht sagt. Die anderen gehen auf die Broadcast Adresse, die wie gesagt, jedes Gerät im Subnetz bekommt.
Offenbar hast du mehrere Geräte am WAN hängen.

Auf jeden Fall dürfe nichts favon zu einer bewusst initierten Verbindung gehören
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 04, 2025, 01:30:57 AM
OK, ich danke dir erstmal ganz herzlich!
Einen Fehler konnten wir immerhin eliminieren.

Vielleicht hat morgen noch jemand eine Idee, weshalb der PING nicht zurückkommt, obwohl ICMP rausgeht oder wie ich die Blockierung protokollieren kann, da sie durch meine offene floating Regel aufgehoben werden kann.

Das ist schon eine harte Nuss ;-)
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 05, 2025, 10:20:25 PM
Hallo zusammen,

ich brauche bitte nochmals Unterstützung (AcmeClient: domain validation failed (dns01)


ich komme nun immerhin bis zum Ende von Part 3, aber wenn das Zertifikat ausgestellt werden soll, sehe ich folgende Fehler:

Services: ACME Client: Log Files: System Log
Code Select
2025-10-05T21:46:54
opnsense
AcmeClient: validation for certificate failed: *.SUBDOMAIN.dedyn.io
2025-10-05T21:46:54
opnsense
AcmeClient: domain validation failed (dns01)
2025-10-05T21:46:54
opnsense
AcmeClient: AcmeClient: The shell command returned exit code '1': '/usr/local/sbin/acme.sh --issue --syslog 6 --log-level 1 --server 'letsencrypt_test' --dns 'dns_desec' --dnssleep '120' --home '/var/etc/acme-client/home' --cert-home '/var/etc/acme-client/cert-home/68e2b234sdfa93.975355095' --certpath '/var/etc/acme-client/certs/68e2b234sdfa93.975355095/cert.pem' --keypath '/var/etc/acme-client/keys/68e2b234sdfa93.975355095/private.key' --capath '/var/etc/acme-client/certs/68e2b234sdfa93.975355095/chain.pem' --fullchainpath '/var/etc/acme-client/certs/68e2b234sdfa93.975355095/fullchain.pem' --domain '*.SUBDOMAIN.dedyn.io' --days '60' --force --ocsp --keylength 'ec-384' --accountconf '/var/etc/acme-client/accounts/68e2b234sdfa93.975355095_stg/account.conf''
2025-10-05T21:46:19
opnsense
AcmeClient: validation for certificate failed: *.SUBDOMAIN.dedyn.io
2025-10-05T21:46:19
opnsense
AcmeClient: domain validation failed (dns01)
2025-10-05T21:46:19
opnsense
AcmeClient: AcmeClient: The shell command returned exit code '1': '/usr/local/sbin/acme.sh --issue --syslog 6 --log-level 1 --server 'letsencrypt_test' --dns 'dns_desec' --dnssleep '120' --home '/var/etc/acme-client/home' --cert-home '/var/etc/acme-client/cert-home/68e2b234sdfa93.975355095' --certpath '/var/etc/acme-client/certs/68e2b234sdfa93.975355095/cert.pem' --keypath '/var/etc/acme-client/keys/68e2b234sdfa93.975355095/private.key' --capath '/var/etc/acme-client/certs/68e2b234sdfa93.975355095/chain.pem' --fullchainpath '/var/etc/acme-client/certs/68e2b234sdfa93.975355095/fullchain.pem' --domain '*.SUBDOMAIN.dedyn.io' --days '60' --force --ocsp --keylength 'ec-384' --accountconf '/var/etc/acme-client/accounts/68e2b234sdfa93.975355095_stg/account.conf''
2025-10-05T21:46:15
opnsense
AcmeClient: using challenge type: deSEC_DNS-01
2025-10-05T21:46:15
opnsense
AcmeClient: account is registered: SUBDOMAIN.dedyn.io
2025-10-05T21:46:15
opnsense
AcmeClient: using CA: letsencrypt_test
2025-10-05T21:46:15
opnsense
AcmeClient: issue certificate: *.SUBDOMAIN.dedyn.io
2025-10-05T21:46:15
opnsense
AcmeClient: certificate must be issued/renewed: *.SUBDOMAIN.dedyn.io

Services: ACME Client: Log Files: ACME Log
Code Select
2025-10-05T21:46:54
acme.sh
[Sun Oct 5 21:46:54 CEST 2025] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
2025-10-05T21:46:54
acme.sh
[Sun Oct 5 21:46:54 CEST 2025] Please add '--debug' or '--log' to see more information.
}
"status": 403
"detail": "Error finalizing order :: OCSP must-staple extension is no longer available: see https://letsencrypt.org/2024/12/05/ending-ocsp",
"type": "urn:ietf:params:acme:error:unauthorized",
2025-10-05T21:46:54
acme.sh
[Sun Oct 5 21:46:54 CEST 2025] {
2025-10-05T21:46:54
acme.sh
[Sun Oct 5 21:46:54 CEST 2025] Signing failed. Finalize code was not 200.
2025-10-05T21:46:53
acme.sh
[Sun Oct 5 21:46:53 CEST 2025] Le_OrderFinalize='https://acme-staging-v02.api.letsencrypt.org/acme/finalize/232344743/27443256063'
2025-10-05T21:46:53
acme.sh
[Sun Oct 5 21:46:53 CEST 2025] Let's finalize the order.
2025-10-05T21:46:53
acme.sh
[Sun Oct 5 21:46:53 CEST 2025] Verification finished, beginning signing.
2025-10-05T21:46:53
acme.sh
[Sun Oct 5 21:46:53 CEST 2025] Successfully removed
2025-10-05T21:46:53
acme.sh
[Sun Oct 5 21:46:53 CEST 2025] Deleted, OK
2025-10-05T21:46:53
acme.sh
[Sun Oct 5 21:46:53 CEST 2025] Deleting record
2025-10-05T21:46:53
acme.sh
[Sun Oct 5 21:46:53 CEST 2025] Using desec.io api
2025-10-05T21:46:53
acme.sh
[Sun Oct 5 21:46:53 CEST 2025] Removing txt: SuOBv0föladikf7o7ß0öajkdfadfr4qr4IfcQzdr97Uc for domain: _acme-challenge.SUBDOMAIN.dedyn.io
2025-10-05T21:46:53
acme.sh
[Sun Oct 5 21:46:53 CEST 2025] Removing DNS records.
2025-10-05T21:46:53
acme.sh
[Sun Oct 5 21:46:53 CEST 2025] Success
2025-10-05T21:46:50
acme.sh
[Sun Oct 5 21:46:50 CEST 2025] Pending. The CA is processing your order, please wait. (24/30)
2025-10-05T21:46:48
acme.sh
...
[Sun Oct 5 21:46:18 CEST 2025] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
2025-10-05T21:46:18
acme.sh
[Sun Oct 5 21:46:18 CEST 2025] Please add '--debug' or '--log' to see more information.
2025-10-05T21:46:18
acme.sh
[Sun Oct 5 21:46:18 CEST 2025] Error adding TXT record to domain: _acme-challenge.SUBDOMAIN.dedyn.io
2025-10-05T21:46:18
acme.sh
[Sun Oct 5 21:46:18 CEST 2025] Add txt record error.
2025-10-05T21:46:18
acme.sh
[Sun Oct 5 21:46:18 CEST 2025] Adding record
2025-10-05T21:46:18
acme.sh
[Sun Oct 5 21:46:18 CEST 2025] Pending. The CA is processing your order, please wait. (12/30)
2025-10-05T21:46:18
acme.sh
[Sun Oct 5 21:46:18 CEST 2025] Using desec.io api
2025-10-05T21:46:18
acme.sh
[Sun Oct 5 21:46:18 CEST 2025] Adding TXT value: SuOBv0föladikf7o7ß0öajkdfadfr4qr4IfcQzdr97Uc for domain: _acme-challenge.SUBDOMAIN.dedyn.io
2025-10-05T21:46:18
acme.sh
[Sun Oct 5 21:46:18 CEST 2025] Getting webroot for domain='*.SUBDOMAIN.dedyn.io'
2025-10-05T21:46:16
acme.sh
[Sun Oct 5 21:46:16 CEST 2025] Single domain='*.SUBDOMAIN.dedyn.io'
2025-10-05T21:46:16
acme.sh
[Sun Oct 5 21:46:16 CEST 2025] Using CA: https://acme-staging-v02.api.letsencrypt.org/directory
2025-10-05T21:46:16
acme.sh
[Sun Oct 5 21:46:16 CEST 2025] Pending. The CA is processing your order, please wait. (11/30)
2025-10-05T21:46:13
acme.sh
...
[Sun Oct 5 21:45:49 CEST 2025] Verifying: *.SUBDOMAIN.dedyn.io

Dankeschön :-)

Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 05, 2025, 10:59:47 PM
[SOLVED]

OK, hier lag wohl der Fehler:

Services: ACME Client: Log Files: ACME Log
Code Select
"status": 403
"detail":
 "Error finalizing order :: OCSP must-staple extension is no longer
available: see https://letsencrypt.org/2024/12/05/ending-ocsp",
"type": "urn:ietf:params:acme:error:unauthorized",

OSCP Must Staple: Yes [ist falsch im Tutorial beschrieben, da heute in der Konfiguration nicht mehr gültig.]

Quote from: TheHellSite on May 31, 2021, 01:06:11 PMNext go to: Services --> ACME Client --> Certificates
Add the certificate for your domain according to the image below.
I prefer to use Elliptic Curve Cryptography (ECC). (https://en.wikipedia.org/wiki/Elliptic-curve_cryptography (https://en.wikipedia.org/wiki/Elliptic-curve_cryptography))
But you can of course also use RSA keys just make sure to set the key length as high as possible in order to get an A+ rating from SSLLabs.

LÖSUNG:
OSCP Must Staple: No

Danach funktionierte es sofort.

Ich werde die Fehlermeldung und Lösung auch beim Tutorial kommentieren. Morgen geht's weiter mit Part 4)
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Patrick M. Hausen on October 06, 2025, 12:31:27 AM
👍
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: Anderer on October 06, 2025, 02:25:09 PM
[SOLVED] Um den Beitrag noch kurz abzuschließen:


WICHTIG war, wirlich extrem strikt nach dem Tutorial vorzugehen. Das ist nicht immer einfach, da mehrfach einige Felder dazugekommen sind und andere Felder gefehlt hatten. Falls etwas nicht funktionierte > einen Schritt zurück > Einstellungen anpassen > nochmals (aus-)probieren, ABER: möglichst ohne andere Einstellungen zu ändern und vor allem: KEINE zusätzlichen Firewall-Regeln o. ä., denn das ist nicht notwendig.

ERGEBNIS:

Weiteres Vorgehen:

Herzlichen Dank nochmals an TheHellSite (https://forum.opnsense.org/index.php?action=profile;u=28778) für das Tutorial und ganz herzlichen Dank an alle, die mich mit Hinweisen, Ideen und Ratschlägen unterstützt haben. Ohne diese Fehler und Irrwege sowie die Unterstützung anderer, war es als Newbie wohl kaum möglich ;-)

Merci
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: JeGr on October 21, 2025, 11:57:57 AM
Quote from: meyergru on October 03, 2025, 04:01:57 PMMan kann keine ACME Wildcard-Zertifikate für Subdomains erstellen - so einfach ist das.

Da das noch so im Raum stand und ich das noch anhängen wollte nach dem Durchlesen des Threads hier:

Doch. Keine Ahnung wo du das hernimmst, dass das nicht erlaubt wäre. Natürlich darf ich ein Wildcard für eine Subdomain erstellen. Haben wir mehrfach im Einsatz. Bspw. für sowas wie "*.dev.domain.tld". Das wäre ja sehr bescheuert, wenn man nur Wildcards auf erster Ebene aber nicht auf höheren erstellen dürfte ;)
Und dedyn hält sich da komplett an den Standard und erlaubt das auch. Das war lediglich ein Knoten in der Konfig, aber können, tut es sowohl Dedyn/deSec als auch ACME. :)

Cheers!
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: meyergru on October 21, 2025, 12:20:10 PM
Hatte Patrick schon gesagt. Ihr habt Recht, allerdings ist das mit DDNS-Domains oft ein Problem, weil man den DNS nicht vollkommen kontrollieren kann (z.B. nur A- und AAAA-Records eintragen).
Title: Re: RRset Konflikt (CAA + CNAME) bei HAProxy mit LE Wildcard von deSEC / dedyn.io
Post by: JeGr on October 21, 2025, 02:53:07 PM
Quote from: meyergru on October 21, 2025, 12:20:10 PMHatte Patrick schon gesagt. Ihr habt Recht, allerdings ist das mit DDNS-Domains oft ein Problem, weil man den DNS nicht vollkommen kontrollieren kann (z.B. nur A- und AAAA-Records eintragen).

Stimmt, wenn Peter und sein Team bei deSec/dedyn nicht genau deshalb ihren Dienst dafür getrimmt hätten ;) Darum wollte ich das nochmal kurz anhängen, sollte es jemand via Suche o.ä. finden, dass das durchaus geht und bei dedyn/deSEC auch kein Thema ist. Die legen da sehr viel Wert drauf, einen sauberen und funktionalen DNS zu haben der DNSSEC bis oben spricht. :)
Text only | Text with Images