Comment by mmd45
Comment by mmd45 2 days ago
unfortunately none of that applies to my setup. my imap server lives in a dmz and doesn't have all that other jazz.
Comment by mmd45 2 days ago
unfortunately none of that applies to my setup. my imap server lives in a dmz and doesn't have all that other jazz.
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 many people care about setting up secure connectivity to an internal server but are unable to either disable this behavior or configure their own internal DNS service?
My internal DNS names are served from my router and I'd imagine a lot of the people who would care about this in a home environment are running either open-source or business-class commercial devices that can do the same.
Mine too. It does apply.
Seems to be a safe assumption you have a domain since you're receiving mail.
Go run something like certbot[0] on your mail server. It has plugins to integrate with various DNS providers. (This is who is hosting the zone where you map domains to IPs, not necessarily where you registered the domain.) If they don't have a plugin for your host, you could look at moving the zone (e.g., CloudFlare is free for something like this, Route53 is <$1/mo) or finding another tool that does support it[1].
No external IPs involved anywhere and you can get valid, trusted SSL certificates for your domain. Set up the auto-renewal (in essentially all cases, add something to crontab), and it'll periodically dump new certificates to disk for you so you never need to think about the certificates again.
If you don't even want anyone to know that there's a "imap.mmd45.com" in existence _somewhere_ in the world, you can issue a certificate for `*.mmd45.com` and it will cover any direct subdomains.
Now you actually need to _connect_ to your mailserver with some sort of hostname rather than IP. For desktop devices and stuff, you could just throw this in /etc/hosts if you wanted. Some VPN/VPN-adjacent tools have ways to push mappings like that. Basically all of them have a way to override the DNS server in use if you were willing to run your own DNS server on the same host that has your mailserver. You can also just create a public record mapping imap.mmd45.com to 10.1.2.3.
[0] https://eff-certbot.readthedocs.io/en/latest/ [1] https://letsencrypt.org/docs/client-options/