Is het gevaarlijk om door te klikken bij "Je verbinding is niet privé"?

Meestal is de oorzaak onschuldig, zoals een verlopen certificaat. Maar je browser kan niet controleren of je écht met de juiste site praat. Klik nooit door als je gaat inloggen of betalen. Bij een informatieve site is het risico kleiner, maar wachten tot de eigenaar het oplost blijft het veiligste.

Hoe lang duurt het om een verlopen SSL-certificaat te vernieuwen?

Technisch gezien enkele minuten. Een nieuw Let's Encrypt-certificaat aanvragen en installeren is bij een goed ingerichte server zo gebeurd. Duurt het langer, dan zit er meestal iets onder: een DNS-wijziging die de validatie blokkeert, een firewall die poort 80 dichthoudt, of een verlengingsscript dat stilletjes kapot is.

Waarom krijgen sommige bezoekers de SSL-fout wel en anderen niet?

Vaak door DNS-caching na een verhuizing — de ene bezoeker komt nog op de oude server met een geldig certificaat, de ander al op de nieuwe zonder. Ook een verkeerde computerklok bij de bezoeker of een ontbrekend tussencertificaat (dat sommige apparaten zelf aanvullen en andere niet) geeft dit wisselende beeld.

Mijn certificaat is geldig, maar ik zie geen slotje. Hoe kan dat?

Dan is er vrijwel zeker mixed content — je pagina laadt afbeeldingen, scripts of stylesheets nog via http:// in plaats van https://. De verbinding zelf is goed, maar de browser waarschuwt omdat er onbeveiligde onderdelen meekomen. In WordPress los je dit meestal op met een zoek-en-vervang van de oude http-URL's.

Wat kost een SSL-certificaat?

Een Let's Encrypt-certificaat is gratis en voor de meeste sites prima; de versleuteling is identiek aan die van betaalde certificaten. Betaalde certificaten koop je vooral voor extra's zoals uitgebreide validatie of garantie. Belangrijker dan de prijs is dat de verlenging automatisch loopt en bewaakt wordt.

"Je verbinding is niet privé" — SSL-fout uitgelegd en opgelost

Zie je "Je verbinding is niet privé" in je browser, dan kan de browser het SSL-certificaat van de site niet vertrouwen — meestal omdat het verlopen is, voor een andere hostnaam is uitgegeven of niet compleet geïnstalleerd is. Voor jou als bezoeker is het zelden acuut gevaarlijk, maar log niet in en reken niet af zolang de melding er staat. Ben je de eigenaar van de site, dan is dit een probleem dat je (of je hoster) vandaag nog wilt oplossen: bezoekers haken af en Google waardeert het niet. Hieronder leg ik uit wat elke foutcode betekent en hoe je het fixt.

Wat betekent de melding precies?

Elke serieuze website draait tegenwoordig via HTTPS: het verkeer tussen jouw browser en de server is versleuteld. Dat werkt met een SSL-certificaat (officieel TLS-certificaat, maar iedereen zegt SSL). Zo'n certificaat bewijst twee dingen: dat je met de échte server van dat domein praat, en dat niemand onderweg kan meelezen.

Voordat je browser ook maar één pagina laadt, controleert hij dat certificaat: klopt de domeinnaam, is het nog geldig, en is het uitgegeven door een uitgever die de browser vertrouwt? Faalt één van die checks, dan gooit de browser er een groot waarschuwingsscherm tussen. Chrome noemt dat "Je verbinding is niet privé", Firefox zegt "Waarschuwing: mogelijk beveiligingsrisico" en Safari houdt het op "Deze verbinding is niet privé". Onder de melding staat een foutcode — en die code vertelt je precies waar het misgaat.

Welke foutcode zie je, en wat zegt die?

Scroll in het waarschuwingsscherm even naar de code in hoofdletters. Dit zijn de drie die ik verreweg het meest tegenkom:

NET::ERR_CERT_DATE_INVALID — het certificaat is verlopen (of, zeldzamer: nog niet geldig). Certificaten hebben een houdbaarheidsdatum; Let's Encrypt-certificaten zijn maar 90 dagen geldig en horen automatisch verlengd te worden. Zie je deze code, dan is die verlenging ergens misgegaan. Let op: deze code verschijnt óók als de klok van je eigen computer fout staat — daarover verderop meer.

NET::ERR_CERT_AUTHORITY_INVALID — de browser herkent de uitgever van het certificaat niet. Dit zie je bij zelf-ondertekende certificaten (bijvoorbeeld het standaardcertificaat van een server waar nog nooit een echt certificaat op is gezet), of wanneer de tussencertificaten ontbreken. Een certificaat staat namelijk nooit alleen: het hangt via een keten van tussencertificaten aan een vertrouwde rootuitgever. Vergeet de serverbeheerder die keten mee te installeren, dan kan een deel van de apparaten de puzzel niet leggen — typisch het patroon waarbij het op jouw laptop werkt maar op de telefoon van je klant niet.

CERT_COMMON_NAME_INVALID (in Chrome vaak NET::ERR_CERT_COMMON_NAME_INVALID) — er ís een geldig certificaat, maar voor de verkeerde naam. De klassieker: het certificaat dekt jouwdomein.nl maar niet www.jouwdomein.nl, of andersom. Ook veelvoorkomend: het domein wijst (nog) naar een server waar een certificaat van een heel ander domein op staat, bijvoorbeeld halverwege een verhuizing.

Firefox gebruikt eigen codes (zoals SEC_ERROR_EXPIRED_CERTIFICATE en SSL_ERROR_BAD_CERT_DOMAIN), maar die vertalen één-op-één naar dezelfde drie oorzaken: verlopen, niet vertrouwd, of verkeerde naam.

Wat zijn de meest voorkomende oorzaken?

Het certificaat is verlopen

Veruit de nummer één. Vrijwel alle sites draaien op certificaten die automatisch verlengd worden — tót het moment dat die automatiek stilletjes stukgaat. En het venijnige is: dat merk je pas weken later, als het oude certificaat echt verloopt.

Uit mijn eigen praktijk: verlopen certificaten zie ik het vaakst vlak na een DNS-wijziging (zie ook DNS-records uitgelegd). Een domein verhuist naar een andere server of gaat achter een dienst als Cloudflare hangen, en de verlenging op de oude plek faalt vanaf dat moment geruisloos. Let's Encrypt controleert bij elke verlenging namelijk of het domein echt naar jouw server wijst; klopt dat niet meer, dan wordt er simpelweg geen nieuw certificaat uitgegeven. Niemand die het ziet — tot dag 90.

Certificaat voor de verkeerde hostnaam

Een certificaat geldt alleen voor de namen die erin staan. Is het alleen aangevraagd voor jouwdomein.nl, dan geeft www.jouwdomein.nl een foutmelding — en andersom. Goede hostingpanelen vragen standaard beide varianten aan, maar bij handmatige installaties of oude configuraties gaat dit geregeld mis. Ook subdomeinen (shop., mail., app.) hebben elk hun eigen dekking nodig, tenzij er een wildcard-certificaat draait.

Ontbrekende tussencertificaten (de chain)

De sluipmoordenaar onder de SSL-fouten, omdat de site voor de één perfect werkt en voor de ander niet. Moderne browsers op recente besturingssystemen vullen een ontbrekende keten vaak zelf aan; oudere Androids, mailprogramma's en API-koppelingen doen dat niet. Krijg je klachten van "sommige" bezoekers terwijl jij niets geks ziet: denk aan de chain.

Mixed content — het slotje ontbreekt ná een geslaagde SSL-installatie

Dit is technisch een ander probleem, maar het komt op hetzelfde neer voor je bezoeker: geen slotje, geen vertrouwen. Het certificaat is prima, maar de pagina zelf laadt nog onderdelen via http:// — afbeeldingen, stylesheets, scripts. De browser toont dan een waarschuwing of blokkeert die onderdelen, waardoor je site er kapot uit kan zien. Bij WordPress-sites die net van http naar https zijn gegaan is dit schering en inslag: de oude URL's staan nog hard in de database. Een zoek-en-vervang over de database (van http://jouwdomein.nl naar https://jouwdomein.nl) lost het vrijwel altijd op.

Als bezoeker: je computerklok staat fout

Krijg je zelf op elke HTTPS-site deze melding, dan ligt het niet aan die sites maar aan jouw apparaat. Een browser vergelijkt de geldigheidsdata van certificaten met jouw systeemklok. Staat die klok maanden of jaren verkeerd — een lege bios-batterij, een verkeerde tijdzone, een tablet die lang uit heeft gestaan — dan lijkt élk certificaat verlopen. Zet datum en tijd op automatisch en de meldingen verdwijnen.

Hoe check je wat er aan de hand is?

Je hoeft geen techneut te zijn om de diagnose te stellen:

Lees de foutcode in het waarschuwingsscherm. Zoals hierboven beschreven wijst die je direct in de goede richting.
Klik op het slotje (of het waarschuwingsicoon) links van de adresbalk en kies "Certificaat" of "Verbinding is niet veilig → meer informatie". Je ziet dan voor welke naam het certificaat is uitgegeven en tot wanneer het geldig is. Staat daar een datum in het verleden: verlopen. Staat er een andere domeinnaam: verkeerde hostnaam.
Gebruik een online SSL-checker. Er zijn gratis tools waarmee je een domeinnaam invult en binnen een minuut een compleet rapport krijgt: geldigheid, gedekte hostnamen én of de tussencertificaten compleet zijn. Dat laatste zie je in de browser zelf niet goed, dus juist bij "werkt bij mij wel, bij de klant niet"-klachten is zo'n checker goud waard.
Test beide varianten: met en zonder www. Werkt de één wel en de ander niet, dan weet je meteen dat het om de dekking van het certificaat gaat.
Check een andere site. Geeft elke HTTPS-site dezelfde fout, dan is het jouw apparaat (klok!), niet de site.

Wat moet je hoster doen om het op te lossen?

Als site-eigenaar hoef je dit niet zelf te fixen — dit is werk voor je hostingpartij. Maar het helpt als je weet wat er moet gebeuren, zodat je gericht kunt vragen:

Verlopen certificaat: een nieuw certificaat aanvragen en installeren. Bij Let's Encrypt is dat een kwestie van minuten — mits het domein correct naar de server wijst. Belangrijker: de hoster moet uitzoeken wáárom de automatische verlenging faalde, anders sta je over drie maanden weer op hetzelfde punt. Meestal is de boosdoener een DNS-wijziging, een dichte poort 80 of een validatiemap die geblokkeerd wordt.
Verkeerde hostnaam: het certificaat opnieuw uitgeven met alle benodigde namen erin — minimaal het kale domein én de www-variant.
Ontbrekende chain: de tussencertificaten toevoegen aan de serverconfiguratie. Vijf minuten werk als je weet waar je moet kijken.
Mixed content: de site-URL's omzetten naar https, bij WordPress via een database-zoek-en-vervang, plus een redirect van http naar https zodat niemand meer op de onbeveiligde variant binnenkomt.

Een goede hoster draait dit binnen een uur; het is standaardwerk. Duurt het dagen of krijg je vage antwoorden, dan is dat een signaal over je hoster, niet over de moeilijkheid van het probleem.

Hoe voorkom je dat dit nog een keer gebeurt?

Eén keer een verlopen certificaat overkomt de besten. Twee keer is een procesprobleem. Zo voorkom je het:

Bewaak de verlenging, niet alleen het certificaat. De meeste ellende ontstaat doordat de automatische verlenging stilletjes faalt en niemand het ziet. Zorg dat er monitoring draait die niet pas alarm slaat als het certificaat verlopen is, maar al waarschuwt als het over pakweg twee weken verloopt zonder dat er verlengd is. Dan heb je ruim de tijd om in te grijpen.
Extra alert na elke DNS-wijziging. Verhuis je een domein, wissel je van nameservers of zet je een dienst als een CDN ervoor? Controleer een paar dagen later of de certificaatverlenging nog werkt. Dit is in mijn ervaring hét moment waarop het misgaat.
Vraag certificaten altijd aan voor beide varianten (met en zonder www), ook als je er maar één actief gebruikt.
Test na elke SSL-wijziging met een externe checker, niet alleen in je eigen browser. Jouw browser is te vergevingsgezind om chain-problemen te zien.
Redirect alles naar https en werk oude http-verwijzingen in je content weg, zodat mixed content geen kans krijgt.

Bij ons draait deze bewaking standaard mee voor alle klanten: verloopt een certificaat bijna zonder dat de verlenging gelukt is, dan krijgen wíj een melding — niet jouw bezoekers een foutscherm.

Staat de melding er nu op jouw site?

Dan wil je vooral dat het snel weer werkt: meestal is dit binnen het uur weer een groen slotje, mits de oorzaak — verlopen certificaat, ontbrekende chain of mixed content — eenmaal helder is.