Thing is, you may have some devices that should be accessible even if the reverse proxy is unreachable.
And if you have HSTS and wamt to reach a device under the same local DNS suffix (example: External -> service.example.org, Internal: service.int.examole.org) you can’t just bypass the https warning.
Same for devices reachable over RDP, SSH, etc. etc.
If you switch to the dns-01 challenge you can just generate the certs on multiple servers hasselfree. And as a bonus you can get wildcard certs for subdomains.
I must admit that one disadvantage of Caddy compared to when I was using acme.sh, is having to make a request to Let’s Encrypt (even automatically) for every subdomain, making all of them visible on crt.sh
deleted by creator
But you’re still using Caddy as the sole reverse proxy, don’t you? Do you have multiple Caddy instances that require access to a single certificate?
Thing is, you may have some devices that should be accessible even if the reverse proxy is unreachable.
And if you have HSTS and wamt to reach a device under the same local DNS suffix (example: External -> service.example.org, Internal: service.int.examole.org) you can’t just bypass the https warning.
Same for devices reachable over RDP, SSH, etc. etc.
If you switch to the dns-01 challenge you can just generate the certs on multiple servers hasselfree. And as a bonus you can get wildcard certs for subdomains.
How ?
I’ve seen nothing about that in the Caddy docs.
I must admit that one disadvantage of Caddy compared to when I was using
acme.sh, is having to make a request to Let’s Encrypt (even automatically) for every subdomain, making all of them visible on crt.shThe docs on DNS challenge are here, and a bit further down you can find the ones on wildcard certificates
Oh, thanks !