Wat is een SSL-certificaatketen? Werking en tips

Wie een website beveiligt met een SSL-certificaat, hoort vaak de term ‘certificaatketen’, maar wat dat precies inhoudt blijft voor velen vaag. Die onzichtbare keten bepaalt of een browser uw site vertrouwt; dit artikel laat zien hoe de keten werkt, waarom de volgorde essentieel is, en hoe u problemen zoals self_signed_cert_in_chain oplost.

Websites die HTTPS gebruiken (2025): 95% ·
Aantal vertrouwde root-certificaten in gangbare browsers: ~150 ·
Gemiddelde lengte van een certificaatketen: 2 tot 3 certificaten ·
Browsers die automatisch vertrouwde root-certificaten updaten: Alle grote (Chrome, Firefox, Safari, Edge)

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

Wat is een SSL-certificaatketen?

Een SSL-certificaatketen is een geordende lijst van certificaten die het vertrouwenspad vormt van het servercertificaat (leaf-certificaat) naar een vertrouwd root-certificaat. De keten bevat minimaal een leaf-certificaat, een of meer tussenliggende certificaten, en een root-certificaat. Zo creëert u een chain of trust die browsers gebruiken om te controleren of uw site écht is wie u beweert te zijn.

Hoe is een certificaatketen opgebouwd?

De keten volgt een strikte hiërarchie. De server stuurt tijdens de TLS-handshake het leaf-certificaat plus eventuele intermediate-certificaten; de client bouwt daarna de keten omhoog naar een vertrouwde root, zoals beschreven in de handleiding van Netray (informatiebeveiligingsexpert). Enkel als de Issuer van elk certificaat overeenkomt met het Subject van het volgende, is de keten geldig (bron: Salesforce Help – ketenvalidatie (tier 2 expert)).

De vertrouwensopbouw: Het leaf-certificaat wordt door een tussenliggende CA ondertekend, die op zijn beurt weer door een root-CA is geaccordeerd. Zo ontstaat een ongebroken vertrouwensketen van leaf → tussenliggend → root.

Wat is de rol van het root-certificaat?

Een root-certificaat is zelf-ondertekend en staat vooraf in de trust store van de browser, het besturingssysteem of de runtime, zoals uiteengezet door SSLCheckerNow (certificaatspecialist). Omdat het zelf-ondertekend is, vertrouwen browsers het standaard zonder dat de server het hoeft te versturen. Daarom kan een root-certificaat in de serverconfiguratie vaak worden weggelaten – browsers gebruiken de root rechtstreeks uit hun eigen truststore.

Wat is een tussenliggend certificaat?

Een tussenliggend certificaat (ook wel intermediair certificaat) overbrugt de kloof tussen het leaf- en het root-certificaat. Het beschermt de root key: als een tussenliggende CA wordt gecompromitteerd, treft u alleen de intermediaire laag, niet de root. De DigiCert Knowledge Base (certificatieautoriteit) legt uit: “Any certificate that sits between the SSL/TLS Certificate and the Root Certificate is called a chain or Intermediate Certificate.”

Het exacte aantal tussenliggende certificaten varieert per CA en is niet gestandaardiseerd. Sommige ketens gebruiken er één, andere twee. Het principe blijft: elk extra niveau maakt de root aanrakingsvrij.

Wat is het doel van certificaatketening?

Waarom is een hele keten nodig in plaats van een enkel certificaat? Het antwoord ligt in risicospreiding en schaalbaarheid. Certificaatketening maakt het mogelijk om het vertrouwen van een root-CA via tussenliggende CA’s naar een specifiek servercertificaat te leiden – zoals Netray (security-gids) benadrukt. Het verspreidt de verantwoordelijkheid en beperkt de schade bij een compromittering van een tussenliggende CA: in plaats van dat alle vertrouwen instort, wordt alleen die ene CA getroffen.

Zonder ketening moet elk certificaat direct door een root-CA worden ondertekend – wat zowel onpraktisch als onveilig is. De root wordt dan overbelast en zou moeten draaien in online, kwetsbare servers. Dat willen we niet.

Waarom is een keten nodig in plaats van een enkel certificaat?

Zoals de Capy Toolkit (veiligheidssuite) uitlegt: een keten zorgt dat alle certificaten tegelijk moeten voldoen aan signature-, validity-, name constraints- en usage-checks. Browsers bouwen de keten op door vanaf het leaf-certificaat te beginnen en proberen een pad naar een vertrouwde root in de trust store te construeren. Dat pad is enigszins foutbestendig: als een tussenliggend certificaat ontbreekt, faalt de verbinding direct.

Het patroon: De keten wordt niet enkel abstract bekeken – hij wordt hard real-time gecontroleerd door de browser, wat veilig is, maar ook een zwakke plek introduceert: een misplaatst certificaat in de serverconfiguratie breekt meteen de hele site.

Wat is het verschil tussen een certificaat en een certificaatketen?

Een enkel certificaat is een digitaal document dat een identiteit bevestigt – denk aan uw paspoort. Een certificaatketen is het hele verhaal: van paspoort tot nationale identiteit tot overheid die de uitgever van het paspoort vertrouwt. Voor publieke TLS-verbindingen is dat traceerbare pad naar een vertrouwde root essentieel.

Wat is een zelf-ondertekend certificaat versus een keten?

Een zelf-ondertekend certificaat heeft geen keten; het vertrouwt alleen op zichzelf. Bij een SSLCheckerNow (ketenexpert)-lezing: “A self-signed certificate has no chain above it; it is its own root.” In een keten is de Issuer van elk certificaat gelijk aan de Subject van het volgende, tot u uitkomt bij een root.

Zet u een zelf-ondertekend certificaat in voor openbare websites, dan krijgen gebruikers een waarschuwing. De browser ziet de eigen vertrouwde root niet, en vindt geen pad in de keten. Daarom is een keten noodzakelijk voor publiek TLS.

Het patroon: Het is niet alleen een technisch formaat – het is een operationele schil die grootschalig vertrouwen mogelijk maakt. Zonder die schil faalt de site voor alle bezoekers.

Hoe genereer ik een certificaatketen?

Het genereren van een certificaatketen is in principe eenvoudig: u voegt het leaf-certificaat samen met intermediaire certificaten in de juiste volgorde. De basisstap is cat, maar de meeste tools hebben een specifiek formaat nodig, en de volgorde is cruciaal.

Hoe maak ik een certificaatketen met OpenSSL?

Het canonieke commando voor het maken van een ketenbestand in PEM-formaat:

cat server.crt intermediate.crt root.crt > chain.pem

De volgorde is: leaf eerst, dan tussenliggend, dan daadwerkelijk root. Gebruik PEM als standaardformaat. Voor DER moet u apart converteren met openssl x509 -inform PEM -outform DER -in chain.pem -out chain.der.

Let op: roots kunnen worden weggelaten als ze in de truststore van de client zitten, maar het is veilig om ze mee te sturen.

Hoe genereer ik een chain-bestand voor webbrowsers?

Om een .crt keten te genereren voor een webserver voert u het volgende uit:

cat server.crt intermediate.crt root.crt > chain.crt

Apache/nginx verwachten vaak het chain.crt in de configuratie.

Exact de volgorde: leaf eerst, dan intermediair, dan root. DigiCert (certificaatbegeleiding) benadrukt: houd de orde van onder naar boven aan.

Het patroon: Browsers starten met het leaf-certificaat en moeten via de intermediaire direct de link naar de root kunnen maken. Foutieve volgorde betekent dat de browser bij elke request handmatig de volgorde moet herstellen – wat faalt.

Hoe valideer ik een certificaatketen?

Validatie controleert of elk certificaat in de keten correct is ondertekend door de volgende. U kunt dit doen met tools zoals OpenSSL en online checkers.

Welke online tools kan ik gebruiken?

Enkele van de beste:

• SSL Labs van Qualys – test.html – geeft gedetailleerde beveiligingsinformatie.
• Trustico Chain Analyzer – (tool) – controleert of alle intermediair zijn opgenomen.
• DigiCert – (hulpmiddelen) – vergelijkbaar.
• WRVault Certificate Chain Validator – (gratis online) – directe foutopsporing.

Ze geven of uw keten in de juiste volgorde is, of ontbrekende intermediates.

Hoe controleer ik de keten met OpenSSL?

De standaard is:

openssl verify -CAfile root.pem -untrusted intermediate.pem server.crt

Deze opdracht controleert de handtekening van elk element, inclusief de root-CA, en controleert de geldigheidsperiode tegen de systeemtijd, aldus OpenSSL (officiële docs). Als alle schakels kloppen, ziet u CN = server.domain.com: OK.

Meer bronnen: Capy Toolkit (RFC-based validatie) en uitleg van Google Apigee (Google API-platform).

Het patroon: Een keten die fout is, kan vaak door een eenvoudig commando worden gevonden. Het is een kwestie van de juiste bestanden samenvoegen alsof het een lijst is.

Hoe los ik self_signed_cert_in_chain op?

Deze fout treedt op als de server een keten stuurt met een certificaat dat zelf-ondertekend is en de browser de ondertekenaar van dat certificaat niet vertrouwt.

Oplossingen

1. Controleer de ketenvolgorde met openssl s_client -connect host:443 -showcerts.
2. Zorg dat de keten eindigt op een root die in het truststore van uw OS of browser staat.
3. Voeg ontbrekende tussenliggende certificaten toe.
4. Gebruik online checkers om de fout te vinden.

Verwijder het zelf-ondertekende certificaat en genereer de keten met de juiste intermediates.

Het patroon: Over het algemeen is de fout een van de makkelijkste om op te lossen, maar het is een teken dat uw configuratie faalt. Het impliceert dat de keten niet correct is opgebouwd en dat de browser geen vertrouwenspad kan vinden.

Veelgestelde vragen

De essentie: Het correct opbouwen en valideren van een SSL-certificaatketen is een fundamentele taak voor elke webbeheerder. Een fout in de keten leidt onmiddellijk tot browserwaarschuwingen en verlies van vertrouwen bij bezoekers. Door de volgorde, validatie en veelvoorkomende fouten te begrijpen, kunt u uw website veilig en betrouwbaar houden.