Jarenlang leunde webversleuteling op een ongeschreven basisregel: als een dienst HTTPS wil, heb je een domeinnaam nodig. Dat is praktisch — mensen surfen op namen, niet op nummers — maar ook historisch: validatie en certificaatbeheer zijn ontworpen rond DNS.
Die regel begint nu te verschuiven. Sinds 15 januari 2026 biedt Let’s Encrypt de algemene beschikbaarheid van TLS-certificaten voor IP-adressen. Daarmee kun je HTTPS rechtstreeks op IPv4 of IPv6 beveiligen zonder afhankelijk te zijn van een domeinnaam. Dat is vooral relevant voor homelabs, tijdelijke infrastructuur, testomgevingen, “basis” netwerkdiensten en scenario’s waarin een domein niet past (of simpelweg niet bestaat).
Wat betekent een “certificaat voor een IP” — en waarom is dit nu belangrijk?
Een traditioneel TLS-certificaat bevat domeinnamen in het SAN-veld (Subject Alternative Name), zodat een browser of client kan controleren of de server waarmee hij verbinding maakt daadwerkelijk is wie hij zegt te zijn. Met de nieuwe optie kan de identificator in het certificaat een IP-adres zijn: de client valideert het versleutelde kanaal tegen dat IP-adres, en niet tegen een FQDN.
In de praktijk lost dit een veelvoorkomend probleem op: een HTTPS-dienst via IP benaderen — bijvoorbeeld een beheerconsole, een tijdelijk panel, een test front-end of een interne dienst die je kortstondig publiek maakt — zonder browserwaarschuwingen, zonder self-signed certificaten en zonder permanente “security exceptions”.
Let’s Encrypt geeft wel aan dat dit niet “voor iedereen” is. De meeste diensten blijven beter werken met domeingebaseerde certificaten, door de extra flexibiliteit (hostingwissels, load balancing, multi-site) en door gebruiksgewoonten. Maar voor wie écht HTTPS via IP nodig heeft, haalt algemene beschikbaarheid een drempel weg die admins en developers jarenlang heeft afgeremd.
De prijs van de vooruitgang: ultrakorte certificaten van 160 uur
De belangrijkste voorwaarde voor IP-certificaten is de verplicht korte geldigheid: 160 uur, iets meer dan zes dagen. Let’s Encrypt kiest hiervoor om een heel concrete reden: IP-adressen kunnen snel van eigenaar veranderen, zeker bij residentiële verbindingen (dynamische IP’s) en bij kortlopende deployments. Een “lang” certificaat dat gekoppeld blijft aan een IP dat de aanvrager niet meer beheert, zou onnodige risico’s creëren.
Deze aanpak sluit aan bij een bredere trend in de sector: de blootstellingsperiode verkleinen bij sleutelcompromittering of foutieve uitgifte, en automatisering gebruiken zodat rotatie routine wordt.
Hoe uitgifte werkt: ACME-profielen en validatie-uitdagingen
Voor het verkrijgen van deze certificaten vereist Let’s Encrypt dat de ACME-client ACME Profiles ondersteunt, en dat je expliciet het profiel shortlived aanvraagt. Het ontwerp stuurt sterk op automatisering en laat weinig ruimte voor handmatige setups die in de praktijk vaak “blijven liggen”.
Er zijn ook logische technische beperkingen: je kunt DNS-01 niet gebruiken om controle over een IP aan te tonen (er is geen DNS-record dat eigendom van een IP als primaire identificator bevestigt). Daarom is validatie beperkt tot:
- http-01
- tls-alpn-01
Praktisch betekent dit dat de server moet aantonen dat hij daadwerkelijk controle heeft over het endpoint dat via dat IP bereikbaar is om de challenge te halen.
Praktische use-cases: van homelab tot kritieke infrastructuurservices
Let’s Encrypt noemt verschillende scenario’s waarin dit zinvol is. Het patroon is duidelijk: omgevingen waarin een domein een luxe, extra kostenpost of simpelweg overbodig is voor het technische doel.
Veelgenoemde toepassingen:
- Veilige toegang tot diensten zonder domein, met als kanttekening dat dit minder comfortabel en fragieler is dan DNS-gebaseerd.
- “Default” pagina’s bij hostingproviders: als iemand een IP in de browser plakt en je zonder TLS-fouten wilt antwoorden.
- Infrastructuurdiensten zoals DNS over HTTPS (DoH) of andere endpoints waarbij een publiek certificaat clientvalidatie vereenvoudigt.
- Remote toegang tot thuisapparaten (NAS, IoT, lab-apparatuur) wanneer er geen domein aan gekoppeld is.
- Kortstondige verbindingen binnen cloud-infrastructuur (beheer of tijdelijke services), mits er een publiek IP beschikbaar is.
De onderliggende boodschap: het web is niet alleen “pagina’s”. Steeds meer diensten gebruiken HTTPS als veilig transport, zelfs als de eindgebruiker nooit een “mooie” naam in de adresbalk ziet.
Snelle tabel: wat verandert er met short-lived certificaten?
| Type certificaat | Identificator | Geldigheid | Profiel / aanpak | Wanneer geschikt |
|---|---|---|---|---|
| “Klassiek” | Domein (DNS) | 90 dagen | Standaard geautomatiseerde vernieuwing | Publiek web, stabiele services, hybride infra |
| Kort (gepland) | Domein (DNS) | 45 dagen | Opt-in en geleidelijke transitie | Teams die vaker willen roteren |
| Ultrakort | Domein of IP | 160 uur | Profiel shortlived (ACME Profiles) | Homelabs, tijdelijke omgevingen, direct IP-gebruik, tests |
Let op voor beheerders: zonder automatisering is dit niet werkbaar
De keerzijde van 160-uurs certificaten is evident: elke paar dagen vernieuwen is niet realistisch zonder een stevige automatiserings- en monitoringketen. Minimaal heb je nodig:
- geplande vernieuwing met voldoende marge,
- automatische uitrol van het nieuwe certificaat,
- alerts als vernieuwing faalt,
- en periodieke tests (bijvoorbeeld extern controleren als het endpoint publiek is).
Let’s Encrypt maakt duidelijk dat dit de richting is waarin ze het ecosysteem willen duwen. Hun roadmap wijst op een geleidelijke verkorting van de standaardgeldigheid van 90 naar 45 dagen, beginnend met vrijwillige adoptie en ondersteund door verbeteringen in tooling en processen.
Een kleine wijziging op papier, grote implicaties in de praktijk
Dat een gratis en massaal gebruikte certificaatautoriteit als Let’s Encrypt certificaten voor IP-adressen uitgeeft, gaat verder dan een leuke feature. In de praktijk normaliseert het een patroon: versleuteling “by default” ook zonder DNS, met een trustmodel dat leunt op snelle rotatie.
Voor gevorderde gebruikers is het effect direct: meer opties om services te bouwen en te exposen zonder onveilige shortcuts. Voor het ecosysteem is de boodschap dieper: de toekomst van TLS lijkt minder op “certificaat installeren en vergeten” en meer op “certificaten roteren zoals je secrets roteert”.
Veelgestelde vragen (FAQ)
Waarvoor dient een TLS-certificaat voor een IP als ik al dynamische DNS kan gebruiken?
Voor omgevingen waar je niet wilt — of niet kunt — leunen op DNS: labs, tests, tijdelijke endpoints, infrastructuurservices of directe toegang via IP. Een geldig publiek certificaat voorkomt security exceptions.
Waarom beperkt Let’s Encrypt deze certificaten tot 160 uur?
Omdat “eigenaarschap” of controle over een IP snel kan wijzigen (dynamische IP’s, herallocatie, tijdelijke infra). Een korte geldigheid beperkt het risico dat een certificaat geldig blijft terwijl de aanvrager het IP niet meer beheert.
Wat heb ik nodig om een IP-certificaat met Let’s Encrypt uit te geven?
Een ACME-client die ACME Profiles ondersteunt en expliciet het profiel shortlived kan aanvragen. DNS-01 is niet mogelijk; je gebruikt http-01 of tls-alpn-01, afhankelijk van je setup.
Hoe beheer je zulke korte certificaten in homelabs of dev-omgevingen?
Met volledige automatisering: ruim op tijd vernieuwen, automatisch uitrollen, alerts en doorlopende verificatie. Als het proces handmatig is, loop je al snel tegen expiraties en downtime aan.
Source: Cloud News