Certificaatketen

Het pad van een certificaat via intermediates naar een vertrouwensanker, en wat padvalidatie per schakel controleert: geldigheid, gebruik en intrekking.

De geordende reeks certificaten die loopt van het certificaat dat je voor je hebt, via een of meer intermediates, naar een vertrouwensanker dat je al accepteert. Aan een X.509-certificaat is op zichzelf niets te vertrouwen: het wordt vertrouwd omdat er een keten naar een bekend anker te bouwen en te controleren is.

Een keten controleren is meer dan handtekeningen volgen. Per schakel controleert een validator de handtekening, de geldigheidsduur, het toegestane sleutelgebruik, eventuele naamsbeperkingen en de intrekkingsstatus via een CRL of OCSP - de regels voor padvalidatie uit RFC 5280. Beide staan daar nog in, maar ze zijn in de praktijk niet meer gelijkwaardig: het CA/Browser Forum maakte publicatie van een CRL verplicht en het draaien van een OCSP-responder optioneel, en Let's Encrypt zette zijn responders in augustus 2025 uit en publiceert intrekking nu alleen nog als CRL. Bouw dus een validator die een CRL kan lezen; zie een OCSP-antwoord als extra, niet als de bron waarop je leunt. Een dienst voor handtekeningvalidatie rapporteert het resultaat per schakel, en daarom is een validatierapport langer dan ja of nee.

Wat in de gekwalificeerde wereld anders is, is waar de keten eindigt. Een browser eindigt in zijn eigen rootstore; een gekwalificeerde controle eindigt bij de EU-vertrouwenslijst, want daar zegt een lidstaat welke QTSP onder toezicht stond en voor welke dienst. Intermediates bestaan om de root uit het dagelijks gebruik te houden: de rootsleutel komt tevoorschijn voor een sleutelceremonie en gaat weer offline, en de intermediate geeft uit. Het gevolg is operationeel en niet cryptografisch: een verlopen intermediate, een ingetrokken uitgevende CA of een certificaat dat niet meer verwijst naar waar zijn uitgever te vinden is, breekt de validatie van alles eronder.