Een SSL-certificaat is niet iets wat je eenmalig regelt en daarna vergeet. Toch is het een van de meest onderschatte technische details bij websites, webshops en portalen die ik in mijn werk tegenkom. Het probleem zit hem niet alleen in een verlopen certificaat, want dat valt meestal snel genoeg op. De schade zit in de subtielere gevallen: een certificaat dat wel geldig is, maar fout is geconfigureerd. Een cipher suite die al jaren als onveilig wordt beschouwd maar nog steeds actief is. Een HTTP-verbinding die naast HTTPS blijft bestaan zonder doorverwijzing. Dat zijn de situaties waarbij bezoekers niets merken, totdat het te laat is.
Wat browsers en zoekmachines doen met een zwakke configuratie
Chrome, Firefox en Edge rapporteren al jaren actief aan gebruikers wanneer een verbinding niet volledig vertrouwd wordt. Dat hoeft niet eens een volledig verlopen certificaat te zijn. Een zogenaamd "mixed content"-probleem, waarbij een HTTPS-pagina nog onbeveiligde afbeeldingen of scripts laadt via HTTP, is genoeg om een waarschuwing te activeren. Voor een bezoeker die overweegt iets bij je te kopen of een offerteaanvraag te doen, is zo'n browserwaarschuwing een harde stop.
Google kijkt ook mee. HTTPS is al jaren een rankingfactor, maar de kwaliteit van je TLS-implementatie speelt ook een rol in hoe snel een pagina laadt. Verouderde protocollen zoals TLS 1.0 of TLS 1.1 veroorzaken extra handshake-tijd bij elke verbinding. Dat telt op, zeker op mobiel. Een site die gemiddeld 300 milliseconden langzamer laadt dan de concurrent verliest in zoekmachineposities, ook als de content identiek is.
De verborgen risico's van een "gewoon werkend" certificaat
Stel: je site heeft een geldig certificaat, de browser toont het slotje, en iedereen is tevreden. Dat is niet per definitie veilig. Certificaten worden uitgegeven door zogenaamde Certificate Authorities, en niet alle authorities zijn even betrouwbaar. Wanneer een authority wordt gecompromitteerd of wordt verwijderd uit de vertrouwenslijsten van browsers, vervalt het vertrouwen in alle certificaten die die authority heeft uitgegeven, ook als jouw eigen certificaat nog maanden geldig is. Dit is geen theoretisch scenario: het is meerdere keren voorgekomen met grote providers.
Daarnaast is er het probleem van wildcard-certificaten die breder worden ingezet dan bedoeld. Als een wildcard-certificaat voor *.jouwdomein.nl wordt gedeeld tussen meerdere omgevingen, inclusief een testomgeving, geldt een inbreuk op die testomgeving voor alle subdomeinen. Maatwerk vraagt hier om een bewuste keuze: per omgeving een apart certificaat, of minimaal een strikte scheiding in wie toegang heeft tot de private key.
Wat ik in projecten altijd doe, is de configuratie toetsen via een tool als SSL Labs van Qualys. Die geeft een A tot F-score op basis van protocollen, cipher suites, certificaatketen en HSTS-headers. Een score van B of lager is voor mij reden om direct in te grijpen, want die score zegt iets over de feitelijke kwetsbaarheid, niet over hoe het eruit ziet voor de bezoeker.
HSTS en wat er misgaat als je het weglaat
HTTP Strict Transport Security, afgekort HSTS, is een header die je server meestuurt met elke HTTPS-respons. Hij vertelt de browser: stuur de volgende zes maanden geen enkel verzoek via HTTP naar dit domein, ook niet als de gebruiker zelf http:// intypt. Zonder die header is er altijd een klein venster waarin een aanvaller een verbinding kan onderscheppen voordat de browser doorverwijst naar HTTPS. Dat heet een SSL-stripping aanval en het werkt vooral op openbare wifi-netwerken.
Voor een webshop of portaal met inlogmogelijkheid is dit geen academisch risico. Klantgegevens, sessietokens en wachtwoorden kunnen over een onbeveiligde verbinding worden meegelezen als HSTS ontbreekt. De instelling kost niets en duurt vijf minuten, maar zonder expliciete controle op serverinstellingen blijft hij vaak weg. Zeker bij websites die zijn gebouwd door een partij die de hosting en configuratie niet als onderdeel van het project zag.
De max-age-waarde in de HSTS-header bepaalt hoe lang een browser de instelling onthoudt. Een waarde van 31536000 staat voor één jaar. Wil je opgenomen worden in de HSTS-preloadlijst van browsers, dan gelden aanvullende eisen: de header moet includeSubDomains en preload bevatten, en alle subdomeinen moeten daadwerkelijk via HTTPS bereikbaar zijn. Dat laatste is iets wat ik altijd verifieer voordat ik een domein aanmeld voor preloading, want een subdomein dat alleen via HTTP bereikbaar is zorgt na preloading voor een harde fout.
Certificaatbeheer als terugkerend proces, niet als eenmalige taak
Lets Encrypt heeft het mogelijk gemaakt om certificaten gratis en automatisch te vernieuwen, maar "automatisch" is niet hetzelfde als "zorgeloos". De vernieuwing loopt via een Certbot-script dat via een cronjob of systemd-timer wordt uitgevoerd. Als die timer stil komt te staan door een servermigratiehat of een configuratiewijziging, merk je dat pas wanneer het certificaat al verlopen is en bezoekers een harde foutmelding zien.
Betaalde certificaten van commerciële aanbieders hebben langere looptijden, maar vereisen handmatige verlenging. De maximale geldigheid van een certificaat werd in 2023 teruggebracht naar 398 dagen, en er zijn plannen om dat verder te verkorten naar 90 dagen voor alle certificaten. Dat maakt monitoring des te belangrijker. Ik stel voor elk project alerts in die minstens dertig dagen voor verloopdatum afgaan, zodat er altijd tijd is om in te grijpen zonder dat bezoekers iets merken.
Hosting bij een partij die SSL-beheer als vanzelfsprekend heeft meegenomen klinkt als een geruststellende gedachte. Maar als je niet weet wie verantwoordelijk is voor het vernieuwen van jouw certificaat, wie de alerting beheert en wie ingrijpt als het fout gaat, ben je afhankelijk van iemand die misschien niet eens weet dat jouw site bij hem staat. Dat is een organisatorisch risico, geen technisch een.
Wat dit concreet betekent voor een project dat je laat bouwen
Als je een website, webshop of portaal laat bouwen, is de vraag over SSL-configuratie een van de vragen die je moet stellen voordat je tekent. Niet of er een certificaat is, want dat heeft tegenwoordig vrijwel iedereen, maar hoe het certificaat wordt beheerd, welke protocollen zijn uitgeschakeld, of HSTS is geconfigureerd en hoe alerting is geregeld.
Een bouwer die de hostingkeuze en serverconfiguratie volledig buiten scope plaatst, laat je met een website die technisch werkt maar kwetsbaar is op een manier die pas zichtbaar wordt als het te laat is. Conversieverlies door browserwaarschuwingen, lagere Google-posities door vertraagde TLS-handshakes, of in het ergste geval een datalek bij een portaal met klantgegevens. Dat zijn geen hypothetische scenario's, dat zijn de uitkomsten van configuraties die ik tegenkom bij sites die al een paar jaar live staan zonder dat iemand er ooit naar heeft gekeken.
Zelf bouw ik websites en webapplicaties waarbij de serverconfiguratie en beveiliging altijd onderdeel zijn van het project, niet een bijgedachte. Het verschil tussen een score van A+ en een score van B op SSL Labs zit in details die een half uur kosten maar jaren beschermen. Dat vind ik onderdeel van mijn vak.
Als je wilt weten hoe jouw huidige site scoort of wat er geregeld moet worden bij een nieuw project, kun je meer lezen op https://pimvdmolen.nl/diensten/beveiliging. Wil je direct bespreken wat jouw situatie vraagt, dan is https://pimvdmolen.nl/contact de kortste weg.