[oneplane]

No, but you could use DNS for that internal IP. And then you'd have a hostname. Since your IMAP server likely has some way of getting external mail, it is likely that you have a DNS zone and MX records, so adding an A record for your internal IMAP access isn't that much of an effort compared to what you already would have.

If you have mmd45.com as a domain and have MX records pointing to your mail server, adding imap.mmd45.com pointing to your IMAP server should be fairly simple. Getting a Let's Encrypt certificate for *.mmd45.com is all that remains for the TLS part with a valid CA chain. As a bonus you can then also use encrypted SMTP.

[mmd45]

unfortunately none of that applies to my setup. my imap server lives in a dmz and doesn't have all that other jazz.

[nucleardog]

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/

[0x457]

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.

[mschuster91]

> 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.

[mmd45]

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.

[ninkendo]

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.

[Arnt]

LE doesn't need any A or AAAA record. The domain must exist in the DNS and you must be able to create records in the domain.

If you're using internet mail you have a domain, so you can do this. The time for self-signed certificates has passed.

[kortilla]

A pinned self cert is still more secure than this because you don’t have to trust any CAs.

> The time for self-signed certificates has passed.

This is bad blanket advice and very much depends on use-case.

[Arnt]

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.

[greyface-]

https://letsencrypt.org/docs/challenge-types/#dns-01-challen...

[Spivak]

This can still work imap.mydomain.com resolving to your hardcoded private ip, put the cert on your imap server, connect by name, done.

[lxgr]

This won't work on many home routers that filter out private/local IP A/AAAA records from DNS responses to protect against DNS rebinding.

[wolrah]

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.