KPN-klanten kunnen Experiabox V10A niet benaderen door verlopen certificaat

Klanten van KPN met een Experiabox V10A kunnen de instellingen van dat apparaat niet meer benaderen doordat een ssl-certificaat voor mijnmodem.kpn op 3 juli is verlopen. Drie weken geleden waarschuwde een gebruiker KPN hier al voor. Er zijn wel work-arounds.

Op het KPN-forum melden verschillende klanten dat ze in de browser foutmeldingen krijgen als ze hun modem/router proberen te benaderen. Het probleem komt alleen voor bij de Experiabox V10A, die KPN sinds 2018 in gebruik heeft. Het ssl-certificaat van het apparaat is op 3 juli verlopen en daardoor zien browsers de verbinding als onveilig.

Als work-around melden gebruikers dat ze door de systeemtijd van het apparaat aan te passen naar een datum voor het verlopen van het certificaat de instellingen wel kunnen bereiken. Ook kan in sommige browsers de veiligheidswaarschuwing genegeerd worden, door een uitzondering toe te voegen.

Drie weken geleden merkte gebruiker wjb op het KPN-forum al op dat het certificaat bijna was verlopen. Dat lijkt echter niet opgemerkt te zijn door de provider. Inmiddels geven moderators op het forum aan de meldingen door te zetten naar de developmentafdeling van KPN.

Reacties (223)

[jcbvm]

Je kunt de modem overigens wel gewoon benaderen. Je moet dan alleen doorklikken op de waarschuwing. De doorsnee gebruiker zal dit waarschijnlijk niet snappen.

EDIT:
Ik zie dat in sommige gevallen dit niet meer mogelijk is in chrome, in Firefox kan ik wel gewoon doorklikken.

[Reactie gewijzigd door jcbvm op 22 juli 2024 19:18]

[Cergorach]

Je wordt gedownmod, maar je heb absoluut gelijk. Gebruikers kunnen nog prima een webinterface/site benaderen als een certificaat is verlopen. Daarmee is de titel ook weer eens misleidend. Juist Chrome, de meest gebruikte browser, geeft netjes de optie om toch door te gaan naar de site. Het is zo simpel als op het knopje geavanceerd te klikken en dan onderin op doorgaan naar...

[z1rconium]

geeft netjes de optie om toch door te gaan naar de site

Het word tijd dat dat niet meer mogelijk is. Er is een reden waarom je de melding krijgt.

[SuperDre]

Nee, het wordt ZEKER geen tijd dat het niet meer mogelijk is. Stel dat je dadelijk een device hebt waarvan het certificaat niet meer geupdate kan worden, maar het device zelf werkt nog goed, dan zou het toch te gek voor woorden zijn dat een browser je verbiedt om nog door te gaan naar je eigen apparaat. Dat er een zware waarschuwing voor komt en dat je dan eerst ergens anders moet klikken, ok, maar volledig blokkeren vind ik toch echt te ver gaan.

[Singillatim]

Ben ik mee eens. Ik heb nog zo'n router en deze meld het ook. Even als de V10a kan je voor de instellingen ook gewoon poort 80 nemen.

[Dennism]

Die waarschuwing is ook nog eens een wassenneus, het betekent namelijk helemaal niet dat de site aan de andere kant "onveilig" is, genoeg apparatuur bijvoorbeeld (denk aan managed switches, routers, camera's e.d.) waar je lang niet altijd een certificaat van een externe uitgever op zal installeren.

De webinterface van dat soort apparatuur zal dus altijd een waarschuwing geven, zelfs wanneer je de apparatuur uit de doos haalt, terwijl het totaal niet onveilig is.

[.oisyn]

De webinterface van dat soort apparatuur zal dus altijd een waarschuwing geven, zelfs wanneer je de apparatuur uit de doos haalt, terwijl het totaal niet onveilig is.

Het is bijna zo onveilig als geen https gebruiken. Een man in the middle kan namelijk gemakkelijk als proxy fungeren met een self signed cert. Jij zal het verschil niet zien omdat het certificaat niet is ondertekend door een authority, en dus klik je gewoon maar weer door, zoals je altijd doet.

Goed, afluisteren is natuurlijk iets lastiger, maar iemand die kan afluisteren kan over het algemeen ook je verkeer omleiden.

[xenn99]

Het gaat hier toch enkel om een interne verbinding (LAN)? of je daarvoor nou http of https gebruikt, en of hier wel of geen certificaat aan hangt lijkt me niet heel belangrijk?
Voor een man in the middle attack moet die persoon dan namelijk wel eerst je interne netwerk binnen dringen..

Mijn Ziggo modem heeft ook geen https (en dus ook geen certificaat)..

[.oisyn]

Of jij je interne LAN afgeschermd genoeg acht is een andere vraag. Ik stel alleen maar dat HTTPS met een self-signed cert amper veiligheid biedt boven HTTP. Als jij dat laatste goed genoeg vindt is er natuurlijk niets aan de hand. Maar er zijn natuurlijk tal van situaties waarbij mensen wel toegang mogen hebben op je LAN, maar niet in mogen loggen op een apparaat op dat LAN. Denk aan netwerken binnen het bedrijfsleven, of je buurman waarmee je je WiFi code hebt gedeeld maar waarvan je niet wilt dat hij je routerinstellingen aanpast.

[Reactie gewijzigd door .oisyn op 22 juli 2024 22:51]

[xenn99]

Wat je zegt klopt helemaal hoor, Https met een self signed certificaat biedt nauwelijks meer beveiliging dan http.

In mijn ogen voegt een certificaat in deze situatie echter weinig tot niks toe aan de veiligheid..

Een certificaat is bedoeld om de integriteit te controleren van het apparaat waar je mee verbindt, en aangezien de router onderdeel uitmaakt van jouw eigen interne netwerk is deze validatie toch eigenlijk niet echt nuttig?

Dat het in een zakelijke situatie anders ligt lijkt me logisch maar ik ging er eigenlijk van uit dat de Experiabox alleen voor consumenten was.

Sowieso vindt ik het persoonlijk wat vreemd dat er gebruik gemaakt wordt van een domein ipv gewoon direct te verbinden met het ip adres van de router.
In mijn ogen is dat een groter beveiligingsrisico..

[.oisyn]

Een certificaat is bedoeld om de integriteit te controleren van het apparaat waar je mee verbindt, en aangezien de router onderdeel uitmaakt van jouw eigen interne netwerk is deze validatie toch eigenlijk niet echt nuttig?

Ik zou toch niet graag willen dat mijn hypothetische buurman met mijn WiFi wachtwoord mogelijk inloggegevens van bepaalde apparaten zoals een NAS en router weet te bemachtigen door een mitm-aanval te doen .

Maar goed, mijn NAS request dan ook een wildcard cert voor mijn domein via Let's Encrypt, en pusht die verovlgens maar allerlei apparaten. Niet eens voor de veiligheid, maar omdat ik die browser warning zat was

[EnigmA-X]

Wat je zegt klopt helemaal hoor, Https met een self signed certificaat biedt nauwelijks meer beveiliging dan http.

In mijn ogen voegt een certificaat in deze situatie echter weinig tot niks toe aan de veiligheid..

Een certificaat is bedoeld om de integriteit te controleren van het apparaat waar je mee verbindt, en aangezien de router onderdeel uitmaakt van jouw eigen interne netwerk is deze validatie toch eigenlijk niet echt nuttig?

Encryptie van het verkeer tussen device en client lijkt mij toch ook wel een belangrijk onderdeel van een (self-signed) certificaat. Eavesdropping en tampering van de data wordt daarmee al een heel stukje lastiger.

Sowieso vindt ik het persoonlijk wat vreemd dat er gebruik gemaakt wordt van een domein ipv gewoon direct te verbinden met het ip adres van de router.
In mijn ogen is dat een groter beveiligingsrisico..

Je zal toch echt iets van een commonname nodig hebben dat gevalideerd kan worden via de certificate chain en met de huidige stand van zaken is dat feitelijk altijd via public dns. Tenzij je verwacht dat iedere klant zijn eigen PKI faciliteiten en certificate store in gaat richten en/of op de client de CA's gaat importeren.

[NielsFL]

Strict genomen kan een self-signed certificate natuurlijk veiliger zijn dan die van de derde partij, mits je weet waar je mee bezig bent.

[EnigmA-X]

Maar er zijn natuurlijk tal van situaties waarbij mensen wel toegang mogen hebben op je LAN, maar niet in mogen loggen op een apparaat op dat LAN. Denk aan netwerken binnen het bedrijfsleven, of je buurman waarmee je je WiFi code hebt gedeeld maar waarvan je niet wilt dat hij je routerinstellingen aanpast.

Hiermee suggereer je dat, zolang je http of een self-signed certificate gebruikt, de mogelijkheid bestaat voor Jan en alleman om iets te wijzigen op je router. Dat lijkt me een beetje te eenvoudig gesteld.

Een self-signed certificate encrypt nog altijd het verkeer tussen device en client. Met http gaat alles "plat" over de lijn.

In een ander daglicht, SSH verbindingen zijn ook niet per definitie onveilig, terwijl ik toch wel durf te beweren dat het overgrote deel van de keypairs self-signed zijn.

[.oisyn]

Hiermee suggereer je dat, zolang je http of een self-signed certificate gebruikt, de mogelijkheid bestaat voor Jan en alleman om iets te wijzigen op je router. Dat lijkt me een beetje te eenvoudig gesteld.

Dat doe ik inderdaad. Lees .oisyn in 'nieuws: KPN-klanten kunnen Experiabox V10A niet benaderen door ver... nog maar eens

Een self-signed certificate encrypt nog altijd het verkeer tussen device en client

Een wassen neus, want jij checkt de validiteit van die cert niet (tenzij je 'm natuurlijk expliciet toevoegt aan je trusted certs lijst). Als dat certificaat wordt vervangen met een ander certificaat, omdat je eigenlijk met een andere partij praat die er tussenin is gaan zitten, dan gaat er geen enkel belletje rinkelen. Iedereen kan namelijk zelf certs signen.

[Reactie gewijzigd door .oisyn op 22 juli 2024 22:51]

[EnigmA-X]

[...]
Dat doe ik inderdaad.

Ik mag toch hopen dat een experiabox nog iets van een login + wachtwoord heeft?
(dat je op voorhand niet aan jan en alleman uitdeelt?)

[.oisyn]

Zie mijn tweede alinea in mijn vorige post, die had ik er nog bij geëdit. Met een self-signed cert is een mitm een koud kunstje, en dus kun je makkelijk die login afluisteren.

Moet hij natuurlijk wel eerst even wachten totdat jij daadwerkelijk een keer inlogt.

[Reactie gewijzigd door .oisyn op 22 juli 2024 22:51]

[xenn99]

Als iemand jouw (thuis)netwerk binnen dringt is in mijn ogen sowieso alle beveiliging zoek hoor, gevalideerd certificaat of niet..
Natuurlijk maakt een certificaat het moeilijker om het verkeer direct af te luisteren, maar als je al binnen bent zijn er legio andere (makkelijkere) manieren.

(sowieso zie ik niet zo in waarom iemand de router nog zou willen binnendringen als hij al toegang tot het netwerk heeft)

Je moet gewoon nooit je wachtwoord aan de buurman geven, dan is de hele situatie die je omschrijft ineens een heel stuk lastiger te realiseren.

[.oisyn]

Als iemand jouw (thuis)netwerk binnen dringt is in mijn ogen sowieso alle beveiliging zoek hoor, gevalideerd certificaat of niet..

Right, ok, dus certificaten zijn compleet nutteloos in een bedrijfsomgeving? Je stelling is quatsch. Beveiliging van lokale apparaten valt niet met het binnendringen van het lokale netwerk.

[Reactie gewijzigd door .oisyn op 22 juli 2024 22:51]

[xenn99]

Waarom verdraai je mijn woorden?
Het gaat hier over een router voor thuis gebruik, dat heb ik nu al een paar keer gezegd.
Waarom je dus steeds weer komt met voorbeelden die over bedrijfsomgevingen gaan is mij een raadsel.

In een bedrijfsomgeving zou je sowieso nooit een onbetrouwbare client direct toegang geven tot de router, daar zitten (mag ik hopen) nog wel een paar lagen tussen.

Wat jij hier toepast is in mijn ogen omgekeerde logica..
Alsof je de dieven de sleutel van je huis geeft, maar dan zegt ja ze kunnen toch niets doen, want alle kamers zitten op slot..

Natuurlijk als jij een heel domein bouwt binnen jouw thuis netwerk en overal certificaten aan hangt zal het ongetwijfeld veiliger zijn dan zonder certificaten, dat ontken ik helemaal niet.
(denk overigens niet dat dat echt representatief is voor de meerderheid van de thuisgebruikers)

Maar in mijn ogen is het veel slimmer om kwaadwillenden direct bij de deur tegen te houden dan ze binnen te laten en vervolgens te hopen dat andere beveiligingsmaatregelen wel afdoende zijn.
(dat geld voor zowel privé als zakelijke netwerken)

[.oisyn]

Waarom verdraai je mijn woorden?

Ik verdraai ze niet, ik extrapoleer ze. Waarom vind je iemand die toegang heeft tot je thuis-LAN wel een issue, maar iemand die toegang heeft tot een bedrijfs-LAN niet? Ik zie echt het verschil niet.

Maar deze hele discussie is zinloos. Mijn punt is dat self-signed certificates niet veel beter zijn dan gewoon helemaal geen certificaten. Ik heb al gezegd dat je dat op je lokale thuisnetwerk prima kan vinden. Ik heb ook aangegeven dat dat in sommige gevallen misschien toch niet helemaal prima is, en dat je soms communicatie tussen twee apparaten op je netwerk wil beveiligen. Maar dat kan nauwelijks met een self-signed cert.

Dat je netwerk al niet veilig is als iemand erop kan is echt onzin. Waarom dan überhaupt nog logins voor dergelijke apparaten?

[Reactie gewijzigd door .oisyn op 22 juli 2024 22:51]

[2TheMaks]

Met een self-signed cert is een mitm een koud kunstje, en dus kun je makkelijk die login afluisteren.

Word er voor iedere experiabox een eigen key-pair gegenereerd, met voor iedere experiabox een digitaal getekend certificaat met de unieke public-key voor die experiabox?

Of is er slechts één key-pair + signed certificate wat in de firmware van alle experiaboxen zit? In dat geval maken alle experiaboxen gebruik van dezelfde private key!!! In dat laatste geval kun je rustig stellen dat de private key gecompromitteerd is (er zijn immers duizenden kopieën van, toegankelijk voor iedereen die een experiabox in handen heeft), en de verbinding niet langer veilig!!!

[EnigmA-X]

Een wassen neus, want jij checkt de validiteit van die cert niet (tenzij je 'm natuurlijk expliciet toevoegt aan je trusted certs lijst).

Dat is een valide punt. Ik doe dat inderdaad wel. Als ik *weer* eenzelfde waarschuwing krijg, dan klopt er iets niet. Stukje beroepsdeformatie inderdaad

Als dat certificaat wordt vervangen met een ander certificaat, omdat je eigenlijk met een andere partij praat die er tussenin is gaan zitten, dan gaat er geen enkel belletje rinkelen. Iedereen kan namelijk zelf certs signen.

Dat klopt. Echter, mijn persoonlijke inschatting is, dat wanneer je iemand op je netwerk hebt die MITM zit te doen je sowieso een wat groter issue hebt dan alleen je netwerk infra zoals een router.

Ik gok namelijk dat wanneer er *wel* een signed certificate (door een officiele CA) op zit de uitkomst van een MITM niet zo heel anders zal zijn: de meeste beheerders zullen proberen om die melding heen te werken en proberen in te loggen op het device om vast te stellen waar die gekke melding ineens vandaan komt. Dan ben je alsnog "ge-eavesdropped"

In die optiek is het dus goed dat een browser dat actief zo moeilijk mogelijk maakt. Ik weet het niet, maar wellicht is dat het hele idee erachter?

Edit: als je overigens zelf je signing doet en zorgt dat je goed omgaat met je CA, keys, etc, je clients voorziet van het juiste CA-certificate, dan hoeft dat niet per definitie onveiliger te zijn. Wel beetje een corner-case, geef ik toe. Je komt dan een beetje op het gebied van hoe betrouwbaar andere partijen zijn...

[Reactie gewijzigd door EnigmA-X op 22 juli 2024 22:51]

[phex]

De man in the middle kan ook een trojan zijn

[xenn99]

Als je een trojan op je pc hebt gaat een certificaat je echter ook niet beschermen..
Een certificaat is volgens mij eigenlijk alleen relevant om te zien of de computer/server waar je mee verbindt veilig/betrouwbaar is.

Aangezien het in dit artikel gaat over je eigen modem weet je al dat die betrouwbaar is, in mijn ogen biedt een certificaat in dit geval dus eigenlijk geen meerwaarde.

[.oisyn]

Een certificaat is volgens mij eigenlijk alleen relevant om te zien of de computer/server waar je mee verbindt veilig/betrouwbaar is

Nee, een cert zegt niets over de veiligheid of betrouwbaarheid van de andere partij. Het zegt iets over de identiteit van die partij. De identitieit bij een self-signed cert is niet gegarandeerd, iedereen kan die faken.

En het gaat er niet om of jij je eigen modem vertrouwt. Het gaat erom dat het antwoord dat je terugkrijgt als je met het apparaat communiceert, wel echt van je modem afkomt, of van een derde partij.

[Reactie gewijzigd door .oisyn op 22 juli 2024 22:51]

[laptopleon]

Maar als je PC echt gehackt is, is het hek toch van de dam? Hoe weet je dan dat je uberhaupt wel in de originele browser zit en niet een aangepaste versie die nep-certificaten toont c.q. geen waarschuwingen geeft waar dat zou moeten etc.

[.oisyn]

Maar als je PC echt gehackt is, is het hek toch van de dam?

Ja, maar wie heeft het hier over een gehackte PC?

[laptopleon]

Nou, @phex waarop @xenn99 reageerde waarop jij reageerde.

[THM0]

Precies, en dan is er qua risico ook nog een verschil tussen "verlopen" en "subject/SAN klopt niet met URL" of "certificaat is revoked". Qua encryptie maakt het niet uit, tenzij de private key bij een aanvaller beschikbaar is gekomen (en als dat bekend is zou ie revoked moeten zijn).
Sowieso verbind je naar dit soort apparaten toch vaak gewoon via IP adres? Dan krijg je toch altijd zo'n melding?

[Blokker_1999]

En er is een reden waarom het nog altijd mogelijk is. Stel dat je zelf het apparaat beheerd en vergeten bent het certificaat te vernieuwen. Hoe wil jij je certificaat vervangen als je niet meer kunt inloggen omdat de browser dat onmogelijk heeft gemaakt?

De waarschuwing die je te zien krijgt is zeer duidelijk en dient om mensen schrik aan te jagen. Maar mensen die weten wat ze doen moeten gewoon de optie krijgen om deze melding te negeren.

[Kees]

Zodra je HSTS aanzet op dat domein dan kun je ook niet eens meer doorclicken. Daar heb ik zelf ervaring mee, domein met htst aan en de enige mogelijkheid is om via de webinterface certificaten te beheren. 1 keer vergeten te verlengen en voila de enige mogelijkheid om erbij te komen in een moderne browser is door de klok terug te zetten.

[witchdoc]

Je kan bij Chrome elke security melden omzeilen door gewoon "thisisunsafe" te typen.
Gewoon (onzichtbaar) op de pagina, dus niet in het url veld ofzo.

[GreatDictator]

Ik ga er vanuit dat dit bij HSTS toch niet werkt, dat is immers een server-side beveiliging.

[rbr320]

HSTS is inderdaad een server side instelling die de client vertelt dat hij alleen over https met de site mag communiceren, dus niet over plain http. HSTS kan echter niet voorkomen dat de client een ongeldig of onveilig TLS certificaat accepteert voor die communicatie.

[supersnathan94]

Nee HSTS is nog steeds Client side. alleen geeft een server daarmee aan in principe alles gewoon via HTTPS kan dus dat HTTP requests helemaal geen zin hebben. Een browser zal daardoor dus intern de redirect uitvoeren en een stukje zekerheid hebben over dat het werkt.

HSTS kun je als browser ook gewoon maling aan hebben natuurlijk. Server heeft niks te zeggen over het gedrag van de client. Die kan alleen suggesties geven.

[Raymond Deen]

Weer wat geleerd!

[Patrick_v_L]

Zo leer ik elke dag weer eens iets nieuws, tnx!

[Alexh81]

Je kan ook Chrome Incognito openen. Dan krijg je ook de optie 'doorgaan' te zien.

[BobV]

Dat werkt niet altijd: zodra de site op de preloaded HSTS list staat bijvoorbeeld niet.

[Khrome]

Als het goed is kun je dan de lokale HSTS cache leeghalen, tenzij de site het aldaar alsnog forceert.

[BobV]

De preloaded list valt volgens mij niet onder de cache, aangezien het hardcoded is. Zie https://hstspreload.org/

[Yzord]

Gewoon server based of via je webhosting portal? Ik heb het nooit in de cms zelf hoeven doen. Gewoon via de server of als je daar geen toegang toe hebt via je webhosting panel.

[tweazer]

Waar is de knop in de gui om het certificaat te vernieuwen ? Als je benzine op is koop je toch ook geen nieuw auto ? (ik kan het in ieder geval niet veroorloven, stuur maar een PM als je het wel doet )

[Robbaman]

Precies, dat mensen die niet weten hoe certificaten werken niet verder gaan!

Ik wil toch wel graag gewoon op m'n servers/apparaten/etc kunnen inloggen als er zoals in dit voorbeeld een certificaat verlopen is.

[tweazer]

Ik wil een door mij zelf gegenereerd certificaat voor 20 jaar geldig kunnen aanmaken bij het 1st time aanzetten van een kastje. Na 20 jaar (alhoewel ik hier computers van 40 jaar oud heb) is een certificaat minder relevant ...

[casberrypi]

Inderdaad zou je zoiets graag willen. Self-signed certificering automatisch in een device, en de eenvoudige mogelijkheid om zo'n certificaat te accepteren. En dan niet voor 20 jaar, maar gewoon een paar maanden, en daarna maakt je device gewoon een nieuw self-signed certificaat aan. Gek dat dit voor client-side certificaten wel standaard in browsers aanwezig is, maar server-side niet.

[Raymond Deen]

Zo'n zelf gegenereerd certificaat wordt vaak ook niet voldoende vertrouwd, tenzij je de CA dan weer toevoegt als vertrouwde CA in je eigen cert store...

[.oisyn]

En inmiddels bewegen browsers in de richting dat certs met een lange validiteit ook niet meer geaccepteerd worden

[Cergorach]

Het is een waarschuwing! Als je dan nog niet voldoende bent ingelicht dat de verbinding niet veilig is... Dat browsermakers even gaan bepalen wat wel en niet kan is absoluut van den gekke! Wat als ze straks ook gaan bepalen naar welke websites je wel en niet mag... Dat is effectief wat nu ook al gebeurd op basis van certificate.

[tweakerbee]

Er zijn genoeg scenario's denkbaar, zoals ook met dit verlopen certificaat, waarin je dat wel wilt kunnen doen.
Wat je wilt voorkomen is dat onkundige gebruikers het "per ongeluk" doen. Dat lijkt wel opgelost door de knop te verbergen.

[HollowGamer]

Ik mag nog altijd zelf bepalen of ik het wil vertrouwen of niet, wat denk je bijvoorbeeld van een lokale site die je draait als testing of een simpel LAN webinterface die over SSL loopt?

Het lijkt me niet erg zinvol om voor elke interne site een certificaat aan te vragen. Het kan wel, maar ik zie er het nut niet zo van als je niet deze deelt met andere (over het WAN).

[Knoose]

Ik hou graag zelf de keuze dank u wel het is al frustrerend genoeg dat ik steeds vaker rare stappen moet doen om de keuzes die voor mij gemaakt worden te omzeilen.
Ik zet nog weleens een eigen server op en dan is het handig om bijvoorbeeld soms snel een zelf gesigneerd certificaat te gebruiken om dingen te testen (waarna ik later in het proces overstap op letsencrypt). Daar geven browsers ook altijd waarschuwingen voor, fijn als ik daar gewoon overheen kan klikken.

Dat je gewaarschuwd wordt ben ik overigens wel een voorstander van, want ja er is inderdaad een reden waarom je de melding krijgt en de gemiddelde gebruiker zou daar op moeten letten.

[To_Tall]

Chronium, wilt dadelijk sites die via SSL te benaderen zijn altijd een certificaat moet hebben.
Probleem is alleen interne apparatuur.. met allemaal interne certificaten die de browser standaard niet zal accepteren..

Denk ook niet dat dit de bedoeling is..

[Keypunchie]

Het word tijd dat dat niet meer mogelijk is. Er is een reden waarom je de melding krijgt.

Oneens. Google of andere browsermakers zijn welkom om me te *helpen* keuzes te maken, maar uiteindelijk hoort een gebruiker de baas te zijn en de eindbeslissing te kunnen nemen.

Er zijn zat situaties waarin ik als eindgebruiker echt iets wil/moet doen en dat de beheerder een self-signed of verlopen certificaat heeft ingesteld staan.

Om een voorbeeld te geven: ik kreeg een notificatie van een monitoringssysteem voor een klantomgeving. Het certificaat voor de grafische interface was verlopen*. Toch wil ik op dat moment dat monitoringssysteem in kunnen om het probleem te analyseren.

Kan ik wel heel boos worden op de beheerders van dat monitoringssysteem, maar dat is 100% ondergeschikt aan mijn meer prangende issue. Als de browser geen 'override' zou hebben voor mij om die situatie te negeren, is die browser waardeloos.

*de beheerders zijn intussen op mijn advies overgestapt op Let's Encrypt. Ze hadden een duur publiek certificaat en geen budget om het te vernieuwen, vandaar laten verlopen (was immers niet public-facing).

[Reactie gewijzigd door Keypunchie op 22 juli 2024 22:51]

[Djeepman]

Laat mij dat zelf beslissen😉

[Triodes]

Hoe zou de gemiddelde webdeveloper met zijn lokale dev omgeving met self-signed-certificate dan weer z'n webapplicatie moeten testen? Dat lijkt mij super onhandig. Chrome geeft de mogelijkheid om door te gaan trouwens niet als de webserver een HSTS header meegeeft.

[rjtuijnman]

Ik wil ZELF graag beslissen of ik doorga of niet. Google zit er regelmatig naast en laat me ook op sommige veilige sites niet toe omdat het certificaat niet in orde is. De waarschuwing is prima, maar uiteindelijk wil ik zelf bepalen om door te gaan of niet. Reden waarom ik hier vier of vijf browsers geïnstalleerd
heb staan...

[SunnieNL]

Die mogelijkheid heb je volgens mij alleen nog maar in een oudere versie van Chrome.
Ik kom nu regelmatig tegen dat ik het niet meer kan, maar kan zijn dat een website dit mee kan geven. Er stond toen iets van "door de configuratie van de website kunt u zonder geldig certificaat deze niet benaderen"

[Cergorach]

Ik draai Versie 83.0.4103.116 (Officiële build) (64-bits) en daar werkt het netjes in. Nieuwer dan dat en het is beta, dev of 'your asking for it' channel...

[SunnieNL]

Dat ligt dus aan de instellingen die de website meegeeft.
Als KPN het high secure heeft ingesteld kan dat dus niet meer. Ik heb hetzelfde al gehad met een Ivanti CSA.

Ik kon even zo snel geen plaatje vinden, maar dit youtube filmpje geeft het ook weer:
https://www.youtube.com/watch?v=e0ZKskYqf64

[Pietjebelll]

Ik had gisteren dit probleem met de V10a, en ik kon er met geen mogelijkheid inkomen. Uiteindelijk de datum terug moeten zetten. Doorklikken kon bij mij niet (chrome op Mac)

[EXCalibur_EeK]

Probeer eens als je op die pagina zit dit in te typen achter elkaar zonder spaties: THIS IS UNSAFE

[aikebah]

Volgende keer gewoon een keer Safari gebruiken... dan kun je wel doorklikken

[Pietjebelll]

Uiteraard geprobeerd en werkte ook niet...

[jozuf]

Als je een HSTS header zet is het ook in FireFox niet mogelijk, net als Chrome (dit is al heel lang zo).
Dat zal hier dan ws niet het geval zijn.

[Reactie gewijzigd door jozuf op 22 juli 2024 22:51]

[jcbvm]

Dat wist ik niet, in chrome zie ik dit voorbij komen:

You cannot visit mijnmodem.kpn right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later.

Toch kan ik in de laatste versie van Firefox de melding nog negeren.

[aikebah]

History even clearen voor die site en dan gaat het wel. Wel zorgen dat je daarna certificaat vervangt, want anders blijf je history wissen omerbij te komen (dwz dat werkte toen ik nog een server had draaien waar ik via een webui het nieuwe cert moest uploaden, is al weer even terug, tegenwoordig alles langs Let's Encrypt, dus nooit meer een verlopen cert)

[Heroic_Nonsense]

Direct naar het IP-adres van het modem surfen kan ook gelukkig; standaard is dat 192.168.2.254.

[skunkopaat]

Dat kan op de v9 en v10 wel, maar sinds het begin heeft de v10a me altijd verwezen naar mijnmodem.kpn.

Wat ik overigens vreselijk vind. Ik Benader altijd via ip.

[Reactie gewijzigd door skunkopaat op 22 juli 2024 22:51]

[Heroic_Nonsense]

Oh, dat is vreemd. KPN geeft dit namelijk wel als workaround.

Ik heb sinds een maand geen 10A meer (maar een 10-zonder-A), dus kan het niet testen helaas.

[pepijnm]

Off topic maar waarom ben je geswitched?

[Heroic_Nonsense]

KPN heeft de V10A omgeruild wegens problemen met de DHCP-functionaliteit. Hierdoor deelde de/mijn V10A IP-adressen uit in een range die niet van hem was en weigerde vervolgens die apparaten toe te laten.

[BeerenburgCola]

Bij Chrome kan dit niet meer tenzij je dit ergens in de (diep)verborgen instellingen veranderd.
Bij Edge kon ik dit laatsten (nog) wel, maar dan moet je eerst op 'details' klikken (o.i.d.)

[Chiron]

in Brave (gebaseerd op Chrome) kan je als je de waarschuwingspagina krijgt zonder mogelijkheid om door te klikken nog verder door "thisisunsafe" in te typen.

Doet me een beetje denken aan Doom cheat codes

[GertMenkel]

Je kunt er zelfs in Chrome nog voorbij! Hacky methode, maar als je in het error screen "thisisunsafe" typt (je hoeft geen input field aan te klikken ofzo, gewoon typen in de error page) kun je alles behalve protocolfouten bypassen. Heel handig voor het debuggen van webservers en hsts.

Het werkt zelfs op Android als je het toetsenbord open forceert (bijvoorbeeld met Hacker's Keyboard, welke een permanente "open toetsenbord" knop in de meldingenbalk zet).

Vroeger was deze geheime code "badidea" maar dat is toen in handleidingen opgenomen en daarom is het veranderd, dus verspreid de code niet al te ver

[N. Steenvoorde]

Firefox inderdaad wel mogelijk. Heel bijzonder.

[Concentr8]

Voor Chrome en Firefox kan het soms voorkomen dat je niet kunt doorklikken. Dat heeft met de HSTS settings te maken.

Een fix waardoor dit opgelost wordt vind je hier:
https://www.thesslstore.c...-settings-chrome-firefox/

[Reactie gewijzigd door Concentr8 op 22 juli 2024 22:51]

[Douweegbertje]

In chrome is het nog steeds wel mogelijk, alleen dat zit heel diep verborgen (met een reden).

Als je op zo'n pagina zit en je typed "thisisunsafe" of "badidea" dan kan je verder

[Justin4711]

Er zit een kleine achteringang in Chrome gebouwd, door de tekst 'thisisunsafe' in te typen zal de browser alsnog toegang geven tot de experiabox.

[sciuro]

Blijkbaar gebruikt KPN voor zijn modems publiekelijke certificaten. Deze zijn terug te vinden op https://crt.sh/ en hier is te zien dat er blijkbaar wel degelijk een nieuw certificaat aangevraagd is, maar gewoonweg nooit in een update is mee genomen.

Daarnaast is blijkbaar elke modem met exact hetzelfde certificaat uitgerust, zowel de publieke als private key...

[praseodymium]

En dan ook nog eens een PKIoverheid-certificaat, dat bedoeld is voor overheidsdiensten: https://logius.nl/diensten/pkioverheid.

[Blokker_1999]

Voor zover ik op die pagina kan zien zijn deze certificaten helemaal niet beperkt tot enkel overheidsdiensten maar lijkt het alsof iedereen ze kan aanvragen.

[Arjant2]

Je hebt hier gelijk in. Het is niet bedoeld alleen voor overheidsdiensten maar wel met name voor communicatie MET overheidsdiensten. Maar uiteindelijk kan iedereen gewoon een dergelijk certificaat gebruiken en is het absoluut niet alleen voor overheidsdiensten. Deze certificaten zijn in het leven geroepen om te voldoen aan de hoogste standaarden en te voldoen aan internationale en Nederlandse wetgeving.

Zo moeten financiële instellingen, beleggingsmaatschappijen etc voor communicatie met de belastingdienst ook een dergelijk certificaat hebben om gebruik te kunnen maken van logius portal. Zonder dit certificaat is dat niet mogelijk.

[Reactie gewijzigd door Arjant2 op 22 juli 2024 22:51]

[tweazer]

Grote voordeel van deze kontstruktie is dat ik vermoed dat de nsa niet rechtstreeks kan meekijken...
Slordig overigens.

Aan de andere kant heb ik ondertussen technisch mijn buik vol van certificaten: waarom kan de gebruiker/eigenaar van een kastje de certificaten niet updaten ? Door certificaten afgeschreven tv's, androids, apple computers. "Onveilig" omdat certificaten niet los van het kastje te managen zijn door gebruiker en/of eigenaar van een kastje... Hoezo fabrikant geforceerde weggooieconomie ?

[supersnathan94]

Lijkt mij nogal logisch dat het niet kan. Als iedere jan het certificaat kan vervangen dan kan een attacker dat ook. Dan kunnen we het net zo goed niet doen.

[tweazer]

dan kan een attacker dat ook.

avm (fritzbox) heeft dat gedeelte goed opgelost: bij bepaalde akties moet je met een telefoon een kode intiepen, kortom quasi physieke beveiliging.

[supersnathan94]

2FA ihelpt inderdaad wel tegen dat soort dingen, maar dan nog is dit gewoon een verantwoordelijke partij. Let wel. die ExperiaBox is niet van jou, een Modem/router/combi krijg je in bruikleen. Dat je überhaupt dingen in kunt stellen is al bij de gratie van provider.

Bij je eigen apparaat mag je klagen als het certificaat verlopen is, maar ja dan is het ook eigen verantwoordelijkheid natuurlijk.

[t link]

omdat we allemaal prijsvechters kopen. dan is daar gewoon geen geld voor.

[thof]

Dat klopt, PKI overheid certificaten kunnen iedereen aanvragen. Ook door de semioverheid bijvoorbeeld.
KPN is heel toevallig zelf een van de partijen die PKIOverheid certificaten uitgeeft. Je zou dus verwachten dat ze prima zelf een nieuw certificaat kunnen aanvragen en uitrollen.

Zie website KPN over PKI Overheid certificaten:
https://certificaat.kpn.c...eidcertificaten/tarieven/

[sciuro]

Dat is ook nog wel een dingetje ja! Volgen mij heeft KPN genoeg mogelijkheden om hun eigen certificaten uit te geven, maar gebruik maken van een CA die primair is tbv de Nederlandse overheid is, lijkt me niet helemaal de bedoeling nee. Het zou verder onderzoek vergen, maar ik vraag me af of Logius toestemming heeft geven om alle KPN modems in Nederland hiermee uit te rusten.

[supersnathan94]

KPN is uitgever van PKIo certificaten. Dan is het dus opzich wel logisch dat ze er gebruik van maken.

Aan de andere kant is het dan bijzonder knullig dat ze hem niet op tijd hebben vervangen.

[Arjant2]

Niet correct, iedereen kan in principe deze certificaten aanvragen.
Je MOET het alleen hebben als je wil communiceren met bepaalde overheidsdiensten, bijvoorbeeld financiële instellingen en beleggingsmaatschappijen moeten deze hebben voor rapportages aan belastingdienst etc.

[Reactie gewijzigd door Arjant2 op 22 juli 2024 22:51]

[Anoniem: 718943]

Ik denk dat het er dan ook primair op zit om de verbinding te encrypten, niet om de identiteit van de remote partij (de modem in je kast, in je eigen bezit) te garanderen.

[t link]

Het hele nut van het certificaat is om de identiteit te bevestigen. anders kan je er ook gewoon een self signed certificaat aan hangen wat het apparaat zelf maakt.

[Niemand_Anders]

Dat is niet juist, wat jouw browser zal standaard self-signed certificaten niet accepteren. Je zult dan net als met verlopen certificaten een uitzondering moeten opnemen..

[t link]

Dat je browser ze niet accepteerd betekend niet dat het nut niet is verifieren van identiteit. dat is letterlijk het doel en het nut. self signed zegt alleen ik zeg wie ik zeg dat ik ben. het klopt dat je een uitzondering dan moet opnemen, maar dat veranderd niet zoveel aan het cryptografische nut van het certificaat.

[Niemand_Anders]

Heb je enig idee hoeveel mensen met de KPN helpdesk gaan bellen als zij van de browser een melding krijgen dat het certificaat van een onbekende uitgever komt?

Dan is het eenvoudiger om gewoon een geldig SSL certificaat te kopen (10 euro per jaar) en deze op alle modems te zetten. De verbinding is encrypted en de gebruiker krijg geen foutmelding..

Alleen is men dit keer vergeten de certificaten op de modems te updaten. Echter zodra deze update is gedaan, is het op de helpdesk een stuk rustiger (de meeste mensen loggen zelden in op hun router).

Dit in tegenstelling tot als je self-signed certificaten zou gebruiken. Klanten zullen dan altijd altijd je helpdesk blijven bellen. Via diverse campagnes van de overheid (en banken) hebben we geleerd hoe we onveilige websites kunnen herkennen..

[t link]

ik zeg ook niet dat het een goede oplossing is. ik zeg dat het hele nut van een certificaat identiteit bevestigen is. en dat is het ook, omdat anders browsers bijvoorbeeld gaan klagen. als het ging om encryptie dan was self signed goed genoeg. maar dat is niet waar het om draait.

[Niemand_Anders]

Het draait erom dat de klant een beveiligde verbinding heeft zonder dat hij/zij allerlei uitzonderingen hoeft te accepteren..

Ofwel je (lokale) HTTPS modem interface moet hetzelfde gemak hebben als de website van je favoriete krant.. Als je allerlei waarshuwingen krijgt, is die ervaring niet hetzelfde en wordt de helpdesk van de provider overbelast..

[t link]

dat is niet het nut van certificaten het nut van certificaten is cryptografisch bevestigen wie je zegt dat je bent. het is een neveneffect door de implementatie van browsers om te voorkomen dat het misbruikt wordt.

[NielsFL]

Een self-signed certificaat geeft een waarschuwing, of volgens de leek: een foutmelding. Ik vermoed dat dat de enige reden is dat ze een echt certificaat hebben gebruikt, om van die melding af te zijn.

Voorheen had men gewoon http gebruikt. Maar browsers worden daar steeds kritischer op, wat weer supportvragen oplevert.

[WoutervOorschot]

De enige reden dat ze het gebruiken is (lijkt me) het gedrag van browsers tegenwoordig. Als je naar je modem gaat zonder https (of self signed) komen er steeds meer waarschuwingen dat het onveilig zou zijn (terwijl het in je eigen netwerk afgeschermd van internet is). Ook werken op bijvoorbeeld chrome sommige API's niet als je geen https gebruikt.

[kodak]

Dat neemt het nut van een officieel certificaat wat weg. Lijkt me niet de bedoeling. Zeker niet zolang het apparaat niet volledig onder controle is van de klant.

[ANdrode]

Afhankelijk van de implementatie is het veilig genoeg om op alle modems hetzelfde certificaat te gebruiken. Want dat is eigenlijk ook wat je indirect doet bij DRM.

Maar in de praktijk betekent dit waarschijnlijk dat je de private key uit flash kan halen. De CA moet het certificaat daarna binnen 24 uur intrekken. En daarna begint die cirkel weer opnieuw...

[dennizzz]

Dat is niet echt een best practice. Als het iemand lukt om de private key te verkrijgen van het modem, kun je het op deze manier laten revoken,

[KRASH]

Je kunt deze melding overigens makkelijk omzeilen door in het desbetreffende scherm "thisisunsafe" in te typen. Dit werkt volgens mij in alle chromium based browsers.

[GertMenkel]

Een publiek certificaat voor een lokaal apparaat, wait what? Hier zit geen enkel beveiligingsvoordeel aan.

Wie dumpt er even de ROM van het modem om de private key te delen? Als ik KPN had, had ik het zelf gedaan. Wat een ronduit achterlijk idee is dit zeg.

Als KPN meeleest: je kunt het bijvoorbeeld veilig oplossen door publieke-identifier.modem.kpn.nl ofzo te maken, en dan de identifier automatisch te bepalen op basis van het externe IP bij een KPN-server. Als je die certificaten met ACME configureert (net zoals letsencrypt) heb je per apparaat een publiekelijk bruikbaar certificaat en kan je alleen je eigen modem hacken.

[Darses]

Een aardig achtergrond artikel over hoe Plex deze oplossing gebruikt is hier te lezen.

[itsmemax]

Stomme vraag misschien, maar is het modem niet gewoon probleemloos bereikbaar via 192.168.2.254?

[kozue]

Volgens mij krijg je een redirect naar https://mijnmodem.kpn wanneer je het via http of het IP probeert te benaderen.
Ronduit irritant overigens, want die hostname werkt alleen als je dat modem als DNS server gebruikt. Als je een eigen DNS gebruikt (bv een pihole) dan is het hele ding niet te bereiken. Daar kom ik als IT’er dan wel weer omheen door het in /etc/hosts toe te voegen, maar hoe moet een gemiddelde gebruiker dat weten? Het is gewoon een rommelige klungeloplossing...

[ballo50]

Een gemiddelde gebruiker zal geen pihole draaien en dus ook geen probleem hebben met de redirect. Als je een pihole draait, zal je meer verstand hebben van IT en dus ook weten dat het modem gewoon op zijn op adres bereikbaar is. Hoef je dus ook niet te rommelen in een host file...

[NielsFL]

Voor de PI-hole heb je een punt. Maar er zijn ook mensen die met een simpele app malware- of adult-content filteren via DNS diensten als OpenDNS, Cloudflare, etc.

Overigens is .kpn een echt bestaand top-level domein. KPN zou er dus best voor kunnen zorgen dat mijnmodem.kpn altijd naar een vast adres resolved. (Moeten ze wel alle modems op hetzelfde LAN IP vastzetten.)

[Rolfie]

(Moeten ze wel alle modems op hetzelfde LAN IP vastzetten.)

Das wel een klein en belangrijk puntje.... Want als een klant al een andere DNS server gebruikt, dan is de configuratie al niet standaard meer, en is de kans ook aanwezig dat het mogelijk een ander IP adres nodig is voor mijnmodem.kpn.

[readefries]

Je kunt ook gewoon die host aan je pihole toevoegen...

[kozue]

In het geval van een pihole wel, maar dat was slechts een voorbeeld. Er zijn genoeg andere scenario's waarin er een andere DNS gebruikt wordt dan die op de router (VPN bv), waarin je niks aan de DNS kunt wijzigen.

[Vulcanic]

Zeker, via een ip adres is deze op een lokaal netwerk zonder problemen te bereiken.

Echter biedt KPN zelf een andere methode, die vervolgens niet goed wordt onderhouden. Dat is toch wel slordig.

[JJ Le Funk]

Precies, vanaf het LAN het IP adres gebruiken om de Experiabox te benaderen werkt gewoon en is een onbeveiligde verbinding.

[kozue]

Werkt helemaal niet. Ik heb het net geprobeerd en krijg een redirect...

[The Zep Man]

Mogelijk wel, maar je zal nog steeds een certificaatfout krijgen als het apparaat enkel bereikbaar is via HTTPS.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 22:51]

[Cergorach]

Dat ligt er heel erg aan, veel (moderne) apparatuur forceert https en dan wil een browser een geldig certificaat zien, als die vervolgens is verlopen krijg je dit soort issues.

[SunnieNL]

Dan is het modem wel benaderbaar, maar krijg je dezelfde foutmelding.
Het wordt verergerd omdat de nieuwe browsers (In ieder geval Firefox en Chrome) standaard niet meer de mogelijkheid hebben om op details te klikken en vervolgens het foutieve certificaat te negeren. Dat kun je natuurlijk wel weer aanzetten, maar zit wel een eind weggestopt in de menu's.

[mr_evil08]

Voor de gewone gebruiker te moeilijk.

[SinergyX]

Grappig dat Edge origineel dus wel standaard optie heeft om door te gaan (onder advanced), maar Edge Chromium dus niet meer, altijd handig in geval van nood de oude Edge nog te hebben (makkelijker uit te leggen naar de leek, dan settings in Chromium te gaan overrullen).

[Henk Poley]

Edgium zijn ze inmiddels al via Windows Updates aan het uitrollen.

[mg794613]

"Zeg pa, hoe krijg je het voor elkaar dat je schijf nu weer encrypt is?"
"Ja op werk zeiden ze, klik maar door, want dat betekend niks"

Beetje gekscherend, maar helaas wel het resultaat voor sommige.
Nu snap ik wel dat jij en ik relatief beter kunnen inschatten dan hem.
Maar browsers zijn dit natuurlijk niet voor niks aan het beperken.

[Micahve]

Ja, maar de echte grap is: Welke gek gebruikt er nog Edge

[Luchtbakker]

Wel heel erg slordig dat dit schijnbaar geen prioriteit heeft om op te lossen in een periode van 3 weken .

[kodak]

Vergeet niet dat het oplossen van het verlopen van het certificaat al minimaal sinds het uitgeven van het vernieuwde certificaat (september 2019) duurt. Dat is dus heel wat langer dan 3 weken.

[QuatroXL]

Ik zit dan niet bij KPN, maar het lijkt mij dat het ook niet de hoogste prioriteit heeft. Hoeveel gebruikers moeten hun DHCP range aanpassen omdat ze bijv. te veel devices hebben. en gast toegang ach dit is de code voor de WIFI.

Volgens mij zit een gemiddelde tweaker weleens op zijn modem ingelogd, maar het ros van de gebruikers toch niet? Of heb je dat als KNP gebruiker nodig?

[BramuS]

De Experiabox v10a is nu niet het meest stabiele apparaat, ik gok dus dat er zeker wel eens inlogd om dat ding een schop te geven, of anderzijds de settings te controleren (port forward gooit hij wel eens door elkaar bijv)

Dat is ook een van de redenen dat ik persoonlijk de v10a heb vervangen door een Mikrotik router gezien dit inmiddels supported is bij KPN. Ben je in ieder geval van die blunders, en een onstabiel apparaat af.

[Reactie gewijzigd door BramuS op 22 juli 2024 22:51]

[Zapato]

Stroom uit en aan.

[Doane]

De Experiabox v10a is nu niet het meest stabiele apparaat

Mwa, nooit iets van 'instabiliteit' gemerkt hier. Zal dus niet bij iedereen zijn schat ik.

[Fancyland]

Ik heb de Experiabox v10a ook niet als meest stabiele apparaat gevonden. Elke dag rond hetzelfde uur kreeg de router een SIGTERM en startte deze opnieuw op. Tot ik de kabel die de KPN-monteur van de glasvezelbox naar de Experiabox aan had gesloten verving en sinds dien draait het geheel non-stop.

[Fancyland]

De enige rede die ik zie voor de gemiddelde gebruiker om in te loggen is zijn wifi naam/wachtwoord te veranderen. Ook dit zullen zij slechts bij het instellen van een nieuwe router doen, als ze er zelfs tijd voor over hebben.
Daarbij laat KPN het niet toe om de DHCP range te veranderen van de standaard 192.168.2.xxx. Gelukkig is de blokkade security by obscurity en zit het alleen in de gui, via f12 is de range wel te veranderen en via de gewone knop op te slaan. Ik liep hier tegen aan toen ik een vpn verbinding aan het opzetten was, welke op dezelfde range zat.

[Oon]

Echt weer iets voor KPN. Ze hebben de laatste jaren vaker dat er een probleem is dat bij veel of alle gebruikers speelt maar waar weken lang niks mee gedaan wordt. Voorbeelden hiervan zijn het forceren van HDR: nieuws: KPN-update voor interactieve tv-ontvanger forceert hdr-modus op telev... (deze hebben ze uiteindelijk teruggerold) en het uitbrengen van 'gigabit' waar gebruikers de eerste weken maar 850-860Mbps geleverd kregen (ver onder de 940Mbps die ze zouden moeten kunnen leveren).

Ik kan persoonlijk niet wachten tot een andere provider gigabit gaat leveren. Mobiel is er niks mis met KPN, maar voor thuis zijn ze belachelijk duur en niet meer van de kwaliteit die ze ooit waren.

[n9iels]

Ik heb ook voor 3 juli al vreemde problemen ervaren met dit certificaat. Firefox accepteerde hem niet en bleef zo'n standaard validatie waarschuwing tonen. In een andere browser werd het certificaat wel gewoon geaccepteerd

[Anoniem: 718943]

Dat lijkt mij dan een issue met Firefox. Mogelijk dat ie niet de hele chain kon volgen, dat verzameling CA's of intermediates in Firefox misschien niet up-to-date was.

[Darses]

Dat Firefox de (intermediate) CA niet zou kennen lijkt mij onwaarschijnlijk omdat deze van te voren gedownload worden.

[Supertroeper]

Is dit niet aan Kpn om op te lossen?

[Micahve]

Op een vraag als deze moet het antwoord toch duidelijk zijn...
Of mis ik wat?

[Yucon]

Vooropgesteld: fouten gebeuren. Maar in dit geval is het wel zo dat providers het gebruik van eigen modems zoveel mogelijk tegenwerken, oa omdat "klanten hun modems niet updaten" en het "tenminste wel goed gaat als wij het doen", en dat maakt dat ik er toch een beetje met een glimlach naar kijk.