SSL en veilig afrekenen: wat er werkelijk verplicht is voor een webshop
Zoek op 'SSL verplicht webshop' en je vindt tientallen pagina's die stellen dat het moet. Wat geen van die pagina's noemt, is welk wetsartikel dat dan zegt. Dat komt doordat het er niet is. De verplichting bestaat wel, maar hij komt ergens anders vandaan, en dat verschil bepaalt waar je op moet letten.
Kort antwoordGeen enkele wet eist letterlijk een SSL-certificaat. Wel eist artikel 32 van de AVG passende technische maatregelen bij het verwerken van persoonsgegevens, en een webshop verwerkt die bij elke bestelling. Versleuteld verkeer via TLS is daarmee in de praktijk verplicht. Een verlopen certificaat is bovendien direct zichtbaar voor elke bezoeker.
Waar komt de verplichting dan vandaan?
Artikel 32 van de AVG verplicht een verwerkingsverantwoordelijke tot passende technische en organisatorische maatregelen, en noemt versleuteling met zoveel woorden als voorbeeld. Een webshop verwerkt bij elke bestelling naam, adres en vaak een telefoonnummer. Die gegevens onversleuteld over het internet sturen is geen passende maatregel, en dat oordeel hoeft een toezichthouder niet ingewikkeld te motiveren.
Daarnaast speelt de betaalkant. Betaaldienstverleners stellen versleuteld verkeer als voorwaarde in hun eigen overeenkomsten, en de sterke cliëntauthenticatie die bij online betalingen hoort, veronderstelt een beveiligde verbinding. Formeel is dat contractrecht en geen wetgeving, maar praktisch betekent het dat je zonder geldig certificaat geen betalingen kunt aannemen.
SSL of TLS: waarom maakt het verschil uit?
SSL bestaat niet meer. De laatste versie is in 2015 formeel afgeschreven en wordt door geen enkele moderne browser meer geaccepteerd. Wat je installeert is een TLS-certificaat, en wat je server spreekt is TLS 1.2 of 1.3.
Dat onderscheid is niet alleen taalkundig. Een server die uit gewoonte nog TLS 1.0 of 1.1 aanbiedt, biedt een zwakkere route aan die een aanvaller kan afdwingen. Zet die versies uit. Hetzelfde geldt voor verouderde cijferreeksen.
Wat gaat er in de praktijk mis?
Een certificaat kan technisch geldig zijn en toch niet werken voor jouw bezoeker. Deze vier gevallen komen het vaakst voor, en drie ervan zie je niet als je alleen je eigen homepage opent.
- Verlopen. Automatische vernieuwing die stil is gestopt is de belangrijkste oorzaak van uitval.
- Naam komt niet overeen. Het certificaat dekt example.nl maar niet www.example.nl, of andersom.
- Onvolledige keten. Het eigen certificaat klopt, maar het tussenliggende certificaat ontbreekt. Sommige browsers repareren dat zelf en andere niet, dus de helft van je bezoekers ziet een fout en de andere helft niet.
- Mixed content. De pagina is versleuteld maar haalt een script of afbeelding onversleuteld op, waardoor de browser de hele pagina degradeert.
Hoe controleer je het goed?
Controleer altijd van buitenaf en niet vanaf de server zelf. Vanaf de server gebruik je vaak een lokale configuratie die niet is wat een bezoeker krijgt. Open je winkel in een browser waarin je niet bent ingelogd, klik op het hangslot en kijk naar de vervaldatum en naar de domeinnaam waarvoor het certificaat is uitgegeven.
Controleer daarbij zowel het adres met als zonder www, en controleer of het onversleutelde adres netjes doorstuurt naar het versleutelde. Een winkel die op beide adressen bereikbaar blijft, verspreidt zijn vindbaarheid over twee versies van dezelfde pagina.
Wat meet VeriShop hiervan?
Dit is een van de vijf regels die VeriShop doorlopend meet. De scanner legt de verbinding op precies dezelfde manier als een browser en registreert of het certificaat geldig is, of de keten compleet is en of de naam klopt. De uitkomst krijgt een datum en een hash, zodat je later kunt aantonen wat er op dat moment stond.
Deze controle is als kritiek geclassificeerd. Bij een ongeldig certificaat kan er geen positieve Trust State ontstaan, hoe goed de rest ook in orde is. Een winkel waarvan de verbinding niet te vertrouwen is, is niet gedeeltelijk in orde.