Only thing required for this setup to work: client needs to be able to resolve domain to internal ip.
I have wireguard mesh with a bunch of services that use LE for TLS that have no access to interwebs and not accessible from interwebs.
LE can use DNS itself as the challenge. It works something like:
- You manage the mmd45.me domain (through a dns provider, say dnsimple)
- You ask LE for a cert for imap.lan.mmd45.me (an address that doesn’t exist, but you use in /etc/hosts or something internally. Or maybe an internal dns server like a pihole or something. The rest of the internet doesn’t see this address)
- LE says “prove you own lan.mmd45.me by creating a TXT record containing <random-nonce> inside _acme-challenge.lan.mmd45.me”
- Certbot integrates with your DNS provider to create said TXT record
- LE sees the TXT record and determines you are the owner, and signs your cert. At this point certbot can just delete _acme-challenge.lan.mmd45.me because it did its job.
At no point does mail.lan.mmd45.me need to be externally resolvable to any address for this to work.
Software is a collective. A billion or so people get the same software. The time for self-signed certs has passed because supporting that in software for a billion people opens up some of that billion to attack.
The few people who understand the niceties of certs can create a private CA, trust that, and use that CA to sign a regular cert. Doing that is nontrivial, but it doesn't put other people at risk.
> Only thing required for this setup to work: client needs to be able to resolve domain to internal ip.
It does not. Use DNS validation, that way you can issue LE certs for individual domains as well as wildcard certificates without needing to expose anything anywhere other than a CNAME record for the validation.
how are you renewing the LE certificate if the domain is resolving to an internal ip? this seems like a big hoop to jump through.