Comment on Caddy + DeSEC.io + DNS Challenge
iggy@lemmy.world 1 week ago
Just as an aside, you’re half way to being able to use wildcard certs, you might as well just do the last bit of work so the domain names you’re using are a little less public. Let’s Encrypt puts every domain name on every cert in a public database. I’ve seen much less random probing of my services since moving to wildcards
Oh no, I was just about to move forward and then you gave me another rabbit hole.
I didn’t know Let’s Encrypt had a public database, that does sound like a good idea to use wildcard certs instead.
I assume this is what I can use as a reference for wildcard certs.
How do you keep track of probing? I’ve been curious about that but haven’t put much effort into that as I’ve been focused on getting things working.
it’s not just Let’s Encrypt, it’s because of certificate.transparency.dev
Thanks for sharing that.
It’s nice to get extra context, it helps me understand how I can protect my devices and myself a bit better as I learn more about self hosting.
confusedpuppy@lemmy.dbzer0.com 1 week ago
I sat down and managed to get wildcard certs working.
I figured I would leave my Caddyfile here in case anyone in the future needs a working reference. This is based off the Caddyfile mentioned in the original post.
Caddy Reference
Caddyfile
# GLOBAL ENCRYPTION - DESEC.IO { acme_dns desec { token “DeSEC.io Token Number” } } *.samplesite.ca { # SITE WIDE ENCRYPTION tls { dns desec { token “DeSEC.io Token Number” } } # SUB DOMAIN #1 @files host files.samplesite.ca handle @files { root * /srv file_server { hide misc browse } } # FALLBACK FOR UNHANDLED DOMAINS handle { abort } }