A Caddy Cert Expired Because Systemd-Resolved Was Selectively Broken

farfatched

There was interesting commentary on https://lobste.rs/s/z0ozbb/caddy_cert_expired_because_system...

eqvinox

There's this adage about consuming whatever newspaper reporting, everything seems fine and dandy, until one day they report on something in your field. Say, chemistry, and you're a chemist, and... it's all wrong. Even the basics. My field is networking, roughly from Ethernet physicals to TCP/UDP. systemd has no f*cking clue what they're doing on networking . You need to not use systemd-resolved, and not use systemd-networkd or systemd-timesyncd either. I really hope they are service manager people and know how to write a service manager, and I have no counterindications on that. But don't let them touch your networking, aside from service-managing on that. (My recommendation for DNS - on servers - would be to install unbound locally and use that. It's not great for clients since it doesn't deal well with frequently changing network connectivity, or rather, it does, but only if you restart it on network attachment change, which implies flushing all cached data.)

gucci-on-fleek

What's the server's hostname? If it's the same as the domain that's not working, perhaps you're running into this bug [0]? If that's the case, then adding # /etc/systemd/system/systemd-resolved.service.d/override.conf [Service] Environment=SYSTEMD_RESOLVED_SYNTHESIZE_HOSTNAME=0 might fix it. [0]: https://github.com/systemd/systemd/issues/34897#issuecomment...