'Mijn UWV'-omgeving onbereikbaar door vergeten certificaatvernieuwing - update

Gebruikers die willen inloggen bij het Nederlandse UWV, stuiten op een foutmelding doordat het certificaat voor Mijn UWV is verlopen. Daardoor is een beveiligde verbinding met de inlogsite niet mogelijk. Het UWV spreekt van een storing.

Het SSL-certificaat voor Mijn UWV is op 16 oktober vorig jaar uitgegeven en verliep in de nacht van woensdag 5 november . Dit is zichtbaar in de certificaatgegevens in een browser bij bezoek aan die inlogsite. Nederlanders die recht hebben op een uitkering vanwege bijvoorbeeld ziekte of werkloosheid kunnen hierdoor niet veilig inloggen bij de publieke dienstverlener.

Het UWV meldt op de homepagina van zijn algemene site dat Mijn UWV niet bereikbaar is 'door een storing'. "Wij proberen dit zo snel mogelijk op te lossen. Onze excuses voor het ongemak."

Update, 11.14 uur – Het UWV heeft een nieuw certificaat ingesteld voor de 'Mijn UWV'-omgeving. De geldigheid van dat certificaat loopt van woensdagnacht 5 november tot zondagnacht 16 november. Gebruikers die willen inloggen op Mijn UWV kunnen nu in een wachtrij terechtkomen. De site meldt dat er op het moment 'erg veel mensen' zijn die willen inloggen en er daarom een wachtrij geldt.

Reacties (211)

[enetrati]

Ik vind dat dit incident niet te rijmen is met proactief beheer dat je mag verlangen van het UWV anno 2025.

Om dit te te voorkomen zijn er momenteel meerdere mogelijkheden variërend van veel tot weinig handwerk. Waarbij het inregelen van een reminder in een agenda het minimale is.

Andere mogelijkheden zijn: regelmatige check vanuit een script getriggerd door een monitoringpakket zoals Nagios of vanuit een automation-tooling zoals Ansible. Maar de echte slimme beheerder regelt het gewoon in met ACME zodat het vervangen en het herstarten geautomatiseerd wordt.

Dat dit nog niet behoorlijk is ingeregeld, is echt onacceptabel.

[Sebazzz]

Maar de echte slimme beheerder regelt het gewoon in met ACME zodat het vervangen en het herstarten geautomatiseerd wordt.

ACME heeft zelfs bij Forum Standaardisatie de status "Pas toe of leg uit" wat in principe betekend dat het verplicht is.

[Reactie gewijzigd door Sebazzz op 5 november 2025 13:18]

[porn*]

Verplicht? Volgens mij betekent dit dat het verplicht is tenzij je uit kunt leggen waarom het echt niet kan of wenselijk is. En daar natuurlijk talloze redenen voor de bedenken.

[DataGhost]

Dat moeten dan wel verdomd goede redenen zijn anders heb je alsnog pech. Als je op de ⓘ op de gelinkte pagina klikt staat erbij dat het zo goed als gelijk staat aan "verplicht" en in het wetsartikel staat het duidelijker uitgelegd en behoorlijk beperkt. Mag jij me eens een van de "talloze redenen" uitleggen die okee zijn volgens het artikel.

[Reactie gewijzigd door DataGhost op 5 november 2025 15:01]

[porn*]

Tijd, geld, propriatory software waarin de implementatie (nog) niet mogelijk is, etc etc.

[DataGhost]

Zal ik het lid voor je quoten?

Van het eerste lid kan worden afgeweken indien een dergelijke dienst of product naar verwachting in onvoldoende mate wordt aangeboden, onvoldoende veilig of zeker functioneert, of om andere redenen van bijzonder gewicht.

Er zijn voldoende diensten die gewoon ACME aanbieden en voldoende veilig of zeker functioneren. De redenen die je noemt zouden dus moeten vallen onder "redenen van bijzonder gewicht" maar de zaken die je noemt zijn meer "excuses als gevolg van mismanagement". Oftewel: in dit geval gewoon niet zeuren, en dus verplicht.

[porn*]

Je hebt helemaal gelijk. Maar, tegelijkertijd, hoe vaak zie je dat dit soort constructies toch bestaan?

Zeker bij de overheid verbaast het met niet dat er veel software draait die niet aan hun eigen specs voldoet. Prio's, capaciteit, de excuusjes hoor je toch al tientallen jaren?

[Mellow Jack]

Geld kan, tijd ook. Software eigenlijk niet. De meeste bedrijven van dit formaat hebben SSL op een WAF. Dat zorgt ervoor dat je endpoint onafhankelijk en gecentraliseerd te werk kan gaan

[enetrati]

Het zal waarschijnlijk niet eens op de agenda staan want een solution architect moet daar nog een plasje over doen. Dat het UWV op zoek is naar solution architecten zal vermoedelijk een van de redenen zijn waarom het nog niet is gedaan.

Bron:
https://www.uwv.nl/nl/werken-bij/vacatures/noord-holland/amsterdam/it-data/senior-solution-architect/a1WSc000001N3vtMAC

https://www.uwv.nl/nl/werken-bij/vacatures/utrecht/utrecht/it-data/solution-architect-bkwi/a1WSc000001UFAjMAO

[MB54]

Heb daar in IT gewerkt en ben inmiddels 11 jaar gepensioneerd.
Vaker meegemaakt; niets nieuws onder de zon
Ezel - steen...

[dr86]

Als je weleens moet inloggen op die site weet je dat het al jaren drama is, of er werkt weer eens wat niet, bijlages die niet geopend kunnen worden, berichtenboxen die verdwenen zijn, de website zelf die weer eens in onderhoud zit... dan kijk ik hier niet gek van op.

[Consequator]

Om 1 of andere reden is certificaat beheer moeilijk. Daar is niet echt professionele tooling voor, of het is belachelijk duur.

En volgens mij kan je EV certificaten niet met ACME doen, maar niet zeker.

[laurxp]

En volgens mij kan je EV certificaten niet met ACME doen, maar niet zeker.

ACME heeft ondersteuning voor "out of band" validation. In feite komt het er op neer dat je de authenticatiesleutel van je ACME-client moet invullen op de website van de cert provider, en als de ACME-client dan een certificaat probeert aan te vragen krijgt die niet een "doe eerst een DNS challenge" response, maar een "wacht op handmatige goedkeuring" response.

In feite behoud je de traditionele EV/OV validatie workflow, maar, de server is in staat het certificaat zelfstandig en automatisch te installeren. De validatie is vaak langer geldig dan het certificaat, dus je hebt er weinig omkijken naar.

[firest0rm]

Ik denk dat je je behoorlijk verkijkt op de hoeveelheid certificaten die bij gehouden moeten worden bij dit soort instanties en dat het vrij makkelijk kan zijn dat er 1 in het verschiet is gelaten door een update proces wat niet volledig is afgerond.

[Keypunchie]

Man, tegenwoordig zet je bij al die dingen “automatisch vernieuwen” aan op 2 weken van te voren en laat je alerteren bij certificaten die binnen een week verlopen.

Dat er ergens op een interne koppeling of secundair systeem wat verloopt, kan, maar op je primaire dienstverlening was dit eind jaren ‘00 al treurig.

[Reactie gewijzigd door Keypunchie op 5 november 2025 21:58]

[firest0rm]

Man, tegenwoordig zet je bij al die dingen “automatisch vernieuwen” aan op 2 weken van te voren en laat je alerteren bij certificaten die binnen een week verlopen.

Man ook die diensten moeten zo nu en dan bij gewerkt worden. en kan je garanderen dat dat wel eens fout gaat.

[Reactie gewijzigd door firest0rm op 5 november 2025 22:09]

[ErikHoogland87]

Het is overheid, daar moet je niet veel van verwachten op ICT gebied. En met het nieuwe kabinet, wat het ook wordt, zal dit niet veel verbeteren denk ik.

Ik heb bij het UWV gewerkt als ICT'er, en dat dit kan gebeuren, verbaast me niks.

[enetrati]

Dat het overheid is, MOET je als burger ervan verwachten dat zij hun zaken op orde hebben om drie redenen:

• Het is een standaard vanuit IT-beleid binnen de overheid, voorheen BIO, nu NIS2, dat verbindingen die in contact staan met de buitenwereld, ten alle tijden veilig moet zijn. En elke voorzorgsmaatregel getroffen moet worden om te voorkomen dat uitval zoveel mogelijk geminimaliseerd wordt
• In tijden waarin continu gesproken wordt over dreiging, kan je het dus niet permitteren dat dit zaken als een futiliteit worden gezien.
• Het is een dienst waar mensen afhankelijk zijn voor het al dan niet ontvangen van een inkomen of andere regelingen. En op dit moment is het de tijd waarin inkomstenopgaven ingeleverd moeten worden.

Dit incident moet voorkomen worden en had voorkomen kunnen worden. Maar dat is niet gedaan, en dat is zeer discutabel. De reactie "dat het overheid is", kan geen reden zijn om de fouten te accepteren.

[Reactie gewijzigd door enetrati op 5 november 2025 14:07]

[zenith]

"Dat het overheid is", is juist het probleem. ;)

[Bitje-Scheef]

Fijne aanname maar helaas. Overheid is per definitie complex en dit soort zaken lopen altijd achter of uit de gestelde tijd. Er komt altijd iets uit de hoge hoed.

[denkster]

Je hebt helemaal gelijk.

[GF187um]

Dit is wel het minst erge wat op er dit moment speelt bij het UWV. De artsen zijn incapabel, het systeem deugt voor geen millimeter. Ze maken fout op fout op fout. Medewerkers zijn niet op de hoogte van de laatste communicatie en steken het liefst ook hun kop in het zand.

Je hebt de fouten maar te accepteren want er gaat bij die organisatie niets veranderen en daarnaast wat wil je eraan doen?

[Aherin]

En wij moeten op jouw blauwe ogen vertrouwen?

Ik heb daar gewerkt. HARD gewerkt. Net als alle andere mensen die ik daar ken.

[cem.]

Wat is hard werken? Hele dag op je lui stoel zitten? En ik dan als timmerman? Hele dag staand hard werken. Wat ga je zeggen? “Had je ook maar moeten leren? Verschil moeten zijn?”

[sicco.]

Ze moeten nog meer aan de bak: het certificaat van digid.werk.nl (ook van UWV) verloopt over 7 dagen. Zie https://basisbeveiliging.nl/report/certificates/NL/government/2249, sorteer de 'Expiration' kolom en scroll een beetje naar beneden. Er staat ook dat werk.nl over 2 dagen verloopt, maar die hebben ze inmiddels verlengd.

[Reactie gewijzigd door sicco. op 5 november 2025 15:31]

[stuiterveer]

Nederlanders die recht hebben op een uitkering vanwege bijvoorbeeld ziekte of werkeloosheid kunnen hierdoor niet veilig inloggen bij de publieke dienstverlener.

Misschien is het een beetje muggenziften, maar: "niet veilig kunnen inloggen" is behoorlijk kort door de bocht. Het is net zo veilig als een self signed certificaat, waarbij het niet meer mogelijk is om de echtheid te controleren. Als de verloopdatum het enige is dat niet klopt, dan wil dat niet direct betekenen dat het niet veilig is. HTTPS werkt nog steeds, zolang mensen bewust kiezen om de error te negeren.

Maar de browser geeft misschien een verwarrende melding dat de verbinding niet veilig is, terwijl het mogelijk niet velig kan zijn. Is toch wat nuance, ook al is het stom dat ze dit niet goed hebben geregeld bij UWV deze keer.

[phYzar]

Nutteloze nuance. Alsof je over een gammele houten loopbrug wilt lopen en vraagt: "is dit wel veilig?" "Ja, het zou veilig kunnen zijn". Vervolgens zak je erdoorheen, en terwijl je de beantwoorder boos aankijkt zegt hij: "Ja, ik heb toch ook nooit gezegd dat het veilig IS, maar het HAD zo kunnen zijn".

[stuiterveer]

Nee, het is hetzelfde als een APK keuring die niet wordt gedaan waarna je concludeert "dus de auto is niet veilig". Of als we bij de brug analogie blijven: alsof een brug elk jaar onderhoud krijgt, je een sticker ziet die aantoont dat de laatste keuring precies een jaar geleden was, en je dan weigert om er overheen te lopen omdat dit niet veilig zou zijn.

HTTPS is bedoeld om te garanderen dat communicatie niet in kan worden gezien door anderen dan de zender en ontvanger. Zolang het certificaat onveranderd kun je er eigenlijk vanuit gaan dat het net zo veilig is als voordat het certificaat verlopen was. Er is nu alleen een partij die heeft gezegd "na <datum> moet je dit certificaat niet meer accepteren", verder niks.

[Reactie gewijzigd door stuiterveer op 5 november 2025 09:57]

[Gwaihir]

En dat is exact wat de politie zal concluderen, mocht je aangehouden worden. Geen certificaat is niet aangetoond veilig en dus moeten we van onveilig uitgaan.

Er kunnen andere problemen zijn waardoor het certificaat niet vernieuwd is / kon worden, zowel aan de zijde van de website als aan de zijde van de certificaatverstrekker. Dat kun je onmogelijk weten. Je ziet slechts dat er geen geldig certificaat is.

En wil je mensen dan echt aanmoedigen in interactie met de overheid (BSN en alles op tafel) certificaatwaarschuwingen te omzeilen?

[stuiterveer]

En wil je mensen dan echt aanmoedigen in interactie met de overheid (BSN en alles op tafel) certificaatwaarschuwingen te omzeilen?

Nee. Als mensen de melding niet negeren geef ik ze totaal geen ongelijk, UWV had dit gewoon moeten regelen. Deze volledige discussie gaat puur over het statement dat veilig inloggen bij UWV nu niet zou kunnen, en daar ben ik het gewoon mee oneens als het "enige probleem" is dat het certificaat verlopen is. Dat maakt de site niet meer of minder onveilig.

[supe]

Strikt genomen konden zij inderdaad niet veilig inloggen gezien er geen garantie van veiligheid gegeven kan worden. Dat is waar zo'n certificaat voor dient. Dat het mogelijk wel veilig was klopt volledig, maar je kunt daar aan de voorkant niet van uitgaan. Het gaat er dus niet om of het praktisch gezien in deze situatie wel of niet veilig is, het gaat erom dat er geen garantie gegeven kan worden dat het veilig is.

Deze discussie lijkt vooral uit te lopen op semantiek en dat is totaal niet relevant hier. Vanuit een security oogpunt is de site, met een verlopen certificaat, niet veilig. Einde discussie.

[supersnathan94]

maar je kunt daar aan de voorkant niet van uitgaan

Sorry maar dat kun je wel.

Er is geen enkele reden om aan te nemen dat het certificaat vandaag minder veilig is dan gisteren gebaseerd op de tijd. Zet je namelijk je systeemklok een dag terug en NTP sync uit dan zal de browser hier niks over zeggen.

Het ding is namelijk dat het certificaat is uitgegeven voor een bepaald domein via een bepaalde methode en die eigenschappen zorgen ervoor dat het werkelijk niet anders kan zijn dan dat het certificaat op ieder willekeurig moment in tijd gekoppeld is aan deze specifieke website en set aan servers.

De verloopdatum is iets cosmetisch om ervoor te zorgen dat er ook daadwerkelijk een APK komt, maar dat is niet per de een APK voor de website maar voor de Certificate Authority

Neemt niet weg dat dit gewoon echt jammer is. Dit is gewoon een proceshygiene dingetje. Als je dit al niet een jaar in het vizier kunt houden.

[Gwaihir]

Je weet nu dus niet of de Authority haar APK doorstaan heeft. Er zijn verschillende voorbeelden uit afgelopen jaren waar juist dat niet het geval was.

[supersnathan94]

Dat weet ik, maar met een certificaatduur van een jaar boeit dat echt niet, die tijd is veel te lang om geen active pull te doen. Want wat als dat een dag na uitgave bekend wordt? Dan kun je niet op die verloopdatum gaan zitten wachten.

In dergelijke gevallen moet de rootCA gewoon ingetrokken worden en alle uitgegeven certificaten ongeldig verklaard worden.

Maar zoiets heeft het UWV in 2022 ook al eens gehad toen logius een aantal certificaten introk. forumtopic: UWV website heeft ingetrokken certificaat

[Glashelder]

Deze hele discussie doet me aan dit filmpje denken waarbij jij de Amerikaan bent en de rest komt allemaal uit Duitsland

James May Explains What Happens If You Drive A Car In Germany Without A Licence | The Grand Tour

[supersnathan94]

"Nein you cannot do zat!"

Het is wel zo ja.

Maar die datum is natuurlijk gewoon een compleet arbitrair gekozen dag (het is niet eens een jaar zoals je kunt zien. maximaal 398 dagen) en om heel eerlijk te zijn is een jaar gewoon echt te lang. Ik dacht eerst met LE dat 90 dagen echt bijzonder kort was, maar nu ik wat vaker met key en secret rotation aan de gang ben geweest, het boeit werkelijk waar niet of het 90 dagen of 2 dagen is als je je automatisering goed op orde hebt.

Het is echt niet interessant dat er een verloopdatum op zit. De enige reden dat dat ooit is gedaan is om ervoor te zorgen dat de certificaten ook daadwerkelijk een keer vernieuwd zouden worden om zo ook nieuwe standaarden toe te kunnen voegen en de impact van een CRL (Certificate Revocation List) te kunnen beperken (anders moet je tot in den treure alle ingetrokken certificaten daarin bewaren.

Als het namelijk een jaar oud kan zijn dan is dit ook niet meer een reden voor "ja maar wat nou als de CA.." ja dan moet je echt actief gaan revoken, want anders duurt het nog mogelijk een jaar waarin je wel misbruik kunt hebben.

Verlopen datum is gewoon heel knullig, technisch maakt het weinig verschil

[latka]

Definieer "veilig": het kanaal is beveiligd maar dat zegt maar heel weinig over de veiligheid van de keten: je weet niet hoeveel ransomware er op de server staat, hoeveel medewerkers van het UWV ongeauthoriseerd je gegevens in kunnen zien. Ik zie HTTPS/TLS als een minimale stap op weg naar veiligheid maar zeker niet afdoende om veiligheid aan te tonen.

In dat opzicht is een verlopen certificaat vooral sympomatisch voor een organisatie: als dat soort hygiene al niet lukt verwacht ik achter de voordeur een nog veel grotere bak ellende aan te treffen.

[SillieWous]

De politie zal dan concluderen dat degene die de brug inspectie op tijd moet regelen geen adequate maatregelen heeft getroffen om te voorkomen dat je toch over de brug loopt.

[Miglow]

Nee, dat is de onderzoekscommissie die aangesteld door een onderzoekscommissiecomissie na kamervragen dat concludeert voor uiteraard veel geld. Politie kijkt naar strafbare feiten, eventueel wat randonderzoek omtrent toedracht, maar bruggen onderzoeken doen ze niet.

[SillieWous]

Het is een strafbaar feit als je letsel veroorzaakt door nalatigheid.

[Miglow]

Maar dan nog gaat de politie dat niet onderzoeken. Die nalatigheid wordt aangetoond door onderzoekers, waarna degene die onderhoud uit had moeten laten voeren voor de rechter komt.

[Reactie gewijzigd door Miglow op 5 november 2025 10:42]

[SillieWous]

Wie zijn die magische onderzoekers dan? Die niet onder het OM vallen maar wel een strafzaak kunnen beginnen.

[memphis]

En wat nu als je net na de APK goedkeuring zonder problemen bij de garage weg rijdt en de rem doet het opeens niet meer. Menselijke fout, toeval of iets anders?

Ik weet natuurlijk niet of zo'n certificaat een blinde verlenging is of dat er vooraf nog een soort van test gedaan wordt maar een niet gedane update of een programmeerfroutje in het afgelopen jaar is snel gebeurd.

[Miglow]

"APK is een momentopname" 😇

[arikkert]

hoop niet voor je dat je bij de douane aangehouden wordt als je paspoort expired is ;-)

[stuiterveer]

Maar stemmen mag met een ID wat niet langer verlopen is dan 5 jaar... raar he, hoe perceptie van veiligheid totaal kan verschillen afhankelijk van de context.

[HuisRocker]

Maar stemmen mag met een ID wat niet langer verlopen is dan 5 jaar... raar he, hoe perceptie van veiligheid totaal kan verschillen afhankelijk van de context.

Ho ho... Dat is een tijdelijke regeling, men wil hier dus weldegelijk vanaf!

Dat heel veel bejaarden het ID niet op tijd verlengen omdat ze denken 'het niet nodig te hebben' (want; 'ik ga toch niet meer op reis') is echter wel echt een probleem. ID is wel nodig, o.a. om te stemmen dus (en uiteraard omdat 'geen geldig ID kunnen tonen' al jaren strafbaar is).

Persoonlijk verwacht ik dat juist bij het wel uitsluiten van stemmers met een verlopen ID dit probleem zich al relatief snel vanzelf oplost. Maar ja, dat zou consequent zijn, en als 'de politiek' iets niet is, al helemaal als het om de politiek zelf draait (zoals bij stemmen), dan is het consequent!

Hoe zijn we zo ver off topic gegleden? Oh ja, het algemene begrip 'veiligheid'... Dan gaat het inderdaad al snel mis.

[snrwo1]

en dus betalen. Het verlengen is niet gratis

[watercoolertje]

Dat je er misschien niks aan hebt maakt niet dat die nuance niet uitmaakt. De opmerking dat het per definitie niet veilig is klopt simpelweg niet.

Bij een brug waarover ik twijfel ga ik ook niet zeggen dat ie onveilig is maar dat het MOGELIJK onveilig is (cq ik weet het niet, dat kan je gewoon uitspreken, er is meer dan enkel zwart of wit). En dat jij een brug waarvan je niet weet behandeld alsof die niet veilig is, is 100% terecht, maar dat bepaald niet of die daadwerkelijk onveilig is

Overigens kan je prima aan de fingerprint van het certificaat zien of die gelijk is aan vorige week (had je die toen wel even moeten checken), en als dat zo is dan weet je ook dat je exact net zo veilig bent als vorige week toen het certificaat nog niet verlopen was.

[Reactie gewijzigd door watercoolertje op 5 november 2025 10:03]

[bwerg]

"Veilig" in termen van software-beveiliging is de onmogelijkheid dat iemand misbruik maakt van de communicatielijn (voor een bepaalde klasse van misbruik). Dus effectief komt de nuance neer op het verschil tussen de mogelijkheid dat iets mogelijk is en de zekerheid dat iets mogelijk is. Mijn stelling is dat die twee gewoon wel hetzelfde zijn. En in algemene zin is een website met een verlopen certificaat dus niet veilig.

Wel is die "bepaalde klasse van misbruik" relevant: bij een verlopen certificaat zijn er minder scenario's waarop iemand kan inbreken dan bij een verbinding die uberhaupt niet via HTTPS verloopt. Dus de nuance is op zich wel terecht, maar impliceert niet dat deze foutmelding negeren veilig is.

[ioor]

En wat nou als er wel een keuring sticker opgeplakt is maar er niet gekeurd is?

Dat kom je namelijk heel vaak tegen ,is het dan wel veilig?

[Triblade_8472]

En in algemene zin is een website met een verlopen certificaat dus niet veilig.

Nope. In algemene zin is het prima veilig, alleen de door Google afgedwongen einddatum van 1 jaar is voor certificaten overschreden met nog niet eens één hele dag. Als mn kaas 1 dag over de datum is, eet ik die ook nog gewoon.

Het is gewoon een groot verdien model lekker certificaten aftikken. Dat de leverancier zegt dat iets verloopt maakt het niet veilig of onveilig. De cryptografische toepassing blijft namelijk exact hetzelfde als een dag ervoor.

BTW, vanaf 2029 zijn certificaten nog maar maximaal 47 dagen geldig. Succes!! Zie tweakers hier.

[supersnathan94]

bij een verlopen certificaat zijn er minder scenario's waarop iemand kan inbreken dan bij een verbinding die uberhaupt niet via HTTPS verloopt

Bij een verlopen certificaat zijn er exact dezelfde scenario’s waarbij iemand kan inbreken dan bij een niet verlopen certificaat

[sundrak]

De certificaat IS nog steeds veilig.

Niks klapt in elkaar niks valt om.

Het enigste is dat de certificaat een verval datum heeft, als een preventieve maatregel.

[willieverhoef]

Die ene dag van een verlopen certificaat maakt het echt niet onveilig. Het zou veel problemen kunnen voorkomen om dit soort meldingen voor bijv. 2 dagen te voorzien van een kleinere waarschuwing dan met veel toeterst en bellen via een geavanceerde mode of misschien helemaal niet meer. Geeft gebruikers wel 2 dagen de mogelijkheid iets te doen. Natuurlijk moet je optijd de certificaat vervangen, maar we zijn al terug van 3 jaar naar 1 jaar, en door het op tijd te doen, wordt het bijvoorbeeld ook weer met enkele dagen ingekort.

[PROnline]

HSTS is actief, dus de optie om door te klikken op een onveilig certificaat is er niet.

Echter type in "thisisunsafe" en chrome gaat alsnog door.

edit:
met Chrome

[Reactie gewijzigd door PROnline op 5 november 2025 10:18]

[svane]

Interessant, de mozilla developer docs geven je gelijk:

If a TLS warning or error, such as an invalid certificate, occurs when connecting to an HSTS host, the browser does not offer the user a way to proceed or "click through" the error message, which would compromise the intention of strict security.

Maar in de praktijk, met Chrome, kon ik wel doorklikken en inloggen met DigID.

Ik vermoed dat dit te maken heeft met het feit dat ik deze site niet eerder heb bezocht, en dat de HSTS header niet geaccepteerd werd doordat het certificaat niet klopte. HTST headers worden namelijk ook genegeerd op HTTP verbindingen:

Note: The host must send the Strict-Transport-Security header over HTTPS only, not insecure HTTP. Browsers ignore the header if sent over HTTP to prevent a manipulator-in-the-middle (MITM) from altering the header to expire prematurely or adding it for a host that doesn't support HTTPS.

[Niemand_Anders]

En als je het met Firefox (van ontwikkel Mozilla) probeert?

[svane]

Goede vraag, maar helaas...

Toen ik dat wou proberen, kwam ik erachter dat het certificaat inmiddels alweer vervangen is door een nieuw, geldig, certificaat.

offtopic:
(het dit al door gegeven aan de redactie voor een update van 't artikel)

[stuiterveer]

Vreemd, ik kan gewoon doorklikken.

[moonlander]

Probeer het maar eens, je kan gewoon doorklikken hoor.

[DigitalExorcist]

Omgekeerd geldt ook: een SSL-certificaat maakt iets niet per definitie veilig. Ja, het stelt dat je praat met wie je dénkt te praten, maar wat er ondertussen met je gegevens gebeurt zegt helemaal niks. LInkedIn gebruikt ook SSL-certificaten, toch lekken daar massa's aan wachtwoorden en gebruikersdata. Facebook gebruikt ook SSL-certificaten en toch verkopen ze je ouders nog aan de hoogste bieder als ze de kans kregen.

[stuiterveer]

LInkedIn gebruikt ook SSL-certificaten, toch lekken daar massa's aan wachtwoorden en gebruikersdata. Facebook gebruikt ook SSL-certificaten en toch verkopen ze je ouders nog aan de hoogste bieder als ze de kans kregen.

Dat de partij waarmee je communiceert onbetrouwbaar is maakt niet de communicatiemethode zelf onbetrouwbaar natuurlijk. ;)

[DigitalExorcist]

Dat bedoel ik.

Maar vaak wordt gedacht "oh maar een groen balkje/certificaat/https is veilig, dus..". Nee, inderdaad alleen de _verbinding_ is veilig, en dat zegt niets over de partij waarmee je praat.

[L01]

Je hebt gelijk. Scammers maken ook gebruik van certificaten voor hun websites, waardoor de browser (voorheen) een "veilig" stempel gaf. Ook al ging de stempel veiligheid alleen maar over de verbinding.


Dat is dan ook de reden dat Chrome enige tijd geleden de security indicator heeft aangepast van een groen slotje, met secure tekst, naar een grijs slotje.

[AnonymousGerbil]

Vergelijkbaar met het e2e encryptie verhaal dat niks zegt over wat er op de "endpoints" gebeurt.

Zoals recent prachtig geïllustreerd werd door de politieke leiding aan de overkant van de grote plas.

[Blokker_1999]

Het is minder veilig omdat van een vervallen certificaat niet meer kan nagegaan worden of het nog geldig is. Als nu het certificaat gecompromiteerd zou zijn, dan kan het UWV of Digicert dit niet langer op de CRL zetten om zo ongeldig te laten verklaren. En als je mensen nu gaat aanleren van deze meldingen te negeren, dan verlaag je letterlijk de veiligheid voor hen want als er dan toch eens een man-in-the-middle aanval komt waardoor er een ongeldig certificaat staat gaan diezelfde mensen ook gewoon doorklikken met de gedachte dat het wel in orde zal zijn.

[com2,1ghz]

Het gaat om de communicatie naar je gebruikers. Die kunnen geen onderscheid maken of iets wel of niet veilig is. Voorhetzelfde geldt hebben ze een linkje aangeklikt waarbij je dezelfde melding krijgt.

Dus het is onveilig omdat het niet voldoet aan de eisen van een HTTPS verbinding. Dat is heel de reden waarom we HTTP niet meer vertrouwen terwijl je daar ook over kan muggenziften of het nou echt onveilig is.

[supersnathan94]

Dat is heel de reden waarom we HTTP niet meer vertrouwen terwijl je daar ook over kan muggenziften of het nou echt onveilig is.

Nee dat is daadwerkelijk onveilig. Zoek maar even op

• Comcast ad injection
• Bt phorm, tracking
• Airtel JavaScript injection
• Marriott hotels certificate spoofing
• Verizon “supercookie”

Daar valt weinig over te muggenziften.

[com2,1ghz]

Beide gevallen zijn onveilig gezien er met self signed en een verlopen certificaat geen onderscheid meer hebt met een MITM attack.

[supersnathan94]

Er zit een gigantisch groot verschil in “onveilig” en “onveilig” in deze 3 scenario’s.

scenario 1: HTTP:

Kompleet irrelevant gebruiker gaat nooit doorhebben dat een website aangepast is, maar is daar wel de dupe van (zoals met extra Ads, tracking cookies) er is in deze dan ook nul encryptie of chain om te checken of het klopt.

Scenario 2 self signed:

Self signed certificate zal nooit een geldig certificaat zijn tenzij de rootCA waarmee het certificaat is ondertekend (en de gehele chain daaronder) ook wordt toegevoegd aan de certificate store van de gebruiker. Dit gebeurt vaak met bijvoorbeeld Enterprise Proxies (cisco umbrella). Daarvan moet je het dan dus ook vertrouwen wetende dat er een MITM ís (namelijk die proxy)

Scenario 3 verlopen cert:

Het certificaat is hetzelfde als gisteren en de “garantie” die wordt afgegeven is exact hetzelfde als gisteren, maar technisch gezien had het certificaat gewoon vernieuwd moeten worden.

Als ik echter de klok op mijn device een dag terugzet dan zal de browser het certificaat weer accepteren, waarbij dat bij een self signed cert niet het geval is.


Mijn initiële reactie was alleen bedoeld op het stukje HTTP. Dat is écht onveilig en daar valt weinig over te muggenziften. De enige reden om nog HTTP te gebruiken is intern, en zelfs daar is TLS echt wel een goede gewoonte aan het worden op enterprise (want data in flight kun je geen auditlogs voor vastleggen dus dat is ontzettend lastig om dat nog te mogen doen in bijvoorbeeld PCI-DSS omgevingen)

[com2,1ghz]

Nee het is veilig(groen,) of niet veilig(rood) Het probleem met Scenario 3 is dat gebruikers geen onderscheid kunnen maken tussen een verlopen certificaat en een self signed certificaat want in beide gevallen krijg je dezelfde foutpagina met een andere technische foutcode. Je kan niet tegen je gebruikers zeggen dat ze ze melding maar moeten negeren.

Dat het technisch mogelijk niet gevaarlijk is dat is een andere discussie.

[supersnathan94]

I know.

Ik reageerde niet op jouw stukje over het deel uiterlijke communicatie, want daar heb je gewoon gelijk, maar op je statement over HTTP. Daar valt weinig over te muggenziften, ook op technisch vlak.

Je tweede statement over dat je geen verschil hebt ben ik het echter ook niet mee eens. Self signed is namelijk in 99/100 gevallen een corporate CA en per definitie een TLS rewrap en dus een MITM. Die 1 keer dat je een self signed cert tegenkomt is dat meestal een foutieve configuratie, want niemand heeft de RootCA chain daarvan om dat te kunnen accepteren.

Het probleem met Scenario 3 is dat gebruikers geen onderscheid kunnen maken tussen een verlopen certificaat en een self signed certificaat want in beide gevallen krijg je dezelfde foutpagina met een andere technische foutcode.

Dat ligt er dus aan. Een self signed cert kun je wel degelijk groen krijgen als je de chain dus toevoegt aan je trust store. Echter kan een self signed cert ook verlopen. en dan zit je weer in hetzelfde schuitje. Dat heb ik een keer gehad met dus 1 van die corporate Proxies. Kon het hele bedrijf niet mer internetten. Tenzij je dus je klok een dagje terugschroefde.

Je kan niet tegen je gebruikers zeggen dat ze ze melding maar moeten negeren.

Eens!

[Aalard99]

Vanuit een technisch perspectief heb je gelijk, alleen vanuit een gebruikersperspectief zou het heel raar zijn om maar aan te geven: Klik maar door en negeer de waarschuwingen in de browser.

We zijn juist de afgelopen jaren druk bezig om de bewustwording te creëren op de risico's van cyberveiligheid, dus iemand die niet technisch onderlegd is zou ik adviseren om dit soort waarschuwingen niet te negeren. Zeker omdat het hier gaat om vaak zeer gevoelige persoonsgegevens die uitgewisseld worden.

[Jaldea]

thisisunsafe *ENTER* en door.

[nervwrecker]

Nee het is niet veilig het certificaat is verlopen. Geen discussie.

[kr4t0s]

Zeker, maar je moet wel wat expertise hebben om dat zeker te zeggen, de gemiddelde persoon zal dat niet hebben. Als je dan in cert kijkt en ziet dat datum heel recent verlopen is maar gewoon het uvw cert is er waarschijnlijk niks aan de hand. Maar kan ook dat cert vervangen is door kwaadwillende en dat host- of san name of iets anders niet correct is. In algemeen zou ik gewoon even afwachten tot cert netjes vervangen is.

[stuiterveer]

Helemaal mee eens, het beste is om alsnog te wachten. Maar het statement dat op een techsite wordt gemaakt dat het gewoon per definitie onveilig zou zijn, daar mag toch wel opnieuw over nagedacht worden.

[Aerophobia1]

De meeste mensen zullen toch niet inloggen als deze beveiligings melden krijgen.
Niet iedereen is een Tweaker die weet hoe dingen achter de URL werken.

[CaptainKansloos]

Maar de browser geeft misschien een verwarrende melding dat de verbinding niet veilig is, terwijl het mogelijk niet velig kan zijn.

Volgens mij ’blokkeren' de meeste moderne browsers toegang tot een website wanneer het certificaat verlopen is. De melding (en de opties die je hebt) zijn dus anders dan bij bv. een selfsigned cert wat nog binnen de geldigheidsduur valt. Dat gedrag zal vast onder de motorkap aan te passen zijn, maar het is de vraag of dat wenselijk is.

Vergeet niet dat lang niet iedereen die van deze site gebruik moet maken niet per definitie tech-savvy is. "Doet het niet" ==Doet het niet. En daar hebben ze nog gelijk in ook.

[Remzi1993]

Ik snap nog steeds niet waarom ze niet gewoon Let's Encrypt instellen die alles automatisch doet. Het is zo ouderwets om dit handmatig te moeten doen.

[dev10]

Er zijn valide redenen waarom het voor een organisatie niet mogelijk is om gebruikt te maken van Let's Encrypt. Sommige organisaties vereisen certificaten van een specifieke CA die onder contractuele SLA's vallen. Het is ook mogelijks dat er andere auditgaranties gevraagd worden die Let's Encrypt niet biedt.

Wat ik hiermee wil zeggen is dat het zonder te weten welke beleid hier binnen de organisatie voor geldt, je niet zomaar kunt roepen: "Geen Let's Encrypt gebruiken is zo 1999, ik begrijp niet dat ze niet gewoon Let's Encrypt gebruiken"

[Remzi1993]

Begrijp ik, maar dan lijkt mij dat ze dat technisch ook kunnen automatiseren.

[HKLM_]

Blijft moeilijk certificaatjes vervangen voor ze verlopen

[WernerL]

Het is semi-overheid dus waarschijnlijk een heel bureaucratisch proces voordat het certificaat eindelijk vervangen is. Het emailtje met 'SSL certificaat verloopt binnenkort' wordt vaak genegeerd totdat het (bijna) te laat is. Ik zie het in de organisatie waar ik nu werk helaas ook gebeuren.

[Blokker_1999]

Want private bedrijven laten nooit certificaten vervallen natuurlijk ...

Waarom toch altijd de schuld leggen bij het feit dat het om de overheid gaat? Zij falen echt niet vaker dan private ondernemingen. Maar zij zijn wel meer zichtbaar door hun publieke functie.

[Keyb]

Waarom toch altijd de schuld leggen bij het feit dat het om de overheid gaat?

Omdat het om publieke centjes gaat. Als een private onderneming zoiets doet (of laat) zijn het geen publieke centjes. Dus ja, als (semi-) overheids organisatie moet je het beter doen.

[InsanelyHack]

Het onderscheid tussen publieke en private sector wordt vaak gemaakt, maar technisch gezien werkt het certificaatproces overal hetzelfde. Of je nu een webshop of een uitvoeringsorganisatie bent, het aanvragen, valideren en deployen van een TLS certificaat blijft een keten met veel afhankelijkheden waarin nog te vaak handwerk zit. Dat verklaart waarom dit niet alleen overheidsorganisaties overkomt.

Waar het werkelijke verschil zit, is in de impact. De overheid verwerkt gegevens die een stuk gevoeliger zijn dan een doorsnee e commerce omgeving: BSN, gezondheidsinformatie, uitkeringsgegevens. Een certificaatfout kan dan niet alleen een dienst platleggen, maar ook leiden tot ongemakkelijke datalekrisico’s en maatschappelijke schade. Tegelijk kent de overheid door wet en toezicht juist méér compliance en formele stappen voordat een wijziging live mag, wat de snelheid niet ten goede komt.

De conclusie is dus niet dat de overheid het per definitie slechter doet, maar dat ze opereert in een complexer speelveld met hogere risico’s. De echte oplossing is procesmatige modernisering en automatisering, want alleen dan voorkom je dat een verlopen certificaat nog zo zichtbaar wordt.

[GreatDictator]

Omdat het om publieke centjes gaat. Als een private onderneming zoiets doet (of laat) zijn het geen publieke centjes. Dus ja, als (semi-) overheids organisatie moet je het beter doen.

Nou, toen vorig jaar een van onze (=overheid) leveranciers (=privaat) een certificaat had laten verlopen op hun SaaS-applicatie heeft dat ons (=overheid) ook enkele tientallen uren verloren tijd opgeleverd. Was rond 9:15 wel opgelost maar de eerste werknemers stonden rond half acht al buiten in het veld voor hun werk.

[mjtdevries]

Dat soort stommiteiten gebeurt bij private bedrijven ook ja.
Maar meestal maar éénmalig, want dan gaat iemand hoog in de boom vragen hoe dat in hemelsnaam mogelijk was en hoe men gaat voorkomen dat, iets dat zo simpel te vermijden is, nog een keer gebeurd, want daar verliest het bedrijf inkomsten door.

Maar de overheid is geen commercieel bedrijf, dus word er veel minder prioriteit gegeven om dit in de toekomst te voorkomen.
Dat een paar klanten overlast hebben gehad, daar merkt het UWV zelf uiteindelijk niks van.

[Heloise]

Het punt is dat er maar één “overheid” is, waar ik dus gedwongen diensten af moet nemen. Met andere woorden: ik heb geen enkele keuze en kan ze bv. niet via mijn portemonnee treffen bij wanprestatie en dergelijke. En sterker nog: ik heb er via de belastingheffing al dubbel en dwars voor betaald.

Kortom: juist diensten van de overheid behoren altijd feilloos te werken.

[SirBlade]

Er zijn zo'n 195 nationale overheden. Je hebt dus wel degelijk een keus.

[Heloise]

Begrijp ik niet, leg eens uit?

Er is volgens mij bv. maar 1 belastingdienst, UWV, DUO, RDW, voor mij relevante provincie of gemeente (die waar ik ingeschreven sta), maar 1 voor mij relevante netbeheerder (als voorbeeld van een semi-overheidsbedrijf) etc. etc.

Nergens heb ik een keuzemogelijkheid bij dit soort organisaties.

[SirBlade]

Je kan immigreren naar ander land, dan krijg je automatisch een andere overheid. Het is een keus met consequenties, maar het is een keus

[Heloise]

Nog afgezien van deze m.i. volstrekt onzinnige suggestie: dat verandert nog steeds precies niets aan de situatie.

[Zapato]

Als er iets bureaucratisch is dan is het wel het vervangen van een certificaat.

[InsanelyHack]

Het voelt bureaucratisch, maar dat komt vooral doordat de risico’s groot zijn en het proces nog niet overal geautomatiseerd is. Een certificaat aanvragen en uitrollen raakt meestal meerdere teams, afhankelijkheden en controles. Als één stap blijft hangen, ligt meteen een hele dienst plat. Niet omdat het moeilijk is, maar omdat het kritisch is. Automatisering maakt dit een non issue, maar daar zijn organisaties in verschillende tempo’s mee bezig.

[SPee]

Kan ook zijn dat het een paar weken geleden is aangevraagd, maar dat moet allemaal via een centraal servicedesk waar je een ticket aanmaakt. En dat die servicedesk gewoon langzaam is met tickets oppakken, handtekeningen van managers nodig heeft, finance goedkeuring, niet alle benodigde informatie heeft en dan het certificaat opvraagt bij een partij waar het meerdere werkdagen kan duren voordat je het certificaat ontvangt.

[moonlander]

Als het update scriptje altijd werkt, en de instantie die de certificaten uitdeelt iets wijzigt in de api zonder bijvoorbeeld dat te laten weten.. en het update scriptje draait en ziet foutmelding over het hoofd, of krijgt helemaal geen foutmelding... Dan weet niemand er vanaf.. tot het mis gaat. En blijkbaar is het toch niet zo simpel, want een nieuwe certificaat aanvragen duurt niet heel lang. Dat kan binnen een paar min geregeld worden. En die storing duurt veel langer.. dus waarschijnlijk is het update/api process gewijzigd waardoor het nieuwe certificaat niet geupdate is. Of de server accepteert het nieuwe certificaat niet... Het is niet altijd zo simpel als je denkt.

[Sappig]

Daarom zet je ook monitoring op de vervaldatum van je certificaten. Certificaten vervang je niet op de dag dat ze verlopen, maar weken eerder.

[moonlander]

Ja, dat zullen ze vast gedaan hebben. Wat als de monitoring failt en de update van het cerificaat...

[Delgul]

Je kunt je monitoring site ook altijd nog monitoren. En andersom. Als ze allebei tegelijk falen, tja... Maar dat heb ik nog nooit mee gemaakt.

[moonlander]

Misschien is het certificaat vernieuwd, maar na een reboot van de server dat toch het oude certificaat wordt ingeladen.. zeg het maar.. soms klinkt simpel nooit zo simpel.. En als het wel simpel is, hebben ze er wat van geleerd. Ze hebben certificaten van een jaar. Als de medewerker die daar verantwoordelijk voor is niet meer daar werkt.... tsja

[supersnathan94]

Als de medewerker die daar verantwoordelijk voor is niet meer daar werkt.... tsja

.... Een bedrijf is geen zootje random aan het werk zijnde mensen toch? tenminste dat mag ik hopen. Ik vind wel echt veel te makkelijke excuses om gewoon je shit niet op orde te hebben en daar nul verantwoording op te hoeven geven.

[supersnathan94]

Wat als de monitoring failt ? Hier heb je toch sws een agenda reminder Voor staan in je sprint dat je het even checked?

Dit is de voorkant van je winkel. Dit moet werken.

Monitoring kan falen, proces kan falen, dit doe je daarom toch juist een maand van tevoren?

In een organisatie waar je niet zelf vernieuwingen kunt doen, wil ik minstens 2 maanden van tevoren het eerste bericht de deur uit hebben naar het team wat het certificaatbeheer doet. “Let op over een maand verloopt ons certificaat, we willen graag vervanging met jullie inplannen”.

[moonlander]

In welke agenda zet je dat? Als Josien verantwoordelijk was daarvoor en die heeft een andere baan, dan staat dat in de agenda van Josien en dan ook nog eens 1x per jaar.. Dat valt niet op... In een algemene agenda? Wie pakt het dan op, als er 20 developers zijn, en niemand pakt het op... Tsja zo kan ik nog uren doorgaan wat fout kan gaan. Simpel zijn die dingen vaak niet.

[Reactie gewijzigd door moonlander op 5 november 2025 13:33]

[supersnathan94]

Hoe bedoel je in welke agenda? In alle agenda's. Of andere tools die je al in je proces hebt geïntegreerd, zoals Jira reminders: https://marketplace.atlassian.com/apps/1212665/reminders

Wie pakt het dan op, als er 20 developers zijn, en niemand pakt het op

Dan ben je al 3 jaar te laat om eens naar je processen te kijken. Hier heb je gewoon herhalende planningen en allerlei andere overkoepelende procesmanagement strategieën voor toch? Prince2, SAFe, noem maar op.

Je gaat niet een taak oppakken rechtstreeks vanuit een agenda. De agenda item is er om ervoor te zorgen dat je het issue in gaat plannen. En iemand pakt dat dus serieus op. Je PO is uiteindelijk verantwoordelijk dat het namelijk af is.

[Metalfreak]

Tja, waar gewerkt wordt, worden fouten gemaakt. Ergens waar geen fouten worden gemaakt, wordt ook niet gewerkt.

[ramonfincken]

Tis een OV ... dat is altijd ellende , moet je elke secretaresse instructie geven dat er een Engelstalige mevrouw gaat bellen over een cert. En dat je dan moet zeggen "ja wil ik verlengen en heb ik aangevraagd".

Echt vreselijk.

[VHware]

Als je niet Managed SSL afneemt bij bv Globalsign, dan is het per certificaat dat je gebeld wordt / verificatie hebt. Bij Managed SSL wordt het hoofddomein geverifieerd voor OV SSL en eventueel ook EV SSL en dat is dan voor een jaar. Dan kun je OV / EV SSL certificaten vrijwel onmiddellijk aanvragen ipv steeds die verificatie.

[Roko]

Dat krijg je bij outsourcing waarbij de partner achter een ticket-muur zit. Geen ticket? Geen actie!

[Marber]

Een certificaat tijdig vervangen is een heel eenvoudig proces, en vraagt niet meer dan goed beheer van certificaten. Dit niet op orde hebben geeft te denken over de rest van beheerprocessen.

Ik hoop dat de UWV eens geaudit wordt op deze processen.

[Blokker_1999]

Als zelfs grote tech bedrijven er niet in slagen om hun certificaten tijdig te vervangen, waarom dan direct hier roepen voor een audit?

Ja, 1 certificaat vervangen is snel gedaan. Maar tenzij je gaat investeren in goed certificaatbeheer wordt het in een onderneming al snel zeer moeilijk om alles onder controle te houden. En goed certificaatbeheer is ook weer niet gratis.

[FrankHe]

Goed certificaatbeheer is geen luxe, het is een noodzaak.

[Calypso]

Mee eens, maar aan de andere kant maak je mij niet wijs dat er geen procedures/processen ingeregeld kunnen zijn om dit soort situaties te voorkomen. Beheerprocessen, monitoring, etc.

Bij alle bedrijven waar ik de afgelopen 20 jaar gewerkt heb, heb ik een punt gemaakt van "meten is weten" oftewel monitoring. Het in je monitoring opnemen van het verlopen van certificaten stelt niet veel voor.

De alarmbellen hadden af moeten gaan dat de certificaten tegen de verloopdatum aan zaten. En als die alarmbellen al afgegaan zijn en ze desalniettemin verlopen zijn, dan zijn je processen gewoon niet op orde.

Dit had zo makkelijk voorkomen kunnen worden, zelfs in grote organisaties met hun logge besluitvorming en verwantwoordelijkheidafschuiverij.

[Reactie gewijzigd door Calypso op 5 november 2025 10:17]

[ArremeR]

Dit is mijn paradepaardje stokpaardje; UWV wordt uiteraard wel ge-audit wegens certificering, zo'n incident als dit zegt hoeveel ISO-certificeringen en de daarbijbehorende audits eigenlijk waard zijn.

EDIT:

paradepaardje aangepast naar stokpaardje omdat dit beter past in deze context, hierop gewezen door @laptopleon

[Reactie gewijzigd door ArremeR op 7 november 2025 10:01]

[Klauwhamer]

Je paradepaardje is niet heel sterk; gecertificeerd zijn betekent niet dat je nooit incidenten hebt namelijk. Incidenten komen voor, en een kwaliteits- of IT-audit gaan primair of mitigerende voorzorgsmaatregelen op geïdentificeerde risico's belegd zijn in beleid en procedures, en hoe incidenten worden afgewerkt door middel van een behoorlijke registratie en RCA, die wordt meegenomen in MT.

[ArremeR]

Ik doe nogal een generaliserende statement hiermee, waarvan ik me bewust ben, echter is het opnoemen van het doel van audits, certificeringen, risicobeheersing en mitigatie natuurlijk geen indicatie van het nut ervan.

Dat niet alle incidenten voorzien en voorkomen kunnen worden is logisch, interessanter is om te weten of in dit geval het (mogelijk) verlopen van een certificaat bij het UWV als risico en wat de maatregelen zijn, en misschien daarmee ook in zijn geheel wat de effectiviteit is van certificeringen en de daarbij behorende audits.

[Klauwhamer]

Als je niet inziet wat het nut is van een goed functionerend kwaliteits- en veiligheidsraamwerken in je bedrijf, kan ik je ook niet verder helpen. Nogmaals: het één (certificeringen op een goed raamwerk) sluit het ander (menselijke fouten) niet uit. Je begrijpt dan niet goed wat een ISO-certificering en zelfs een ISAE 3402 Type II-verklaring betekent.

[ArremeR]

Ik heb het niet goed verwoord, met beheersingsmaatregelen en veiligheidsraamwerken (best-practices) is niets mis, daarmee ben ik het eens. Wat ik weerleg is het nut van externe audits, deze fungeren als een momentopname waarbij mijn ervaring is dat alle zeilen worden bijgezet totdat de vinkjes zijn gezet. Misschien inderdaad dan wel een zwak punt.

[laptopleon]

Bedoel je stokpaardje?

[kodak]

Onafhankelijk controleren of omstandigheden voldoen aan de eisen om er van te leren is wel het minste wat er na dit soort fouten hoort te gebeuren. Omdat het toepassen van certificaten een belangrijk onderdeel van de beveiliging is en dat beschikbaar houden blijkbaar niet voldoet.

[supersnathan94]

Er is een reden dat partijen als

Let’s encrypt maximaal 90 dagen aanhouden.

juist dat soort korte periodes dwingen je om het snel te regelen. Cert rotatie moet je gewoon direct goed inregelen. Want anders gaat dit je ieder jaar gewoon bijten.

[ramonfincken]

DV ? eens

OV ? oneens, probeer het maar eens met een klant die wat groter is.

[GertMenkel]

OV kan in principe ook via ACME, al moet je dan wel de juiste certificaatboer hebben. Veel certificaatboeren lopen nog achter en zetten het uitgeven van het certificaat ergens in de papiermolen, maar in principe kan je een organisatie valideren en de credentials van die organisatie gewoon automatisch certificaten laten aanvragen.

Partijen als Sectigo bieden dit al aan, dus in principe is het automatisch vernieuwen van een OV-certificaat net zo makkelijk als een Let's Encrypt-certificaat, mits je natuurlijk je organisatie-validatie op orde houdt.

[JoWa]

Er is wel meer mis bij het UWV, lees maar de verhalen van Daan Rijsenbrij op LinkedIn (https://www.linkedin.com/pulse/stop-het-geldverslindend-digitaliseringsdrama-uwv-daan-rijsenbrij-dynxe/).

[lenwar]

Er is inderdaad veel mis.
Maar als we nou ook nog even net doen alsof het allemaal voor het echie is. Er is continu veranderende wetgeving (er worden iedere week wel nieuwe wetten geactiveerd). Het UWV 'moet' continu aanpassen om aan wetgeving te voldoen.
Naast de wetgeving is er ook nog een eis/wens van hun 'klanten', die ook gewoon efficient/klantvriendelijk hun zaken willen kunnen regelen. En tegelijkertijd wil de overheid natuurlijk dat er zo min mogelijk fraude is.

De conclusie die deze meneer trekt is volledig onrealistisch. (dus het maar 'even direct stoppen met alle veranderingen' en maar is met een goed plan komen. Als het zo simpel was.....)

Verder een interessante column hoor, maar weinig meer dan dat.

[JoWa]

Het UWV wil een mega operatie in gang zetten: niet alleen veel vernieuwen, maar ook meteen een heel andere ontwikkelwijze. En dat allemaal zonder gedegen architectuur. Dat ontbreekt nu ook al grotendeels, waardoor de puinhoop aldaar is ontstaan.
En ja, de veranderingen in de wetgeving helpen ook niet echt, maar als de architectuur op orde is, kan je dat in principe nog wel verwerken.
Verder is Daan Rijsenbrij een zeer kundige voormalige IT-hoogleraar die gewoon weet waarover hij praat.

[DataMan]

En je gaat er vanuit dat dit niet gebeurt?

[ramonfincken]

En nog MEGAzwak ook -> https://www.xolphin.com/sslcheck/mijn.uwv.nl

RSA 2048 ... dat is echt uit de middeleeuwen

[stuiterveer]

Voordat je het zo gretig afkraakt, is het misschien ook goed om in gedachten te houden dat bijvoorbeeld Let's Encrypt ook gewoon en masse RSA 2048 gebruikt.

[mexicanburribo]

Dat is ook een kwestie van instellen. Je kunt als je een nieuwe cert genereert bij letsencrypt de size meegeven

[stuiterveer]

En als je dat niet opgeeft, wat veel mensen zullen doen omdat ze geen idee hebben wat wat is en ze gewoon iets werkends moeten hebben, dan is dat alsnog RSA 2048.

[mexicanburribo]

Dat is correct, zou inderdaad mooi zijn als de default hoger zou liggen. De optie is er iig al. Al weten we allebei dat de (semi) overheid dan alsnog vrolijk aan 2048 vol zou houden totdat dat depricated wordt in de browser. Dus dan heb je alsnog hetzelfde probleem

[WokBoy]

2048 is voorlopig echt nog niet deprecated. Laten we trouwens ook vooral niet vergeten dat een site als het UWV heel veel verschillende mensen moet bedienen, waaronder een hoop met weinig geld die misschien nog met een verouderde telefoon de site willen kunnen openen. En zolang je server side niet toestaat dat je te ver "naar beneden" gaat is het nog echt geen probleem.

[ramonfincken]

kijk en huiver ( tabel ) https://www.ssl2buy.com/wiki/rsa-vs-ecc-which-is-better-algorithm-for-security#:~:text=RSA%20vs.%20ECC%20Algorithm%20Strength

Ja LE is ook een draak, en kun je heel simpel gewoon ECC kiezen.
Zonder nadenken 2048 gebruiken vind ik persoonlijk echt niet kunnen. Niet dat de andere ( en ECC ) opties pas net bestaan ook ..

[stuiterveer]

Je denkt dat jan en alleman die tabel kan interpreteren? Los daarvan: de standaard instructies van Let's Encrypt noemen niet het specificeren van het type encryptie. En dat is prima voor de meesten, zolang het werkt is het goed. Dat je iets anders kunt gebruiken is ook prima, maar laten we wel realistisch zijn en beseffen dat het gros van de LE certificaten gewoon RSA 2048 gebruiken. En dat is prima.

[ramonfincken]

De normale eindgebruiker niet, maar die hoeft dat ook niet te snappen


In jouw voorbeeld zetten de LE lui hem ook al op 4096 en kun je makkelijk naar ECC
https://eff-certbot.readthedocs.io/en/stable/using.html#getting-certificates-and-choosing-plugins:~:text=%23%20Use%20a%204096%20bit%20RSA%20key%20instead%20of%202048%0Arsa%2Dkey%2Dsize%20%3D%204096

[njitter]

Maar certificaat wordt wel elke 3 maanden vernieuwd. Als men RSA2048 in 3 maanden kan kraken dan hebben we een veel groter probleem. Zover is het nog niet met Quantum computing.

[enetrati]

Dat zou geen probleem hoeven te zijn mits het certificaat regelmatig wordt veranderd: lees elke maand a twee maanden, het advies dat Lets Encrypt ook geeft. Dat gebeurt juist niet. Het is tot nu toe jaarlijks en dan wordt het wel weer een probleem.

[Blokker_1999]

Niets mis met RSA 2048. Als dat je enige reden is om het zwak te noemen ...

[watercoolertje]

Het is afwachten wat het nieuwe certificaat doet, het oude certificaat is sowieso niet relevant meer

Maar zelf zie ik geen probleem om nu nog RSA 2048 te gebruiken, is redelijk standaard...

[Reactie gewijzigd door watercoolertje op 5 november 2025 09:51]

[mjtdevries]

"MEGAzwak" zelfs.

Wat is jouw reden om het zwak of zelfs megazwak te noemen?
Daarmee laat je zien dat je eigenlijk heel weinig kennis van encryptie hebt.

Dat je de optie hebt om een "sterker" certificaat te kiezen, betekent niet dat deze zwak is.

Als een encryptie zo sterk is dat onze zon eerder uitdooft dan dat je het kan bruteforcen, dan is er weinig reden om nog een sterkere encryptie te gebruiken.

[Kun]

Even advocaat van de duivel hier. Ik begreep (mogelijk aluhoedjes geneuzel) dat er al versleuteld verkeer wordt opgeslagen door partijen als de NSA zodat als ze in de toekomst (misschien met quantum computers) deze encryptie wel kunnen breken ze alsnog inkijk krijgen in belangrijke informatie. Heeft een sterker SSL certificaat dan mogelijk voor die redenen nu al zin? Zijn er op dit moment überhaupt al post-quantum encryptie algoritmes te gebruiken in SSL certificaten?

[mjtdevries]

Quantum computers werken op zo'n totaal andere manier dat op het moment dat 2048 niet meer veilig genoeg is 4096 dat dan ook niet meer is.

Als je je daar zorgen om maakt dan is het inderdaad beter om naar een totaal ander algoritme te gaan.
Er zijn op dit moment al wel nieuwe algoritmes, maar het probleem is dat die nog niet geaccepteerd zijn als standaard.
Dus als je je TLS op basis van zo'n algoritme maakt, dan heb je waarschijnlijk het probleem dat je klanten je niet kunnen bereiken.

[Kun]

Ik denk dat iets teveel mensen nu certificaten aan het testen zijn via die link, want ze zijn nu plat

[wiseger]

Dan gebruik je mijn favoriet: https://www.ssllabs.com/ssltest/analyze.html?d=mijn.uwv.nl

[Kun]

Thanks, laten we eens kijken of we die ook gezamelijk kunnen overbelasten

[MeNTaL_TO]

Denk dat ze meelezen. Nieuwe certificaat is RSA 4096

[GK87]

Inmiddels is er weer een nieuw certificaat actief tot 04-11-2026 met RSA4096.

edit:
Dubbel (MeNTaL_TO)

[Reactie gewijzigd door GK87 op 5 november 2025 11:38]

[robbinkg]

@ramonfincken ze hebben iig gehoor gegeven aan je reactie, het is nu RSA 4096

[supersnathan94]

Hij is geüpgradet naar RSA-4096 ondertussen

Maar je kunt geen certificaten met RSA-4096 gebruiken als je een standaard loadbalancer in AWS gebruikt met HTTPS offloading: https://stackoverflow.com/a/63532773

Dit is pas recent aangepast en allemaal wat strakker getrokken, maar het wordt echt nog heel veel gebruikt

https://repost.aws/knowledge-center/elb-ssl-tls-certificate-https

Volgens mij is ACM support met ELB pas een jaar live.

[lenwar]

https://www.ssllabs.com/ssltest/analyze.html?d=mijn.uwv.nl&s=145.84.24.50

Qualys geeft ze toch nog een A-

Het vervelende voor een organisatie als het UWV is, is dat zij iedereen moeten kunnen bedienen. Ook iemand die geen geld/zin/interesse heeft voor een nieuwe(re) telefoon/computer waar de TLS-certificaten niet meer van worden bijgehouden.

De RSA key is is overigens gewoon 4096 bits lang (wat op het moment nog als voldoende wordt beschouwd). Het intermediate certificaat is wel 2048 bits lang. Verder zijn zaken als HSTS en forward secrecy gewoon geregeld.

Wat ik veel kwalijker vind, is dat ze geen TLS1.3 ondersteunen, maar 'alleen' TLS1.2.

[Davey400]

Nederlanders die recht hebben op een uitkering vanwege bijvoorbeeld ziekte of werkeloosheid kunnen hierdoor niet veilig inloggen

Het verlopen van een certificaat zorgt er niet voor dat je niet veilig meer in zou kunnen loggen. Dat het certificaat niet al te sterk was, was gedurende de geldigheidsduur ook al een ding.

Het vervelende is dat mensen in hun browser een waarschuwing krijgen, en daardoor (terecht) afhaken.

Het is vooral heel slordig.

[latka]

Hoe bedoel je "niet al te sterk was" ?

[Heroic_Nonsense]

@Davey400 refereert naar de huidige concensus dat RSA2048 niet meer voldoet voor certs binnen beveiligde verbindingen.

Echter zijn NIST, ENISA en Microsoft het daar niet meer eens - voor eenvoudige certs zoals waar we het hier over hebben, is RSA2048 in het dagelijkse gebruik prima (stellen zij). Ook cert vendors zoals Let's Encrypt geven nog altijd RSA2048 certs uit.

NCSC stelt wel dat 2048 uitgefaseerd zou moeten worden, en beveelt 3072 en hoger aan (bron, pagina 17 en 18). Men geeft er nog geen negatief advies over uit dus.

EDIT: typos

[Reactie gewijzigd door Heroic_Nonsense op 5 november 2025 10:27]

[latka]

Volgens mij was het idee per 2030 over te stappen op 3k certs. Maar als we inderdaad naar een levensduur van 3 maanden voor een cert gaan is dat denk ik ook niet echt meer passend en zou 2k voldoende zijn.

[Blokker_1999]

Maar je doet hier geen authenticatie. Je beveiligd een verbinding.

[Heroic_Nonsense]

My bad, ik bedoelde ook de verbinding (link gaat ook naar een bron over gebruik van TLS).

Post aangepast.

[mjtdevries]

Als NIST, ENISA en Microsoft het er niet mee eens zijn dan is er duidelijk geen concensus.

Het is eigenlijk gewoon een kwestie dat veel mensen denken dat een hoger getalletje beter is, en dus MOET je dan dat ook gebruiken.

De mensen die kennis van zaken hebben weten dat er eigenlijk geen risico is. Maar het is zo vermoeiend om steeds aan mensen met onvoldoende kennis uit te leggen waarom er geen valide reden is het aan te passen.
Zeker wanneer het voor huidige computers eigenlijk geen performance verschil oplevert en je het ook niet hoeft te laten vanwegen kosten.

[Basszje]

Dat is toch echt iets wat al minstens een decennium geen probleem zou moeten zijn met autorenew etc.

[Khrome]

Autorenew is niet mogelijk voor EV certificaten. Die moet je elk jaar handmatig vernieuwen en verifiëren, hier komen ook telefoontjes bij kijken van de CA naar het bedrijf wat die aanvraagt - En ze mogen een akkoord alléén accepteren via één specifiek telefoonnummer en één specifieke persoon.

EV certs zijn echt een drama.

[Kalief]

Iedereens gezicht die van hen wel eens een mailtje 'uw CV verloopt binnenkort' heeft ontvangen vertoont nu een ironische grijns.

[W1ck1e]

Elke 80 dagen als ik mij niet vergis. Wat een raar getal.
doe dan 90, of 128 ;)

[mr.DJ95]

Aangezien we de maximale geldigheid van publicly trusted Web PKI certificaten zoals deze langzaam gaan afbouwen naar 47 dagen in 2029 vraagt dit om automatisering. Voor het automatisch vernieuwen van certificaten zijn inmiddels ook zat mogelijkheden met ACME integraties, let's encrypt, Certify the web etc.

Ik verwacht dat MSP's hier nog wel een uitdaging hebben,

Zie ook: https://datatracker.ietf.org/doc/html/rfc8555/

[Liger]

Het NSCS heeft met het oog op die wijzigingen recent een publicatie uitgebracht over hoe je dit toekomstbestendig inricht: https://www.ncsc.nl/wat-kun-je-zelf-doen/weerbaarheid/beschermen/certificaatbeheer

Met als belangrijkste punt: ook ACME gebruiken binnen grote organisaties en voor OV en EV. Als ik de comments lees weet menig Tweaker niet eens dat dat kan, dus er is nog een boel werk aan de winkel.

[mr.DJ95]

De publicatie is mij inderdaad bekend en ik kan niet hard genoeg benadrukken dat bedrijven, zeker MSP's hierin moeten investeren. Een certificaat is altijd een operationeel en security risico met eventuele impact op de reputatie. Ze kosten in veel situaties nog altijd veel moeite en tijd om te vervangen terwijl dat zoveel makkelijker kan.