TLS en SSL-certificaten zijn vanaf 2029 nog maximaal 47 dagen geldig

De geldigheid van TLS- en SSL-certificaten wordt de komende jaren verkort. Nu zijn de certificaten nog 398 dagen geldig; vanaf 2029 wordt dit 47 dagen. Zo moeten de certificaten veiliger worden. Onder meer Google, Amazon en DigiCert stemden vóór de wijziging.

De certificaten worden gefaseerd korter geldig. Zo zijn nieuwe certificaten vanaf 15 maart 2026 nog maar 200 dagen geldig. Een jaar later wordt dit gehalveerd. Op 15 maart 2029 wordt dit verder verkort tot 47 dagen. Dan moet ook de domain control validation, ofwel dcv, maximaal 10 dagen geldig zijn.

Het verkorten van de geldigheid van de certificaten is het gevolg van een stemming. Onder meer Amazon, DigiCert, Disig, D-Trust, GlobalSign, SSL.com, SwissSign, Visa, Apple, Google, Microsoft en Mozilla stemden vóór het besluit.

Volgens het voorstel is het veiliger om de certificaten korter geldig te maken, onder meer omdat de cryptografische algoritmes van een certificaat verouderd kunnen zijn en het daarom belangrijk kan zijn om snel over te stappen naar een nieuw algoritme. Als oude certificaten met onveilige algoritmes nog maanden of jaren geldig zijn, kunnen die certificaten zelf ook onveilig zijn. Sectigo, een van de partijen de het voorstel ondersteunt, zegt daarnaast dat de stap de gevolgen van man-in-the-middleaanvallen en datalekken bij certificaatverstrekkers verkleint.

Reacties (235)

[PixelPionier]

Je zet toch ook niet iedere 6 weken een nieuw slot in je voordeur omdat iemand misschien een foto van je sleutel gemaakt heeft en je dus niet weet of iemand dan binnen kan komen? Als je je sleutel verloren bent, dan zet je er nieuwe sloten in! Als je slot niet veilig is vanwege nieuwe inbrekerstechnieken, dan zet je er nieuwe betere sloten in.

Dit is nu de slotenmaker die zegt dat je iedere 6 weken nieuwe sloten moet nemen omdat sommigen (niet jij zelf maar anderen) te dom zijn om zelf actie te ondernemen en er mogelijk nieuwe inbrekerstechnieken kunnen komen waarvoor je huidige slot dan niet goed genoeg is.

Laten we vooral zelf niet meer moeten nadenken! Dat levert vast minder beveiligingsproblemen op......

[michaelkamen]

En iedereen die zegt "het is heel eenvoudig te automatiseren" heeft waarschijnlijk geen hardware of appliances te onderhouden die daar niet voor geschikt zijn...

[blinchik]

Klopt, maar die zullen zich wel aanpassen op termijn. Want dat zal wel moeten.

Dat gezegd zijnde vind ik het ook irritant dat de duurtijd minder zal worden en mij lijkt het niet echt dat zoveel security issues gaat oplossen. Als je certificaat gestolen is, markeer je dat als gestolen en dan wordt dit OCSP geblokkeerd. Daar wil je dan toch ook geen 47 dagen op wachten...

[Martijn.C.V]

Voor degene die ook nieuwsgierig zijn omdat er in het artikel enkel namen staan van die VOOR stemmen:
In alle reacties er geen enkele 'votes No'

https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/9768xgUUfhQ?pli=1:
Certificate Issuers
30 votes in total:
 * 25 voting YES: Amazon, Asseco Data Systems SA (Certum), Buypass AS, Certigna (DHIMYOTIS), Certinomis, DigiCert, Disig, D-TRUST, eMudhra, Fastly, GlobalSign, GoDaddy, HARICA, iTrusChina, Izenpe, NAVER Cloud Trust Services, OISTE Foundation, Sectigo, SHECA, SSL.com, SwissSign, Telia Company, TrustAsia, VikingCloud, Visa
 * 0 voting NO:
 * 5 ABSTAIN: Entrust, IdenTrust, Japan Registry Services, SECOM Trust Systems, TWCA

Certificate Consumers
4 votes in total:
 * 4 voting YES: Apple, Google, Microsoft, Mozilla
 * 0 voting NO:
 * 0 ABSTAIN:

[Reactie gewijzigd door Martijn.C.V op 16 april 2025 09:11]

[Khalid.]

Ik zie 5 partijen die Nee hebben gestemd.

[BGLAdmin]

Abstain betekend onthouden van stemming, niet tegen.
als je goed leest zie je staan 25 voor 0 tegen en 5 onthouden van stemming.

[Triblade_8472]

Onthouden van stemming is naar mijn mening ook gewoon nee, zonder nee te zeggen. Je weet namelijk dat je het niet tegen kan houden en wil niet te boek komen als de minderheid. Maar je staat ook niet geregistreerd als ja stemmer, mocht je dat anders problemen opleveren.

[BGLAdmin]

De partijen die zich onthouden hebben van stemmen zullen daar hun redenen voor hebben, van Entrust is die denk ik wel duidelijk zij hebben hun Publieke CA tak overgedaan aan Sectigo.
De andere vier die zich onthouden van stemming hebben dat uitgelegd in de conversatie die ook terug te vinden is
Als het zie je dat ze niet tegen zijn, maar ook geen voordeel voor hun sector zien.

[familyman]

Nee, het is meer, wat eruit komt vind ik prima.

[The Third Man]

Dat is dan inderdaad slechts jouw mening en die wordt ook niet eens breed gedeeld. In veel politieke systemen met stemmingen wordt onthouden of abstain gebruikt en daar hangt nooit de connotatie ‘nee maar niet letterlijk nee’ aan, er hangt slechts aan dat dit dus geheel in de lucht hangt.

[MilanSxD]

Men onthoud zichzelf van stemmen wanneer iets geen invloed op hen heeft.
Dit is voor Entrust in ieder geval het geval. De andere 4 heb ik geen ervaring mee.
Als de uitkomst geen invloed op je heeft, dan voegt jouw stem ook geen meerdwaarde toe.
Dus in plaats van ja of nee te stemmen, wat de belangen van andere partijen zou kunnen beïnvloeden, onthouden zij zichzelf van stemmen.
Dit is dus niet per definitie nee, anders hadden ze wel nee gestemd.

[phantom09]

Waarom niet tegelijk maximaal 1 dag geldig? Nee beter nog 1 uur geldig...

[duderuud]

Leuk als je 100 certificaten te beheren hebt op je bedrijf (zoals bij ons)...

[GertMenkel]

Dit is een goede reden om de komende vier jaar te pushen voor software en apparaten die ACME ondersteunen. Dat doet bijvoorbeeld Let's Encrypt, maar ook betaald certificaatleveranciers bieden tegenwoordig ACME aan. Mocht je huidige aanbieder dat (nog) niet doen, dan lijkt dit een uitstekend moment om daar achter aan te gaan (of alvast naar een leverancier te zoeken die je leven makkelijker maakt).

Er zijn genoeg gevallen te bedenken waar standaard ACME niet goed werkt (air gapped systemen, etc.) maar daar zullen de komende jaren waarschijnlijk genoeg alternatieven voor komen. Het verminderen van de levensduur heeft de meeste certificaatboeren al gedwongen om een gestandaardiseerde automatiseringsmethode toe passen, en dit zal hopelijk niet anders zijn.

[Reactie gewijzigd door GertMenkel op 15 april 2025 16:21]

[GeroldM]

Certificaten hebben bestaansrecht, omdat deze een mate van beveiliging bieden die nogal moeilijk te breken (brute-force) is. Er is volgens deze PDF echter ineens heel veel optimalisatie voorhanden middels het veel beter inzetten van steeds minder GPUs, maar toch succesvol zijn met breken in een veel kortere tijd dan eerder werd aangenomen, c.q. 'educated guesses'.

https://tosc.iacr.org/index.php/ToSC/article/view/12078/11919

De sprong naar voren aangaande het breken van encryptie die certificaten bieden...neigt naar het betwijfelen of het nog veel langer nut heeft om nog met certificaten aan de slag te gaan en nu al serieus uit te gaan kijken naar alternatieven voor encryptie. Zeker voor beveiliging van zaken die open staan naar het internet.

[deadinspace]

Er is volgens deze PDF echter ineens heel veel optimalisatie voorhanden middels het veel beter inzetten van steeds minder GPUs, maar toch succesvol zijn met breken in een veel kortere tijd dan eerder werd aangenomen, c.q. 'educated guesses'.

https://tosc.iacr.org/index.php/ToSC/article/view/12078/11919

Je haalt hier echt heel veel dingen door elkaar.

1) Die paper gaat over het optimaliseren van het brute-forcen van de KASUMI, SPECK, en TEA3 symmetric encryption ciphers. Dit zijn relatief oude ciphers met wat zwakheden die vaak met korte sleutels gebruikt worden in de range van 64 tot 96 bits. De papier onderzoekt hoe deze efficient te brute-forcen zijn met veel GPUs.

Dit is relevant, want deze ciphers worden wel gebruikt in GSM, RFID, en TETRA (draadloos communicatiesysteem dat wereldwijd veel gebruikt wordt door politie, brandweer, etc). Gebrekkige crypto komt helaas regelmatig voor in dergelijke systemen.

Maar het heeft NIKS te maken met het web, TLS, en de daarvoor gebruikte x509 certificaten, want deze ciphers worden daar helemaal niet gebruikt. Moderne TLS (1.3) staat alleen AES en Chacha20 toe, beiden met 128- of 256-bit keys. De hele paper is irrelevant in de web/TLS context.

2) De voornaamste conclusie van de paper is dat korte keys gevaarlijk zijn, vooral 64-bit keys, want deze zijn met de rekenkracht van moderne GPUs realistisch te brute-forcen:

Symmetric key encryption algorithms that use short keys appear in standards and many real-world applications making them susceptible to exhaustive key search attacks. [...] Thus, we strongly recommend avoiding keys shorter than 128 bits.

Maar TLS gebruikt minstens 128 bit voor de channel encryption, waarvoor brute-force voorlopig niet praktisch haalbaar is.

3) Je hebt het over "breken in een veel kortere tijd dan eerder werd aangenomen, c.q. educated guesses", oftewel better-than-brute-force-attacks. De paper biedt hier inderdaad een strategie voor, maar alleen voor KASUMI-64, en slechts met grofweg een factor 3 sneller dan brute-force. Dat is relevant in sommige situaties, maar valt compleet in het niet bij een upgrade naar bv een 128-bit key.

De sprong naar voren aangaande het breken van encryptie die certificaten bieden...

Er is geen sprong naar voren mbt "die certificaten". Certificaten gebruiken asymmetrische ciphers (RSA, DSA, ECDSA), die zijn weer heel anders. TLS gebruikt met name AES. Voor die ciphers zijn de afgelopen tijd geen schokkende zwakheden of sprongen vooruit op brute-force gevonden.

En al was dat wel zo, het afdwingen van grotere keys is dan prima mogelijk, en in het verleden al gebeurd (zoals in 2013, waar browsers voor RSA keys van ten minste 2048 bits zijn gaan afdwingen).

neigt naar het betwijfelen of het nog veel langer nut heeft om nog met certificaten aan de slag te gaan en nu al serieus uit te gaan kijken naar alternatieven voor encryptie.

De huidige crypto in certificaten is voorlopig voldoende. Langere keys gebruiken is ook makkelijk, en biedt heel veel bescherming. Het kost alleen iets meer rekenkracht.

(Wat op termijn wel een serieuze dreiging kan worden met name voor de asymmetrische crypto is quantum computing; maar zo ver zijn we nog lang niet, en op dat vlak wordt ook zeker al onderzoek gedaan naar alternatieven)

[willieverhoef]

Ofwel het moet automatisch of het wordt onmogelijk. En juist bedrijven die hiermee gemoeid zijn de uitgevers, waarschijnlijk kunnen ze deze kosten ook weer heerlijk doorberekenen aan de klanten.
Vind 47 dagen best kort voor de argumenten zie ze geven.

[Blokker_1999]

De uitgevers van certificaten zijn niet diegene die de certificaten bij eindgebruikers implementeren. Ook de certificaatuigevers gaan kosten maken die ze niet zomaar kunnen terughalen.

En 47 dagen is nog zeer lang, op langere termijn zal het nog korter gaan. Let's Encrypt geeft nu al optioneel certificaten die slechts 6 dagen geldig zijn. Dat is dus letterlijk elke dag je cert vervangen.

[OruBLMsFrl]

Voor de argumenten hier gegeven, zoals encryptie algoritme kunnen wisselen, is dat echt wat vreemd kort. In welk geval moet je nu binnen zes dagen van encryptie algoritme wisselen, laat staan twee keer op rij?
Maakt de infrastructuur wel heel afhankelijk van die aanbieders. Laat de grootste EU software leverancier SAP niet al te makkelijk certificaten wisselen, en nu vooral Amerikaanse bedrijven roepen dat we naar minder dan een jaar moeten.
Let op dat een nieuwe soort hash, laat staan encryptie algoritme, vele jaren peer review vraagt om ook maar een beetje cryptografisch serieus genomen te worden, en dan voor de implementaties ervan vaak ook nog jaren staan tot alle grote platformen mee zijn... SHA-3 was een jarenlange zoektocht en uitrol traag, voor RSA is er minstens al tien jaar ECC p521 als vervanger beschikbaar

[aikebah]

In welk geval moet je nu binnen zes dagen van encryptie algoritme wisselen, laat staan twee keer op rij?

Zie het meer als: als je moet wisselen dan is dat zo gepiept en is er (buiten hooggevoelige certificaten) geen reden om miljarden certificaten preventief in te trekken en op een revocationlist te plaatsen, want de max 6 dagen die de onveilige nog geldig zijn is een acceptabel risico in veel situaties. Revocationlist zelf kun je ook sneller weer opschonen, want expired certificaten hoeven daar niet meer op te staan, die zijn al niet meer geldig.

[F4RR3L]

Maar hoe moet dat dan gaan als je Extended Validation certificates e.d. hebt? (+ die zijn ook nogal duur, dus dat lijkt me dan 'kassa' voor die partijen? (dat zal wel niet, but it raises questions nonetheless))
Kunnen dat soort EV certs al met ACME overweg?

[Glashelder]

Waarom zou je die nemen? De meeste browsers doen daar toch niets meer mee dacht ik?

[orvintax]

Ben niet OP, maar voor sommige instanties/applicaties heb je dat wel nodig. Certificaten gaan verder dan de browser.

[Glashelder]

Zoals?

Het enig nut van een EV certificaat is toch ‘de groene balk’ ?

[keranoz]

Die groene balk is er zelfs al niet meer.

Maar, OV en EV certificaten worden ook gebruikt voor koppelingen tussen verschillende systemen van bijvoorbeeld overheden en banken.

Voorbeeld: https://www.logius.nl/onz...ening/toegang/pkioverheid

[JapyDooge]

Ik verwacht niet dat de PKIoverheid-certificaten ook meegaan met deze verkorting van maximale geldigheid; en dat ze ook client authenticatie blijven ondersteunen ook al bouwen deze partijen dat af.
Specifiek om die reden. Deze certificaten zijn dan ook enkel bedoeld voor M2M koppelingen en worden door browsers niet vertrouwd.

[F4RR3L]

Bijv. als je bedrijf iets doet met DigiD e.d. (of andere overheids aangelegenheden), of met banken, nouja, dat soort dingen dus (zoals orvintax al schreef, sommige instanties vereisen dat nu eenmaal)

[Reactie gewijzigd door F4RR3L op 16 april 2025 07:43]

[FF]

Pki overheid is nodig voor DigiD, die zijn nu 3 jaar maximaal geldig.
EV wordt vaak gebruikt om te bewijzen dat de organisatie echt eigenaar is, je bent dan echt gecontroleerd. Deze zijn nu slechts 1 jaar geldig.

Ik maak me zorgen over de automatisering rondom verlengen in installatie. Voor een website is dat eenvoudig. Maar heb je een koppeladapter die met tientallen verschillende leveranciers communiceerd en daarnaast ook ket cpa's werkt, dan heb je een heel grote uitdaging. Elke maand moeten dan tientallen partijen tegelijk jouw certificaat en cpa gaan vertrouwen.

En ik geloof niet dat de controle bij EV nog wel goed uitgevoerd gaat worden. Nu duurt de aanvraag van een EV al snel een week. Dus men is continue bezig met het aanvragen en vervangen van certificaten.

[JapyDooge]

Ik verwacht niet dat de PKIoverheid-certificaten ook meegaan met deze verkorting van maximale geldigheid; en dat ze ook client authenticatie blijven ondersteunen ook al bouwen deze partijen dat af.
Specifiek om die reden.

Deze certificaten zijn dan ook enkel bedoeld voor M2M koppelingen en worden door browsers niet vertrouwd.

[FF]

Als het niet voor PKIO (M2M) is maak ik me al minder zorgen ja.
En zoals ik verder gelezen heb, zou een EV ook moeten lukken als er een verificatie komt die voor een periode geldig is en niet per certificaat.

Maar het gaat wel extra werk opleveren.
Denk aan partijen die bij verschillende externe dienstverleners een dienst afnemen met een website.
Deze diensten hebben wel een FQDN en certificaat van de partij zelf. Alleen de partij kan het certificaat aanvragen en alleen de dienstverlener kan deze installeren.

[GertMenkel]

Ieder certificaat kan met ACME overweg mits de uitgever maar een serverimplementatie heeft. Voor EV zijn daar al verscheidene partijen voor zover ik weet. Jij betaalt bedrijf X een paarduizend euro om een mannetje langs te laten komen die zegt "dit bedrijf bestaat" en krijgt een jaar lang je account gevalideerd. Vervolgens praat je ACME-client tegen de servers van je certificaatboer en zolang je nieuwe certificaat niet langer geldig is dan de validiteit van je bedrijfscontrole/betaaltermijn, krijg je een nieuw certificaat.

Als je je certificaat per ongeluk lekt hoef je ook geen nieuwe controle aan te vragen (al zijn sommige certificaatboeren wel vervelend en moet je extra bijbetalen voor de anderhalve seconde werk om een certificaat te revoken). Je betaalt die bedrijven voor het valideren dat je bedrijf bestaat, niet voor een bestandje.

Nu is de certificaatwereld leugenachtig genoeg dat er vast een paar gaan proberen om hier extra geld mee te verdienen, maar er zijn genoeg concurrenten dat iedereen die verstandig is, eieren voor zijn geld kiest. Bovendien blijft Let's Encrypt gratis en zijn EV-certificaten in het verleden ook al onbetrouwbaar en verwarrend gebleken (wie is de echte Apple, Apple in Oregon of Apple in Delaware? Was het ING Bank of ING Monetary Services International?) dus voor de meeste bedrijven is er sowieso weinig toegevoegde waarde. Dat maakt het risicovol voor certificaatboeren om dit proces te vervelend té maken.

[Reactie gewijzigd door GertMenkel op 16 april 2025 09:53]

[aikebah]

Je certificaat kun je niet lekken, die is juist gemaakt om ongebreideld uit te delen. Wat je onverhoopt zou kunnen lekken is je private key die hoort bij de public key uit je certificaat en strikt geheim gehouden dient te worden.

Het certificaat is simpelweg je publieke sleutel en een verklaring van je CA dat de houder van het certificaat de enige instantie is die de bijbehorende private key kent. Het revoken van het certificaat is de erkenning dat dat niet langer het geval is of in ieder geval niet langer gegarandeerd kan worden (het revoken kan ook een preventieve reactie zijn op een onbewezen/onbevestigd mogelijk lekken van de private key).

[GertMenkel]

Okee, foutje, ik bedoelde de private key natuurlijk. Als je je certifaat niet verspreid heb je er zo weinig aan
Plus, het staat toch al in de certificate transparency log als het goed is.

[laurxp]

Ja, dat is allang een opgelost probleem. De validatie is namelijk onafhankelijk van het certificaat zélf: de automatische tooling kan dus bijvoorbeeld inloggen met een account dat al EV validatie gedaan heeft, waardoor dit kan worden meegenomen in het certificaat. Ook hoef je niet voor ieder certificaat opnieuw validatie te doen: EV validatie kan bijvoorbeeld gewoon een heel kalenderjaar geldig blijven.

[Jaldea]

EV is validatie op meer dan 1 punt, zoals telefonisch/mail + DNS + fileauth, dan moet dit wel ondersteund blijven voor een jaarlijkse lease, anders kan je dat elke ~50 dagen pushen.

[F4RR3L]

Ah, check, helder thnx

[elmuerte]

Ja natuurlijk. ACME is een protocol voor automatische certificaat vernieuwing. (Als voorbeeld) Een DigiCert zou hun eigen ACME server optuigen die certificaten kunnen ophoesten voor hun betalende klanten. Dan koop je dus bijvoorbeeld voor een jaar een EV certificaat abonnement. Als je dan door de keuring heen bent kan je bij DigiCert 3 jaar lang, elke ~40 dagen een nieuw EV certificaat ophalen.

[FF]

Waarmee er in mijn ogen geen toegevoegde beveiliging meer is.

[deadlock2k]

maar daar zullen de komende jaren waarschijnlijk genoeg alternatieven voor komen

Ik voorspel een massale teruggang naar self signed 10 jaar geldige certs, en al helemaal voor air gapped systemen.

[Reactie gewijzigd door deadlock2k op 15 april 2025 18:01]

[Blokker_1999]

Kan niet, geen enkele browser vertrouwd ze, krijg je altijd waarschuwingen die je mag wegklikken, want simpelweg het certificaat in je certstore steken zal niet voldoende zijn.

[uiltje]

Na ja een eigen CA en dan de root pushen dmv group policy is wel degelijk mogelijk. Als je toch self signed doet is een extra laagje ook weer geen enorm issue. En ook dat kan geautomatiseerd.

[Milt]

Maar dan nog gaat de browser het certificaat niet accepteren. Deze nieuwe regels worden namelijk ook in de broncode van de browsers geïmplementeerd. Als een certificaat dan een 'Valid Until' datum heeft die meer dan 47 dagen in de toekomst is dan zal de browser deze niet als geldig accepteren, ook al is het certificaat verder helemaal correct. Je zou dat nog een klein beetje kunnen manipuleren door de 'Valid From' datum nog in het verleden te houden want dat bepaald welke regels van toepassing zijn op certificaten. Maar uiteindelijk komt er een dag waarop het niet meer werkt.

[deadlock2k]

Je kan de root-CA installeren als vertrouwde uitgever, daarmee voorkom je dat probleem.

ik gebruik nu op een aantal plekken, zoals voor onze SAML-vertrouwensrelaties, hetzelfde certificaat als wat ik op al onze andere public facing meuk heb staan. Mooi lijstje SANs erin. Heel veel software ondersteunt nu geen ACME en ik zie heel veel legacy-systemen ook niet snel ACME gaan ondersteunen. Ik heb nu dus jaarlijks een lijstje van 25 SAML-applicaties en handvol java keystores die geüpdatet moeten worden met het nieuwe certificaat; daar is wel wat in te automatiseren, maar niet alles. Er zijn zelfs SAML-applicaties tussen waarbij het niet mogelijk is voor de klant om zelf de metadata te updaten. Daarvoor moet je altijd een ticket inschieten.

We gaan het zien.

[Remzi1993]

Inderdaad, dat zou dus standaard de laatste 10 jaar geïmplementeerd hadden moeten worden in alle softwarepakketten en dergelijke. Dat dit niet is gebeurd laat al zien dat men het op deze manier moet forceren, blijkbaar doet men dit uit eigen beweging niet terwijl het wel allemaal goedkoper maakt.

[hbvdh]

Er zijn genoeg gevallen te bedenken waar standaard ACME niet goed werkt (air gapped systemen, etc.) maar daar zullen de komende jaren waarschijnlijk genoeg alternatieven voor komen.

Air gapped systemen zijn of kunnen beter via een interne CA geregeld worden, ze hangen immers niet aan internet dus heeft verificatie met 3party certifcaten ook niet veel zin.

[familyman]

Ik heb op mijn homelab airgapped servers draaien. 1 vm spint op, haalt het certificaat, en verspreidt het naar alle andere servers.

Ik doe het met bash en ssh. Maar acme naar interne server wijzen, zou wel cool zijn. Ik denk ook dat er zat zero trust systemen zijn die automatisch certificaten verspreiden.

[deadinspace]

Ik heb op mijn homelab airgapped servers draaien. 1 vm spint op, haalt het certificaat, en verspreidt het naar alle andere servers.

Ik doe het met bash en ssh. Maar acme naar interne server wijzen, zou wel cool zijn. Ik denk ook dat er zat zero trust systemen zijn die automatisch certificaten verspreiden.

Airgapped betekent dat er geen netwerkverbinding bestaat tussen dat systeem en de rest. Dat maakt alle aanvallen via het netwerk onmogelijk.

Certificaten genereren en pushen over het netwerk is dus absoluut GEEN airgapping.

[kodak]

Het punt is dat er momenteel niet zomaar goed algernatief in processen of tools voor is. En ik lees niet dat daar echt rekening mee is gehouden. Terwijl men zowek voor die organisaties als gebruikers ondertussen de problemen veroorzaakt en daar zelf geen duidelijke verantwoording voor neemt. En het belangrijkste daarbij is dat het gebrek aan alternatief het dus niet zomaar veiliger maakt. Meer automatiseren is niet zomaar de oplossing voor tijdgebrek. Meer tijd van miljoenen eisen is niet zomaar een oplossing voor gebrek aan tijd en mensen.

[Jeoh]

Nu kan je het automatiseren, straks moet je het automatiseren

[Scriptkid]

automatiseren is leuk voor Https

Voor email auth is het wel iets lastiger gezien dat een big bang is vaak en als je hele clusters moet kan dat een uitdaging zijn.

[lenwar]

Het gaat hier specifiek om domeinvalidatiecertificaten communicatiecertificaten niet om authenticatiecertificaten.

Edit: Ter verduidelijking aangepast:
Ik probeerde te zeggen dat het dus alleen om certificaten gaat die gebruikt worden op webservers/mailservers/ftp-servers/enz. en niet om certificaten die gebruikt worden als authenticatie. (client certificates enzo)

[Reactie gewijzigd door lenwar op 15 april 2025 17:02]

[mrdemc]

Nee, het gaat hier om SSL/TLS certificaten. De domeinvalidatie waarop gedoeld wordt is het proces van het valideren van het domein, maar dat staat verder los van de maximale geldigheidsduur van SSL/TLS certificaten.

- SSL/TLS krijgt straks in 2029 een maximale geldigheidsduur van 47 dagen
- DV, OV en EV certificaten hebben allemaal validatiestappen waarvan de stappen respectievelijk cumulatief zijn:
- DV = Een certificaat uitgegeven op basis van de validatie van het domein/IP waarbij bevestigd wordt dat het systeem dat de aanvraag doet, ook toegang heeft tot de instellingen danwel inhoud van het endpoint waarvoor de validatie wordt aangevraagd. (DNS-01, HTTP-01, TLS-ALPN-01 challenges)
- OV = Domeinvalidatie + het valideren van de organisatie die eigenaar is van het domein en of deze organisatie ook daadwerkelijk de aanvraag heeft gedaan.
- EV = Domeinvalidatie, Organisatievalidatie + Diepgaandere validatie op basis van het fysieke adres, en of het bedrijf écht bestaat (Comodo praat dan bijv. over operationeel zijn voor een periode van 3 of meer jaar).

- De domeinvalidatie zal straks slechts 10 dagen geldig zijn. Dat betekent dat je als 'server' binnen 10 dagen een nieuw certificaat kunt aanvragen, zonder dat je daarbij opnieuw het domein hoeft te valideren.
- De OV/EV validatie stappen die daarbovenop komen blijven wel 398 dagen geldig, je zult dus de extra validatiestappen niet nodig hebben bij het verlengen van het TLS/SSL certificaat gedurende de eerste 398 dagen waarop je de 47-dagen geldige TLS/SSL certificaat wilt verlengen. Ná die 398 dagen zul je dan weer de extra validatiestappen moeten doorlopen.
- Alle typen SSL/TLS certificaten hebben een maximale geldigheidsduur van 47 dagen.

Certificaten voor mailservers hebben net zo goed een DV verificatiestap nodig, net als bij HTTPS. Echter zul je dat meestal doen aan de hand van de DNS-01 challenge verwacht ik waardoor het niet per sé 'lastiger' is dan bij HTTPS via de HTTP-01 challenge.

bronnen:
- https://groups.google.com...6A2Wmu0gUw/m/DHdyyp7EBQAJ
- https://comodosslstore.com/ssl-validation-process

[Reactie gewijzigd door mrdemc op 15 april 2025 17:06]

[lenwar]

Snap ik, maar @Scriptkid doelt, als ik hen goed begrijp, op authenticatiecertificaten. Dus niet "communicatiecertificaten". (dus niet de certificaten die je op webserver/mailserver/ftpserver/enzovoortsserver zet, maar volgens mij bedoelde hen certificaten die bedoeld zijn om mee te authenticeren (Dus bijvoorbeeld client-certificaten om als client naar een andere dienst te authenticeren.)

Allicht dat ik met 'domeinvalidatiecertificaat' een verkeerde term pakte omdat die term ook wordt gebruikt voor DV-certificaten

[Reactie gewijzigd door lenwar op 15 april 2025 17:02]

[mrdemc]

Zo had ik deze post nog niet begrepen; Maar dan begrijp ik inderdaad nu beter wat je bedoelde te zeggen

[lenwar]

Ik heb hem aangepast. Ik snap de verwarring. Ik zit zelf midden in de materie van het geheel, dus in mijn hoofd was ik helemaal duidelijk .

[Hansie9999]

dus in mijn hoofd was ik helemaal duidelijk

In mijn hoofd is altijd alles heel duidelijk, de rest (vooral mijn vrouw ) vind het gewoon nooit zo duidelijk dus daar ben je niet alleen in hoor

[Scriptkid]

Alleen heel vaak zijn dat de zelfde of chain,

Voorbeeld, je autodiscover cert gebruik je ook als SMTP cert voor TLS, en die is weer gebonden aan je MTA STS die weer gebonden is aan de webserver https waar hij op staat.

[lenwar]

Er is niets algemeens te zeggen over iedere situatie. Het is allicht een beter idee om de boel gescheiden te houden dan? En ook hier is niets algemeens over te zeggen.

[uiltje]

Client certificaten zijn vaak ook servercertificaten met een extra key usage. Dus voor de meeste server-to-server communicatie zal hetzelfde cert gebruikt worden. Er zijn natuurlijk ook certificaten waarbij dat niet opgaat maar dat zal voor redelijk specifieke toepassingen zijn...

[lenwar]

Klopt ja. Er is niks algemeens over te zeggen.

[FaLLenOnes]

M.b.t. je voorbeeld.

Client Authenticatie (EKU), wordt ook over een jaar uit de publieke TLS certificaten gehaald. Server to server communicatie zoals mTLS wordt ook iets anders.
https://www.sectigo.com/f...ntication-eku-deprecation

[Dennism]

Probleem is natuurlijk dat dit op heel veel plekken niet altijd te automatiseren is, niet alleen aan de software kant, maar ook bijvoorbeeld aan de hardware kant. Bij een vorig werkgever beheerden wij bijvoorbeeld hele vloten aan security gateway's, ieder jaar een certificaat erop is natuurlijk prima, 15-30 min werk. Maar niet te automatiseren met lets encrypt oid, als je dat dan ineens 7-8 per jaar moet gaan doen, kan ik me wel begrijpen dat dit vervelend wordt.

Want volgens mij is dat voorbeeld nog steeds niet te automatiseren, net als bijv. legacy software en andere zaken. Ik zal gister ook even op bijv /r/sysadmin te lezen, en daar kwamen ook al flink wat scenario's langs waar dit voor (veel) extra werk gaat zorgen, in plaats van het makkelijker en veiliger te maken.

[Reactie gewijzigd door Dennism op 15 april 2025 16:30]

[Woohooo]

Het hele idee van dit korte periode is om juist te gaan automatiseren. Als ik de reacties hier allemaal zo lees zijn er veel die nog niet aan automatisering doen via certbots / ansble achtige oplossingen.

Denk dat ieder bedrijf wel zijn uitdagingen heeft om nog een deel te automatiseren, maar de tijd is daar nog wel om dit te doen. Ook voor externe certificaten zijn er intussen amce tooltjes beschikbaar om het e.e.a. makkelijker te maken.

[Haribo112]

Certbot is leuk voor Let's Encrypt en dergelijke, maar probeer maar eens een Sectigo EV certificaat er mee te automatiseren... Extra leuk als je dat niet voor je eigen organisatie maar namens een klant moet doen. Alleen de communicatie om de benodigde DNS records aan te laten maken duurt soms al een week.

[feuniks]

Ik ben blond op dit gebied, maar iets als DNS records klinkt bij mij in de oren als een eenmalig iets dat je bij de initiële implementatie moet doen.
Daarnaast: als certificaten zo kort geldig gaan zijn, dan zullen de uitgevers van de certificaten ook aan de bak moeten om het proces zo eenvoudig mogelijk te maken (met uiteraard de veiligheid niet vergeten). Dit zal ook geheid de reden zijn, waarom het nog tot 2029 duurt om het helemaal in te voeren. Ze beginnen volgend jaar en dan is het voor sommigen een beetje een probleem, omdat ze het nu tweemaal per jaar moeten doen en langzaam wordt het steeds meer werk voor de organisaties die niet slimmer gaan werken.

[VHware]

Het ACME protocol met DNS challenge vereist TXT record met daarin de oplossing van de gegeven challenge. Daarmee wordt geverifieerd dat he eigenaar bent van het domein en wordt bij elke aanvraag gedaan.

[Arfman]

Haha, ga maar eens certificaten automatiseren in Centric onprem software. Good luck

[SkiFan]

Of Dynamics 365 on-prem. Ook nooit gevonden hoe we dat moesten automatiseren. Maar het was wel ellendig veel werk.

[SuperDre]

Maar ik besteed mijn tijd liever aan andere belangrijke zaken, heb het al druk zat.

[-Vasa-]

4 jaar is wel erg kort om dat in alles op die manier in orde te krijgen. Zeker voor niche-hardware die bereikbaar is via een browser om deze te besturen.

En acme tooltjes zijn allemaal goed en wel, maar in een windows omgeving heb je geen officiële MS tools om dit te doen. Maar MS heeft ook voor gestemd, dus hopelijk komen zij hier dan snel mee af. Uiteindelijk gaat het om servers die bereikbaar zijn via het internet, dus daar een 3d party tool op zetten om dit te doen, lijkt mij niet aanvaardbaar.

[lenwar]

Klopt. Ofwel, bij je (hardware)leveranciers aankloppen dat je een aanpassing aan de API's wil hebben om certificaten te kunnen vervangen. Ik zou het overigens nu ook al niet zien zitten om 1x per jaar 'hele vloten' aan apparaten met de hand te moeten doen.

Nou weet ik natuurlijk niet hoe je handmatige handelingen er nu uit zien, maar er is over het algemeen verbazingwekkend veel te automatiseren als je out of the box redeneert. (alleen oppassen dat het niet teveel hack en slash werk wordt )

[Dennism]

Nou weet ik natuurlijk niet hoe je handmatige handelingen er nu uit zien, maar er is over het algemeen verbazingwekkend veel te automatiseren als je out of the box redeneert. (alleen oppassen dat het niet teveel hack en slash werk wordt )

Ik werk daar nu niet meer, dus hoe het nu gaat durf ik niet met 100% te zeggen. Ik heb echter nog wel zo'n apparaat staan en het lijkt niet veranderd tot op heden. Maar dat was simpelweg inloggen op het apparaat, CSR maken, deze exporteren. Dan je CSR indienen (dit kan je natuurlijk wel (deels) automatiseren door CSR's bijv. in batches te verwerken). En dan het geleverde certificaat importeren en activeren op de appliance.

Was wel allemaal uurtje factuurde, dus dat scheelde wel.

[Reactie gewijzigd door Dennism op 15 april 2025 16:43]

[lenwar]

Maar de betreffende apparaten hebben niet gewoon een REST-API ofzo? De meeste zakelijke hardware heeft wel iets van automatiserings-mechanismen. (mijn privé-printertje heeft dat niet in elk geval )

[Dennism]

Destijds in ieder geval niet voor certificaat beheer, wij (en vast ook anderen) hebben dat toen uitgebreid besproken, maar het aanmaken van een CSR op het device en het inlezen van het certificaat kon / kan alleen handmatig.

Voor andere (management) zaken hadden ze al weer een API, al kon daar ook niet al het andere mee.

[lenwar]

Ik bespeur een feature-request

[The Zep Man]

Destijds in ieder geval niet voor certificaat beheer, wij (en vast ook anderen) hebben dat toen uitgebreid besproken, maar het aanmaken van een CSR op het device en het inlezen van het certificaat kon / kan alleen handmatig.

Alles is te automatiseren. Ook handelingen door gebruikers. Je zal moeten investeren. Je moet er misschien een systeem omheen bouwen. Je moet goed testen om het geheel robuust te maken. Maar het is te automatiseren.

Anderen die claimen dat het niet kan hebben te weinig ervaring en/of creativiteit. Degenen met meer ervaring zullen wellicht roepen dat het "te duur" is. Ook "te duur" is relatief, zeker als de deadline eraan komt. De TLS klok stopt voor niemand en onder toenemende druk wordt alles vloeibaar.

[Reactie gewijzigd door The Zep Man op 15 april 2025 18:28]

[WhiteDog]

Handmatig? Je klikt toch ergens op enzo? 20 jaar geleden genoeg zotte dingen geautomatiseerd met bv. AutoHotKey. API's had je toen nog niet echt 😇

[Remzi1993]

als je dat dan ineens 7-8 per jaar moet gaan doen, kan ik me wel begrijpen dat dit vervelend wordt.

Waar een wil is is een weg, dan moet dat dus aangepast worden. Organisaties gaan dan naar de kosten en baten plaatje kijken en dan zie je dat het wel dus kan. Als de kosten hoger worden dan het aanpassen en automatiseren dan gaat men dat wel doen.

[Z80]

8 keer per jaar een cert kopen. De tijd om deze op de hardeare te zetten.
DUUR. Laat maar verlopen dat cert.
Zeker in het mkb gaat het deze oplossing worden.

[Remzi1993]

Totdat het er honderden zijn. Er is altijd wel een grens wanneer men dit gaat automatiseren.

[The Lord]

Wel een uitdaging met airgapped omgevingen.

[Remzi1993]

Wel een uitdaging met airgapped omgevingen.

Dan heb je sowieso geen TLS certificaten nodig lijkt mij? Ik kan het mis hebben als web developer en student software engineering.

[Magiciano]

Ook op airgapped netwerken wil je kunnen authenticeren wie je communicatiepartner is (oa interne dreiging). Daar wordt vaak met self signing en/of eigen trust store gewerkt.

[Remzi1993]

Ook op airgapped netwerken wil je kunnen authenticeren wie je communicatiepartner is (oa interne dreiging). Daar wordt vaak met self signing en/of eigen trust store gewerkt.

Ja, dat dacht ik al. Vaak gebruikt men inderdaad self signed certs daarvoor.

[uiltje]

Of een heel eigen CA omgeving natuurlijk. Er is zat OS software ondertussen om dat te maken en het kan ook met Microsoft spul als je daar in vast zit.

[Remzi1993]

Inderdaad, het is mogelijk en voor intern gebruikt lijkt dat mij het beste. Alles in eigen beheer. Extern moet je helaas kopen, vooral bij code signing en dergelijke. Maar voor websites zou ik echt Let's Encrypt gebruiken, dat wil je niet handmatig doen.

[uiltje]

Inderdaad, je kan niet verwachten dat iedereen maar je certificaat gaat trusten. Het kan natuurlijk wel handig zijn voor intranet site, waar je controle hebt over de PKI en het trusten van root certs e.g. via Active Directory / Group Policy.

[ZinloosGeweldig]

Daar wordt vaak met self signing en/of eigen trust store gewerkt.

Sowieso per definitie geen publieke CA's. Ik moet het eerste airgapped systeem dat revocation online kan checken nog tegenkomen in elk geval

[Reactie gewijzigd door ZinloosGeweldig op 15 april 2025 23:33]

[SunnieNL]

Wordt lastig controleren op de revoke lijst als de machines niet naar buiten kunnen.
Binnen airgaped systemen worden veelal interne certificaten gebruikt die van een eigen CA komen binnen dat airgapped netwerk. Dus die heb je helemaal zelf in de hand.
Vermoedelijk moeten die systemen wel meegaan met deze beslissing omdat browsers hier naar zullen gaan kijken, maar binnen een airgapped netwerk is dat goed te automatiseren.

[Martijn.C.V]

Dan hebben we het over innovatieve oplossingen als postduif met een ID kaart

[mrdemc]

StepCA
Airgapped zal er toch alleen toegang zijn door systemen die ermee kunnen verbinden en dus als het goed is onder controle staan.

[Reactie gewijzigd door mrdemc op 15 april 2025 16:54]

[lenwar]

Niet meer dan nu, alleen wat vaker.

Let wel dat de controle op 'browsers' zit. (versimpeld gezegd) dus als je in die air-gapped omgeving geen browsers gebruikt is er niet zo veel aan de hand.

[SgtElPotato]

Dus je beheert 100 certs maar doet dat met de hand? Een handmatige controle na een automatische renewal is prima, maar echt met de hand vervangen??

[Marve79]

Interne certificaten worden bij ons automatisch vernieuwd door de interne PKI, maar externe certificaten moeten inderdaad allemaal handmatig worden vernieuwd.

[lenwar]

Dan zou ik toch is gaan kijken naar een andere CA. Er zijn zat commerciële CA's die ACME (of andere vergelijkbare protocollen) ondersteunen.

[Haribo112]

Bij Sectigo zijn daar enorme kosten aan verbonden. Ik had laatst al even bij ze geinformeerd, en alleen de setup fee was al 4k.

[lenwar]

https://www.sectigo.com/47-day-ssl <-- Misschien dat daar verandering in komt
Maar allicht kijken bij een andere CA? Ik weet niet wat voor 'perks' Sectigo allemaal heeft. Ik ken het bedrijf verder niet.

[Haribo112]

Weet ik ook niet precies, maar wij zaten al bij Xolphin voordat ik hier kwam werken. Xolphin is nu volledig overgenomen door Sectigo dus vandaar dat wij daar nu klant zijn. Overstappen kan natuurlijk maar is wel gedoe met de enkele tientallen certificaten die wij beheren.

[lenwar]

Dat valt toch een mee? Die oude certificaten blijven het gewoon doen.

Hooguit met CAA-records even oppassen. De primaire risico's zijn administratief.

[VHware]

Dan zou ik bij een partij als GlobalSign de dienst Managed SSL afnemen waarbij verificatie niet per los certificaat gaat.

https://support.globalsig...-ssl/managed-ssl-overview

NL Handleiding:
https://media.globalsign....sl-quick-start-guide-v5.0

Verder volledig integratie met Azure Key Vault mogelijk, waardoor er nergens handmatige stappen nodig zijn voor certificaataanvraag en automatische verlenging.

https://www.globalsign.co...guide-azure-key-vault.pdf

[n9iels]

Ik neem aan dat je die 100 certificaten toch niet met het handje vervangt dan? 😅 Zoja, goede incentive om dat eens te automatiseren

[JapyDooge]

Dit is met partijen die veel koppelen m.b.v. mTLS wel een uitdaging; daar is (nog) niet echt een veelgebruikte standaardmethode voor en gaat vrijwel altijd nog met de hand qua wijzigingen.

[mobrockers]

Dit is helemaal niet relevant voor mTLS. Dit gaat om browsers.

[JapyDooge]

Voor mTLS worden zeer vaak dezelfde X.509 certificaten gebruikt die ook voor de host zelf worden gebruikt. En zelfs al zou je er een apart certificaat voor aanschaffen met enkel client authenticatie, dan loop je tegen dezelfde issue aan. Meerdere certificaataanbieders gaan binnenkort zelfs stoppen met het ondersteunen van client authenticatie in X.509-certificaten. Absoluut een issue.

[mobrockers]

Je hebt 0 voordeel aan publieke certificaten voor mTLS. Publieke certificaten zijn voor publiek verkeer. mTLS is per definitie private verkeer, je kent elke cliënt direct. Waarom zou je daarvoor betalen?!? Maak je eigen ca, sign je eigen cliënt certificates. Logisch dat certificaat boeren ermee stoppen want het is een onzin dienst. Ik heb echt nog nooit gehoord dat iemand hier publieke certificaten voor inzet.

[aikebah]

Voor mTLS hoef je niet per se zelf de certificaten uit te delen. Je kunt ook prima met je klanten op een vertrouwde manier informatie uitwisselen over het te gebruiken certificaat dat ze zelf moeten regelen.

1e onboarding (en heractivatie na verlopen zonder tijdige vervanging door een nieuw certificaat) via een separaat validatieproces om je klant en hun certificaat betrouwbaar te linken; vernieuwing tijdens de looptijd middels authenticatie op basis van nog geldig mTLS om te valideren voor wie het nieuw aangeleverde certificaat trusted moet zijn.

[JapyDooge]

Waarom zou je daarvoor betalen?!?

Zoals ik al aangaf worden vaak dezelfde certificaten gebruikt die je toch al nodig hebt; maar ook waar je er een apart certificaat afneemt kan er een goede reden zijn.
Als de private key lekt en er kan op dat moment om wat voor reden dan ook geen direct contact zijn (weekend, vakanties, noem maar op); dan kan de eigenaar het laten intrekken. Dat lukt je niet met een self-signed certificaat bijvoorbeeld.

Maak je eigen ca, sign je eigen cliënt certificates.

Dit is mogelijk nog problematischer; want dan moet de andere partij jou CA vertrouwen (en er vanuit gaan dat jij betrouwbaar genoeg bent om die te beheren) + komt er een complete rol CA beheer bij welke via het internet bereikbaar is (in ieder geval de CRL). Dat is een enorme hoeveelheid complexiteit voor een relatief simpele authenticatiemethode. Een eigen CA werkt prima intern bij dezelfde organisatie zonder al te veel risico, maar daarbuiten voegt het een boel complexiteit toe.

Ik heb echt nog nooit gehoord dat iemand hier publieke certificaten voor inzet.

Dan werk je waarschijnlijk in een andere markt dan mij, maar in de publieke sector of alle bedrijven die er mee koppelen is dit zéér gebruikelijk en eerder regel dan uitzondering, en is mTLS met een certificaat uitgegeven door een vertrouwde leverancier hiervoor vaak een eis. Veel hiervan zullen voor dit soort koppelvlakken moeten overstappen op het gebruik van PKIoverheid-certificaten - die specifiek hiervoor waarschijnlijk langer geldig zullen blijven en client authenticatie blijven ondersteunen; zonder technische meerwaarde maar wel een zeer veel hogere kostenpost.

[Blokker_1999]

Oh jawel, elke 2 jaar een weekje werk voor enkele mensen om zeker te zijn dat alles in 1 keer vervangen wordt. En het publieke certificaat dat 1 jaar geldig is, is elk jaar een feest.Project om te automatiseren stond dit jaar al in de stijgers en zal nu wat meer prio krijgen.

[pennywiser]

Hoe gebeurt dat nu dan?

[ShitHappens]

Dan is het een mooie reden om te kijken naar auto-renewing certificates echt 0 gezeik meer mee sinds we die toepassen waar mogelijk

[Travelan]

Dan lijkt het mij verstandig te gaan automatiseren, iets wat je m.i. al lang geleden had moeten doen als je meer dan 100 certificaten onder beheer hebt!

[Remzi1993]

Inderdaad, ik zou als ICT-er gek worden als ik dat soort hoeveelheden handmatig zou moeten doen. Als het salaris gemiddeld is zou ik zelfs overwegen om naar een andere baan te zoeken. Geen haar op mijn hoofd dat ik zoveel handmatige werk ga doen, dan moeten ze mij goed betalen.

[Reactie gewijzigd door Remzi1993 op 15 april 2025 20:13]

[klakkie.57th]

Dan moet de onderliggende hardware dit toch echt ondersteunen wat echt heel vaak nog niet zo is en al helemaal niet als het gaat om niet publieke dns names

[Reactie gewijzigd door klakkie.57th op 15 april 2025 18:56]

[Travelan]

Welke hardware ondersteunt dit anno 2025 nog niet..? Voor niet publiek (c.q. intern) lijkt me een interne PKI een prima oplossing?

[Reactie gewijzigd door Travelan op 15 april 2025 21:31]

[klakkie.57th]

Voorbeelden die ik zo meteen weet.

UPS, Noodgenerator, sturing van cooling, loadbalancers, switches, brandcentrale, oudere IPMI

Vervolgens allerhande software, ik denk zelfs dat iets als een Microsoft sql server 2016/2019 dit ook niet kan, idem voor de reporting server.

Als vervolgens browsers niet langer certificaten ondersteunen met een langere geldigheid dan houdt het snel op.

[Travelan]

Wat bedoel je met 'dit'? Sowieso dat MSSQL Server scriptable een SSL certificaat kan vervangen. Daarnaast denk ik niet dat het verstandig is om dingen als een noodgenerator of brandcentrale kaal op het netwerk te hangen. Daar zet je typisch een gateway tussen, welke al je problemen met certificaten voor je op zal lossen.

[klakkie.57th]

En wat is “kaal” zonder gateway op een netwerk, binnen hetzelfde vlan wil je toch ook encryptie.

Maar er werden voorbeelden gevraagd van devices die anno2025 nog in gebruik zijn en native geen ACME ondersteuning hebben, daar dus een lijstje van devices waarvoor je manueel een cert zilt moeten aanvragen en dat kunnen er best heel wat zijn binnen een onderneming.


Dan moet ik nog niet eens denken aan al de iot rommel

[Reactie gewijzigd door klakkie.57th op 15 april 2025 23:00]

[Remzi1993]

Leuk als je 100 certificaten te beheren hebt op je bedrijf (zoals bij ons)...

Daarom dat je dit moet automatiseren, als dat je nog steeds niet is doorgedrongen als organisatie dan denk ik dat er op ICT gebied nog meer misgaat.

Dit is al 10 jaar bekend dat certificaten en dergelijke op 1 plek moet beheren en automatiseren, als je dit nog handmatig doet dan verdien je het als organisatie om nu op de blaren te zitten. Zo vaak als ICT-er gezegd tegen verschillende werkgevers. Elke keer weer komt dit aan bod. Dit is goed dat browsermakers dit niet meer gaan accepteren, eindelijk.

[Knorretje63]

Inderdaad...., leuker kunnen we het niet maken..

[dimdek]

Zoveel wijzigingen worden verkocht als ǘeiligheidsmaatregelen' terwijl ze vooral dienen om de macht van de grote techbedrijven te vergroten.
Recaptcha is er ook zo een; daarmee traint Google zij AI algorthmes terwijl wij het werk doen. Ondertussen wordt het verkocht als een veiligheidsmaatregel.

[friemelss]

Het is juist de bedoeling dat je automatiseer.
Dan kan je slechts nog bij enkele certificaat leveranciers terecht.

De business reden is niet veiligheid.
Zelfs een 1k RSA sleutel is nog nooit gekraakt (wel gestolen, nooit gekraakt).
Er is geen heel goede veiligheidsreden voor verkorting levensduur.

De echte reden is dat de alleen BigTech (zoals LetsEncrypt) nog certificaten levert.
Als dan (zoals nu nog steeds) een validatie request naar de VA gaat, dan krijgt die VA de ping van jouw IP adres (met nog een aantal additionele gegevens) dat jij het certificaat van Audi.com of Volkswagen.com of BMW.com of Mercedes.com wil controleren.
Dan weet BigTech dat de reclamespace geveild kan worden tussen de Duitse autofabrikanten. Die reclamespace gaat dan veel meer kosten.
EN: het is een technische omzeiling van een mogelijk tracking cookie verbod.

Niet de website eigenaar is het product. Het is de bezoeker van de website die het product is.

Dat daardoor ondertussen de veiligheid op internet wordt ondermijnd, dat is collateral damage voor BigTech.
- jij wordt getracked
- de website eigenaar kan niet meer worden gevalideerd omdat dit niet is te automatiseren (daarom is de groene EV balk verdwenen). Dus foute websites kunnen hun gang blijven gaan. En dat is groeiende.

[markg85]

Kan iemand mij misschien vertellen wat een certificaat nou doet voor je site?
Ik weet de technische kant (je webserver), het zorgt ervoor dat je een ge-encrypte verbinding tussen de server en de gebruiker kan opzetten.

Maar garandeert het certificaat naast het hebben van die beveiligde verbinding nog meer?
Ik denk bijvoorbeeld aan:
- Garanderen dat de content die je krijgt ook de bedoelde content is van de developer (geen malicious content)
- Dat je site naam niet ineens in handen van een malafide partij is?

[xorinzor]

het garandeert je alleen dat je communiceert met de server die genoemd is in het certificaat, en dat alle content die je krijgt ook daadwerkelijk van die server komt zonder dat er tussentijds mee geknoeid is of dat iemand zich voor probeert te doen als.

Echter, dat is er vanuitgaande dat de private-key niet in kwaadaardige handen gevallen is, anders is een man-in-the-middle attack alsnog mogelijk.

Het doet dus niets voor als jouw domeinnaam in handen van iemand anders komt, zij kunnen dan met alle gemak ook gewoon een certificaat voor het domein verkrijgen zoals jij dat ook kan.

[Reactie gewijzigd door xorinzor op 15 april 2025 17:00]

[markg85]

Super, dankjewel de de duidelijke uitleg!

[friemelss]

Wat xorinzor zegt is juist.
Het zorgt voor een versleutelde verbinding (eenvoudig gezegd)
Maar er is meer.

er zijn verschillende soorten certificaten voor websites:

1. Domain Validated (DV). Dit checkt alleen maar dat het domein bij de certificaataanvrager onder controle is. Voordeel: dit is volledig te automatiseren. Nadelen: je kan niet weten wie de echte eigenaar van dat domein is. Die kan je dus ook niet aanklagen als dat een bewust bekwame slechterik is. Daarom is DV heel erg in trek bij frauduleuze partijen.

2. Organization Validated (OV). Dit checkt ook de organisatie die de certificaataanvraag doet. Iets beter dan DV.

3. Extended Validated (EV). Dit checkt de werkelijke eigenaar van het domein. Er zitten veel controles in. En juist dit was het soort dat vroeger het groene balkje gaf (wat mij betreft moet dat weer terug komen. Nadeel: dit is niet te automatiseren. Dus duurder. Voordeel: Maar geeft wel kennis van de eigenaar. En dus zullen bewust bekwame slechteriken hier niet (graag) gebruik van maken. Overigens: niets is perfect.

4. Qualified Web Authentication Certificaat (QWAC). Dit is een uitvinding (ontwikkeling) uit de Europese eIDAS verordening. Dit doet alles wat EV ook doet. Het grote verschil is de wettelijke erkenning en herkenning en doorwerking in alle BigTech die in Europa is uitgerold. Dat wil zeggen dat ook aansprakelijkheid is ingeregeld. En ook formeel Europees toezicht. Wil je echte (ook juridische) bescherming, dan ga je voor QWAC.

Een QWAC kan door BigTech niet in levensduur ingeperk worden. Dus géén 47 dagen voor QWAC.

[watercoolertje]

Maar garandeert het certificaat naast het hebben van die beveiligde verbinding nog meer?
Ik denk bijvoorbeeld aan:
- Garanderen dat de content die je krijgt ook de bedoelde content is van de developer (geen malicious content)

Als de verbinding veilig is zoals je zegt dan is toch ook uitgesloten dat andere de content aan kunnen passen?

Overigens sluit dat malicious content niet uit, alsnog kan de developer packages gebruiken in de backend of frontend van 3de die malicious code kunnen bevatten. Kan ook dat iemand javascripts van een 3de partij inlaadt via een CDN in de browser van de gebruiker, als die 3de partij de code dan aanpast dan krijgt de eindgebruiker dus ook die aangepaste code voor zijn kiezen.

- Dat je site naam niet ineens in handen van een malafide partij is?

Dat regel je in ieder geval niet met een certificaat.

[Reactie gewijzigd door watercoolertje op 15 april 2025 17:16]

[markg85]

Als de verbinding veilig is zoals je zegt dan is toch ook uitgesloten dat andere de content aan kunnen passen?

Dat denk ik dus niet. Je heb een beveiligde verbinding tussen A (server) en B (gebruiker). Maar de data die A naar B stuurt is simpelweg wat daar op die server als content van een site. Die content kan zomaar malicious zijn. Of anders verwoord, je server kan zijn gehacked. En zo zijn er nog wel wat manieren te bedenken hoe de data die je krijgt niet de data is die de site maker heeft bedoeld ondanks dat je verbinding veilig is.

Packages die malicious zijn is weer een andere variant. Dat is overigens ook een categorie waar de developer ook al de malicious content gebruikt maar het simpelweg nog niet weet. Dus die manier is wat verder gezocht dan ik bedoelde.

[yzf1kr]

Is dit om het veliger te maken, of is dit een nieuw verdienmodel?
Ipv 1x per jaar je certificaat vernieuwen, moet je het straks 10x per jaar.

[GertMenkel]

Als ze proberen er een verdienmodel van te maken, verdwijnt iedereen naar Let's Encrypt. Dat is sowieso voldoende voor de meeste mensen, dus ze moeten al behoorlijk op de prijs concurreren.

Overigens hoeft certificaatgeldigheid natuurlijk niet samen te hangen met abonnementsduur. Je kunt prima "een jaar lang certificaten" kopen met oneindig nieuwe certificaten binnen je jaartermijn.

[Remzi1993]

Als ze proberen er een verdienmodel van te maken, verdwijnt iedereen naar Let's Encrypt. Dat is sowieso voldoende voor de meeste mensen, dus ze moeten al behoorlijk op de prijs concurreren.

Het verbaast mij dan ook dat LE maar iets van 60% marktaandeel heeft (laatst even gecheckt), terwijl het voldoende is voor 99% van de online diensten en/of producten. Misschien zou je zelfs kunnen zeggen dat het wel 100% voldoende is maar ik heb gelezen en gehoord dat als je extended validation certs neemt er ook een soort van verzekering bijzit. Maarja, dat is alleen wanneer de cert partij nalatig is geweest.

Code signing en andere certs zal wel een ding blijven, maar voor websites lijkt mij dat LE echt voldoende is, bij extended validation is er ook geen groene balk ofzo meer, dat is ook weggehaald door de browsermakers dus het heeft volgens mij niet echt een nut, klanten merken ook geen verschil.

[Reactie gewijzigd door Remzi1993 op 15 april 2025 17:08]

[Cybje]

Als er geen LE wordt gebruikt, betekent niet meteen dat er voor een certificaat wordt betaald. Bijvoorbeeld bij Cloudflare kun je ook gewoon een gratis certificaat krijgen. Bij AWS dacht ik ook, als je hun certificate manager gebruikt.

[Polderviking]

Ik denk dat dat verdwijnen naar LE sowieso wel gebeurd met deze aanpassing eerlijk gezegd.

Dat certificaten langer geldig zijn is voor sommige mensen/toepassingen nog de enige reden om er voor te betalen in plaats van gewoon LE toe te passen.
Ik heb één zo'n applicatie waar ik nog certificaten voor koop, ondanks dat ik al vele jaren (sinds begin eigenlijk) op LE leun, omdat ik dat met de hand moet veranderen als die gaat verlopen.

Als je nu toch moet gaan automatiseren, wat hier de consequentie van gaat zijn, kan je dat net zo goed gewoon gelijk met LE/Certbot doen en faseer ik dat betaalde certificaat uiteraard gewoon helemaal uit door gebrek aan toegevoegde waarde.

[Reactie gewijzigd door Polderviking op 16 april 2025 14:32]

[lenwar]

Als je het op een goede manier doet (geautomatiseerd en goed dichtgetimmerd) is dit inderdaad veiliger. Iedere keer dat je met de hand een certificaat vervangt zijn er risico's (meer dan geautomatiseerd).

Door de certificaten sneller te laten vervallen is bij diefstal van het certificaat (incl sleutel) minder lang een probleem.

Voor mijn privé-certificaten (via LetsEncrypt) maakt het allemaal niet zoveel uit. Ik heb dat een aantal jaar geleden opgezet en nooit meer naar omgekeken, maar al zou dat ooit gecompromitteerd zijn, is dit niet heel spannend.

Als je nu naar de sites van Google of Facebook gaat, dan zie dat Google en Facebook al certificaten gebruikt van 3 maanden. Geloof maar dat ze dat niet doen, omdat het zo inspirerend is om certificaten te vervangen op al hun diensten. (het verbaast me overigens heel erg dat de Nederlandse banken, overheden en de SIDN het (nog) niet doen. Zeker die laatste is altijd zo bezig met beveiliging van het internet enzo.)

[Remzi1993]

Als je nu naar de sites van Google of Facebook gaat, dan zie dat Google en Facebook al certificaten gebruikt van 3 maanden. Geloof maar dat ze dat niet doen, omdat het zo inspirerend is om certificaten te vervangen op al hun diensten.

En dat hebben ze intern helemaal geautomatiseerd, ik snap niet waarom niet meer organisaties dit zo aanpakken. Je automatiseert dit in 1 keer en 1 keer opzetten en je hebt geen omkijken naar

[lenwar]

Ik werk even in de aanname dat meer bedrijven dit wel geautomatiseerd hebben, maar dat het nu dus gewoon alsnog jaarlijkse certificaten zijn. En dat laatste vind ik raar. Want jaarlijks op je hele webserver-park certificaten verversen is ook niet zo interessant om met de hand te doen

[Remzi1993]

Inderdaad, de meeste organisaties zijn de lange termijn oplossingen niet, ze vergelijken de kosten en baten en doen het niet. Terwijl de baten bijna altijd wel beter zijn op de lange termijn.

[cdwave]

Door de certificaten sneller te laten vervallen is bij diefstal van het certificaat (incl sleutel) minder lang een probleem.

Door de hogere frequentie van het vervangen is het ook waarschijnlijker dat er iets gebeurt.

Ik zou verwachten dat de meeste schade wordt aangericht in de eerste minuten na het "compromitteren". Verkorten van 300 naar 47 dagen zet dan weinig zoden aan de dijk.

[lenwar]

Dat ligt er volledig aan wat het doel is geweest van de diefstal.

Als het doel immiatie van de webdienst was (dus dat ik op mijn prive-server tweakers.net ga hosten met een sleutel en certificaat van tweakers.net), is dat compleet wat anders dan dat ik ga proberen om de versleutelde data ter ontsleutelen (dus ik heb een datastroom gestolen/ondervangen en ik wil er op een later moment naar kijken wat het allemaal is.)

Voor beiden zijn methoden het hele nut van het stelen van een sleutel überhaupt minder effectief te maken natuurlijk, dus m'n voorbeelden zijn allicht niet helemaal valide, maar wat ik dus wil aangeven, is dat het per geval verschilt wat je met een gestolen certificaat/sleutel kunt doen.

Persoonlijk zou ik overigens een voorstander zijn van nog korter dan 47 dagen voor bepaalde diensten (zoals webservers en mailservers en dat soort zaken.)

[Jeoh]

Verdienmodel voor wie? Je kan nog gewoon een certificaat voor x jaar kopen, je moet alleen wat vaker langs de certificatenboer om een nieuwe op te halen.

[Bender]

De meeste certificaten zijn gratis, daar is geen verdienmodel.
Het vernieuwen van certificaten is een automatisch proces (tenzij het niet geautomatiseerd is, maar dat kom ik al lang niet meer tegen).

[lenwar]

En straks betaal je per jaar, ipv per certificaat?
De aanjagers hiervan zijn niet alleen certificaatverkopers. Ook Microsoft, VISA, enz. zijn hier voorstanders van.

Buiten dat zijn er gewoon gratis TLS-certificaten beschikbaar.

[laurxp]

Ja, het is veiliger. En het verdienmodel is irrelevant, want juist de browsers zijn dit aan het pushen.

Het probleem dat ze willen oplossen is dat veel bedrijven niet in staat zijn om hun certificaten bij incidenten op tijd te vervangen: ze hebben er een hele bureaucratische rompslomp omheen gebouwd, waardoor zo'n proces al snel enkele weken kan duren. Dit zorgt er vervolgens voor dat CAs weigeren deze certificaten ongeldig te verklaren, want dan zou er "kritieke infrastructuur" offline gaan.

Door de geldigheid zo kort te maken is het in de praktijk onmogelijk om het niet te automatiseren, waardoor het vervangen van certificaten voor de meeste bedrijven niks meer dan een druk op de knop zal worden. Het is daardoor niet meer nodig om onveilige certificaten langer te blijven gebruiken dan strikt noodzakelijk.

[Microkid]

Dus dan moeten bedrijven straks elke maand hun certificaten vernieuwen? Dat zal een feest worden. En ook de particulieren? Ik heb een eigen SSL certificaat, mag ik dan straks elke 49 dagen 15 euro aftikken voor een nieuw certificaat? Ik zie dat niet zitten... Wat een onzin weer allemaal.

[pennywiser]

Je kent Letsencrypt nog niet?

[Microkid]

Jawel, maar ik wil niet dat ik een firewall poort open moet zetten zodat mijn Synology zelf certificaten kan updaten. Ik hou dat graag in eigen beheer.

[pennywiser]

Hoeft ook niet. Gebruik Cloudflare DNS challenge via hun API. Zone naar Cloudflare verplaatsen, wat sws handig is want dan kan je een domein tenminste nog eens verhuizen en hoef je niet alle DNS records over te tikken, maar alleen 2 naamservers aan te passen.

[Reactie gewijzigd door pennywiser op 15 april 2025 16:21]

[RobertMe]

Ja, lekker alles bij een grote Amerikaanse partij zetten.
Niet dat ik perse anti Amerika ben. Maar het halve internet hangt tegenwoordig al op aan Cloudflare, Amazon, Google, Microsoft (/Azure).

En er zijn ook gratis (Europese) alternatieven v.w.b. DNS. Zelf zit ik bv al jaren bij DeSEC (desec.io), een Duitse non-profit, en dat werkt al al die jaren prima. En dat is inclusief een API bij hun en vele ACME clients met ondersteuning voor hun API (als in, Traefik bv kan, via de LEGO Lets encrypt library, prima de DNS challenge uitvoeren door het record bij DeSEC te plaatsen).
En geeft verder dus dezelfde voordelen. Toen ik van TransIP naar mijn.host ben gegaan heb ik bij mijn.host de nameserver weer ingesteld op die van DeSEC en alles draaide prima verder zonder verder iets aan te passen. Net zo simpel als dat jij dus stelt met Cloudflare.

[pennywiser]

Cloudflare is ook gratis, DEsec ken ik niet, zal van hetzelfde laken een pak zijn. Mooi dat er keuze is.

[Freekers]

Tijd dat Synology DNS validation implementeert.

[pennywiser]

Gewoon recente certbot gebruiken?

[Yggdrasil]

Dat zit niet ingebouwd in Synology DSM. HTTP validatie wel.

[lodu]

DNS-01 challenge gebruiken, dat vereist geen open port.

Cloudflare Tunnel/Zero Trust zou ook een uitkomst kunnen zijn afhangend van je setup.

[Metalman]

Met DNS-01 challenge kan het ook zonder poorten open te hoeven zetten. Enige vereiste om het automatisch te doen is dat je DNS provider een API heeft. Maar dat hebben ze tegenwoordig bijna allemaal wel.

[dev10]

Ik weet niet of het mogelijk is met een Synology NAS, maar je kunt ook door middel van een DNS-challenge een Lets Encrypt certificaat aanvragen. Op de servers waar ik dit op gebruik, is de enige poort die open staat poort 22 op mijn eigen IP-adres.

Zie: https://letsencrypt.org/d...e-types/#dns-01-challenge

Ik gebruik dit al een poosje en hoef er dus nooit naar om te kijken.

[G-Meister]

Wellicht is ACME-DNS een oplossing voor je? Het lijkt erop dat er vanuit Synology niet directe support voor is, maar op het forum van Synology is wel een workaround te vinden.

[Room42]

Je denkt in problemen die er helemaal niet zijn.

Nee, je gaat geen 15 euro per 50 dagen betalen, je betaalt nu al per jaar, dat zal wel zo blijven.
Nee, je hoeft het niet met de hand te doen, dat is prima te automatiseren.
Nee, je hoeft je poort niet open te zetten voor Let's Encrypt, ook daar zijn alternatieve challanges voor.

[SourceUnknown]

Gebruik je ddns van Synology zelf? Dan hoef je poort 80 inbound namelijk helemaal niet open te hebben, dat staat niet duidelijk in hun eigen documentatie.

Als je geen gebruik maakt van ddns van Synology, dan zijn genoeg manieren van automatisering te vinden om over te stappen op Let's Encrypt die volledig op de NAS zelf kunnen draaien.

Zie voor context:

• https://www.synology-foru...uik-te-maken-van-port-80/
• https://www.christosgeo.c...n-synology-using-acme-sh/

[Reactie gewijzigd door SourceUnknown op 15 april 2025 21:59]

[Martijn.C.V]

Allereerst zou voor gewoon een particulier LetsEncrypt meer dan genoeg zijn en gratis. En dat is het voor veel bedrijven trouwens ook nog.

En als het nu 15eu voor 398 dagen, wordt dat echt niet 15eu voor 49 dagen... Mogelijk krijg je nog steeds bijvoorbeeld een jaar geldigheid, moet je alleen tussendoor vernieuwen. Een process dat automatisch zou moeten worden gedaan, dus in praktijk veranderd er ongeveer niets.

[happysan]

Toen men over ging van 3 jaar geldigheid naar 1 jaar hebben veel providers gewoon de optie voor 3 jaar geschrapt en niets gedaan met de prijs voor 1 jaar. Dus waar je eerder korting kreeg voor 3 jaar tegelijkertijd afnemen, kun je nu maar 1 jaar afnemen en betaal je dus altijd de volle mep.

[VHware]

De 3 jaar en 5 jaar opties zijn gebleven, alleen dan welk elk jaar “renewal” certificaat ophalen

[DDX]

En bij partijen zoals Comodo gewoon ieder jaar een telefonische verificatie doen als je meer wilt dan een DCV cert. (wat je straks ook wilt want 10 dagen is wel heel kort)
Ook al koop je hem direct in voor 3 jaar, je mag ieder jaar telefonisch valideren. (leuk bij sommige grote bedrijven die lastig bereikbaar zijn via algemeen nummer wat in gouden gidsen staat ed)

[VHware]

Dan zou ik bij een partij als GlobalSign de dienst Managed SSL afnemen waarbij verificatie niet per los certificaat gaat.

https://support.globalsig...-ssl/managed-ssl-overview

NL Handleiding:
https://media.globalsign....sl-quick-start-guide-v5.0

Verder volledig integratie met Azure Key Vault mogelijk, waardoor er nergens handmatige stappen nodig zijn voor certificaataanvraag en automatische verlenging.

https://www.globalsign.co...guide-azure-key-vault.pdf

[Reactie gewijzigd door VHware op 15 april 2025 17:07]

[lenwar]

Nee, je betaalt straks waarschijnlijk gewoon per jaar en dan mag je gedurende een jaar je certificaten een paar keer verversen. (goede kans dat je nu ook tussentijds je certificaat kunt vervangen als je hem bent 'kwijtgeraakt'). En mocht dat niet het geval zijn, dan ga je gewoon naar een ander die dat wel ondersteunt.

Dit mechanisme forceert automatisering wat voor 'veel' gewoon mogelijk is, en voor sommige dingen niet. Zeker bij consumentenapparatuur zie je dat het mogelijk problematisch is om het te automatiseren. (volgens mij ik op mijn Xerox printer niet via een API een certificaat pushen.)

[Marve79]

Nee zo werkt het niet, je kunt nu ook een certificaat kopen voor 5 jaar. Alleen om de zoveel dagen moet je terug naar de site om hem te vernieuwen maar je hoeft zeker niet opnieuw te betalen.

[GertMenkel]

Als je 15 euro aftikt voor een certificaat, heb je wel een hele dure partij gekozen. Veel partijen zullen je nu ook al binnen de periode die je hebt afgesloten (een jaar of twee jaar of meer) ook een nieuw certificaat geven, zolang die het einde van je afgesloten termijn maar niet overschrijdt. Als je 15 euro per jaar betaalt, zul je waarschijnlijk dus ook gewoon voor 15 euro per jaar je certificaten kunnen vervangen.

Voor het vervangwerk zelf heb je tools als Certbot die het vervangen voor je doen. Dat werkt met gratis certificaatboeren als Let's Encrypt, maar ook met betaalde certificaatboeren, middels het ACME-protocol.

[hbvdh]

Je kan nog gewoon bij de meeste certifcaat verkopers certificaten kopen voor meerdere jaren, alleen verlopen die nu na ongeveer een jaar en kun je onder dezelfde bestelling een verleging krijgen. Je koopt zeg maar de dienst voor drie jaar maar dat zijn dan nu dus drie certificaten.

[klakkie.57th]

Ik heb deze “fetisj” nooit zo goed begrepen. Als je private keys gecompromitteerd werden, heb je volgens mij een veel groter probleem dat je niet opgelost krijgt door even je cert te vervangen.

[CAPSLOCK2000]

Klopt, dat ben ik met je eens, het slachtoffer heeft grotere problemen. Maar voor de rest van de wereld is het mooi dat zo'n gestolen certificaat niet lang meer gebruikt kan worden.

[sharkzor]

Private key ook altijd hergeneren en oude intrekken? Opgelost

[ralphm]

Intrekken is het probleem hier. De mechanismen daarvoor zijn slecht ondersteund en foutgevoelig. Bij korte levensduur van certificaten omzeil je al die problemen.

[klakkie.57th]

Wat ik bedoel is dat je dan waarschijnlijk een groter veiligheidslek hebt … als men je private key heeft kunnen stelen.

[Reactie gewijzigd door klakkie.57th op 15 april 2025 20:57]

[aikebah]

Je hebt enkel een keer een kritiek zero-day lek a la heartbleed nodig om je private key te lekken (of een snellere brute-force van een bij een public key passende private key)

Alleen keyrotatie bij de cert renewal (waarom zou je private key niet renewen, dat gaat in een moeite mee in het scripted scenario) gaat het niet volledig oplossen, daarvoor zal ook de serverkant gepatcht moeten worden zodat de nieuwe key niet ook ontfutseld kan worden cq ander key algorithme waar brute-force vanuit de public key niet snel genoeg kan).

Zichzelf voordoen als de vertrouwde site is voor de dief niet langer mogelijk dan 6 dagen (ipv niet langer dan een jaar) zonder de nieuwe prive sleutel ook weer te stelen. En een brute-forcer heeft slechts 6 dagen de tijd ipv bijna een jaar (een jaar minus een korte tijd om zich voor te kunnen doen als de legitieme site) om een passende private key te vinden bij de public key.

[PixelPionier]

Vreemde manier om dingen veiliger te maken.... Als het onveilig is, dan is de tijdsduur van de geldigheid geen factor die daar invloed op heeft. Los gewoon op wat er onveilig is! Dus als oude algoritmes niet meer veilig zijn, stop daar dan mee!
Denk dat dit toch meer met geld te maken heeft dan met wat anders. Toch een inflatie van 600% als je straks 6x een certificaat moet kopen voor dezelfde periode je nu 1 certificaat nodig hebt.

[Blokker_1999]

Jawel, want beheerders zijn lui, als er een vermoeden is dat een certificaat gecompromiteerd is gaat men het vaak gewoon laten staan. Zal zoveel kwaad wel niet kunnen is dan de redenering. Letterlijk laten revoken en een nieuw installeren kost tijd en moeite. En dat moet dan weer tussendoor terwijl je net een andere crisis aan het oplossen bent en het dus niet in je planning past. Dus laat maar. Alles blijft werken en het zal wel geen kwaad kunnen.

Van zodra je automatisatie hebt staan is het in essenite 1 druk op de knop en je certificaat is vernieuwd. En zelfs als je het niet doet gaat het risico zeer kort in tijd zijn, gemiddeld nog geen 24 dagen.

[uiltje]

Na ja, als je lui bent fix je het originele probleem ook niet en staat de private key alsnog ergens beschikbaar, zonder dat iemand er erg in heeft. Dat kan je heel vaak op het knopje rammen maar veiliger wordt het er niet van. Dus dit zou alleen werken voor incidenten waarbij er nu geen toegang meer is tot de sleutel.

[bdbfz]

de meeste encryptiemethodes zijn kraakbaar, als er maar genoeg tijd beschikbaar is. Door nieuwe technieken (hardware en software) wordt voor sommige methodes die tijd ingekort, maar niet tot quasi 0. Het kraken wordt gewoon versneld met een percentage of een factor. En daarom kan hetzelfde type sleutel dat vroeger een jaar veilig beschouwd werd, nu nog maar een maand veilig genoemd worden.

[lenwar]

Nu word je gedwongen het te doen.
Wat nu veilig (genoeg) is, is over 9 maanden misschien niet meer veilig. Houd jij alles bij voor je al apparaten? Zeker met langlopende certificaten kan dit een ding zijn.

Het verkleint ook de impact van gestolen certificaat/sleutel.

En zoals al elders geschreven zullen de certificaten niet 6x zo duur worden (uiteraard wel duurder, want nieuwe kansen). Gewoon een abonnementje en dan kun je x-keer per jaar een nieuw certificaat ophalen. (net zoals je nu ook een renewal kunt krijgen binnen de termijn, mocht je je certificaat verloren zijn of zo.)

[FrostyPeet]

Wel vreemd dat de s/mime x509 e-mail/pdf sign certificaten niet dezelfde redenering volgen. Als het cryptografisch materiaal zo snel verouderd kan iemand nog een jaar lang lekker e-mail/pdf/docx/odt etc ondertekenen.

[laurxp]

Als het cryptografisch materiaal zo snel verouderd

Dat is niet het geval, er is niks mis met de sleutels zelf. Het gaat hier puur om het afdwingen van automatische certificaatvervanging op het web.

Daarnaast heeft het CA/Browser Forum niks te zeggen over s/mime certificaten - ze gaan alleen over de certificaten die websites gebruiken.

[MartijnK_SE]

[...]

Daarnaast heeft het CA/Browser Forum niks te zeggen over s/mime certificaten - ze gaan alleen over de certificaten die websites gebruiken.

Wel degelijk, en tevens voor Code Signing. Daarvoor zijn speciale S/MIME en Code Signing werkgroepen

[Locke_]

Commercieel gezien gaat dit in potentie veel bedrijven naar Letsencrypt duwen. Zeker als de prijzen van een certificaat wel gelijk blijven.

Vermoed dat ze hier toch wel weer op terug gaan komen..

[Martijn.C.V]

Het zou goed kunnen dat je gewoon nog steeds een jaar je certificaten kun updaten voor hetzelfde bedrag, enkel tussendoor vernieuwen. Sterker nog, dat lijkt me aannemelijker dan dat ze hetzelfde blijven vragen voor 1/6e van de dienst.

[Dennism]

Ergens hoop je dat natuurlijk wel, maar ik vraag het me wel een beetje af. Het zal immers ook (als het geautomatiseerd is) 7-8x meer API calls e.d. kosten, om hetzelfde voor elkaar te krijgen. Willen dat soort bedrijven dat 'gratis' weggeven? Ik weet het niet. Wanneer niet geautomatiseerd zal daar dan mogelijk ook nog 7-8x arbeid bij komen.

Dit natuurlijk als je betaalde certificaten hebt, de meeste gevallen waar je kan automatiseren zie ik veelal lets encrypt gebruikt worden, wat natuurlijk geen geld kost per certificaat.

[watercoolertje]

Ergens hoop je dat natuurlijk wel, maar ik vraag het me wel een beetje af. Het zal immers ook (als het geautomatiseerd is) 7-8x meer API calls e.d. kosten, om hetzelfde voor elkaar te krijgen. Willen dat soort bedrijven dat 'gratis' weggeven? Ik weet het niet. Wanneer niet geautomatiseerd zal daar dan mogelijk ook nog 7-8x arbeid bij komen.

Die calls kosten toch praktisch niks, maar laat het een euro extra zijn per jaar, en dat valt prima door te berekenen en ja dan wordt het misschien 2 euro duurder op jaarbasis.

En als een certificaatboer niet kan/wil automatiseren moet je daar al sowieso geen klant willen zijn! Uiteraard heb je wel handmatige processen (het keuringsproces zelf), maar die hoef je niet voor elke uitgifte te doen, kan je nog steeds prima 1 keer per jaar doen.

De discussie begon omdat er gesuggereerd werd dat de prijs voor die 47 dagen even hoog zou zijn als voor een jaar en dus 7 a 8x zo duur zou zijn op jaarbasis. Dat is vrijwel onmogelijk te verkopen natuurlijk

[Reactie gewijzigd door watercoolertje op 15 april 2025 17:07]

[lenwar]

Dat ligt eraan. LE biedt geen geverifieerde certificaten aan, waar veel (grote) bedrijven waarde aan hechten. Als de commerciële certificaat-boeren een meerwaarde bieden ten opzichte van het gratis LE (ik zou niet weten wat, maar ik ben ook geen bedrijf), dan zie ik niet in waarom ze voor die paar tientjes per jaar per certificaat ergens anders naartoe zouden willen gaan. Zeker omdat volgens mij alle certificaten-boeren al ACME ondersteunen voor geautomatiseerd certificaten verversen.

De prijzen zullen wel 'iets' omhoog gaan, maar men zal straks niet meer per certificaat betalen, maar per jaar of zo.

[Locke_]

Wat je nu bij in ieder geval sommige certificaatboeren ziet is dat ze weinig mogelijkheden tot automatiseren hebben. Aanvragen gaan via de website en ik weet er zelfs eentje die dat via e-mail wilt (redelijk kansloos, maar oke). Dit geldt zeker niet voor alle, maar als je wilt automatiseren is Letsencrypt wel het schoolvoorbeeld van hoe dat zou moeten en er is al flink wat automatisering voor terug te vinden met een simpele google search.

Verschillende vendoren van Loadbalancers en Reverse Proxies hebben de automatisering hiervoor zelfs al ingebakken zitten, inclusief de vol-automatische certificate renewal.

Ik snap ook behoefte voor geverifieerde certificaten niet helemaal, enige wat dat doet is dat de certificaatboer een keertje het telefoonnummer welke geregistreerd is op de KVK belt om te kijken of ze daar een aanvrager kunnen vinden. Dat biedt mij persoonlijk nog geen extra bescherming. Enkel de bevestiging dat op het geregistreerde nummer een keertje iemand de telefoon heeft opgenomen, maar gezien dat op een voor het bedrijf moment bekend moment was, zegt dat nog niets.

Maar, je krijgt dan wel een mooi groen balkje

[lenwar]

Volgens mij zijn er wel aardig wat CA's die ook het ACME-protocol ondersteunen. (LE heeft het protocol open gemaakt vanaf dag 1)

Die extra validatie-certificaten snap ik wel voor bedrijven als banken, grote webwinkels als bol of Amazon en overheden, maar verder ook niet.

Ik pleit persoonlijk ook al jaren voor speciale certificaten voor banken/overheden, en dat die ook met heel veel poehoe zichtbaar zijn.

En dan dus echt alleen voor banken/verzekeraars/betalingsverwerkers en overheden (Mogelijk nog een paar doelgroepen), en dat die ook wettelijk verplicht worden die certificaten te gebruiken. Puur vanuit een stuk transparantie/duidelijkheid.

[Marve79]

Dit gaat enkel over vernieuwen, niet over betalen daar verandert niks.