@Whitestrake. Actually I’d prefer not to use the wildcard. It would allow me to have sub/sub domains
One of the reasons I’ve used a wildcard is that I have FQDN subdomains I use only within my private lans with corresponding dns records served only locally within the lans. I need caddy to serve https for those without depending on an internet connection (I have iot stuff that must work always, and for security don’t want public dns records for lan only subdomains). But I also have publicly accessible subdomains serviced via route53. Using a wildcard (for at least the local subdomains) allowed me to do that.
I have a cron script that checks/renews the wildcard cert and distributes to my caddy servers which means I can go something like 90 days without an internet connection which is of course fine.
So either I need an alternative to using a wildcard that meets my needs or I’ll just have to wait unit V2 supports wildcard subdirective :(.
Even if I am forced to abandon wildcard subdirective I would need to get acme route53 dns tls working and that is currently just a PR that I am trying out. V2 modules and cross compile
Maybe I don’t need to use a wildcard if.
- The cert caddy gets for each subdomain is good for some time. Is it like wildcard about 90 days? (i.e. caddy still works if it can’t access the acme server but the cert is still valid)
- A public dns record (i.e. at route53) is not required for caddy/acme to successfully get a cert for that subdomain and that subdomain does not have reachable from public internet for the cert to be assigned?
I see this post V2 Get it working with internal CA in systemd?
Maybe I need to go the way of an internal CA? In that post @matt talks about an internal acme CA server for 2.1 Maybe that’s the solution? But can that approach live together with the acme certs for public subdomains on the same FQDN?
your thoughts?