HackCuraçao is in oprichting: onze diensten volgen binnenkort. Laat je interesse achter

HackCuraçao
Gratis checkTrainingKennisNieuwsOver onsContact

← kennis / artikelen

SSL-certificaten: hoe ze werken en waarom veiligheid telt

7 min lezen

Een SSL-certificaat, technisch een TLS-certificaat, is het digitale bewijs waarmee een website aantoont dat hij is wie hij zegt te zijn. Zonder certificaat is er geen veilige HTTPS-verbinding. Dat bewijs wordt uitgegeven en ondertekend door een certificaatautoriteit (CA), en daar zit het risico: als een CA wordt gehackt of slordig werkt, kan iemand zich voordoen als uw bedrijf of uw bank. Dit artikel legt uit hoe SSL-certificaten werken, hoe ze worden uitgegeven en waarom veiligheid bij de uitgever zo zwaar weegt. Absolute veiligheid bestaat niet, maar een CA moet er met meerdere beveiligingslagen zo dicht mogelijk bij komen.

Wat is een SSL-certificaat en wat bewijst het?

Een certificaat is volgens Cloudflare een bestand op de server met de publieke sleutel van de website en gegevens over de identiteit van de site. De bijbehorende private sleutel blijft geheim op de server. Het certificaat bewijst dat u verbinding hebt met de server die het domein echt beheert, en het maakt een versleutelde verbinding mogelijk.

TLS zelf biedt volgens MDN drie dingen: versleuteling, integriteit en authenticatie. Bij het opzetten van de verbinding, de handshake, kiezen browser en server een TLS-versie en een set algoritmes. Daarna bewijst de server zijn identiteit en spreken beide een geheime sleutel af voor al het verkeer dat volgt. TLS 1.3 is de huidige versie; TLS 1.0 en 1.1 mogen niet meer worden gebruikt.

De naam SSL is verouderd. SSL 3.0 is achterhaald en met een "SSL-certificaat" bedoelt men in de praktijk een TLS-certificaat. Een zelfondertekend certificaat, waarbij u uzelf als uitgever aanwijst, is volgens Cloudflare niet te vertrouwen: browsers markeren zo'n site vaak als onveilig of blokkeren de verbinding.

Hoe werkt de vertrouwensketen?

Een browser kent niet elke website, maar wel een beperkt aantal vertrouwde CA's. Dat werkt via een keten. Een root-certificaat is zelfondertekend en geeft zelf geen eindcertificaten uit. Let's Encrypt schrijft dat zijn rootsleutelmateriaal veilig offline wordt bewaard. Roots ondertekenen alleen intermediates, en die intermediates geven de eindcertificaten uit. De server stuurt de keten mee, zodat de browser de handtekeningen kan nalopen tot een root die hij vertrouwt. Die vertrouwde roots zitten in browsers en besturingssystemen.

Dat maakt een CA tot een aantrekkelijk doelwit. Wie een CA overneemt, kan certificaten laten uitgeven voor domeinen die niet van hem zijn.

Hoe wordt een certificaat uitgegeven?

Hoe uitgifte werkt, laat Let's Encrypt goed zien. Dat is een gratis, geautomatiseerde CA. Het proces kent twee stappen.

  1. Domeinvalidatie. De aanvrager toont aan dat hij het domein beheert, bijvoorbeeld met een DNS-record of een bestand op een vaste plek op de website. De CA controleert dit vanuit meerdere netwerkperspectieven tegelijk, als extra bescherming.
  2. Uitgifte. De aanvrager stuurt een aanvraag (CSR) met de publieke sleutel, ondertekend met de private sleutel. De CA controleert de handtekeningen, geeft het certificaat uit en stuurt het naar publieke Certificate Transparency-logs.

Vernieuwen betekent het hele proces opnieuw doorlopen. Een ACME-client doet dat zonder menselijke tussenkomst.

Niet elk certificaat is even streng gecontroleerd. Cloudflare onderscheidt drie niveaus: Domain Validation (u toont aan dat u het domein beheert), Organization Validation (de CA neemt direct contact op met de aanvrager of het bedrijf) en Extended Validation (een volledige achtergrondcontrole van de organisatie). Daarnaast bestaan single-domain-certificaten, wildcard-certificaten (één domein plus subdomeinen) en multi-domain-certificaten.

Bij de strengere niveaus levert de aanvrager gegevens aan, en die hebben zelf bescherming nodig. DigiCert meldde in een incidentrapport bij Mozilla dat onbevoegden toegang kregen tot een intern archief met door klanten aangeleverde gegevens om hun identiteit te valideren. Certificaten waren volgens DigiCert niet geraakt.

Waarom gaan certificaten steeds korter mee?

Het CA/Browser Forum, het overlegorgaan van CA's en browserbouwers, nam in april 2025 ballot SC-081 aan. Sectigo beschrijft het schema: sinds 15 maart 2026 geldt een maximale looptijd van 200 dagen, vanaf 15 maart 2027 100 dagen en vanaf 15 maart 2029 47 dagen. Ook het hergebruik van domeinvalidatie wordt uiteindelijk beperkt tot 10 dagen.

GlobalSign noemt als reden dat de betrouwbaarheid van certificaatinformatie afneemt en dat browsers controles op ingetrokken certificaten vaak negeren. Korte looptijden werken dan als vangnet. Handmatig vernieuwen wordt daarmee onhoudbaar. GlobalSign adviseert eerst alle certificaten in kaart te brengen en daarna te automatiseren met ACME.

Wat gebeurt er bij intrekking?

Soms moet een certificaat vóór de einddatum worden ingetrokken. Volgens Let's Encrypt is dat nodig als een certificaat niet meer veilig is, bijvoorbeeld door een per ongeluk gedeelde private sleutel of een gehackte server. Bij een gelekte sleutel kiest u de reden keyCompromise. U moet bewijzen dat u bevoegd bent, via het oorspronkelijke account, een ander geautoriseerd account of de private sleutel. De CA maakt intrekkingen bekend via een CRL, een lijst van ingetrokken certificaten, die sommige browsers controleren.

Waarom is veiligheid bij de uitgever zo belangrijk?

Zonder controle kan een CA een certificaat voor uw domein uitgeven zonder dat u het weet. Spoofing en man-in-the-middle-aanvallen zijn dan het gevolg. Daarom bestaat Certificate Transparency: CA's sturen elk certificaat naar publieke, alleen-toevoegen-logs en monitors kijken of er verdachte certificaten verschijnen. Domeineigenaren kunnen zich abonneren op meldingen voor hun eigen domein.

Hoe ernstig het kan misgaan, liet DigiNotar in 2011 zien. Er werden minstens 531 frauduleuze certificaten uitgegeven en ongeveer 300.000 Iraanse Gmail-gebruikers waren het hoofddoelwit. Volgens het Fox-IT-onderzoek, zoals SecurityWeek het weergaf, stonden alle acht CA-servers onder controle van de aanvaller. De beveiliging was zwak: een Windows-domein met een zwak wachtwoord, verouderde webservers, geen antivirus en geen centrale logging. Browsers en besturingssystemen verwijderden de roots van DigiNotar en het bedrijf ging in september 2011 failliet. Ook Nederlandse overheidsdiensten bleken afhankelijk van een DigiNotar-tussencertificaat.

Ook nu gaat het niet altijd goed. DigiCert noemt als oorzaken van zijn incident een netwerkwijziging zonder securityreview, onvoldoende monitoring en een autorisatiemodel dat geen zelfregistratie voorzag. Accounts die zo ontstonden, hadden geen MFA.

Mozilla stelt daarom eisen. Volgens zijn Root Store-beleid is elke niet-naleving van de regels een incident dat binnen 72 uur gemeld moet worden, met tijdlijn, oorzaakanalyse en acties tegen herhaling. CA's worden jaarlijks geauditeerd en bij ernstige of aanhoudende problemen kan Mozilla certificaten uitschakelen of verwijderen.

Absolute veiligheid bestaat dus niet. Wat wel bestaat, is verdediging in lagen: offline roots, strenge en herhaalde validatie, MFA en monitoring, audits, openbare logs en korte looptijden. Dat een CA aan die lagen voldoet, is geen formaliteit. Het is de reden dat u hem vertrouwt.

Wat kunt u zelf doen?

  • Breng alle certificaten in kaart: waar staan ze (website, e-mail, VPN) en wanneer verlopen ze?
  • Automatiseer vernieuwing met een ACME-client, nu de looptijden korter worden.
  • Bescherm de private sleutel. Vermoedt u een lek, trek het certificaat dan in en vervang het.
  • Abonneer u op certificaatmonitoring voor uw domein via Certificate Transparency.
  • Stuur HTTP door naar HTTPS, gebruik HSTS en schakel TLS 1.0 en 1.1 uit. Laat uw TLS-instellingen periodiek toetsen; het NCSC noemt daarvoor de test van internet.nl.
  • Wees zuinig met documenten die u aan een CA aanlevert en vraag hoe ze worden bewaard.

Veelgestelde vragen

Wat is het verschil tussen DV, OV en EV?

Het gaat om de zwaarte van de controle. Bij DV toont u alleen aan dat u het domein beheert. Bij OV neemt de CA direct contact op met de aanvrager of het bedrijf. Bij EV volgt een volledige achtergrondcontrole van de organisatie.

Waarom moet ik certificaten steeds vaker vernieuwen?

Omdat de maximale looptijd stap voor stap wordt verkort: 200 dagen sinds 15 maart 2026, 100 dagen vanaf 15 maart 2027 en 47 dagen vanaf 15 maart 2029. Automatiseren met ACME voorkomt dat een certificaat onverwacht verloopt.

Wat doe ik als mijn private sleutel is gelekt?

Trek het certificaat direct in, met de reden keyCompromise, en vraag een nieuw certificaat aan met een nieuw sleutelpaar. Intrekken kan via de ACME-API van uw CA, mits u kunt bewijzen dat u bevoegd bent.

Hoe zie ik of iemand een certificaat voor mijn domein heeft laten uitgeven?

Certificaten komen in publieke Certificate Transparency-logs. Met een monitor die uw domein volgt, ontvangt u een melding zodra er een (pre)certificaat voor verschijnt.

Conclusie

Een certificaat is maar zo betrouwbaar als de CA die het uitgaf. Daarom moeten CA's hun beveiliging in lagen opbouwen en incidenten openlijk melden. Voor uzelf is de eerste stap eenvoudig: breng uw certificaten in kaart, automatiseer de vernieuwing en zet monitoring op uw domein aan. Houd er rekening mee dat de looptijden korter worden en dat handmatig beheer daardoor steeds riskanter wordt.

Bronnen

Meer kennis

Naar de inhoud