Je site heeft het slotje in de browser, dus "hij is al veilig". Het is de zin die we het vaakst horen en de meest misleidende. Het slotje zegt alleen dat er een geldig certificaat bestaat voor dat domein: het zegt niets over welke protocolversies je accepteert, welke ciphers je onderhandelt, of de keten compleet is of wanneer het verloopt. Daarom geven analysetools een cijfer, van A+ tot F, en daarom kunnen twee sites met een slotje aan tegenovergestelde uiteinden staan. Deze gids legt uit wat elk onderdeel van dat cijfer meet, welke configuratie redelijk is in 2026 en hoe je de jouwe met twee commando's controleert.
Wat een TLS-cijfer beoordeelt
Serieuze tools combineren zeven controles. De eerste twee zijn eliminerend: falen ze, dan zakt het cijfer naar F zonder naar de rest te kijken.
- Geldig certificaat: uitgegeven door een erkende autoriteit, voor het juiste domein, binnen de geldigheidsperiode.
- Complete keten: het tussencertificaat dat het jouwe met de rootautoriteit verbindt, wordt meegestuurd.
- Protocolversies: welke TLS-versies je accepteert en welke je weigert.
- Ciphers: welke algoritmes je aanbiedt en in welke volgorde.
- Redirect: of HTTP op de hele site naar HTTPS leidt.
- HSTS: of je de browser vertelt nooit meer HTTP te gebruiken.
- Bekende kwetsbaarheden: onveilige heronderhandeling, compressie, de aanvallen met eigennamen van het vorige decennium.
Versies: alleen 1.2 en 1.3
TLS 1.0 en 1.1 zijn sinds 2020 verouderd en browsers weigeren ze. Accepteert je server ze nog, dan zakt het cijfer omdat een aanvaller een oude client kan dwingen ze te gebruiken. TLS 1.2 is het aanvaardbare minimum; TLS 1.3 is de huidige standaard: minder heen-en-weer bij het verbinden, moderne ciphers verplicht en zonder de onveilige opties van de eerdere versies. De juiste configuratie vandaag is 1.2 en 1.3 accepteren en verder niets. Gebruik je Vercel, Netlify, Cloudflare of managed hosting, dan is dit al zo; beheer je je eigen nginx of een loadbalancer, controleer het dan.
Ciphers: wat er echt toe doet
De cipher bepaalt hoe de sleutel wordt uitgewisseld en hoe het verkeer wordt beschermd. Twee dingen maken het verschil. Het eerste is perfect forward secrecy (de ciphers die met ECDHE beginnen): steelt iemand in de toekomst je privésleutel, dan kan hij het eerder opgenomen verkeer niet ontsleutelen. Het tweede is gebroken of zwakke algoritmes vermijden: RC4, 3DES, de oude CBC-modi en pure RSA-sleuteluitwisseling. Een redelijke lijst voor TLS 1.2 komt neer op ECDHE met AES-GCM of ChaCha20; in TLS 1.3 staat het protocol sowieso alleen moderne ciphers toe, nog een reden om het aan te zetten.
De certificaatketen: de onzichtbare fout
Je certificaat is ondertekend door een tussencertificaat, en dat is ondertekend door een root die apparaten al kennen. De server moet je certificaat én het tussencertificaat sturen. Vergeet je het tussencertificaat, dan downloadt Chrome op de desktop het zelf en zie je geen fout; maar veel telefoons, curl, AI-bots en betaalintegraties falen met een "niet-vertrouwd certificaat". Het is de meest voorkomende fout op handmatig geconfigureerde servers en de lastigste om op te merken, want "bij mij werkt het". Controleer het zo:
openssl s_client -connect jouwdomein.com:443 -servername jouwdomein.com </dev/null 2>/dev/null | grep -E "s:|i:|Verify return"Er moeten minstens twee certificaten in de keten verschijnen en de verificatie moet eindigen met Verify return code: 0 (ok).
Domein en alternatieve namen
Het certificaat moet precies de namen dekken die je gebruikt: jouwdomein.com en www.jouwdomein.com zijn twee verschillende namen. Een certificaat alleen voor de root laat www een fout geven, en omgekeerd. Huidige certificaten vermelden meerdere namen in het SAN-veld, en wildcards (*.jouwdomein.com) dekken subdomeinen van één niveau. Controleer ook de vergeten subdomeinen: api, app, staging met verlopen certificaten zijn een klassieker.
Vervaldatum: steeds korter
Certificaten van Let's Encrypt zijn 90 dagen geldig, het maximum dat browsers vandaag toestaan is 398 en de industrie heeft afgesproken dat geleidelijk te verlagen tot 47 dagen in 2029. De boodschap is duidelijk: vernieuwing moet automatisch. Managed platforms doen het zelf; heb je je eigen server, gebruik dan een ACME-client met geplande vernieuwing en vooral een externe waarschuwing die je seint als er minder dan 14 dagen over zijn. De storing door een verlopen certificaat is de domste en de meest voorkomende.
Redirect en HSTS
Al het HTTP-verkeer moet met een 301 doorsturen naar HTTPS, op alle routes, niet alleen op de homepage. En zodra alles over HTTPS werkt, vertelt de header Strict-Transport-Security de browser om HTTP niet meer te proberen gedurende de tijd die je opgeeft, wat het kleine gaatje van het eerste verzoek dicht. Met includeSubDomains en preload kun je je domein laten opnemen in de lijst die browsers vanuit de fabriek meekrijgen. Het is het gebruikelijke verschil tussen een A en een A+. Hoe je het configureert, staat in HTTP-beveiligingsheaders.
Gemengde inhoud
Een detail dat het certificaatcijfer niet beïnvloedt maar het slotje wel: laadt je HTTPS-pagina een afbeelding, script of lettertype via HTTP, dan blokkeert de browser het of markeert hij de pagina als niet veilig. Het komt meestal van URL's die uit een oud template zijn gekopieerd. Zoek in de bron naar http:// en verander het in relatieve paden of HTTPS.
Als je op een managed platform zit
Vercel, Netlify, Cloudflare Pages, Railway of Render geven het certificaat uit en vernieuwen het, dwingen moderne versies af en kiezen veilige ciphers. Daar hoef je niets aan te doen. Wat van jou blijft: HSTS toevoegen, gemengde inhoud verwijderen, alternatieve domeinen doorsturen en de subdomeinen in de gaten houden die ergens anders naar wijzen.
Waarom het verder gaat dan het cijfer
Zwakke TLS maakt het onderscheppen van sessies op publieke netwerken mogelijk, en een verkeerd geconfigureerd certificaat laat je site falen op apparaten die je niet ziet. Betaalverwerkers eisen minimaal TLS 1.2 om aan PCI DSS te voldoen. Google gebruikt HTTPS als rankingsignaal en browsers markeren alles zonder als "niet veilig". En, heel aards: een certificaat dat op een zaterdagochtend verloopt, is een site die plat ligt tot iemand het merkt.
In dertig seconden controleren
curl -sIL http://jouwdomein.com | grep -iE "^(HTTP|location|strict-transport)"
openssl s_client -connect jouwdomein.com:443 -servername jouwdomein.com -tls1_1 </dev/null 2>&1 | grep -iE "alert|error" | head -1De eerste moet een 301 naar https:// tonen en daarna de HSTS-header. De tweede probeert te verbinden met TLS 1.1 en moet falen: lukt de verbinding, dan accepteer je een verouderde versie.
Scanaris controleert je TLS bij elke scan
Scanaris controleert protocolversies, ciphers, complete keten, certificaatnamen, dagen tot de vervaldatum, redirect en HSTS, en waarschuwt je per e-mail voordat het certificaat verloopt. Elke bevinding komt met een fix prompt met de exacte configuratie voor je server of platform. Het zijn alleen-lezen controles: het verbindt met je site net zoals een browser dat zou doen. Om te zien wat het allemaal in dertig seconden controleert, lees hoe je in 5 minuten weet of je site veilig is.
Veelgestelde vragen
Wat is het verschil tussen SSL en TLS?
SSL is de oude naam van het protocol, jaren geleden afgedankt als onveilig. Wat vandaag wordt gebruikt is TLS, maar mensen zeggen nog steeds "SSL-certificaat". Praktisch gezien: lees je SSL, denk dan TLS.
Heb ik een betaald certificaat nodig?
Nee. Gratis certificaten van Let's Encrypt of die je platform uitgeeft, versleutelen precies hetzelfde. Betaalde voegen organisatievalidatie of garanties toe, geen extra beveiliging in de verbinding.
Waarom krijg ik een B als mijn certificaat geldig is?
Meestal omdat je TLS 1.0 of 1.1 accepteert, zwakke ciphers aanbiedt of de HSTS-header niet stuurt. Het certificaat is maar een van de zeven dingen waarnaar wordt gekeken.