When I put my first servers online, HTTPS was barely known as “the complicated thing for e-commerce” and we did not care about it AT ALL.

Today, even for a service that only communicates between two servers on my own LAN at home, I wouldn’t even consider sticking to pure HTTP.

Self-signed certificates are awful: they throw errors everywhere (for very good reasons) and lead to security breaches… moreover, more and more libraries (and thus software) reject them.

Managing a PKI involves a lot of work. You have to install your own CA certificate on all your devices (and if any of those devices are Android or iOS, may God help you).

So, we are left with a certificate signed by a public certificate authority… The main problem with this solution is that Certificate Transparency will expose sensitive information about your infrastructure to the public: if you sign the certificate veeam.local.yourdomain.tld, anyone could guess that you use Veeam as a backup solution.
The easy workaround is to simply use wildcard certificates internally.

Of course, you will have to use DNS challenge validation.
You absolutely need to use a tool such as Certbot to handle your certificate renewals, and it will need to have write access to your DNS zone. You should use your DNS provider’s API with a token that has minimal permissions. This is sensitive, so treat it with care.

To obtain publicly signed certificates, you will obviously need to use a public domain name for your internal needs (good luck having your “nas.local” signed by a public authority). But this is a good thing:

  • First, you should never ever use the .local TLD: it is reserved for mDNS and will lead to countless compatibility issues.
  • Even if you choose to use a made-up TLD, what if it is sold and used on the internet in a few months?The advantage of local.yourdomain.tld is that you actually own it.

Of course, you do not want anyone external to your network to be able to resolve anything within this domain, so enter split DNS!

This is quite simple, actually: set up your own DNS in your network (a simple Dnsmasq will do) and only make it manage the zone local.yourdomain.tld. Everything else is delegated to public DNSs. It is not a bad idea to ensure your DNS is accessible over IPv6 (even if you choose to only resolve IPv4 addresses locally) for compatibility with modern OSes.

You should probably rely on DHCP to advertise your DNS server to all your local devices (do not forget about DHCPv6).
I will write an article about how I manage my IPv4/IPv6 stack at home as soon as possible.

I use Cloudflare to protect everything I expose publicly. So, in fact, the only one who knows my public IP address is Cloudflare.

public request
When anyone anywhere in the world makes a query for one of my local domains, they get Cloudflare’s reverse-proxy IP address. When the query comes from one of my internal networks (including through my VPN), the query is relayed by my private DNS.


public request
When anyone anywhere in the world makes a query for one of my private domains, they get an error: public DNSs do not know about them. When the query comes from one of my internal networks (including through my VPN), the query is directly handled by my private DNS.


public request
When anyone anywhere in the world accesses one of my public services, the connection between the browser and Cloudflare is secured using a certificate managed by Cloudflare for my domain name. The connection between Cloudflare and my server is secured by a certificate issued by Cloudflare for this purpose (this certificate has a 15-year validity so I do not need to worry about renewals, and this is safe enough as only Cloudflare’s IPs are allowed to query my web server).
When I access one of my private services from my local networks, the connection between the client and the server is secured using a Let’s Encrypt certificate.