[Unit]
Description=Caddy HTTP/2 web server
Documentation=https://caddyserver.com/docs
After=network-online.target
Wants=network-online.target systemd-networkd-wait-online.service
[Service]
Restart=on-abnormal
; User and group the process will run as.
User=caddy
Group=caddy
; Letsencrypt-issued certificates will be written to this directory.
Environment=CADDYPATH=/etc/ssl/caddy
Environment=CLOUDFLARE_EMAIL=**removed**
Environment=CLOUDFLARE_API_KEY=**removed**
; Always set "-root" to something safe in case it gets forgotten in the Caddyfile.
ExecStart=/usr/local/bin/caddy -log stderr -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp
ExecReload=/bin/kill -USR1 $MAINPID
; Use graceful shutdown with a reasonable timeout
KillMode=mixed
KillSignal=SIGQUIT
TimeoutStopSec=5s
; Limit the number of file descriptors; see `man systemd.exec` for more limit settings.
LimitNOFILE=1048576
; Unmodified caddy is not expected to use more than that.
LimitNPROC=512
; Use private /tmp and /var/tmp, which are discarded after caddy stops.
PrivateTmp=true
; Use a minimal /dev (May bring additional security if switched to 'true', but it may not work on Raspberry Pi's or other devices, so it has been disabled in this dist.)
PrivateDevices=false
; Hide /home, /root, and /run/user. Nobody will steal your SSH-keys.
ProtectHome=true
; Make /usr, /boot, /etc and possibly some more folders read-only.
ProtectSystem=full
; … except /etc/ssl/caddy, because we want Letsencrypt-certificates there.
; This merely retains r/w access rights, it does not add any new. Must still be writable on the host!
ReadWriteDirectories=/etc/ssl/caddy
; The following additional security directives only work with systemd v229 or later.
; They further restrict privileges that can be gained by caddy. Uncomment if you like.
; Note that you may have to add capabilities required by any plugins in use.
;CapabilityBoundingSet=CAP_NET_BIND_SERVICE
;AmbientCapabilities=CAP_NET_BIND_SERVICE
;NoNewPrivileges=true
[Install]
WantedBy=multi-user.target
Cannot get this site to grab a valid cert - locally/intranet when I browse to the site through Caddy proxying it - it tells me the site cert date is invalid.
If I attempt to access the site from the internet it just times out and cloudlfare tells me the host is down.
I have multiple sites working fine on the *.batcave.host domain without issue - I’m only having an issue with schnell-engineering.com and with seafile.batcave.host for some reason (although seafile site works internally and externally)
Not sure what to try - I don’t see why this would fail as I already use 10.10.1.8 to serve web pages without issue - there is something I am missing between the two domain names I suppose and possibly cloudlfare config (both domains are under the same cloudflare account and API access).
Checking my local DNS servers I seem to have the TXT record in place as well:
Whatever’s going on, Caddy isn’t checking the actual authoritative nameserver for DNS propagation. You’re using the Cloudflare module, your public domain nameserver records are Cloudflare servers, Caddy appears to believe it’s successfully configuring your zone on Cloudflare, but it’s checking batcavedc01.batcave.com for propagation instead.
Do you have a paid Cloudflare account with batcavedc01.batcave.com as some kind of white label nameserver maybe?
This error Caddy’s returning:
NS batcavedc01.batcave.com. returned NXDOMAIN for _acme-challenge.schnell-engineering.com
I do not - batcave.com is my internal/local domain batcavedc01 is my AD server (DHCP/DNS).
batcave.host and schnell-engineering.com are both using the single cloudflare account - and this all used to work just fine before I switched to CF. I’ve had a lot of troubles making this all work with CF to be honest.
Using Caddy in it’s default setup and another DNS (afraid) worked flawless. After many stuggles after moving to .host to CF I finally was ready to bring over the last domain now - it’s when I noticed that schnell-engineering.com and seafile.batcave.host give me these errors. Why that is I do not know.
Doesn’t seem to match up with what I’m seeing with respect to the name server:
Whatever’s going on, Caddy isn’t checking the actual authoritative nameserver for DNS propagation. You’re using the Cloudflare module, your public domain nameserver records are Cloudflare servers, Caddy appears to believe it’s successfully configuring your zone on Cloudflare, but it’s checking batcavedc01.batcave.com for propagation instead.
I agree that is the case - why that is so I do not understand - nothing is set up any different for me anywhere when it comes to my DNS.
For some reason, your local DNS resolver is telling Caddy that it is the authoritative name server for schnell-engineering.com, not the Cloudflare NS.
That means when Caddy goes and changes the zone on Cloudflare’s nameservers, your own nameserver doesn’t update, but Caddy’s checking your nameserver, not Cloudflare’s.
Your local DNS either needs to give Caddy the correct nameserver, or it needs to very closely propagate those TXT records from the real authoritative nameserver (Cloudflare’s).
If you can edit your schnell-engineering.com zone in your AD DNS, and set the NS records manually to Cloudflare so it doesn’t assume it’s authoritative, that might work?
