Gedurende tien jaar heeft webversleuteling zich gebaseerd op een eenvoudig idee: TLS-certificaten worden uitgegeven op domeinnamen, niet op IP-adressen. Maar die scheidslijn tussen “wat de gebruiker invoert” (een domein) en “wat daadwerkelijk het internet r perst” (een IP-adres) begint nu aan flexibiliteit te verliezen. Let’s Encrypt biedt nu al de mogelijkheid om geldige certificaten uit te geven voor IPv4 en IPv6, een verandering die het beveiligen van diensten zonder afhankelijkheid van DNS mogelijk maakt en tegelijk de sector stuurt naar een meer dynamisch vertrouwensmodel gebaseerd op automatisering en frequente verversingen.
Waarom is dit relevant: wanneer de dienst ‘direct’ op een IP woont
Let’s Encrypt erkent dat de meeste van haar abonnees nog steeds certificaten voor domeinen zullen blijven gebruiken — dat is de normale situatie: gebruikers identificeren diensten via namen, niet via IP’s. Maar ze geeft ook toe dat er situaties zijn waar de IP het praktische identificatiemiddel is of zelfs het enige beschikbare. Enkele voorbeelden die de organisatie zelf aangeeft:
- Toegang tot een dienst zonder domein, met minder gemak en betrouwbaarheid dan via DNS.
- Standaardpagina’s van hostingproviders, wanneer iemand een IP in de browser plaatst en nu een veiligheidswaarschuwing krijgt.
- Infrastructuurdiensten, zoals DNS over HTTPS (DoH), waar een publiek vertrouwd certificaat helpt bij verificatie en het versterken van beveiligingsbeleid op clients.
- Remote toegang tot thuisapparatuur (NAS, IoT) zonder domein.
- Ephemere verbindingen in cloudinfrastructuur, zoals back-end koppelingen of tijdelijke serverbeheer, zolang er een publiek IP beschikbaar is.
In de praktijk biedt dit een ‘schone’ optie voor labs, tijdelijke omgevingen, proof of concept-tests of deploying die, door hun aard, niet afhankelijk willen zijn van DNS voor het activeren van HTTPS.
De kerneis: certificaten moeten per definitie heel kort zijn
De tegenhanger is van groot belang. Let’s Encrypt stelt als beleid dat certificaten met IP-adressen “kortdurend” moeten zijn: een geldigheidsduur van 160 uur (ongeveer zes dagen). Dat is geen detail: het verplicht een volledig geautomatiseerd levenscyclus vanaf dag één.
Bovendien heeft de organisatie meestal deze optie voor IP en certificaten van 6 dagen voor domeinen algemeen beschikbaar gemaakt, wat de lijn onderstreept dat de toekomst van TLS ligt in frequentere verversing, minder lange blootstelling en minder afhankelijkheid van “lange termijn certificaten”.
Wat verandert er operationeel?
Voor het uitgeven van “short-lived” certificaten voor IP, moet de ACME-client ACME Profiles ondersteunen en het juiste profiel aanvragen (meestal shortlived). Met andere woorden: Het is niet genoeg om simpelweg “Certbot te gebruiken”. Er moet gecontroleerd worden of de client en de configuratie profiles ondersteunen.
Er is nog een belangrijke restrictie: DNS-01 kan niet gebruikt worden om controle over een IP te bewijzen. Let’s Encrypt beperkt de validatie tot HTTP-01 en TLS-ALPN-01. Dit is logisch: DNS bewijst controle over een naam, niet over een nummer.
De bredere context: van 90 naar 45 dagen (en de rol van automatisering)
Deze ontwikkeling past binnen de strategische koers die Let’s Encrypt al geruime tijd volgt: een wereld waarin certificaten standaard kortere geldigheid hebben. De certificeringsautoriteit heeft haar plan aangekondigd om van de huidige standaard geldigheid van 90 dagen te gaan naar 45 dagen, conform de industrietrend. In haar roadmap wordt 2028 genoemd als moment voor een volledige overgang, samen met initiatieven om automatische vernieuwing te ondersteunen (zoals ARI binnen het ACME-ecosysteem).
Kort gezegd: waar de veiligheid voorheen gebaseerd was op “uitgeven en vergeten”, richt het nieuwe model zich op “uitgeven, vernieuwen en voortdurend controleren”. Certificaten voor IP — door hun aard veranderlijk en door de herverdelingsrisico’s — zijn het ultieme voorbeeld van deze filosofie.
Snel overzicht: wat betekent dit?
| Type certificaat | Identificatie | Typische geldigheid | Ondersteunde validatie | Praktische implicaties |
|---|---|---|---|---|
| Standaard TLS | Domein | 90 dagen | HTTP-01 / DNS-01 / TLS-ALPN-01 (afhankelijk) | Automatisch te vernieuwen |
| Toekomstige TLS (roadmap) | Domein | 45 dagen | Zelfde als standaard | Meer automatisering, minder risico |
| Short-lived TLS | Domein | 160 uur | Afhankelijk van client/profiel | Zeer frequente vernieuwing, gericht op volledige automatisering |
| IP-gecertificeerd (Let’s Encrypt) | IPv4/IPv6 | 160 uur (vereist) | HTTP-01 / TLS-ALPN-01 | Ideaal voor labs/infrastructuur; vereist automatisering en controle |
(Profielen en vereisten hangen af van de ondersteuning door de ACME-client en de gekozen profielinstelling.)
Reële impact: meer veiligheid, maar minder ruimte voor improvisatie
Wat veiligheid betreft, is het argument stevig: met zeer korte certificaten wordt, bij een sleutellek of verificatiefout, de impacttijd drastisch verkort. Maar operationeel is de boodschap duidelijk: wie deze optie wil gebruiken zonder automatisering — zoals automatische vernieuwing, serviceherlading, monitoring — zal onnodige onderbrekingen kunnen krijgen.
Voor sectoren met veel zelfhosting, labs en tijdelijke infrastructuren is de strategie logisch: HTTPS wordt niet meer “synoniem voor domein”, maar voor “verifieerbaar controlepunt”, ook al is dat een IP.
Veelgestelde vragen
Waarvoor is een TLS-certificaat voor een IP-adres?
Om HTTPS mogelijk te maken wanneer direct via IPv4/IPv6 wordt verbonden zonder domein, of voor het beveiligen van infrastructuurendpoint waar domeinnamen niet praktisch zijn.
Waarom beperkt Let’s Encrypt deze certificaten tot 160 uur?
Omdat IP-adressen makkelijk kunnen veranderen of opnieuw worden toegewezen. Een korte geldigheidsduur vermindert het risico dat een certificaat nog actief is wanneer de IP niet meer onder jouw controle staat, en beperkt de impact van sleutelcompromis.
Kan ik een IP-certificaat valideren met DNS-01?
Nee. Let’s Encrypt geeft aan dat voor IP alleen HTTP-01 en TLS-ALPN-01 gebruikt kunnen worden, omdat DNS-01 controle over een naam bewijst, niet over een numeriek IP.
Wat is nodig om zonder problemen in productie te gaan?
Een ACME-client met ondersteuning voor ACME Profiles, automatische vernieuwing (cron/systemd), automatische herlading van diensten (Nginx/Apache/HAProxy, enz.), en monitoring van het uitgifte- en vernieuwingsproces.
Bron: Let’s Encrypt opent de deur naar HTTPS op IP