My caddy server is serving a mixture of local lan only subdomains (local DNS only) and public domains (with public DNS).
I had been using a manually created wildcard certificate for all of them which works great but I really need to switch to automated one off certs which I have done for my public DNS domains…
The issue is of course that certbot/letencrypt won’t issue a certificate for a subdomain with no public DNS record and for security reasons (even though firewall and caddy would reject wan requests) I just don’t even want them out there in the public sphere.
The bummer is of course if I can’t get a cert then chrome etc will make this lack of a cert miserable.
So what are my options? I thought update again my wildcard cert and use for internal/lan subdomains but maybe there is a better way than constantly managing this wildcard cert every 90 days.
My domain is hosted with route53 and I have an IAM user with R/W access to DNS records. So one thought was to use the tls_route53 plugin to somehow authenticate certs for those lan only subdomain (without having to make a public A or CNAME record but some kind of challenge record) while using the built in system for my public ones
No worries - LetsEncrypt will issue a certificate only for a publicly accessible domain name, but it doesn’t require A or CNAME records to be set on that domain name.
As long as your local LAN only subdomains are still fully qualified public domain names, even if they don’t resolve outside of your own network, you can use DNS validation to get your certificates. This process temporarily publishes a TXT record to the root of your DNS zone that LetsEncrypt can check to ensure you control the domain.
Check out the Automatic HTTPS documentation on the DNS Challenge:
Since I posted this I have figured out a nice fully automated way with certbot and their route53 plugin to keep my wildcard certificate current so it’s kinda moot.
Still I assume it’s pretty much the same deal. The caddy route53 plugin is probably just a wrapper for the certbot one. For certbot I set the credential environment variables in my script. How best to set the environment variables for my credentials in caddy? In my systemd service??
I’ll probably try it just try this for grins and future reference or in case I wish to drop the wildcard cert.
[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=root
Group=root
; Letsencrypt-issued certificates will be written to this directory.
Environment=CADDYPATH=/opt/caddy/certs
AWS ENVIRONMENT VARIABLE CREDENTIALS HERE???
; Always set "-root" to something safe in case it gets forgotten in the Caddyfile.
ExecStart=/opt/caddy/caddy -log stdout -agree=true -conf=/opt/caddy/caddy.conf -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
Close! Caddy’s DNS provider plugins are courtesy of xenolf/lego, the ACME library Caddy uses.
Yep, that will work well. You’ll want to add two more environmental variables that Caddy will be looking for;
AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY
If you’re quite attached to the wildcard certificate, Caddy can requisition those for you as well. You’d effectively just have Caddy take over your Certbot’s job and run one fewer service on your server.