Een SSL-certificaat is een klein, ondertekend bestand dat een publieke sleutel koppelt aan een domeinnaam. Daarmee kan een browser controleren dat hij met de echte server praat en het verkeer tussen beide versleutelen. De beveiliging die je als hangslotje ziet, komt voort uit een keten van digitaal ondertekende certificaten die loopt van jouw site tot aan een root certificate authority (CA) die de browser al vertrouwt. Als je die keten begrijpt, en het verschil tussen DV-, OV- en EV-validatie, wordt het veel makkelijker om het juiste certificaat te kiezen en fouten te diagnosticeren wanneer er iets misgaat.
"SSL" (Secure Sockets Layer) is de oude naam; het protocol dat vandaag daadwerkelijk wordt gebruikt is TLS (Transport Layer Security), momenteel TLS 1.3 (RFC 8446), waarbij TLS 1.2 (RFC 5246) nog veel voorkomt en TLS 1.0/1.1 formeel zijn uitgefaseerd (RFC 8996). De certificaten zelf volgen het X.509-formaat dat is vastgelegd in RFC 5280. Uit gewoonte zeggen mensen nog steeds "SSL-certificaat", en dat is prima: het betekent hetzelfde als een TLS-certificaat.
Wat zit er precies in een SSL-certificaat?
Een certificaat is een gestructureerd document, niet alleen een sleutel. Het bevat minimaal:
- Het subject: de domeinnaam of domeinnamen waarvoor het certificaat geldt, vermeld in de Subject Alternative Name (SAN)-extensie (RFC 5280 §4.2.1.6).
- De publieke sleutel die de server gebruikt om een versleutelde sessie op te zetten.
- De issuer: welke CA het certificaat heeft ondertekend.
- Een geldigheidsperiode: een not-before- en een not-after-datum.
- De digitale handtekening van de CA, die het geheel verifieerbaar maakt.
Moderne publieke certificaten gebruiken RSA-sleutels van minimaal 2048 bits of ECDSA-sleutels (meestal P-256), en ze worden ondertekend met SHA-256 of sterker. Met SHA-1 ondertekende certificaten worden sinds ongeveer januari 2017 niet meer door browsers vertrouwd. Je kunt de velden, SAN-lijst en vervaldatum van elk live certificaat bekijken met onze gratis SSL-checktool, zonder dat je door de developer tools van je browser hoeft te spitten.
Hoe werkt de certificaatketen (chain of trust)?
Browsers en besturingssystemen worden geleverd met een ingebouwde lijst van vertrouwde root-CA's. Een root-CA ondertekent bijna nooit rechtstreeks het certificaat van je server. In plaats daarvan ondertekent hij een certificaat van een intermediate CA, en die intermediate ondertekent jouw leaf-certificaat (end-entity-certificaat). Dat is de chain of trust:
Root CA (trusted by the browser, kept offline)
└── Intermediate CA (signs certificates day to day)
└── Your leaf certificate (example.com)
Wanneer een browser verbinding maakt met je server, moet je server het leaf-certificaat plus de intermediate(s) aanbieden; de root heeft de browser al. Ontbreekt de intermediate, dan tonen de meeste browsers alsnog een vertrouwensfout, ook al is het leaf-certificaat zelf geldig, omdat ze geen pad terug naar een vertrouwde root kunnen opbouwen. Dit is veruit de meest voorkomende oorzaak van "certificaat niet vertrouwd"-fouten bij een verder correct uitgegeven certificaat, en het loont om hier na elke verlenging of migratie specifiek op te controleren.
WarningEen verkeerd geconfigureerde of onvolledige keten (ontbrekende intermediate) faalt in de meeste browsers, ook al is het certificaat zelf niet verlopen. Controleer na het installeren of verlengen van een certificaat altijd de volledige keten, niet alleen het leaf-certificaat.
DV vs OV vs EV: wat is het echte verschil?
Alle drie de validatieniveaus leveren een certificaat op dat verkeer op precies dezelfde manier versleutelt. Het verschil zit volledig in wat de CA over de aanvrager controleert voordat het certificaat wordt uitgegeven.
| Niveau | Wat wordt gecontroleerd | Gebruikelijke uitgiftetijd | Veelvoorkomend gebruik |
|---|---|---|---|
| DV (Domain Validation) | Alleen controle over het domein (DNS-record, HTTP-bestand of e-mail) | Minuten, vaak geautomatiseerd | De meeste websites, API's, interne diensten |
| OV (Organization Validation) | Domeincontrole plus de juridische identiteit van de aanvragende organisatie | Dagen | Zakelijke sites, klantgerichte apps |
| EV (Extended Validation) | Domeincontrole plus grondige, gestandaardiseerde toetsing van identiteit en juridisch bestaan | Dagen tot weken | Financiële dienstverlening, sites met hoge zekerheidseisen |
Een praktische kanttekening: de groene adresbalk waarmee EV-certificaten zich vroeger onderscheidden, is rond 2019 door Chrome verwijderd, en andere grote browsers volgden. EV-certificaten krijgen in gangbare browsers geen aparte visuele weergave meer, dus de belangrijkste reden om vandaag voor EV te kiezen is organisatiebeleid of compliance-eisen, niet een zichtbaar vertrouwenssignaal voor bezoekers. DV, automatisch uitgegeven via het ACME-protocol (RFC 8555), vormt de basis van de meeste Let's Encrypt-certificaten en is voor het overgrote deel van de sites de juiste keuze.
Twijfel je voor jouw specifieke situatie tussen gratis DV-certificaten en een betaald commercieel certificaat? Die afweging bespreken we uitgebreider in Let's Encrypt vs commerciële SSL-certificaten: welke heb je echt nodig?
Hoe lang is een SSL-certificaat geldig?
De looptijd van publiek vertrouwde certificaten wordt al jaren korter, gedreven door de Baseline Requirements van het CA/Browser Forum: van 60 maanden vóór 2015, naar 39 maanden in 2015, 825 dagen (~27 maanden) in 2018 en 398 dagen (~13 maanden) sinds september 2020. Let's Encrypt-certificaten zijn standaard slechts 90 dagen geldig en zijn bedoeld om automatisch te worden verlengd, meestal rond de 60 dagen, in plaats van handmatig.
TipKortlevende certificaten worden in de hele branche de norm, dus handmatig verlengen is een risico. Automatiseer het, of gebruik een dashboard dat de vervaldatums van al je certificaten bijhoudt.
Wat is Certificate Transparency en waarom is het belangrijk?
Certificate Transparency (CT) is een openbaar logsysteem (RFC 6962, bijgewerkt door RFC 9162) dat elk uitgegeven publiek vertrouwd certificaat registreert. Chrome vereist sinds april 2018 CT-logging voor publiek vertrouwde certificaten: een niet-gelogd certificaat wordt als onbetrouwbaar behandeld, zelfs als een legitieme CA het heeft uitgegeven. CT-logs zijn ook op zichzelf een nuttig beveiligingsinstrument: je kunt ermee in de gaten houden of er certificaten voor je domein zijn uitgegeven die je niet hebt aangevraagd, wat een vroeg signaal kan zijn van een gecompromitteerd account bij een CA of registrar.
Hoe zit het met intrekking en wildcard-certificaten?
Als een private key is gecompromitteerd, moet een certificaat vóór de vervaldatum worden ingetrokken. Daarvoor bestaan twee mechanismen: Certificate Revocation Lists (CRL's) en het Online Certificate Status Protocol (OCSP, RFC 6960). Met OCSP stapling biedt de server zelf een ondertekend OCSP-antwoord met tijdstempel aan, wat sneller en privacyvriendelijker is dan wanneer de browser de CA rechtstreeks bevraagt.
Een veelvoorkomend misverstand: een wildcard-certificaat zoals *.example.com dekt slechts één niveau subdomeinen (www.example.com, api.example.com). Het dekt niet het kale apex-domein example.com, en ook geen geneste subdomeinen zoals dev.api.example.com. Daarvoor heb je extra SAN-vermeldingen of een apart certificaat nodig.
SSL-certificaten beheren bij meerdere providers
De echte operationele pijn bij SSL zit zelden in het begrijpen van de standaarden, maar in het bijhouden van vervaldatums en ketenconfiguraties voor tientallen domeinen, verspreid over verschillende registrars en hosts. Een certificaat dat ongemerkt verloopt op een stagingserver met weinig verkeer, kan nog steeds een integratie platleggen die ervan afhankelijk is. De certificaatbeheer-functie van InfraNest houdt al je certificaten bij, bij elke provider, in één dashboard, en waarschuwt voor naderende vervaldatums voordat ze tot een storing leiden. Beheer je ook de DNS-records waarop certificaten voor validatie vertrouwen? Onze gids over DNS-recordtypen behandelt de recordtypen die CA's gebruiken voor domeincontrolevalidatie.
Controleer nu meteen het huidige certificaat en de keten van elk domein met onze gratis SSL-checktool, of stel geautomatiseerde certificaatbewaking in met het certificaatbeheer van InfraNest.
Veelgestelde vragen
#Is SSL hetzelfde als TLS?
SSL (Secure Sockets Layer) is de oudere, inmiddels uitgefaseerde naam van het protocol; moderne verbindingen gebruiken TLS (Transport Layer Security), momenteel TLS 1.3. In de volksmond zeggen mensen nog steeds "SSL-certificaat" als ze een TLS-certificaat bedoelen.
#Heb ik OV of EV nodig als ik alleen een website draai?
Voor de meeste websites volstaat een DV-certificaat (Domain Validation), dat automatisch kan worden uitgegeven en verlengd. OV en EV voegen identiteitscontrole toe die vooral relevant is voor compliance of organisatiebeleid, aangezien EV geen speciale weergave in de browser meer krijgt.
#Waarom wordt mijn certificaat als onbetrouwbaar weergegeven terwijl het niet verlopen is?
Meestal komt dit door een ontbrekend intermediate-certificaat dat de chain of trust onderbreekt, en niet door een probleem met het certificaat zelf. Installeer de volledige certificaatketen op je server, niet alleen het leaf-certificaat.
#Dekt een wildcard-certificaat elk subdomein?
Nee. Een wildcard-certificaat zoals *.example.com dekt slechts één niveau subdomeinen en dekt niet het apex-domein of geneste subdomeinen zoals dev.api.example.com; daarvoor zijn extra SAN-vermeldingen of aparte certificaten nodig.
Probeer het met een gratis tool
Was dit artikel nuttig?
