HTTPS-certificaten voor je netwerk instellen: zo doe je dat

Wie zelf diensten host, klikt meestal door certificaatwaarschuwingen heen. Met een eigen domein, Pi-hole en Caddy krijgen al die diensten dankzij een DNS 01-challenge het felbegeerde slotje in de adresbalk.

Je kent het wel: “Je verbinding is niet privé” met nog de opmerking over dat kwaadwillende gebruikers mogelijk je gegevens proberen te stelen zoals wachtwoorden, berichten of creditcards. Wie zelf diensten host, is gewend waarschuwingen over zelfondertekende certificaten weg te klikken en maakt zich niet druk om het ontbrekende slotje in de adresbalk. Het is immers allemaal lokaal, dus transportversleuteling is niet per se nodig.

Dat zou je denken, maar het gaat niet altijd op. Verschillende toepassingen vereisen een beveiligde context, dus het overdrachtsprotocol Hypertext Transfer Protocol Secure (HTTPS). Daaronder vallen diensten die bijzonder gevoelige gegevens verwerken, zoals wachtwoordmanager Vaultwarden (een in Rust geschreven implementatie van de Bitwarden-server).

WebAuthn, de webstandaard achter passkeys, werkt alleen wanneer je een pagina via HTTPS opent. Sommige wachtwoordmanagers weigeren bovendien inloggegevens automatisch in te vullen als de verbinding niet versleuteld is.

Het kan ook lastig zijn om anderen uit te leggen waarom ze websites zonder slotje in de adresbalk in het algemeen moeten wantrouwen, terwijl dezelfde waarschuwingen bij hun eigen Nextcloud volstrekt onschuldig zouden zijn. En zou het niet veel netter zijn om diensten te openen via een domein met een geldig certificaat dan met een IP-adres plus een onhandig poortnummer dat je steeds vergeet?

Dankzij certificaatautoriteiten zoals Let’s Encrypt en het ACME-protocol is het tegenwoordig eenvoudiger dan ooit om gratis een TLS-certificaat te verkrijgen.

Wanneer een browser een website via HTTPS bezoekt, onderhandelt hij met de server over een versleutelde TLS-verbinding (Transport Layer Security). Aan de hand van een certificaat controleert de browser of hij met de juiste tegenpartij communiceert. Als het certificaat ontbreekt of ongeldig is, toont de browser een waarschuwing.

We laten zien hoe je al je diensten van een certificaat voorziet zonder poorten op je router te forwarden. Daarvoor heb je alleen een domein nodig bij een provider die een API aanbiedt voor de zogeheten DNS-01-challenge, bijvoorbeeld Cloudflare, en een Linux-systeem. Dat kan een Raspberry Pi, een virtuele machine (VM) of een mini-pc zijn. Voor deze handleiding heb je basiskennis van Linux en Docker nodig.

Let’s Encrypt is een CA (certificaatautoriteit) die gratis certificaten uitgeeft. Een client vraagt deze via het ACME-protocol (Automatic Certificate Management Environment) aan. In onze methode verzorgt reverse proxy Caddy dat.

Vaak wordt daarvoor de HTTP-01-challenge gebruikt: je bewijst aan de CA dat je de server beheert doordat Caddy een token opslaat onder example.com/.well-known/acme-challenge/, waarbij je example.com door je werkelijke domein moet vervangen.

Daarvoor moet de server vanaf internet bereikbaar zijn via poort 80. Bij diensten in een netwerk betekent dit het instellen van poortforwarding op de router. Wildcardcertificaten zoals *.example.org zijn op die manier niet mogelijk. Die zijn juist handig als je een hele verzameling diensten van certificaten wilt voorzien.

Bij de DNS-01-challenge bewijs je de CA daarentegen dat je de controle over het domein hebt. Daarvoor plaatst de ACME-client bij de DNS-provider een token als TXT-record onder _acme-challenge.example.com.

Let’s Encrypt controleert de vermelding via de nameservers van de provider. Zodra het certificaat is uitgegeven, wordt het TXT-record verwijderd. Omdat de CA nooit een verbinding met je eigen server opzet, hoeft die niet vanaf internet bereikbaar te zijn. De ACME-client, in ons geval Caddy, en de DNS-provider communiceren via een API. Daarvoor heb je een token nodig dat toestemming geeft om de DNS-zone te wijzigen.

Om clients in je netwerk een dienst onder zijn domeinnaam te laten openen, heb je een lokale DNS-server zoals Pi-hole nodig, die een A-record laat verwijzen naar het privé-IP-adres van de reverse proxy. Heb je een geavanceerde router waarmee je lokale DNS-records kunt instellen, dan heb je Pi-hole niet per se nodig.

Dat geldt ook als je al een andere lokale DNS-server zoals Unbound of Technitium (zie pagina 142) gebruikt. Als voorbeelddomein gebruiken we in dit artikel .home.example.com. Pi-hole vertaalt dit lokaal (split-horizon-DNS). Alle overige verzoeken stuurt Pi-hole door naar een publieke resolver.

Je hebt een eigen domein nodig bij een DNS-provider die een API voor het aanpassen van DNS-zones aanbiedt en waarvoor Caddy een module heeft. Wij gebruiken Cloudflare, maar als je je DNS-zone liever niet onderbrengt bij een Amerikaanse aanbieder, kun je bijvoorbeeld mijn.host, OVHcloud, transip of een andere EU-provider kiezen. Alle beschikbare Caddy-modules vind je op GitHub (zie link).

Bij Cloudflare maak je in de webinterface onder API Tokens een API-token aan. Geef voor je domein de rechten Zone read en Zone write. Bewaar het token op een veilige plek en behandel het als een wachtwoord.

Wij hebben Pi-hole en Caddy met Docker geïnstalleerd onder Ubuntu Server 26.04, maar het zou ook op andere distributies met Docker moeten werken. Het systeem moet een vast adres in het LAN hebben en de poorten 53, 80 en 443 moeten bereikbaar zijn. Onder Ubuntu moesten we daarvoor de stubresolver van systemd uitschakelen, zoals in de documentatie van Pi-hole staat beschreven. Voer het volgende commando uit: