Browsers waarschuwen op domeinen Nederlandse OM voor verlopen SSL-certificaat

Diverse domeinnamen van het Nederlandse Openbaar Ministerie hebben een verlopen certificaat. Daardoor waarschuwen browsers voor beveiligingsrisico's. De hoofdsite van het OM heeft geen last daarvan.

Het verlopen certificaat betreft veel domeinnamen, waaronder openbaarministerie.nl, landelijkparket.nl, boetebase.om.nl en snelheidsovertredingen.om.nl, zo blijkt in een topic op GoT. Het gaat om een certificaat van Digicert uit Ierland en dat verliep op 31 oktober. De reguliere site van het Openbaar Ministerie, om.nl, heeft een certificaat van Digicert dat pas in juli volgend jaar verloopt. Het is de tweede keer deze week dat een overheidssite een verlopen certificaat blijkt te hebben. Eerder gebeurde dat bij Mijn UWV.

Verlopen certificaat boetebase.om.nl

Reacties (73)

[markjanssen]

Vervanging is zo te zien wel al aangevraagd, het pre-certificate zit in de log

https://crt.sh/?id=22257625130

Maar blijkbaar hebben ze 'm niet op tijd kunnen vervangen...

Deze namen zitten er ook nog in:

 Subject Alternative Name: 
                DNS:boetebase.om.nl
                DNS:moordzaak.om.nl
                DNS:murder-case.om.nl
                DNS:www.boetebase.om.nl
                DNS:www.moordzaak.om.nl
                DNS:www.murder-case.om.nl
                DNS:snelheidsovertredingen.om.nl
                DNS:nevenbetrekkingen.om.nl
                DNS:openbaarministerie.nl
                DNS:www.openbaarministerie.nl
                DNS:landelijkparket.nl
                DNS:www.landelijkparket.nl
                DNS:mta.sts.om.nl
                DNS:www2.om.nl

[Reactie gewijzigd door markjanssen op 6 november 2025 21:20]

[supersnathan94]

Ik zat even een beetje door die URLs heen te klikken, maar zitten nog wel wat oude dingen tussen hee.

http://moordzaak.om.nl/#/ < geen www domein, geen HSTS, geen 302 redirect op HTTP

www.boetebase.om.nl < www domein bestaat ook niet

http://murder-case.om.nl/#/ < geen www domein, geen HSTS en geen 302 redirect


mta.sts.om.nl > Gelukkig staat DMARC hier wel goed op ingesteld en gebruiken ze MTA-STS.

[kozue]

Een www domein is jaren 90 en kunnen we beter vanaf wezen. Iedere site hoort gewoon te werken zonder er www voor te zetten.

[xxs]

www stamt uit de tijd dat we subdomeinen (mis)(ge)bruikte om protocollen mee aan te geven,

www: World Wide Web aka http/html

ftp: File transfer protocol

gopher: Alternatief op http

En nog een paar waar ik zo niet op kan komen.

Gewoon afschaffen, helemaal mee eens.

[supersnathan94]

Ja, maar dan moet je er niet certificaten voor aanvragen als je het www subdomein op een subdomein gaat toepassen. Want dat is sowieso al apart. Maar die drie www subdomeinen bestaan ook niet is dus het punt.

[rgom]

In veel gevallen wordt het gebruikt omdat sommige CDN's met CNAME records werken, en die kun je niet voor de "root" van je domein gebruiken. Bijvoorbeeld Cloudflare, Akamai of AWS CloudFront. (Ja, er is ook CNAME flattening en ja die CDN's bieden ook statische IP's aan)

[Zonderlinger]

Op zich is geen www subdomein op een subdomein niet heel vreemd.

[supersnathan94]

nnee, daarom is het vreemd dat ze daar wel een certificaat voor hebben aangevraagd.

[segil]

domains hoeven niet alleen gebruikt te worden voor een publieke websites. smtp verkeer met TLS encryptie heeft ook een cert nodig, als voorbeeld. Daarnaast kunnen het ook domains zijn die alleen intern gebruikt worden, maar desondanks wel een public cert nodig hebben.

[supersnathan94]

smtp verkeer met TLS encryptie heeft ook een cert nodig, als voorbeeld

ja zie het mta.sts domein.

Daarnaast kunnen het ook domains zijn die alleen intern gebruikt worden, maar desondanks wel een public cert nodig hebben.

zeker, maar dan verwacht ik geen WorldWideWeb als subdomein. Dat is wel een beetje het tegenovergestelde.

Overigens zou ik dergelijke interne zaken niet in dezelfde aanvraag met hetzelfde certificaat doen. Interne zaken doe ik zelf het liefst met andere certificaten die niet zomaar geaccepteerd worden door het publiek zodat er bij een configuratiefout ook aan de voorkant allerlei alarmbellen afgaan dat dit niet de bedoeling is, maar als publiek nodig is zou ik dat wel in een aparte aanvraag behandelen.

Certificaten voor publieke ontsluiting en interne zaken scheiden klonk toen mij daar wat over verteld werd wel als een goed stukje hygiene.

[WPNL]

Inderdaad, ik vind het ook raar dat nichtenbetrekkingen.om.nl er niet tussen staat

[sayf4u]

We moeten af van die afhankelijkheid van erkende certificaten leveranciers en een eigen Nederlandse erkende leverancier worden of een van eigen bodem sponsoren.

[Josaus]

Dat dacht de Nederlandse overheid jaren geleden ook. Sindsdien bestaat het rootcertificaat Staat der Nederlanden root CA. Dit is onderdeel van wat PKIoverheid heet. Volgens mij doet Logius het beheer ervan en was Nederland de eerste met een algemeen vertrouwd rootcertificaat. Het schandaal met Diginotar hielp niet voor het vertrouwen, maar tegenwoordig gaat dat weer goed. Niet alle overheidswebsites gebruiken het op het moment, omdat Letsencrypt wel zo makkelijk uitrollen is. Ik weet ook niet hoe lastig het is een certificaat ondertekend te krijgen door Staat der Nederlanden.

[sayf4u]

De huidige opzet van security op het web met TLS/SSL maakt nationaal beheer een noodzaak! Letsencrypt wordt nog altijd gerund vanuit de VS en valt onder VS wetten. Dat maakt in theorie onze systemen kwetsbaar als men in de VS besluit om de wetten zo aan te passen om derde landen op die manier uit te schakelen, zoals het invalide make van onze certificaten als de VS dat als economische chantage middel inzet. Kortom, een eigen service onder eigen wetten en regelgeving is een noodzaak.

Dat diginotar een misser had moeten we als een verbeteractie zien en niet als een excuus om maar naar het buitenland te outsourcen.

[ZinloosGeweldig]

PKIoverheid wordt al een paar jaar niet meee voor public facing zaken gebruikt

[dasiro]

zoals diginotar?

[Alex3]

Het echte probleem is de wildgroei aan domeinnamen. In plaats van moordzaak.om.nl kun je net zo goed om.nl/moordzaak gebruiken, net als al die domeinnamen in de coronatijd: haaljederdecoronaprikinboerekoolstronkeradeel.nl kan beter overheid.nl/corona/gemeenten/boerekoolstronkeradeel heten. Dat vinden de dns-servers ook prettiger.

[Niema]

Zonder automatische ssl-cert vernieuwing staat de systeembeheerder een bijzonder vervelende toekomst te gemoed. Ik kan me al voorstellen dat het geen feest is als je veel van dit soort (sub)domeinen beheert, maar het lijkt erop dat verschillende ssl certificeer instanties gaan voor een versnelde verlooptijd tot wel eens per week. Ik heb nu al medelijden met de ambtenaar die dat allemaal moet bijhouden

[markjanssen]

Als iemand die o.a. de certificaten van een andere overheidsdienst aanvraagt en vervangt, zou ik zo graag zien dat we dat gewoon met ACME konden doen, maar helaas, allerlei ellendig beleid zorgt ervoor dat we die natuurlijk via een service-verzoek in een helpdesk, naar een preferred partner/aanbestede club moeten doen, die dan geen ACME supporten, en alles lekker handmatig doen.

Daarna moet 5 man dat allemaal heen copy/pasten, om 't vervolgens gelukkig wel met Ansible geautomatiseerd uit te kunnen rollen. Met nu de lifetimes van ~400 naar ~200, 100 en 45 dagen gaan, hoop ik dat ACME toch eingelijk wel een verplicht onderdeel van de aanbesteding gaat worden, en dat het proces een stuk makkelijker moet en kan worden.

(We doen acme waar 't kan/mag, maar op te veel plekken mogen we 't helaas simpelweg niet)

(Monitoren doen wij natuurlijk ook, en ik durf nog wel te zeggen dat bij de domeinen onder mijn beheer nog geen prod-certs expired zijn , op test omgevingen vast wel, maar prod proberen we toch altijd een maand vooraf wel vervangen te hebben, zodat 't niet meteen fout loopt als er ergens iemand op vakantie is in de chain van verzoeken.

[laptopleon]

Wat is de reden dat de verlooptijden korter worden gemaakt?

[dutchgio]

Het wordt als veiliger bestempeld omdat er minder snel misbruik van kan worden gemaakt als de private key uitlekt doordat certificaten snel verlopen en niet meer worden gebruikt. Ook nieuwe technieken om oude encryptie/hashing te kraken etc.

Daarom zaak om er een geautomatiseerd proces van te maken.

[GertMenkel]

Het heeft ook te maken met het feit dat certificaten intrekken nogal een gedoe is. OCSP is praktisch dood, en het alternatief is een lijst met handtekeningen van certificaatintrekkingen downloaden. Als je een keer een fout maakt als CA en bijvoorbeeld een week lang een verkeerd attribuut in een certificaat zet, kan dat bestand in een klap duizenden items bevatten. Als die certificaten vijf jaar geldig zouden zijn zoals vroeger, zit iedereen dus de komende vijf jaar die dingen regelmatig te downloaden.

Omdat certificaten verlopen, kun je verlopen certificaten uit de lijst van ingetrokken certificaten houden. Hoe korter de geldigheidsduur, hoe kleiner de lijst van intrekkingen wordt, en hoe goedkoper en sneller het hele proces wordt aan de serverkant.

Nieuwe technieken worden niet zomaar in een jaar of twee gekraakt, CA's met goede oude RSA bestaan nog steeds. Kortere lengtes helpen natuurlijk wel iets als je net op de valreep nog een 1024-bit RSA-certificaat zou hebben gedownloaded van 5 jaar, maar de tijden waar CAB en Acme naartoe willen (maximaal 47 dagen in 2029, maar ook al maximaal 200 dagen vanaf maart volgend jaar) zijn voor het zorgen van vernieuwde techniek nogal overkill.

[jjjeck]

Het wordt als veiliger bestempeld omdat er minder snel misbruik van kan worden gemaakt als de private key uitlekt doordat certificaten snel verlopen en niet meer worden gebruikt.

Correctie: het is niet minder snel maar minder lang.

[markjanssen]

CAB Forum afspraken... zoals elders in deze comments genoemd.

Kortere certs is zorgen voor minder risico's bij lekken, en kortere revocation-lists.

[laurxp]

Omdat CA's in de praktijk niet in staat bleken om certificaten op tijd in te trekken en te vervangen. Er kwam keer op keer hetzelfde excuus over "kritieke infrastructuur" en "complexe bedrijfsprocessen bij afnemers"': als je een certificaat ééns per 3 jaar moet vervangen, kan je daar een héél complex proces omheen bouwen!

Met een kortere verlooptijd dwing je automatisering af. Het hele "Maar je haalt al het nationale bankverkeer offline als je binnen 90 dagen een revoke doet!" verdwijnt als een renewal letterlijk één druk op de knop is.

[laurxp]

Hoe combineer je dat met de pas toe of leg uit eis op het gebruik van ACME, die er al een flinke tijd aan zat te komen?

[Room42]

Het moet gewoon geen handwerk meer zijn. Dit kan al jaren geautomatiseerd maar om een of andere reden blijven SSL-certificaten (of eigenlijk TLS-) altijd lastig te behappen voor beheerders. Als je het eenmaal door hebt, is het helemaal zo spannend niet, allemaal. ACME (Automated Certificate Management Environment) is er trouwens niet alleen voor Let's Encrypt. Veel meer Certificate providers ondersteunen dat. Ook Digicert, de provider van de in dit artikel genoemde certificaten.

Mijn vermoede is dat hier gewoon even niet goed gemonitord is of de automation nog wel werkt.

[Reactie gewijzigd door Room42 op 6 november 2025 20:56]

[michaelkamen]

Helaas hebben wij nog genoeg apparaten die geen ACME ondersteunen, of zelfs maar een API hebben om geautomatiseerd certificaten te vervangen (SBCs, PBXen). Dat moet allemaal nog met het handje, dus ik zie de buien al hangen.

(En dit zijn geen geen legacy apparaten van kleine spelers ofzo)

[CAPSLOCK2000]

(En dit zijn geen geen legacy apparaten van kleine spelers ofzo)

Even de flauwe vraag: waarom heb je die apparaten gekocht?
Heb je niet in je eisen staan dat apparatuur (progrommatisch) beheerbaar moet zijn?

Ja, ik snap dat je niet altijd te kiezen hebt of moet compromitteren, maar toch...
Ik schrijf dit vooral omdat ik merk dat beheerbaarheid vaak niet wordt meegewogen bij de aanschaf van nieuwe producten. Er wordt nogal eens gedaan of beheer niet bestaat of dat de tijd van beheerders eindeloos is.

[demianmonteverd]

Ik ben niet de originele poster, maar ik heb gewerkt met apparatuur die dit probleem ook heeft. In ons geval betrof het tooling om AB-testing te vergemakkelijken. Er was ook een custom-searchengine (ElasticSearch kloon) met soortgelijke problemen. En misschien bestaat dit probleem ook nog bij VPN devices en ga zo maar door. Als je in de industrie werkt met IoT apparaten kan zal dat ook wel eens kunnen voorkomen.

[michaelkamen]

Dit is bijvoorbeeld Audiocodes SBC, het grootste merk op gebied van session border controllers. Wordt wereldwijd door de meeste telcos gebruikt.

[Vogel666]

• Waar koop jij een printer die zijn eigen certificaat aanvraagt?
• Waar koop jij een slagboom die zijn eigen certificaat aanvraagt?
• Waar koop jij camera's die hun eigen certificaat aanvragen
• Waar koop jij een airco unit die zijn eigen certificaat aanvraagt?
• Waar koop jij een aardappelschilmachine die zijn eigen vcertificaat aanvraagt?
• Waar koop jij een lopende band die zijn eigen certificaat aanvraagt?
• Waar koop jij een weegbrug die zijn eigen certificaat aanvraagt?
• Waar koop jij TV's die hun eigen certificaat aanvragen?
• Waar koop jij alarm/nood knoppen die hun eigen certificaat aanvragen?

[GertMenkel]

Over vier jaar is de maximale geldigheid van een certificaat iets meer dan anderhalve maand. Als ik jou was, zou ik alvast beginnen te lobbyen voor een (software)upgrade binnen je bedrijf, want anders blijf je bezig...

[laurxp]

Het hele doel van de steeds kortere geldigheidsperiode is om dit af te dwingen. Het is niet langer die ene klant die moeilijk doet, maar alle klanten die een API eisen, of anders overstappen naar de concurrent.

[c-nan]

Zo simpel is het niet. Vaak ben je afhankelijk van andere partijen. Partijen die geen API aanbieden bijvoorbeeld.

Als beheerder mag je soms zelf geen certificaten aanvragen bij de leverancier, maar moet je het aanvragen bij een afdeling, de afdeling weer bij de leverancier.

Als je als beheerder zelf je leverancier mag uitkiezen, zelf direct bij de leverancier shoppen kan het allemaal geautomatiseerd worden, maar vaak is dat bij grote (overheids)organisaties niet zo.

[Room42]

Met dat soort (ouderwetse of starre) partijen (ik snap dat er soms wat legacy in het spel is) is het slim om er een reverse proxy tussen te zetten waarin je zelf de TLS offloading regelt en een vast, vertrouwd certificaat tussen de proxy en de uiteindelijke dienst te gebruiken.

[c-nan]

De technische oplossingen zijn er, dat is het probleem helemaal niet. Op mijn werk beheren de beheerders de webservers, maar doordat ze geen eigenaar zijn van het domein mogen ze zelf niks doen kwa DNS, TLS, e.d.

In dat soort omgevingen/organisaties kan je niet even een reverse proxy aan het internet hangen. Architectuur heeft afgesproken dat we dat niet doen, punt. Het probleem is niet de techniek, maar de organisatie, de processen.

Dit soort websites worden al vaak via loadbalancers/reverse proxies ontsloten (bijvoorbeeld Citrix Netscaler). De Netscaler beheerders doen niks met certificaten, zij installeren wat ze aangeleverd krijgen. Zo heb je al 2 teams die iets moeten doen. Vaak wel 3.

Team 1: beheerders, vragen certificaat aan bij afdeling A.
Team 2: afdeling A, vraagt certificaat bij leverancier aan en levert dat vervolgens aan Team 1.
Team 3: Netscaler beheerders. Zij krijgen het certificaat van Team 1 aangeleverd en installeren het.

[laurxp]

Je kan een praktisch identiek proces opzetten met ACME:

- Applicatiebeheerders vragen certificaat aan bij afdeling A.

- Afdeling A maakt profielen aan op het portal van de cert leverancier, en maken een ACME EAB token aan. Ze leveren de ACME server-url en EAB token aan de applicatiebeheerders.

- Proxybeheerders ontvangen ACME server-url en EAB token. Ze installeren dit in hun ACME-client - deze is vervolgens in staat om volautomatisch het certificaat aan te vragen en te hernieuwen.

Precies dezelfde scheiding van taken, maar nu wél op een manier die past bij het jaar 2025.

[ramonfincken]

TLS ipv SSL inderdaad

[Vogel666]

Ik denk niet dat de beheerders degene zijn waar het probleem ligt.

Ik kan je garanderen dat de beheerders dagelijks met hun hoofd op het toetsenbord rammen uit frustratie hoe het nu toch weer kan dat applicatieontwikkelaars allerlei vage in-app wizards ontwikkelen om een certificaat aangevraagd te krijgen.

Heb je 1000 tot 2000 applicaties in beheer dan loop je toch al gauw tegen 4 of 500 verschillende procedures aan waarbij je in de helft van de gevallen de functioneel applicatiebeheerder nodig hebt, omdat jouw credentials geen toegang geven tot de in-application certificate wizard.

Java cert stores, losse base64/pem of der en private keys in een file al dan niet ecrypted, losse pfx-en, Windows certificate stores op machine-level, op user-level of op service-level....allemaal ongedocumenteerde hoepeltjes waar beheerders dagelijks doorheen springen, maar als je csr gegenereerd moet worden IN de applicatie, dan ben je gewoon kansloos.

2 standaarden zou wel zo makkelijk zijn:

• Windows--> windows cert store
• Linux: een Base64/PEM met een losse key file

[Qwerty-273]

Het CA/Browser forum heeft hier inderdaad de plannen (of eigenlijk afspraken) voor liggen.

Phased reduction timeline

• March 15, 2026: Certificate lifespans will be reduced to 200 days.
• March 15, 2027: Certificate lifespans will be reduced to 100 days.
• March 15, 2029: Certificate lifespans will be reduced to the final maximum of 47 days. 

[Reactie gewijzigd door Qwerty-273 op 6 november 2025 20:51]

[Niema]

Lets encrypt ambieert zelf kortere wekelijkse certificaten. https://letsencrypt.org/2025/01/16/6-day-and-ip-certs

Zoals in de comments hierboven blijkt is revocation van onveilige certificaten niet te doen dus dan kan ik me voorstellen dat dit een use case can hebben

[Reactie gewijzigd door Niema op 7 november 2025 08:27]

[Blokker_1999]

Automatisatie wordt een verplichting. Vanaf maart volgend jaar zullen alle grote browsers een geldigheid van maximaal 200 dagen vereisen. 1 jaar later wordt dat nog 100 dagen en in 2029 komen we uit op net geen 50 dagen. Dat doe je niet meer handmatig.

Daarom heb je o.a. het ACME protocol waarmee het volledig geautomatiseerd kan worden.

[willyb]

Toch bijzonder eigenlijk, hoe (ook ver buiten dit artikel) die term SSL nog steeds terug blijft komen, terwijl we al jaren op TLS zitten en dit eigenlijk Wikipedia: X.509 certificaten zijn.

Op https://basisbeveiliging.nl/report/risksummary/NL/government/2544 zijn de verlopen certificaten op de (sub)domeinen ook goed zichtbaar.

[Reactie gewijzigd door willyb op 6 november 2025 20:45]

[Blokker_1999]

Hoewel het een TLS certificaat is, klopt de term SSL ergens ook wel. Het certificaat maakt geen gebruik meer van SSL encryptie, maar als je de term letterlijk neemt, dan is er nog wel altijd zo een laag aanwezig in je communicatie. En dat is ook 1 van de redenen waarom het volgens mij blijft hangen.

[Gazuhl]

Nee dat is het niet. SSL en TLS zijn communicatieprotocollen geen encryptie. Het schrijft enkel voor hoe er gecommuniceerd dient te worden en wat er ondersteund wordt qua encryptie e.d.. SSL2.0 en de laatste 3.0 zijn al meer dan 25 jaar afgeschreven vanwege veiligheidsproblemen in de structuur. TLS1.0 was daar de opvolger van, daarna 1.1, 1.2, en nu (hoewel ook al weer 10 jaar oud ofzo) 1.3. SSL mag al heel lang nergens meer ondersteund worden vanwege downgrade attacks. D.w.z. als een server SSL en TLS ondersteunt, kun je deze altijd forceren om SSL te gebruiken en vervolgens lekker de lijn uitlezen door tussen client en server te gaan zitten.

[Scriptkid]

Tja een SSD is ook nogsteeds een harddisk maar zit al heel lang geen disk meer zit letterlijk geen rond object in :)

[supersnathan94]

<citation needed>

Ik zie SSDs en HDDs echt wel als twee verschillende "Drives", HardDisk gebruik ik in ieder geval alleen bij de HDD variant en nooit bij SSD.

[DDX]

SSL certificaat is nu eenmaal ingeburgerd als term, ik zeg ook regelmatig ssl certificaat.
En een veelgebruikte test noemt het ook ssl test :
https://www.ssllabs.com/ssltest/

[laptopleon]

Zolang zelfs instituten die er over gaan zoals Digicert en de SIDN het ssl blijven noemen en zelfs bij uitleg hierover door elkaar blijven gebruiken, tls als een nieuwere versie van ssl blijven beschouwen, is het niet zo vreemd.

https://www.sidn.nl/4-red...r-je-website-te-gebruiken

https://www.digicert.com/nl/what-is-ssl-tls-and-https

[The Zep Man]

Toch bijzonder eigenlijk, hoe (ook ver buiten dit artikel) die term SSL nog steeds terug blijft komen, terwijl we al jaren op TLS zitten en dit eigenlijk Wikipedia: X.509 certificaten zijn.

Dat Wikipedia artikel noemt ook de term "SSL certificate". Een SSL/TLS (server) certificaat is een X.509 certificaat op dezelfde manier dat een banaan een stuk fruit is.

[Triblade_8472]

Over 3 jaar en een beetje gaan we naar certificaten die maar 47 dagen geldig zijn.

Automatisering is dan een must.

Ik vraag mij af. Is het werkelijk waar zoveel veiliger als alles weggeautomatiseerd wordt?
Als er een issue in het systeem is dat niet snel genoeg gedetecteerd wordt, of gehacked wordt zijn binnen 47 dagen alle certificaten van een uitgever potentieel fout en kan alles in 1x beweging uitgelezen worden of aangevallen via Man-in-the-middle.

Nu is het een jaar voordat alle certs vervangen moeten worden wat de kans op detectie groter maakt.

[GertMenkel]

Hoezo wordt de kans op detectie groter door langer te wachten?

Het probleem dat het verkorten van de geldigheid oplost is dat gelekte certificaten zelden worden ingetrokken (onder andere omdat dat bij sommige certificaatboeren geld kost) en omdat ingetrokken certificaten zolang ze geldig zijn onderdeel moeten zijn van de certificate revocation list die na jaren aan fouten behoorlijk kan groeien. Als certificaten na twee maanden verlopen, hoef je maar twee maanden aan verlopen certificaten in je revocation list te houden, en vervallen gehackte certificaten automatisch mocht de eigenaar ervan het niet zo nauw nemen met de beveiligingsvereisten.

Als een systeem dat iedere paar dagen een check doet gehackt kan worden, kan een systeem dat ieder jaar gecheckt wordt ook gehackt worden.

Automatisering is sowieso al een must als je duizenden servers moet onderhouden zoals overheidsinstanties, maar de manier waarop is nogal afhankelijk van welke aanbieder de aanbesteding wint. Normale certificaatboeren hebben gewoon ACME ingebouwd voor alle soorten certificaten, maar dat betekent helaas niet dat de overheid contracten met die lui aangaan.

[laurxp]

Ja, want in de praktijk is gebleken dat de meeste bedrijven incompetent zijn, en bij een veiligheidsprobleem niet in staat bleken om de certificaten op tijd te vervangen. Het gevolg is dat onveilige certificaten véél te lang in gebruik bleven, omdat het anders voor problemen in "kritieke infrastructuur" zal zorgen.

Met een korte geldigheid dwing je een automatisch vernieuwingsproces aan, waardoor tijdige vernieuwing triviaal is, waardoor we niet gedwongen zijn wékenlang onveilige certificaten te blijven gebruiken.

[FrostyPeet]

Beetje bizar, lijkt mij planmatig in te voeren in een agenda o.i.d.. Als ik dit soort dingen zie vraag ik mij af wat voor essentiële zaken ze ook vergeten.

[SunnieNL]

Normaal zet je dit in een asset database die dan automatisch op een bepaald moment een change request aanmaakt dat dan gaat lopen en alles op het juiste moment laat vervangen.

Maar, ik weet ook dat er maar zeer weinig klanten zijn waar ik langs kom waar ze de certificaten in de asset management tool hebben staan.

Een EASM oplossing zou hier overigens ook voor waarschuwen als de certificaten bijna verlopen. Maar die lijken dus allemaal niet in gebruik bij onze overheid.

[Meteen]

Dat komt omdat de technisch beheerder geen inkoop mag doen. En de afdeling inkoop niet technisch is en de benodigde technische gegevens niet weet in te voeren bij de online aankoop. En omdat de afdeling inkoop pas betaald als het bestelde product (lees certificaat) geleverd is, dat dus niet werkt bij online bestelling ėn online levering van het certificaat.

[johan_L]

Wat dus geen enkel probleem hoeft te zijn als je regelt dat je op rekening koopt

[Meteen]

Ik heb nog nooit een website gezien met de optie “koop op rekening”.🤪

[johan_L]

Dat staat ook niet op de website maar regel je via je accountmanager. Ik bestel al jaren certificaten online die pas later betaald worden (Xolphin).

[Freeaqingme]

@arnoudwokke beetje rare titel. Het nieuws is toch dat die certificaten verlopen zijn - niet dat browsers daar voor waarschuwen?

Stel dat er een ongeluk gebeurt ergens. Dan is het nieuws "ongeluk tussen automobilist en vrachtwagenchauffeur gebeurd op de ...-weg" en niet "Politie zet weg af bij ongeluk op de ...-weg".

[Niema]

Gisteren waarschuwden browsers niet, maar het was al verlopen. De waarschuwing is nieuw. Verlopen ong een week. Verlopen certificaat is ook niet erg. Een ongeluk wel. En een waarschuwing ook, omdat dat gebruikers tegenhoudt

[DDX]

Omdat er gisteren schijnbaar dan een ander certificaat aan de websites hing ?

[dutchgio]

De browsers gebruiken een keystore, als die wordt bijgewerkt en deze certificaten niet meer als veilig bestempelen tonen de browsers een foutmelding. Het certificaat zelf was echter daarvoor al verlopen.

Op een site als SSLLabs kun je ook altijd de resultaten van verschillende partijen (Apple, Microsoft, Google, Mozilla etc.) zien.

[DDX]

De browsers kijken gewoon naar de datum, als je je klok te ver vooruit (of achteruit) zet krijg je ook melding dat certificaat niet meer geldig is.

[GertMenkel]

De certificaten zijn verlopen, niet ingetrokken. De foutmelding verschijnt als je huidige computerklok voorbij de geldigheidsdatum van het certificaat is.

Je kunt daarom de tijd op je computer terugzetten en dan kun je zonder foutmelding met de kapotte servers verbinden. Of de melding gewoon keihard overrulen (kan in Chromium-browsers door "thisisunsafe" in te typen terwijl de foutmelding open staat, zelfs als websites HSTS gebruiken).

[DDX]

En dan scheelt het nog dat ze geen HSTS hebben ingesteld (slecht eigenlijk) waardoor je nog op continue kan klikken om toch de site te benaderen.

[supersnathan94]

Met HSTS kan het ook, maar dan moet je even "thisisunsafe" typen.

Verder zitten er ook nog HTTP domeinen bij die geen 302 geven en zonder HSTS dus gedowngrade kunnen worden. en dus vatbaar voor injectie van van alles. Echt niet handig. Zeker niet van een organisatie die net een paar maanden offline is geweest vanwege een hack.

[mafino]

Het is inmiddels verholpen, de certificaten zijn weer geldig

[bussie66]

Gaat weer lekker daar!

Binnenkort de boel weer offline en weer belastinggeld er tegen aan?

[rneeft]

Toch bijzonder dat menig hobbywebsite dit beter voor elkaar heeft dan de overheid.

[Reactie gewijzigd door rneeft op 6 november 2025 22:45]