Let's Encrypt krijgt ondersteuning voor multi-perspective validation

Let's Encrypt gaat dit jaar ondersteuning voor multi-perspective validation invoeren. Dit moet voorkomen dat kwaadwillenden de validatie voor domeincontrole om de tuin leiden en onterecht een certificaat toegekend krijgen.

Let's Encrypt valideert nu nog uit perspectief van een enkel netwerk. Dat is standaard voor certificaatauthoriteiten, volgens de organisatie. Als een kwaadwillende een netwerkroute misbruikt zou in potentie een certificaat voor een domein onterecht afgegeven kunnen worden. Dit zou bijvoorbeeld kunnen na een man-in-the-middle-aanval via een bgp-hijacking.

Wie het beheer over een border gateway protocol-router heeft, kan in principe elke route aankondigen, die routers waarmee verbinding wordt gemaakt weer doorgeven aan andere routers. Het gebrek aan authenticatie bij bgp leidt potentieel misbruik en andere problemen. Volgens Let's Encrypt biedt voor de certificaattoekenning multi-perspective validation soelaas omdat dan uit perspectief van verschillende Autonomous Systems gevalideerd wordt en een aanvaller dus meerdere routes moet kapen voor een succesvolle aanval.

Let's Encrypt verwacht verdere groei dit jaar tot waarschijnlijk 120 miljoen actieve certificaten en 215 miljoen fully qualified domeinen. Begin februari stond de teller op 92 miljoen actieve certificaten en 157 miljoen gekwalificeerde domeinen.

Reacties (51)

This alleen onhandig bij wildcard certificaten. Je moet daarbij een dns txt record (was 2x, is nu nog maar 1x volgens mij) aanroepen om te valideren wat een handmatig klusje blijft omdat de textstring continue veranderd. Of valt dit wel te automatiseren?

Ik gebruik hiervoor CertifyTheWeb.
https://certifytheweb.com

Die automatiseert dat allemaal voor je en die kan gebruik maken van een ACME DNS server. Daarop worden de TXT records worden geplaatst.
Op je eigen DNS server van het domein waarom het gaat zet je 1 malig een CNAME reccord met verwijzing naar de ACME DNS TXT record.

Alles is te automatiseren.

Wat je eigenlijk wilt is een provider die een API aanbiedt op je domain/dns records. Gelukkig zijn dat enorm veel die zoiets hebben. Voor alle fatsoenlijke spelers in de markt zijn daar ook al kant-en-klare scripts voor aanwezig.

Het enige vervelende is dat je nooit precies kan zeggen wanneer een DNS verandering is doorgevoerd. Hoewel tegenwoordig binnen 4 uur zou moeten kunnen, kan dat dus ook pas de volgende dag zijn (caching niet meegenomen).

Uiteindelijk ben ik afgestapt van DNS validatie (nodig voor wildcard van LE), omdat je immers wilt doorgaan met zo weinig mogelijk downtime. Een ACME-challenge is veel eenvoudiger en kan je ook snel opzetten met iets acme.sh.

[Reactie gewijzigd door foxgamer2019 op 4 april 2019 23:00]

Het enige vervelende is dat je nooit precies kan zeggen wanneer een DNS verandering is doorgevoerd. Hoewel tegenwoordig binnen 4 uur zou moeten kunnen, kan dat dus ook pas de volgende dag zijn (caching niet meegenomen).

Ik geloof niet dat LE gebruik maakt van caching DNS-servers maar direct naar de bron gaat. Mijn scriptjes (die direct tegen mijn DNS-server praten) hebben maar een paar seconde nodig om alles te regelen. De meeste gebruikers hebben niet zo veel controle over hun DNS-server, maar dat is niet omdat het technisch erg moeilijk is maar omdat de meeste gebruikers dusver niet nodig hadden.
We doen steeds meer via DNS en dus begint het steeds handiger te worden om het beheer van DNS ook te automatiseren.

Persoonlijk gebruik ik altijd de certonly fucntie van certbot, met de webroot authenticatie methode. Normaal haalt de bot de webserver offline om vervolgens zelf poort 80 te kunnen claimen. Dat is ongewenst gedrag inderdaad. De certonly functie met webroot is de oplossing. Dit alles in een cronjob en je bent klaar.

Over wat voor soort downtime heb je het in dit geval? Een nieuw wildcard certificaat vraag je toch ruim voor de deadline van 90 dagen (bijv. 10 dagen voor verlopen) opnieuw aan?

Met DNS providers als Google ben ik overigens nog niet tegengekomen dat het verversen van DNS voor dit doel langer dan 5 minuten duurt.

[Reactie gewijzigd door Overv op 4 april 2019 23:47]

Ik heb nog nooit echt last gehad met DNS validatie om dat de renewal ver voor de einddatum gestart wordt en hoewel het de eerste keer misschien niet meteen raak is om dat de DNS change API en DNS zelf tijd nodig hebben, werkt het bij de eerstvolgende validatie update wel. En dan kan je ook live je certs swappen op je edge.

Het probleem met geautomatiseerd aanmaken van die entries via een API is dat weinig DNS providers het API token zo fijnmazig kunnen authoriseren dat je alleen deze TXT records mag aanmaken. Bij de meeste DNS providers kan je met dat API token het hele domein overnemen. In combinatie met het feit dat niet alle web developers een goede rechtenscheiding tussen de website en de letsencrypt setup hanteren zijn veel websites één klein gaatje in Wordpress verwijderd van totale overname.

Over het algemeen kan je met een API token niet een transfer doen en/of je gehele account hijacken. Het probleem is meer dat een web developer dus blijkbaar werkzaamheden doet wat hij/zij niet moet doen

In elk geval een valide argument m.b.t. security. Echter ben ik nog steeds van mening dat zoiets als Letsencrypt en automation enorm goede stappen zijn voor een bedrijf. Dat ze dat dan eventueel overlaten aan iemand die er geen verstand van heeft is natuurlijk jammer.

Dat is zeker weten te automatiseren. Er zijn een aantal grote domeinboeren die dit probleem ook al hebben oplost. Zo heeft Cloudflare een plugin gemaakt voor certbot die de Cloudflare API toepast om het betreffende TXT record aan te maken.

[Reactie gewijzigd door Destroyer998 op 4 april 2019 22:57]

In combinatie met TransIP is het te automatiseren.

Ik heb dat geautomatiseerd met dehydrated. Die voegt de bewuste TXT-records toe aan mijn zonefile mbv lexicon. Draait als een zonnetje in een cronjob!

Dat ziet er goed uit, ik zal deze eens checken

Mijn provider ondersteund ook de dns api, dus thanks voor alle tips.. heb ik weer wat te doen

Alles wat je handmatig doet valt te automatiseren, alleen soms is dat moeilijk / tijdrovend
https://xkcd.com/1319/

Ik zou graag zien dat de Let's Encrypt certificaten langer dan 3 maanden geldig zijn. Weet dat je de renew kan scripten maar je moet er toch op letten.

Nee juist niet, kort durende certificaten zijn juist veiliger. Ook omdat je dit iedere 3 maanden moet vernieuwen moet je juist dit proces gaan automatiseren zodat je nooit met een ongeldig certificaat komt te zotten

Je vergeet alleen wel dat dit een hoop gedoe met zich mee brengt als je applicaties gebruik maken van Certificate Pinning.
Heel leuk als ook dat webapplicaties zijn die bijgewerkt kunnen worden door hetzelfde auto-script, maar dat geldt echt niet voor alles.
Als voorbeeld: Ik heb enkele iOS/Android apps gepublished die Certificate Pinning gebruiken om zéker te weten dat via het juiste certificaat gecommuniceerd wordt. Het is met certificaten met een geldigheid van 1 jaar al bijna niet te doen, laat staan met certificaten van 3 maanden of minder.
Het probleem met 'Netive' applicaties is dat je gebruikers nooit kunt of mag verplichten om te updaten.

Je vergeet alleen wel dat dit een hoop gedoe met zich mee brengt als je applicaties gebruik maken van Certificate Pinning.
[...]
Als voorbeeld: Ik heb enkele iOS/Android apps gepublished die Certificate Pinning gebruiken om zéker te weten dat via het juiste certificaat gecommuniceerd wordt. Het is met certificaten met een geldigheid van 1 jaar al bijna niet te doen, laat staan met certificaten van 3 maanden of minder.

Dat doe je dan ook fout. Je moet in een dergelijk geval niet het certificaat pinnen, maar de public key, en instellen dat de public key een tijdlang hergebruikt wordt.

Voor sommige toepassingen zou dat inderdaad makkelijker zijn. Bijvoorbeeld voor WiFi met authenticatie via een RADIUS server. Nu staan er elke 3 maanden gebruikers aan de deur te kloppen dat de WiFi niet werkt, omdat ze niet door hebben dat ze op accepteren moeten klikken

Voor 7,50 dollar op jaarbasis gaan wij voor dit soort services nog niet eens beginnen aan LE.

Daarnaast zetten wij de Renew date direct in een (shared) Google agenda (een maand voor verloopdatum) voor systeem beheer.
Zodra een event op de agenda wordt bereikt, wordt hiervoor automatisch een work item aangemaakt en in de backlog geplaatst..

Tja, op het werk zou dat inderdaad geen probleem zijn.
Helaas is het op een scouting groep iets anders, daar krijg je al met moeite een 20/20 lijntje geregeld.

Daar heb je toch een cronjob voor? Draai heel wat domeintjes zonder daar verder naar om te hoeven kijken (buiten standaard onderhoud). Gaat al jaren prima.

Moet je wel zorgen dat certbot up to date blijft want de laatste wijziging zorgde ervoor dat oude certbots geen renewals meer konden doen.

Daar gebruik je dus certbot-auto voor, die werkt zichzelf bij

Maar ook dat bijwerken kan misgaan, zoals de laatste keer waar ze een breaking change hadden op een python package, dit raakte vooral wat oudere systemen. Voor de meeste situaties gaat het goed, maar werp een blik op het forum en zie op hoe enorm veel manieren het mis kan gaan.

Nu als ik het goed heb krijg je wel nog een mailtje voordat je certificaten vervallen. Als je 20 dagen voor de deadline nog niet hebt vernieuwd, dan hoor je het dus wel. Lijkt me meer dan genoeg om met een (tijdelijke) oplossing te komen.

Het voordeel is dat je relatief snel merkt als er een breaking issue is. Als je maar om het jaar of om de 2 jaar update... Succes met te achterhalen wat er nu precies veranderd is dat het kapot heeft gemaakt.

Perfect is het niet, maar het is toch een pak beter dan de oude manier. Hoeveel bedrijven hebben al niet voor gehad dat plots hun certificaat afgelopen is, terwijl de persoon die dit normaal in orde hield al 2 jaar het bedrijf verlaten heeft...

Je krijgt inderdaad een aantal malen een e-mail als je het certificate niet hebt vernieuwd. Vooropgesteld natuurlijk dat je een e-mail adres hebt meegegeven bij de aanvraag.

Het werkt heel netjes moet ik zeggen. Helaas heeft mijn provider geen API voor de DNS op dit moment dus moet ik de renewals handmatig doen, maar op zich is het appeltje eitje en kost het nog geen 5 minuten..

Je kunt ook de http api gebruiken voor domein verificatie

Nog niet voor een wildcard certificate, of het moet recent zijn veranderd.

Certbot-auto gebruikt voor zover ik weet zijn eigen venv, en is dus alleen afhankelijk van de basis python op je systeem. En de packages binnen de venv werkt hij automatisch bij (dit is het verschil met de reportage versies).

Ik heb er in ieder geval nog nooit problemen mee gehad, en draai het al jaren.

Of certbot uit de officiële repositories. Je moet ook je systeem up-to-date houden tegen kwetsbaarheden. Certbot wordt dan meteen meegenomen.

De versie uit de repo kan clashen met de versies van je eigen systeem, omdat hij dan afhankelijk is van de python-packages aldaar. Met certbot-auto heb je daar geen last van, want die heeft een eigen venv en werkt daarbinnen zijn packages netjes bij, zonder ooit een conflict te geven met de rest van je systeem.

Tsja, dat hoort bij het vak

Hoezo moet je er op letten? Volgens mij is het een best-practice om ook die monitoring te automatiseren, waarbij je er voor zorgt dat een cert iedere 2 maanden gerenewed wordt, en als er na 2 maanden en 1 week nog een oud cert staat, er automatisch een alarm af gaat.

Dat alarm heeft let's encrypt zelf al ingebouwd. In januari heb ik wat zitten spelen met dingen van mijn NAS naar een VPS te verplaatsen. Begin deze week kreeg ik vervolgens een mail van Let's encrypt dat een certificaat later deze maand zou verlopen, en dat ze aanraden om automatisch elke maand te vernieuwen.

Klopt. Als je een cert aanvraagt en een e-mailadres opgeeft krijg je 20, 10 en 1 dag voordat hij expired een e-mail. Daarnaast kan je gewoon constant je certs renewen, althans totdat je tegen de rate-limit aanloopt.

Er zijn inmiddels diverse management tools uit, zelfs voor de GUI. Ik vind het juist fijn, dat ze maar 3 maanden zijn, dit verhoogt namelijk mijn inziens de security.
Met betreffende management tools, zou je prima in staat moeten zijn, om dingen en te kunnen auto-deployen, en te kunnen monitoren.

Mijn ervaring is, dat wanneer je het goed opgezet hebt, er nog amper werk aan hebt.

Mijn ervaring is, dat wanneer je het goed opgezet hebt, er nog amper werk aan hebt.

Kan ik volledig onderschrijven. 't Is zelfs zó makkelijk dat je je al niet meer kan voorstellen dat je websites ooit níét op https draaiden.

Ik zou graag willen dat ze minder lang geldig zijn. Dat dwingt tot automatisering en dus minder fouten. Een week ofzo lijkt me lang genoeg.

En ik zou willen dat andere aanbieders dat ook gaan doen.

Als het i.p.v.3 maanden naar een jaar getrokken wordt, dan moet je nog steeds de certificaten laten vernieuwen. Dus als enig verschil is dat eens in de 3 maanden gedraaid moet worden i.p.v. 1 keer per jaar.

Ik zou graag zien dat de Let's Encrypt certificaten langer dan 3 maanden geldig zijn. Weet dat je de renew kan scripten maar je moet er toch op letten.

Moet je niet willen, puur om veiligheid. Ik zie liever dat je ze maandelijks moet vernieuwen zodat je zeker weet dat jouw certificaat niet elders al gekaapt is.

Waarom moet je er op letten als je het script?
Het script wat ik gebruik draait elke maand en bij elke reboot.
Checked op dat moment of er certificaten zijn die binnen 30 dagen aflopen en renewed die.
Checked of er certificaten zijn die al 30 dagen verlopen zijn en ruimte die op.

In 10 seconde tijd draait IIS met geupdate certificaten en heb er totaal geen omkijken meer naar.

Er zitten voldoende dingen ingebouwd om dat te voorkomen. Ikzelf doe nog een extra controle. In mijn agenda staat een herhalend item zodat ik eraan herinnerd wordt om een manuele controle te doen op SSLLabs bij een van mijn domeinnamen. Als daarbij de geldigheid ok is, dan is de kans zeer groot dat dit ook zo zal zijn bij de rest. Extra voordeel is dat ik dan ineens die laatste nieuwe veiligheidsaanbevelingen zie.

Er is een optie om ze langer geldig te laten zijn... heb dat al eens gedaan met een console app, kan tot 180 dagen volgens mij.

Zijn ze dat? Ik gebruik certbot, die doet alles automatisch vernieuwen. Ik dacht dat ze een jaar waren?

Is het komkommertijd?
Dit nieuws is voortgekomen uit een nieuwjaarsblog (dus 4 maanden geleden) met de plannen voor 2019.

Ik wist het niet, dus is er minimaal 1 user die wat nieuws heeft geleerd, dús was het een nuttige nieuwspost.

Tegenwoordig kan je ook bij veel hosting partijen automatisch Let's encrypt vernieuwen door de standaard Let's encrypt plugin. Mijn webhoster http://alfa-host.nl gebruikt namelijk Directadmin. Ik kan hiermee aangeven bij 'SSL certificated dat het certificaat automatisch moet worden verlengd. Ik ontvang wel notificaties van let's encrypt maar het systeem verlengd het certificaat steeds automatisch voor me zonder dat ik ook maar iets hoef te doen.

In het verleden moest ik steeds een lastige CSR code maken en daar zelf om denken, dat ging me echt de pet te boven en is erg lastig als je zelf dit niet zo vaak doet en er geen kennis van hebt. Let's encrypt is daarom voor mij erg gemakkelijk.

Ik gebruik voor mijn website Wordpress en heb de plugin Really simple SSL geinstalleerd. Deze zorgde er ook voor dat mijn website automatisch naar https gaat.

In het verleden moest ik steeds een lastige CSR code maken en daar zelf om denken

Certbot is beschikbaar in een vorm voor elk denkbaar platform en neemt dat ook uit handen.

.
Ik gebruik voor mijn website Wordpress en heb de plugin Really simple SSL geinstalleerd. Deze zorgde er ook voor dat mijn website automatisch naar https gaat.

Je kan ook gewoon in Wordpress de url voorzien van https, dan gaat het ook vanzelf.