Many home services should never be exposed to the Internet: the NAS control panel, the document manager, the password vault. Yet these too deserve HTTPS, and not only to avoid the browser warning. Some modern features, such as passkeys, web notifications or installing a site as an app, require a secure context, and certain phone apps refuse untrusted certificates. The cleanest solution is to obtain valid public certificates without opening a single port, thanks to the DNS challenge.
Why self-signed certificates are not enough
A self-signed certificate encrypts the connection, but no device trusts it. You can manually install your own authority on every computer and phone in the house, but management becomes tiresome: every new device, every guest, every reinstall needs attention. Some systems also make installing custom authorities awkward for apps. With a public certificate everything works straight away, everywhere.
The prerequisite: your own domain
To get a public certificate you need a domain registered in your name, even an inexpensive one. Home services will use subdomains such as photos.home.example or docs.home.example. The domain must be managed by a DNS provider that offers a programmable interface (API), because certificate renewal will have to happen automatically.
How the DNS-01 challenge works
Certificate authorities that use the ACME protocol, such as Let's Encrypt, must verify that whoever requests the certificate really controls the domain. There are several challenges; the two most common are:
- HTTP-01: the authority downloads a file from an address on the server. This requires the server to be reachable from the Internet on port 80.
- DNS-01: the requester creates a TXT record called
_acme-challengein the domain's DNS, and the authority reads it. The server does not need to be reachable from outside.
The DNS-01 challenge is therefore perfect for internal services: the home server talks to the DNS provider's API, creates the record, obtains the certificate and deletes the record. No open ports, no exposure.
Wildcard certificates: one for all
With the DNS challenge you can obtain a wildcard certificate, valid for *.home.example, that is, for any first-level subdomain. The advantage is twofold:
- You manage a single certificate for every service.
- The names of individual services do not appear in the public Certificate Transparency logs, where every issued certificate is published.
This second point is often overlooked: anyone can search those logs and discover that vault.home.example exists. With a wildcard only the generic name appears.
The tools
Almost all the reverse proxies used at home support the DNS challenge, often through modules for the most common providers. Alternatively, you can use standalone ACME clients.
| Tool | How it handles the DNS challenge |
|---|---|
| Caddy | DNS provider modules, included in the build |
| Traefik | Built-in support for many providers |
| Nginx Proxy Manager | An option in the interface, with provider credentials |
| acme.sh, Certbot | Command-line clients with plugins or scripts |
Whatever tool you choose, create the API token with minimal permissions: only DNS record editing, ideally only for that zone. If the token fell into the wrong hands, the damage would remain limited.
Local DNS: pointing names inside the house
The certificate alone is not enough: devices at home must resolve photos.home.example to the server's private address, for example 192.168.1.20. There are two main approaches:
- Records in public DNS pointing to private addresses: simple, but some routers block these answers as protection against DNS rebinding attacks, and the name remains publicly visible.
- Local DNS: the home resolver (the router, Pi-hole, AdGuard Home or a dedicated server) answers with the internal address, while public DNS contains nothing. This is the cleanest solution.
With local DNS, the public domain serves only to pass the challenge and obtain the certificate, while name resolution stays entirely at home.
Renewals and checks
ACME certificates have a short lifetime, in the order of a few months, and are renewed automatically ahead of time. Precisely because it is automatic, renewal needs watching: an expired token or a change in the provider's API can silently stop it. It is worth setting up a check that alerts you when a certificate is close to expiry, so you can step in calmly.
In short
- Internal services also benefit from trusted public certificates.
- The DNS-01 challenge issues certificates without exposing the server to the Internet.
- A wildcard covers every service and hides their names in public logs.
- The DNS provider's API token should be limited to the bare minimum.
- A local DNS keeps name resolution entirely inside the house.
