HTTPS on your local network: putting an end to the security warning

You open your NAS web interface, the browser throws up a red warning, you click "continue anyway". Every single day. The traffic is encrypted, so the important part is covered.

Except the real cost is not technical. By routinely clicking through those warnings, you are training yourself to stop reading them — including the one that will, some day, be justified.

What a self-signed certificate does not do

A certificate has two jobs: encrypting the connection, and authenticating the server.

A self-signed certificate does the first one perfectly. It does not do the second one at all: anyone can generate one claiming to be your NAS. The browser has no way to tell yours from an impostor, and that is precisely what the warning is saying.

On a home network you control, the actual risk stays moderate. The habit, on the other hand, follows you everywhere.

The in-house authority: correct, but painful

The classic answer is to create your own certificate authority, sign your certificates with it, and install the root on every device you own. Technically, that is the right answer.

In practice, two problems show up.

The first is deployment. Every device has to receive the root: computers, phones, tablets, the TV, and every newcomer. Some applications keep their own trust store and ignore the system one — common with development runtimes and a fair number of command-line tools.

The second is mobile hardening. Recent mobile systems deliberately make manually added authorities awkward: extra steps, permanent warnings, demotion to a lower trust tier, and apps that flatly refuse anything that did not ship with the system. You end up with a setup that works on the computers and fails on the phones.

Add managing the authority private key — which, if it leaks, lets someone impersonate any of your services — and the cost gets serious for home use.

DNS validation: the clean path

There is a third option, badly underused: getting a publicly trusted certificate for a service that is never exposed to the internet.

It all hinges on the validation method. Normally an authority checks that you control a service by reaching it at its public address — impossible here. With DNS validation, you prove you control the domain instead, by creating a temporary record there that the authority comes and reads.

Nothing requires the service to be reachable. It can stay entirely private, behind your firewall, on a non-routable address.

The certificate you get is signed by an authority your devices already trust. Nothing to install, nothing to deploy, no warnings — including on phones and on devices whose trust store you do not control.

What it requires

Three prerequisites, all reasonable:

A domain you own. That is the main condition. A made-up domain will not do — no authority will sign for an extension that is not yours.

A DNS host you can drive automatically. Validation creates and deletes temporary records; without automation you would be doing it by hand at every renewal, which becomes unsustainable fast.

An internal resolver that points those names at your private addresses. It is the natural counterpart to local DNS.

The wildcard certificate, so you only manage one

Rather than one certificate per service, ask for a wildcard certificate covering every subdomain at one level. A single certificate for all your internal services, a single renewal to keep an eye on.

That kind of certificate is only issued through DNS validation — convenient, since that is already the method you picked.

One constraint worth knowing: a wildcard only covers a single level. A certificate for *.lan.mydomain.com covers nas.lan.mydomain.com but not admin.nas.lan.mydomain.com. Design your naming flat rather than deep.

Distribution through the reverse proxy

Last piece: do not deploy the certificate on every service. Put a reverse proxy at the front door, holding the single certificate and dispatching to the internal services.

You get one renewal point, one place where the certificate is stored, and you no longer have to worry about services that cannot handle TLS properly. It is also the natural place to add authentication in front of the interfaces that have none.

How to choose

• You do not own a domain and do not want one: in-house authority, accepting the limitations on mobile.
• You own a domain: DNS validation with a wildcard certificate, no hesitation. It is less work than an in-house authority, and it works everywhere.
• A single isolated, temporary service: self-signed is still acceptable, provided it is a conscious choice and not a habit.