Post #1137388
2026-04-13 12:23 UTC
Replies (9)
-
@tobybaier@chaos.social 2026-04-13 15:52
update: liegt weder an Caddy noch an Docker oder letsencrypt. Mein DynDNS setup scheint kaport.
-
@Nfoonf@chaos.social 2026-04-13 12:27
@tobybaier hast du ein docker compose setup oder wahlweise den aufruf, mit dem du das alles startest? Ich mach sowas den ganzen tag, ich kann mal draufschauen.
-
@telebumm@metalhead.club 2026-04-13 12:45
@tobybaier herumvermut: du hast noch etwas installiert, das dir Port 80 klaut und schneller atartet
-
@komamuffin@mastodon.world 2026-04-13 12:46
@tobybaier hast du einen eigenen DNS Server? Da ging mal deswegen nicht die challenge durch. Vllt 9.9.9.9 als DNS im Docker compose Network?
-
@laon@ruhr.social 2026-04-13 12:51
@tobybaier ich selber nutzt traefik statt caddy. Dort muss bei der http-challenge /.well-known/… auf Port 80 freigegeben sein - ich mache das dann zeitweise, wenn das SSL-Zert erneuert werden muss. Bei traefik kann man mit ionos (und anderen dns anbietern) sonst auch die dns-challenge nutzen, dann muss port 80 nicht freigeben sein. Das ist mittlerweile mein bevorzugter weg.
-
@dns13@chaos.social 2026-04-13 12:52
@tobybaier wenn Port 80 nie erreichbar war, wie läuft die letsencrypt challenge ab? Hat sich da vielleicht die Konfiguration verschluckt und statt DNS request wird jetzt wieder http versucht?
-
@eNBeWe@chaos.social 2026-04-13 13:34
@tobybaier Wenn 80 nie erreichbar war, hat caddy bisher vermutlich via TLS-ALPN Challenge mit Letsencrypt geredet. Wenn er jetzt 80 haben will, muss er auf klassische HTTP Challenge runtergefallen sein. Warum? Kein Plan...
-
@rodirik@norden.social 2026-04-13 13:37
@tobybaier Caddy muss über Port 80 erreichbar sein, sonst funktioniert die Let's Encrypt ACME Challenge nicht.
-
@vivante@techhub.social 2026-04-14 16:21
@tobybaier ins Blaue hinein: Kurz gesagt: ja – da hat sich ziemlich sicher was geändert. Dein Fehler passt sehr gut zu einer Änderung bzw. strengeren Durchsetzung bei Let's Encrypt?