SSL cert voor local lan lukt maar niet

[Pabz]

Beste allemaal,

Het lukt me maar niet om SSL voor mijn local lan werkend te krijgen. Wat ik tot op heden gedaan heb:

1. Ik heb een domein (www.voorbeeld.nl) en dit beheer ik in Cloudflare
2. In Cloudflare heb ik een API aangemaakt als volgt:
   1. Template edit zone DNS
   2. permissions zons dns edit
   3. zone resources include specific zone voorbeeld.nl
3. NGINX en pihole draaiend op mijn netwerk
4. In pihole alle services in Local DNS records laten verwijzen naar NGNINX ip adres
5. In NGINX certificaat toegevoegd als Let's Encrypt via DNS voor de domeinnamen *.voorbeeld.nl en voorbeeld.nl. Key type ECDSA 256 en provider Cloudflare
6. In NGINX proxy hosts aangemaakt voor elke service en daar het certificaat aangehangen

Verder regelt pihole dus al mijn DNS en heb ik mijn firewall zou ingeregeld dat alleen pihole mijn DNS server is en dat al het andere DNS verkeer gedropt wordt. Verder gebruik ik Cloudflared DNS over HTTPS als custom upstream server in Pihole en heb ik geen andere upstream servers aangevinkt. Tot slot heb ik ook geen conditional forwarding oid aan staan.

Wat er gebeurd als ik naar bijv nas.voorbeeld.nl wil gaan, is dat ik via safari op een Cloudflare pagina terecht komt (ERROR 1016, Origin DNS error). Op een andere laptop met Edge krijg ik de melding ERR_SSL_UNRECOGNIZED_NAME_CERT. Ik denk dus dat pihole mijn Local DNS records niets goed resolved, maar ik heb geen idee hoe ik dit moet oplossen.

Tips zijn welkom

Dank!

[Pabz]

niemand...?

[mfkne]

1016 betekent dat Cloudflare de hostname niet kan resolven: https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/error-1016/

Ik neem aan dat je de hostname alleen in je local DNS records hebt ingesteld, maar Cloudflare vereist dat die publiekelijk resolvebaar zijn.

[jurroen]

Je lokale recursor is heel wat anders dan je authorative nameserver inderdaad.

[ouweklimgeit]

Local-LAN certs zijn gewoon problematisch, je PiHole doet zich nu in feite voor als Origin en dat kan niet met een Cloudflare certificaat. Letsencrypt zou kunnen, maar dan moet je elke paar maanden handmatig vernieuwen (en moet LE werkelijk je proxy/webserver kunnen bereiken). Mijn permanente fix was om Cloudflare Access te gebruiken in combinatie met NPM (Nginx Proxy Manager).

1) A records toevoegen bij Cloudflare
2) Access -> Policies toevoegen
3) Access -> Applicatie toevoegen

Onderstaande screenshot geeft mijn standaard policies aan, dus vanaf mijn thuis-IP geen enkele vorm van extra authenticatie, evenals vanaf mijn mobiele apparaten met de juiste Cloudflare headers (Navibeat -> Navidrome, voor muziek onderweg). Ben ik elders en wil ik toch bij mijn nas, dan krijg ik op dat subdomein direct een 2FA login van Cloudflare te zien.

Vervolgens kun je in je eigen firewall (of NPM) nog de IPv4 en eventueel IPv6 adressen van Cloudflare toevoegen zodat je zeker weet dat al het inkomende verkeer echt via Cloudflare komt.

[madlabber]

Certificaten voor een LAN zijn alleen "problematisch" wanneer je een pseudo man-in-the-middle achtige setup als de TS gebruikt.

De juiste manier is om een eigen root CA te maken (om je eigen certificaten te genereren), en deze te vertrouwen op al je devices. Een bijkomend voordeel van deze methode is dat je dan ook een SAN kunt toevoegen, zodat het certificaat ook werkt als je direct het IP intypt.

Ervan uitgaande dat het doel "SSL voor mijn local lan" is, en niet "SSL voor mijn local lan en eventueel het internet".

[ Voor 4% gewijzigd door madlabber op 25-08-2026 11:18 ]

[Pabz]

madlabber schreef op dinsdag 25 augustus 2026 @ 11:15:
Certificaten voor een LAN zijn alleen "problematisch" wanneer je een pseudo man-in-the-middle achtige setup als de TS gebruikt.

De juiste manier is om een eigen root CA te maken (om je eigen certificaten te genereren), en deze te vertrouwen op al je devices. Een bijkomend voordeel van deze methode is dat je dan ook een SAN kunt toevoegen, zodat het certificaat ook werkt als je direct het IP intypt.

Ervan uitgaande dat het doel "SSL voor mijn local lan" is, en niet "SSL voor mijn local lan en eventueel het internet".

Het doel is idd alleen voor local lan. Is het probleem met een root CA niet dat je deze op ieder apparaat dan moet installeren en updaten? Het doel voor mij is voornamelijk om gewoon van de irritante melding "deze website is niet veilig" af te komen

[jurroen]

Pabz schreef op dinsdag 25 augustus 2026 @ 16:01:
[...]

Het doel is idd alleen voor local lan. Is het probleem met een root CA niet dat je deze op ieder apparaat dan moet installeren en updaten? Het doel voor mij is voornamelijk om gewoon van de irritante melding "deze website is niet veilig" af te komen

Updaten? Maak een CA aan van 30 jaar, trust die. Knap mens als jij dertig jaar met je devices doet.

Alternatief misbruik je de CF DNS API met iets als acme.sh voor een wildcard. Ben je er ook, in combinatie met wat rewrites in je hol.

Nadeel is dat je dan even moet uitzoeken hoe je die certs up to date houdt over je services. De meeste ACME boeren geven (gratis) certs uit van 90 dagen en dit kan in de toekomst misschien later uit gaan vallen. LE is aan het experimenteren met ultra short lived certs van vijf dagen.

Voordeel van zelf je CA worden is dat je ook geen externe CA hoeft te vertrouwen. Mits je de skills hebt. Op de Signal blog kun je wat meer lezen over de achtergrond waarom zij dat zo doen. Dat gezegd hebbende, zijn natuurlijk wel twee uitersten qua threat model