Wat is een SSL-certificaatketen? Uitleg en veelgestelde vragen

Wie wel eens een website bezoekt via HTTPS denkt er meestal niet over na dat een hele keten van digitale handtekeningen nodig is. Toch bepaalt die keten – de SSL-certificaatketen – of uw browser de website vertrouwt.

Percentage webverkeer dat HTTPS gebruikt: Meer dan 90% (Google Transparency Report) ·
Aantal root-CA’s in vertrouwde lijsten: Ongeveer 50 ·
Gemiddeld aantal certificaten in een keten: 3 (server, tussenliggend, root) ·
Meest voorkomende ketenfout: Ontbrekend tussenliggend certificaat

De onderstaande tabel vat de kerngegevens over SSL-certificaatketens samen.

Wat is het doel van een certificaatketen?

Een SSL-certificaatketen verbindt het servercertificaat van een website met een vertrouwd rootcertificaat. Zonder die keten kunnen browsers de authenticiteit van een SSL-certificaat niet verifiëren (DigiCert Knowledge Base). Het doel is één ononderbroken lijn van vertrouwen – van de eindgebruiker tot aan de hoogste certificeringsinstantie.

Waarom is een certificaatketen nodig voor HTTPS?

HTTPS is afhankelijk van de keten om te bewijzen dat het servercertificaat niet is vervalst. Zonder keten zou iedereen een zelfondertekend certificaat kunnen maken en zich voordoen als een legitieme website (Sectigo). De browser stopt dan met het laden van de pagina en toont een waarschuwing.

• Zonder keten: geen vertrouwen, geen groen hangslot.
• Met keten: de browser controleert elke handtekening tot aan een root-CA in zijn trust store (CyberArk).

Wat is de rol van een rootcertificaat?

Het rootcertificaat is de uiteindelijke ‘trust anchor’ – het fundament van de keten. Het is zelfondertekend en wordt door browsers en besturingssystemen in een vertrouwde lijst opgenomen (DigiCert Knowledge Base). Zonder een root-CA in de trust store van de browser wordt het hele certificaat geweigerd.

De implicatie: root-CA’s zijn kritieke infrastructuur. Als een root-CA wordt gehackt of zijn betrouwbaarheid verliest, moeten browsers die uit de trust store verwijderen – en dan storten alle ketens die ervan afhankelijk zijn in.

Hoe werkt een SSL-certificaatketen?

De keten is een geordende reeks certificaten. De server stuurt zijn eigen certificaat (het ‘leaf’-certificaat) samen met alle tussenliggende certificaten naar de browser (Sectigo). De browser controleert vervolgens of elk certificaat is ondertekend door het volgende in de reeks, totdat hij een rootcertificaat tegenkomt dat hij vertrouwt.

Wat is het verschil tussen een rootcertificaat en een tussenliggend certificaat?

• Rootcertificaat: zelfondertekend, aanwezig in de trust store van browsers. Staat aan de top van de hiërarchie (DigiCert Knowledge Base).
• Tussenliggend certificaat (intermediate): ondertekend door een root-CA of een andere intermediate. Fungeert als buffer tussen het servercertificaat en de root, zodat de root-CA niet direct aan het internet wordt blootgesteld (CyberArk).

Zonder tussenliggende certificaten zouden root-CA’s elk servercertificaat persoonlijk moeten ondertekenen – een onhoudbare last. De tussenlaag maakt schaalbaarheid mogelijk.

Hoe verifieert een browser de keten?

De browser doorloopt elke schakel: hij controleert de handtekening van het leaf-certificaat met de publieke sleutel van de intermediate, en vervolgens de handtekening van de intermediate met de publieke sleutel van de root (CyberArk). Ook wordt gecontroleerd of de subject name van het ene certificaat overeenkomt met de issuer name van het vorige (Sectigo).

Het patroon: elke schakel in de keten moet cryptografisch bewijs leveren dat hij de vorige heeft goedgekeurd. Is dat bewijs er niet, dan is de hele keten ongeldig.

Wat betekent ‘verificatie mislukt’ met een certificaatketen?

Een ‘verificatie mislukt’-melding betekent dat de browser of het apparaat de keten niet kan voltooien tot een vertrouwd rootcertificaat. De verbinding wordt dan niet opgezet (Sectigo).

Wat zijn veelvoorkomende oorzaken van verificatiefouten?

• Ontbrekend tussenliggend certificaat: de server stuurt alleen het leaf-certificaat, de browser kan het pad niet compleet maken (DigiCert Knowledge Base).
• Verlopen certificaat: een van de schakels is niet meer geldig.
• Zelfondertekend certificaat: het leaf-certificaat is niet ondertekend door een CA die de browser vertrouwt.
• Ongeldige volgorde: de certificaten worden in de verkeerde volgorde aangeboden (Sematext).

Hoe herken ik een ongeldige keten?

Browsers tonen een slotje met een kruisje of de tekst ‘Niet veilig’. U kunt ook de certificaatdetails bekijken: als er een foutmelding staat zoals ‘Dit certificaat is niet geïnstalleerd met de bijbehorende tussencertificaten’, dan ontbreekt er een schakel (DigiCert Knowledge Base). Tools zoals SSL Labs geven een duidelijke rapportage.

De implicatie: een simpele fout in de keten kan uw bezoekers wegjagen. Meer dan de helft van de gebruikers verlaat een site bij een beveiligingswaarschuwing.

Hoe los ik problemen met certificaatketens op?

Het oplossen begint met het identificeren van de ontbrekende schakel. Volg deze stappen om veelvoorkomende ketenfouten te verhelpen.

Hoe installeer ik een tussenliggend certificaat op de server?

1. Download de juiste intermediate-certificaten van uw certificaatverlener (bijv. DigiCert of Let’s Encrypt). Let op de correcte keten voor uw servertype.
2. Plaats de intermediate- en rootcertificaten in de door uw webserver voorgeschreven map (bij Apache: SSLCertificateChainFile of SSLCACertificateFile) (DigiCert Knowledge Base).
3. Voeg het servercertificaat toe en zorg dat de volgorde is: servercertificaat, vervolgens intermediate(s), en eventueel de root onderaan (Sematext).
4. Herstart de webserver (Apache: sudo systemctl restart httpd).
5. Test de keten met een online tool (zie volgende H3).

Hoe controleer ik de keten met online tools?

1. Bezoek SSL Labs (Qualys) en voer uw domein in. Het rapport toont de volledige keten en eventuele fouten.
2. Gebruik What’s My Chain Cert? om te controleren of de server de juiste volgorde serveert.
3. Controleer met openssl op de commandoregel: openssl s_client -connect example.com:443 -showcerts (DigiCert Help).
4. Controleer of de certificaatdatums niet verlopen zijn.

Het patroon: een correct geïnstalleerde tussenlaag voorkomt de meest voorkomende fouten.

Waarom wordt SSL niet meer gebruikt?

Hoewel we nog steeds spreken van ‘SSL-certificaten’, is het protocol zelf achterhaald. SSL 2.0 en 3.0 hebben bekende kwetsbaarheden die zijn verholpen in TLS (Kaspersky). De certificaatketen werkt echter identiek voor beide protocollen.

Wat is het verschil tussen SSL en TLS?

• SSL (Secure Sockets Layer): ontwikkeld in de jaren 90, versies 2.0 en 3.0 zijn in 2015 officieel afgekeurd door de IETF vanwege beveiligingslekken.
• TLS (Transport Layer Security): de opvolger, gestart met TLS 1.0 in 1999. De huidige standaard is TLS 1.3, die sterkere encryptie en betere prestaties biedt (Kaspersky).

Waarom is TLS veiliger?

TLS versleutelt gegevens met modernere algoritmen (AES-GCM, ChaCha20) en voorkomt aanvalsvormen zoals POODLE en BEAST die SSL troffen. Bovendien dwingt TLS 1.3 een snellere handshake af, wat de laadtijd verbetert (Kaspersky).

De implicatie: als uw server nog SSL ondersteunt, schakelt u dat uit. Moderne browsers weigeren SSL 2.0/3.0 al, maar u wilt geen risico lopen op verouderde verbindingen.

Citaat uit de praktijk

Een certificaatketen bevat altijd een servercertificaat, een of meer tussenliggende certificaten en een rootcertificaat.

DigiCert Support – certificatieketen-uitleg

De SSL-certificaatketen is essentieel om het vertrouwen in een website te waarborgen.

DNSimple Kennisbank – certificaatketen en vertrouwen

De rode draad door alle uitspraken: de keten is geen technisch detail, maar de ruggengraat van webbeveiliging. Wanneer die ruggengraat ontbreekt, stort het vertrouwen in.

Voor Nederlandse websitebeheerders is de boodschap helder: controleer bij elke certificaatvernieuwing of het tussenliggende certificaat correct is geïnstalleerd. Doe een ketentest met SSL Labs en zorg dat uw server de intermediates in de juiste volgorde levert. Zo niet, dan verliest u niet alleen bezoekers, maar ook uw reputatie als veilige partij.

Veelgestelde vragen