Browsers waarschuwen op domeinen Nederlands 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 daar geen last van.

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 (26)

[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]

[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?

[markjanssen]

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

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

[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.

[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]

[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.

[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)

[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]

[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]

[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/

[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.

[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.

[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]

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.

[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.

[bussie66]

Gaat weer lekker daar!

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