TLS-certificaten overheidsdomeinen lijken verlopen door fout certSIGN - update

Door een fout bij de certificaatautoriteit certSIGN lijken de TLS-certificaten van verschillende overheidswebsites ingetrokken. In de Certificate Revocation List (CRL) van het Roemeense bedrijf staat dat de certificaten van onder meer logius.nl en meerdere gemeentewebsites zijn ingetrokken.

De bug is onder meer gedeeld op Bugzilla. De fout ontstond volgens Gabriel Petcu van certSIGN tijdens de voorbereiding op het intrekken van certificaten die nog gebruikmaken van een clientAuth Extended Key Usage. Deze sleuteluitbreiding gebruiken servers om de identiteit van clients te controleren.

OCSP en CRL?

Er zijn twee manieren om de status van webcertificaten te controleren. De Certificate Revocation List (CRL) is een lijst van alle ingetrokken certificaten die de uitgever publiceert. Het Online Certificate Status Protocol (OCSP) werkt gerichter: de browser stuurt een verzoek naar de OCSP-server van de certificaatautoriteit met de vraag of het certificaat van de website nog geldig is. Deze methode is vaak betrouwbaarder, omdat hij in real time werkt, terwijl de certificaatautoriteit de CRL-lijst op specifieke momenten updatet.

Google heeft in het Chrome Root Program, dat de eisen definieert waaraan certificaatautoriteiten moeten voldoen om vertrouwd te worden door de Chrome-browser, opgenomen dat openbare TLS-certificaten vanaf 15 juni geen EKU meer mogen bevatten voor clientauthenticatie. Browsers vertrouwen certificaten die zo'n uitbreiding nog wel hebben na 15 juni niet meer. CertSIGN had klanten op de hoogte gesteld dat ze hun oude certificaat moesten vervangen door een nieuw exemplaar dat wel voldoet aan de nieuwe regels.

Om klanten tijd te geven om hun certificaat te wijzigen, besloot certSIGN zijn CRL-lijsten en de status van het Online Certificate Status Protocol 24 uur na de intrekking te wijzigen. Tijdens het plannen van die publicatie trad een fout op 'bij de aanpassing van de geautomatiseerde workflow'. Daardoor werden de bijgewerkte CRL-lijsten al gepubliceerd voordat de synchronisatie met de OCSP-database was voltooid. Daardoor kunnen CRL- en OCSP-checks nu andere reacties geven.

Dat treft ook Nederlandse websites, omdat KPN daar leverancier is van certSIGN-certificaten. KPN bevestigt dat er vanuit 'een leverancier' een lijst is gepubliceerd waarin 'een aantal websites' onterecht als onveilig wordt aangemerkt. Volgens een woordvoerder heeft de leverancier dat probleem opgelost. Certificaatcheckdiensten tonen nog wel problemen met verschillende websites, waaronder logius.nl en eherkenning.nl.

Update, 19.04 uur – In het artikel stond aanvankelijk dat het CA/Browser Forum had bepaald dat openbare certificaten geen clientAuth EKU mogen hebben. Dat klopt niet: dit is beleid dat Google heeft opgenomen in zijn Chrome Root Program. Het artikel is hierop aangepast.

Bron: Tadamichi via Getty Images

Reacties (56)

[moppentappers]

Leuk dat het is opgepikt. Ik heb de bug op Bugzilla gemeld. In eerste instantie kon ik het niet goed thuisbrengen: het eindcertificaat was geldig en crt.sh liet niets bijzonders zien. Pas toen ik de intermediate tegen de eigen CRL van certSIGN hield, zag ik dat deze was ingetrokken.

Wat ik opvallend vind, is dat certSIGN aangeeft zijn klanten te hebben geïnformeerd, maar dat noch certSIGN noch KPN lijkt te controleren of partijen de nieuwe intermediate daadwerkelijk op hun webserver hebben geplaatst. Het grootste deel is inmiddels overgestapt naar een andere CA of naar de nieuwe certSIGN-intermediate, maar zeker gezien certSIGN een kleine niche speler is, hadden ze hier denk ik meer mee kunnen doen.

maar een aanzienlijk aantal gebruikt twee dagen later nog steeds de ingetrokken keten. Ik heb dit vandaag live gecontroleerd, onder andere bij:

Overheid/PKI: logius.nl, pkioverheid.nl, eherkenning.nl, www.digid.nl, digilevering.nl, digimelding.nl, peppol.nl, internetconsultatie.nl en sbr-nl.nl.
Gemeenten: Alkmaar, Hilversum, Wageningen, Sittard-Geleen, Dronten, Texel, Tholen en Schouwen-Duiveland, plus circa twaalf andere gemeenten.
NS: nspanel.nl, nszakelijkpanel.nl en storingenstations.nl.

Opvallend detail: digid.nl heeft de intermediate inmiddels vervangen, maar www.digid.nl nog niet, dus

Zelf te controleren met: openssl s_client -connect www.digid.nl:443 -servername www.digid.nl | openssl x509 -noout -issuer

[Noxious]

Ik heb hier gisterenmiddag een mail over gekregen van een gemeente, die ze ook dezelfde dag (de 11e dus) hadden gekregen van KPN met daarin een lijstje van hun domeinen die niet op orde waren.

Er lijkt dus wel communicatie te zijn nu, maar rijkelijk laat.

[tanarchy]

Klein beetje context. Die revocation van die intermediate is de de gebeurd. De 11de zijn de klanten op de hoogte gesteld rond 3 uur s'middags op de zelfde wijze als je een random nieuwsbrief krijgt.

Vrijdag, tja wie wil op vrijdag een change doen...

Dit is ook niet iets wat normaal uit monitoring (connect naar port 443, check expiry date -30 dagen) komt want de leaf certificate blijft gewoon goed.

Heb maar een tooltje gemaakt voor chains te testen, wat makkelijk om te zetten is in een automagisch scriptje. https://chainsmith.gillot.eu (githubje is aanwezig)

[moppentappers]

Toch even nieuwsgierig, bedoel je dat KPN toen klanten op de hoogte bracht, of dat certSIGN toen pas de informatie had gedeeld?

De revoke zelf was al van de 9e, als certsign het pas op de 11e heeft laten weten is dat nog wel relevant voor de bug report bij Mozilla.

[tanarchy]

Wij zijn om die tijd door KPN verwittigd iedergeval. Vond het wel heel apart dat hij wel op de CRL stond maar niet op de OCSP bij certSIGN. (Human error?)

[Tri]

In hoeverre de fout menselijk was haal ik niet uit het bericht. Maar de hele oorzaak lijkt dus te zijn dat specifiek de CRL per abuis te vroeg is gepubliceerd.

[moppentappers]

Op bugzilla staat er een uitleg over, maar ik vermoed dat Mozilla reviewers nog wel aanvullende vragen gaan stellen

[Baardappel]

@Imre Himmelbauer het niet meer toestaan van de clientAuth EKU is een besluit van de Chrome root program geweest, niet het CA/B forum. Omdat Chrome natuurlijk nogal een marktaandeel heeft is het de facto wel een verplichting.

[Imre Himmelbauer]

Je hebt gelijk! Ik pas het meteen aan!

[Baardappel]

Die wijziging is trouwens met negen maanden uitgesteld naar maart volgend jaar https://googlechrome.github.io/chromerootprogram/. Naar het schijnt zorgde het grote aantal wijzigingen in CA land (MPIC, persistent-DNS validatie, DNSSEC verplichtingen) voor nogal wat tegengesputter. certSIGN is dus niet alleen slordig, maar ook overhaast geweest?

[Imre Himmelbauer]

Volgens mij gaat dat specifiek alleen over subscriber certificates. Voor certificaten van sub-CA's geldt die datum van 15 juni, als ik het goed lees.

[duiveltje54]

Wat ik mij af vraag bij dit bericht :

In de Certificate Revocation List (CRL) van het Roemeense bedrijf staat dat de certificaten van onder meer logius.nl en meerdere gemeentewebsites zijn ingetrokken

Waarom de gemeente en misschien ook andere overheid instanties dit uit handen geeft en niet in eigenbeheer? ( Waarschijnlijk de centjes die het kost of iets dergelijks ) Het is toch van de zotte dat wij zo afhankelijk van andere moeten zijn voor dit soort zaken? Of denk ik nu te makkelijk? Ik ben ook maar een leek in dit verhaal.....En kan het mij voorstellen net als andere burgers dat ik het best naar vind dit soort berichten in de zin van hoe veilig zijn al onze gegevens bij de overheid ect ect.

Misschien dat er iemand is die dit beter kan verwoorden dan ik ?

[Noxious]

Nederland had vroeger een vertrouwde PKI Certificate Authority, namelijk 'Staat der Nederlanden Root CA', en was daar zelfs het eerste land ter wereld mee buiten commerciële partijen.

Daar waren altijd al (m.i. terechte) moppers over, maar in 2021 heeft de Staatssecretaris besloten te stoppen met deze dienst nadat er een paar incidenten waren geweest en de conclusie was dat commerciële partijen deze dienst minstens zo goed kunnen vervullen.

De certificaat autoriteit bestaat nog steeds, maar zit niet meer standaard in de trust stores van besturingssystemen en browsers, en wordt vrijwel alleen gebruikt voor 'machine-to-machine'-koppelingen (webservices) in overheidsland en zaken als persoonlijke certificaten voor eHerkenning, etc.

[Reactie gewijzigd door Noxious op 12 juni 2026 16:14]

[Xander2]

Urgh. Ik reageerde net op Nederlandse overheid onderzoekt Nextcloud als alternatief voor Microsoft 365 en lees dan dit.

Natuurlijk kunnen commerciële bedrijven dit prima regelen en waarschijnlijk efficiënter dan de overheid met betere helpdesk, maar wie heeft ooit besloten dat het handig is om een paar munten te besparen voor een essentiële dienst en dat met blind vertrouwen over te hevelen naar een partij in een ander land, laat staan Roemenië waarvanuit elke website beheerder ongeveer dagelijks hackpogingen ontvangt.

Het is alsof je het luchtalarm uitbesteed aan een call-centre in India.

[HMS]

Niemand heeft bewust besloten om dit naar Roemenië uit te besteden. Voor overheidsorganisaties is IT gewoon een kostenpost, dus dat wordt aanbesteed en vervolgens uitbesteed.

Deze certificaten zullen ongetwijfeld via de IT leverancier gelopen zijn, die vervolgens weer de goedkoopste CA uitzoekt en dan daar een certificaat aanvraagt. Zou mij niet verbazen als het via KPN gelopen is, zoals het artikel ook al suggereert.

[Noxious]

CertSIGN is zeker niet de goedkoopste CA (€ 259p/j voor OV via KPN), maar wel de enige vertrouwde 'webserver' CA waarvan KPN reseller is, en heel veel overheid neemt certificaten af bij KPN omdat ze daar ook al klant zijn voor PKIoverheid (en historisch al klant waren).

Er zijn er in mijn ervaring ook een boel die gewoon een Sectigo DV certificaat gebruiken van twee tientjes of Sectigo OV (€ 133 p/j).

[Xander2]

Niemand heeft bewust besloten om dit naar Roemenië uit te besteden. Voor overheidsorganisaties is IT gewoon een kostenpost, dus dat wordt aanbesteed en vervolgens uitbesteed.

Dat is hardstikke mooi, ik snap de procedure.

Maar ik verwacht dat de overheid aanvullende eisen stelt zoals ik als burger kan verwachten in elke communicatie met de overheid.

Kwestie van prioriteiten, vertrouwen lijkt mij nummer 1 bij certificaten. Toon maar aan dat leverancier daar beter in is dan LetsEncrypt. Wie of wat dat moet regelen, als subcontractor voor KPN moest ik daar audits, reglementen, voorzieningen en de hele reutemeteut voor afsluiten.

Dat kost geld die toch wel max gevangen wordt door KPN of wie dan ook, dus dan mag je best verwachten en eisen dat iets simpels als een CA geregeld wordt in Nederland, inhouse en niet uitbesteed wordt aan een derde partij waar niets over te zeggen is. Dat is een bewuste keuze en dus is Roemenië een bewuste keuze. Voor hetzelfde geld was GoDaddy of obscure partij ingeschakeld, wie weet het?

Mooie boel, als ik dubieuze Windows/Office licenties ga aanschaffen via Marktplaats of Telegram kan ik toch op geen enkele manier de rotzooi over de schutting gooien?

[Noxious]

Volgens mij staat CertSIGN redelijk goed bekend, maar fouten gebeuren. Deze wijziging was ook al lang vooraf aangekondigd en webservers hadden de certificaten in januari al op orde kunnen hebben. Het ging enkel mis bij het uitstel juist omdat eindgebruikers het nieuwe certificaat nog niet in gebruik hadden genomen.

Een Nederlandse CA zou leuk zijn, die hadden we vroeger ook (DigiNotar), maar dat liep niet goed af - en de overheid heeft het met 'onze eigen' CA ook niet gehaald dan blijven er niet veel alternatieven over binnenlands.

Er is m.i. geen harde reden om niet voor een CA als CertSIGN te gaan.

[Xander2]

Het gaat me niet om fouten of iedereen op het hakblok te zetten.

Er is genoeg technische know-how in Nederland, er is genoeg administratieve vaardigheid om zoiets op te zetten.

Mijn vraag is, hoe kan het dat ondanks deze kennis en ervaring eerst aanbestedingen worden gedaan die blijkbaar falen en vervolgens elders zonder eisen worden aanbesteedt?

Dat snap ik niet.

[Noxious]

Ik denk niet dat hier veel aanbesteding bij komt kijken, dit gaat om kleine bedragen en is regulier onderhoud van bestaande applicaties.

Het staat je natuurlijk vrij om een CA te beginnen, maar om vertrouwd te worden door alle browsers én operating systems omvat een heleboel hoepels om doorheen te springen, zie bijv. https://www.thesslstore.com/blog/how-to-become-a-certificate-authority/ voor een kort overzicht (specifiek het hoofdstuk 'How to Become a Trusted Certificate Authority (Public CA)').

Het draaien van een eigen CA is technisch zeer eenvoudig en vrijwel elk middelgroot bedrijf doet dit al intern; maar het publieke vertrouwen is een hele andere slag en ik zie niet in waarom de overheid daarvoor zou moeten betalen of wat voor grote meerwaarde dit zou bieden buiten de al bestaande CA's.

[Aldy]

Er is genoeg technische know-how in Nederland, er is genoeg administratieve vaardigheid om zoiets op te zetten.

Dat heb je net kunnen lezen in het antwoord waarop je reageert: Wij hadden DigiNotar en dat is niet heel erg goed afgelopen

Mijn vraag is, hoe kan het dat ondanks deze kennis en ervaring eerst aanbestedingen worden gedaan die blijkbaar falen en vervolgens elders zonder eisen worden aanbesteedt?

Als het om grote bedragen gaat, wordt er Europees aanbesteed en dan is het een kwestie welke leverancier aan de gestelde eisen voldoet. Afgezien daarvan is er geen enkele reden om niet voor CertSign te gaan.

Mijn vraag is, hoe kan het dat ondanks deze kennis en ervaring eerst aanbestedingen worden gedaan die blijkbaar falen en vervolgens elders zonder eisen worden aanbesteedt?

Ik begrijp je vraag niet helemaal. Er is een fout gemaakt en voor een groot deel is dit opgelost. Overmorgen zijn die certificaten sowieso niet geldig meer.

[Xander2]

[...]
Dat heb je net kunnen lezen in het antwoord waarop je reageert: Wij hadden DigiNotar en dat is niet heel erg goed afgelopen


[...]
Als het om grote bedragen gaat, wordt er Europees aanbesteed en dan is het een kwestie welke leverancier aan de gestelde eisen voldoet. Afgezien daarvan is er geen enkele reden om niet voor CertSign te gaan.

De veiligheid van communicatie tussen overheid onderling en burgers vind ik een goede reden.

Europees aanbesteden gebeurt zat dat de gewenste leverancier bovenaan eindigt.

[Aldy]

De veiligheid van communicatie tussen overheid onderling en burgers vind ik een goede reden.

Een goede reden waarvoor?

Europees aanbesteden gebeurt zat dat de gewenste leverancier bovenaan eindigt.

Bovenaan eindigen heeft niets met gunnen te maken. Het kan zijn dat een bedrijf dat niet bovenaan eindigt uiteindelijk betere condities heeft, denk bijvoorbeeld aan continuïteit.

[Xander2]

[...]
Een goede reden waarvoor?

Om de veiligheidsketen in-house te houden. Certificaten vormen de basis van versleutelde communicatie.

Als Diginotar niet betrouwbaar was is het overhevelen naar een externe leverancier vreemd en levert dat aan de andere kant vertrouwen en garanties in. Hoe meer schakels in de keten des te onveiliger.

[Aldy]

Om de veiligheidsketen in-house te houden. Certificaten vormen de basis van versleutelde communicatie.

De veiligheid tussen overheid en burger is helemaal niet in het geding en dus in deze discussie niet relevant.

Als Diginotar niet betrouwbaar was is het overhevelen naar een externe leverancier vreemd en levert dat aan de andere kant vertrouwen en garanties in. Hoe meer schakels in de keten des te onveiliger.

DigiNotar was een Nederlandse leverancier van certificaten en is op een bepaald moment gecompromitteerd geraakt. Hierdoor waren ze niet meer betrouwbaar als uitgever van certificaten. En een antwoord op je laatste zin: Een goede en betrouwbare externe leverancier is goedkoper en net zo veilig als dat je dit in-house doet.

[Ferruginous Hwk]

Die is er uit gehaald toen de browsers de houdbaarheid van certificaten steeds meer begon in te korten. Omdat PKI-overheid niet in dat tempo mee kon en wilde voorkomen dat een nieuwe Diginotar situatie zou ontstaan is besloten om geen webserver (browser) certificaten meer uit te geven.

[HMS]

Omdat het exploiteren van Public Key Infrastructure (PKI) op de schaal en het vertrouwen van een globaal erkende Certificate Authority best veel werk is (oftewel alle browsers vertrouwen jou als CA). De overheid heeft wel zijn eigen PKI (PKIoverheid), maar die wordt zeer beperkt ingezet voor publieke websites (ik ken zo geen voorbeelden). Wat leesvoer als je het beter wil begrijpen: Public key infrastructure - Wikipedia & Certificate authority - Wikipedia.

edit:
Ah ik zie dat de Staat der Nederlanden CA er inderdaad uit is zoals @Noxious beschrijft, ik was al een het zoeken in certmgr.msc want ik wist dat die er was

[Reactie gewijzigd door HMS op 12 juni 2026 16:09]

[banaan666]

De huidige PKIoverheid certificaten zijn enkel nog een Private CA. De publiek vertrouwde PKIoverheid CA heeft verschillende root certificaten gehad o.a. G1, G2, G3 en EV, enkel zijn deze nooit vertrouwd door Oracle/Java.

[Sleipnir]

Kort door de bocht kun je best certificaten gaan uitgeven als overheid, maar dat werkt alleen als je de grote browserbeheerders kan overtuigen je blind te vertrouwen. Dus een overheids CA zou door alle hoepels van Google, Microsoft, Mozilla, Apple, etc. moeten springen om ze zover te krijgen jouw certificaten in Chrome, IE, Firefox, etc. als vertrouwd te markeren. Zonder medewerking van o.a. deze lijst van Amerikaanse giganten (het heeft nog wel meer voeten in de aarde dan dat) zijn websites met jouw certificaat "onveilig" als je ze bezoekt met één van die browsers.

[Tinus7]

Ik denk dat Nederland daar te klein voor was om dat voor elkaar te krijgen en professioneel te beheren, zoek maar eens naar Diginotar. Maar de EU zou dat gemakkelijk kunnen beheren en afdwingen bij de OS en browser producenten.

[Noxious]

In theorie mogelijk, maar ik denk niet dat de EU het vertrouwen geniet wat hiervoor nodig is, zeker na wat eerdere acties in dit domein.

De EU heeft met eIDAS 2.0 / Artikel 45 een poging gedaan om besturingssystemen en browsers te forceren om CA's van EU leden te vertrouwen ook als ze niet voldoen aan de beveiligingsstandaarden.

Daar is vanuit de IT wereld een grote negatieve response op gekomen:
- https://openssf.org/blog/2023/11/02/openssf-co-signs-industry-joint-statement-on-article-45-in-the-eus-eidas-regulation/
- https://www.infosecurity-magazine.com/news/eu-eidas-face-backlash-mozilla/
- https://www.internetgovernance.org/2023/11/07/fragmenting-the-web-the-eus-identity-power-play/

Uiteindelijk is artikel 45 aangepast/afgezwakt: https://securityriskahead.eu/wp-content/uploads/2024/02/Mozilla_-press-release_eIDAS-EP-Plenary-adoption.pdf

Nog wat meer achtergrond hier:
https://blog.mozilla.org/netpolicy/2024/11/07/behind-the-scenes-of-eidas-a-look-at-article-45-and-its-implications/

[CAPSLOCK2000]

Een paar punten.

1. Ten eerste hebben onze regering jarenlang geprobeerd om zoveel mogelijk door de markt te laten doen ipv in overheidshanden te houden.

2. Het hele certificaten-gebeuren is gebaseerd op het idee dat er wederzijds vertrouwde onafhankelijke derde partijen zijn. Wie zijn eigen certificaten-systeem draait is geen onafhankelijke vertrouwde derde partij. Binnen onze eigen overheid is dat op zich geen probleem, maar als je met de rest van de wereld wil samenwerken heeft voordelen om het te beleggen bij een neutrale partij.

3. Deel van het systeem is dat alle deelnemers elkaar in de gaten houden zodat rotte appels snel herkend worden. Dat betekent ze allemaal in staat zijn om waarschuwingen uit te sturen en elkaars certificaten op de blokkeerlijst te zetten en aan de noodrem te trekken.
Daar is wat fout mee gegaan. Iemand heeft op de grote rode "Noodstop!" knop gedrukt. Je zou je kunnen afvragen of daar geen extra controle bij moet, maar dat botst weer een beetje met het idee van een noodrem.


PS.
4. Ik vind het hele CA-systeem erg verouderd en redelijk overbodig. 90% van het systeem kunnen we beter vervangen door DANE/TLSA.
Certificaten hebben twee functies, de verbinding versleutelen bewijzen met wie je contact hebt. Dat tweede deel is altijd al problematisch en onbetrouwbaar geweest. In praktijk betekent het niet meer dan dat je control hebt over de web of mailserver en zegt het niks over je een legitiem bedrijf bent. LetsEncrypt heeft dat heel expliciet gemaakt door het systeem volledig te automatiseren, inclusief alle controles. De controles die LE doet kun je net zo goed op je eigen PC laten doen, dan heb je de hele tussenlaag van CA's niet meer nodig. Wat overblijft is vooral end-to-end encryptie.
De ultrakorte uitleg is dat je in DNS het serienummer van je self-signed certificaat publiceert. Als je website bezoekt begint dat sowieso met het IP-adres opzoeken in DNS. Nu krijg je daar dan alvast het serienummer van het certificaat bij zodat je direct kan controleren of de server het juiste certificaat gebruikt. Meer heb je niet nodig, geen derde vertrouwde onafhankelijke partij nodig. Je hebt wel (nog meer) vertrouwen in DNS nodig, maar dat was toch al noodzakelijk. Zo kun je vanaf het eerste begin end-to-end ecnryptie gebruiken.

Er blijft een kleine rol over voor traditionale CA's die daadwerkelijk identeitscontroles doen maar dat is maar een fractie van het totaal. Voor een deel van die functionaliteit zijn er tegenwoordig op andere opties zoals DigiD en Yivi.

[duiveltje54]

Super bedankt , dit geeft mij weer een andere kijk over gedachte waarom de overheid zoiets doet en wat er dus nog meer speelt.

[Groentjuh]

Oh, dat zou misschien verklaren waarom Simyo's forum ook SSL-problemen heeft. Daar melden sommige dat ze deze melding krijgen.

[Noxious]

Yes inderdaad, die gebruikt ook dezelfde CertSIGN keten.

[gertvdijk]

Dat is zeker een verklaring, want forum.simyo.nl heeft een CertSign certificate uitgegeven door KPN die ook wijst naar die onjuist CRL (webca certificates).

[Dooxed]

In hoeverre is dit een securityrisico?

[Noxious]

Niet echt, het is vooral 'slordig' en als er van eind-certificaten de private sleutels uitlekken dan kan het zijn dat de check op intrekking niet goed kan worden uitgevoerd.

Het grootste probleem is dat sommige webservices en browsers die hard de keten controleren een website/endpoint als onveilig gaan beschouwen totdat de hoster van die dienst het intermediate certificaat heeft vervangen op hun webserver.

[F_J_K]

..en dus dat mensen gaan horen dat het okay is om waarschuwingen over incorrecte certificaten weg te klikken omdat het wel zal komen door dit oepsje.

[DDX]

Als je HSTS hebt ingesteld valt er weinig (naja niet eenvoudig) door te klikken.

[F_J_K]

Ja en nee. Dat heb je alleen voor je eigen servers / sites in de hand. Maar de collega zit ook op de site van een ander die dat niet heeft. En leert dus waarschuwingen negeren. Dan moet je denk ik al denken aan voor je users een proxy die TLS inspection doet.

[Keypunchie]

Incognito modus...

[Noxious]

Ja dat helpt inderdaad niet mee inderdaad..

[elmuerte]

Dus is het wel een security issue, want het tast de availability aan.

[Keypunchie]

Dat is een hele discussie op zich: of een beschikbaarheidsprobleem een security probleem is.

In dit geval als het gaat om: welke risico's levert het voor een eindgebruiker op? Weinig. Als je de waarschuwing negeert, dan heb je strict genomen geen garantie op authenticiteit van de server, maar wellicht kun je die op alternatieve wijze vaststellen.

De encryptie is nog gewoon op orde.

[kodak]

Voor zover ik weet voldoet het alleen als de overheid geen verlopen certificaten gebruikt. En daar is geen sprake van. En hoewel er bij heel veel beveiliging wel op te merken valt dat gebruikers dan maar zelf moeite kunnen doen is dat niet waarom de eisen er zijn. Daarbij gaat dit niet alleen om gebruikers zoals bedrijven en personen die risico willen nemen maar ook dat betrouwbare communicatie aan de eisen van de overheid moet voldoen om te kunnen en mogen accepteren. Communicatie is tussen twee partijen, niet slechts de eigen kant.

[cdwave]

... Als je de waarschuwing negeert, dan heb je strict genomen geen garantie op authenticiteit van de server, maar wellicht kun je die op alternatieve wijze vaststellen.

Probleem is dat je dat meestal helemaal niet kunt doen. Misschien op het fietsje naar de eigenaar en dan de signature uitprinten...

De encryptie is nog gewoon op orde.

Encryptie heeft dan geen nut. Zonder authenticatie weet je niet of er iemand meeluistert (man-in-the-middle) of dat je uberhaubt wel met de juiste server communiceert.

Veelvoorkomende misvatting dit laatste...

[Keypunchie]

Mja, het kan. Voor de gemiddelde website vind ik het op bayesiaanse gronden niet zo waarschijnlijk, al helemaal niet als ik via DNSSEC wel op het juiste IP adres uitkom...

[cdwave]

Ach, je hebt dan een onbeveiligde verbinding. Voor 99% van de websites, die je vroeger ook al via plain HTTP (zonder "S") is dat ook prima. Zolang je maar geen informatie over jezelf vrijgeeft (of hoeft te geven)...

Enige probleem is dat je de schijn van veiligheid hebt, en da's erger dan geen veiligheid.

[Reactie gewijzigd door cdwave op 22 juni 2026 16:13]

[Noxious]

Wel in de zin van de 'CIA triad' inderdaad; maar niet in de zin van een datalek of eenvoudigere inbraak op een connectie.

Mijn reactie was misschien wat kort door de bocht omdat het laatste mijn aanname was - in de 'volksmond' is een website die onbereikbaar is niet meteen een security risico.

[Ergomane]

Met name de B in BIV is geraakt. Dit kan gevolgen hebben icm strikte termijnen van overheidspublicaties.

[Noxious]

De oude intermediate is revoked, maar ze hebben de intermediate opnieuw uitgegeven met dezelfde naam, vervaldatum, enz, maar een nieuw serienummer. Bestaande eind-certificaten blijven geldig gesigned, maar je moet op je webserver wel de intermediate vervangen.

De nieuwe is o.a. hier te downloaden:
https://assets.ctfassets.net/zuadwp3l2xby/7z550TtG5KaxKDuEVlebN9/2a25bd5d8a53ebcbc859edec51a1a4e8/certsign-webca.crt

En heeft het serienummer 100679ccf6b277d83b0d en een EKU met enkel Server Authentication.

[Olaf van der Spek]

TLS-certificaten van overheidsdomeinen lijken verlopen door fout certSIGN

Het lijkt er wel op dat die TLS-certificaten niet up-to-date waren..

[mvd64]

Je hebt één taak…

[Nightan]

"Daardoor werden de bijgewerkte CRL-lijsten al gepubliceerd voordat de synchronisatie met de OCSP-database was voltooid. Daardoor kunnen CRL- en OCSP-checks nu andere reacties geven."

Deze tekst insinueert dat er een relatie is tussen de CRL en de OCSP-database.

Maar dit staat toch los van elkaar? Het zijn twee aparte mechanisms om de validiteit van de certificaten te controleren.

[RichieB]

De relatie is dat in beide systemen dezelfde informatie hoort te staan. Daar heeft certSIGN een synchronisatie mechanisme voor, wat in dit geval dus niet goed heeft gewerkt (CRL had nog niet mogen worden bijgewerkt).