Certificaatautoriteiten

Inleiding: De noodzaak van certificeringsinstanties

In eerdere artikelen hebben we gezien hoe digitale certificaten zijn een van de fundamentele bouwstenen van Publieke Sleutel Infrastructuur (PKI)Certificaten worden op meerdere manieren gebruikt: voor het vaststellen van de identiteit, voor het mogelijk maken van veilige webcommunicatie of voor het bewijzen van het eigendom en de integriteit van software door middel van code ondertekening.
De hamvraag is echter: hoewel het certificaat helpt de betrouwbaarheid van andere informatie (zoals identiteit of eigendomsbewijs van software) vast te stellen, wie staat er in voor de betrouwbaarheid van de informatie in het certificaat zelf? Hoe weet een gebruiker of een certificaat betrouwbaar is en of de openbare sleutel in het certificaat daadwerkelijk toebehoort aan de aangegeven eigenaar?

Hier komt een certificeringsinstantie (CA) in beeld. De CA is een entiteit die digitale certificaten uitgeeft, maar doet dit pas na een reeks validaties van de organisatie die het digitale certificaat aanvraagt ​​– bijvoorbeeld door te bevestigen dat de organisatie daadwerkelijk de eigenaar is van de publieke sleutel die in het digitale certificaat wordt opgenomen.

Voorbeelden van bekende certificeringsinstanties zijn Comodo, Symantec, GoDaddy, GlobalSign, DigiCert, Let's Encrypt en Entrust. certificeringsinstanties vormen de kern van PKI als vertrouwde derde partij: ze worden vertrouwd door zowel de certificaataanvragers als de gebruikers (apparaten, besturingssystemen, browsers) die het certificaat ontvangen en beslissen of ze de transactie al dan niet willen voortzetten.

Kort antwoord: Wat is een certificeringsinstantie?

Een certificeringsinstantie (CA) is een vertrouwde derde partij die digitale certificaten uitgeeft na verificatie van de identiteit van de aanvrager. CA's voeren domein-, organisatie- of uitgebreide validatie uit, ondertekenen certificaten met hun privésleutel en onderhouden een vertrouwenshiërarchie die is gebaseerd op een vertrouwd basiscertificaat. Browsers en besturingssystemen vertrouwen CA's die voldoen aan de beveiligingsnormen van het CA/Browser Forum en kunnen het vertrouwen intrekken van CA's die hier niet aan voldoen.

Samenvatting

Certificeringsinstanties (CA's) zijn de vertrouwde derde partijen die PKI mogelijk maken: ze valideren aanvragers en ondertekenen de certificaten waarmee gebruikers een publieke sleutel kunnen vertrouwen. Dit artikel behandelt wat een CA doet, de vier kernfuncties van het ontvangen van een CSR tot het intrekken van certificaten, de drie validatieniveaus (DV, OV, EV), hoe vertrouwenshiërarchieën en rootcertificaten het hele systeem verankeren, waarom de beveiliging van CA's zo belangrijk is en de rol van het CA/Browser Forum bij het vaststellen van branchebrede standaarden. Het bevat ook een praktische verklarende woordenlijst en een beslissingstabel om CA-concepten te begrijpen en hoe dit verband houdt met breder certificaatlevenscyclusbeheer.

Wie zou zich moeten bekommeren om certificeringsinstanties?

De manier waarop certificeringsinstanties (CA's) certificaten valideren en uitgeven, raakt de PKI-werking, de beveiligingsarchitectuur, het platformbeheer en de naleving van regelgeving. Hieronder wordt beschreven wat elke rol zou moeten doen.

PKI-beheerders

Weet welk validatieniveau (DV, OV of EV) elke certificaataanvraag vereist en houd elke CA-relatie bij waarvan de organisatie afhankelijk is, zodat geen enkele certificeringsinstantie onbeheerd blijft.

Beveiligingsarchitecten

Ontwerp een PKI-architectuur rondom vertrouwenshiërarchieën en de plaatsing van rootcertificaten, en evalueer de beveiligingsstatus van een CA, inclusief het gebruik van HSM's, voordat u erop vertrouwt voor de uitgifte van certificaten.

Platformteams

Zorg ervoor dat de root- en tussenliggende certificaten actueel zijn in de besturingssystemen van apparaten en browsers, en reageer onmiddellijk als het rootcertificaat van een certificeringsinstantie ooit uit een vertrouwensarchief wordt verwijderd.

Compliance

Bevestig dat de certificaten die worden gebruikt voor gereguleerde transacties voldoen aan het validatieniveau dat vereist is volgens het beleid, en documenteer dat de gebruikte certificeringsinstanties voldoen aan de basisvereisten van het CA/Browser Forum.

CISO's

Beschouw het vertrouwen in certificeringsinstanties als een fundamenteel risico: een gecompromitteerde of niet-vertrouwde certificeringsinstantie kan elk certificaat dat zij heeft uitgegeven ongeldig verklaren. Zorg er daarom voor dat organisaties inzicht hebben in welke certificeringsinstanties zij daadwerkelijk vertrouwt.

Waarom dit belangrijk is: data en deadlines

Volgens de Trust Pulse Survey van DigiCert (2 juli 2025) heeft bijna de helft van de bedrijven het afgelopen jaar te maken gehad met een storing die verband hield met certificaten. 18.5% van de getroffen organisaties meldde verliezen van meer dan $ 250,000, waarvan 37.5% specifiek te wijten was aan verlopen certificaten. Elk certificaat dat door een certificeringsinstantie (CA) wordt uitgegeven, is onderhevig aan ditzelfde vervalrisico, ongeacht het validatieniveau.

Het voorstel SC-081v3 van het CA/Browser Forum, goedgekeurd op 11 april 2025, verlaagt de maximale geldigheidsduur van openbare TLS-certificaten gefaseerd naar 200 dagen vanaf 15 maart 2026, 100 dagen vanaf 15 maart 2027 en 47 dagen vanaf 15 maart 2029. Dit heeft directe gevolgen voor de frequentie waarmee organisaties met hun certificeringsinstanties (CA's) moeten communiceren voor heruitgifte, waardoor relatiebeheer en automatisering met CA's steeds belangrijker worden.

NIST heeft op 13 augustus 2024 de definitieve post-kwantumcryptografiestandaarden FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA) vastgesteld. Certificeringsinstanties (CA's) zullen deze nieuwe ondertekeningsalgoritmen moeten ondersteunen naarmate organisaties migreren, waardoor de crypto-flexibiliteitsroadmap van een CA een steeds belangrijker selectiecriterium wordt.

Functies van een CA

De functies van een typische CA omvatten het ontvangen van aanvragen voor digitale certificaten, het verwerken van deze aanvragen, inclusief het uitvoeren van achtergrondcontroles van de aanvragers, het goedkeuren en afwijzen van de aanvragen, het daadwerkelijk uitgeven van de certificaten en het beheren en intrekken van certificaten. Deze worden hieronder toegelicht.

1. Ontvang een Certificate Signing Request (CSR):De aanvrager die een digitaal certificaat nodig heeft, genereert een openbaar-privé sleutelpaar en stuurt de openbare sleutel naar de CA, samen met de basisinformatie die de CA nodig heeft om het certificaat uit te geven.
2. Verwerk de informatie in het CSR: De CA verwerkt de informatie in het CSR, inclusief het benodigde certificaattype en de gegevens van het aanvragende bedrijf. Afhankelijk van het benodigde certificaattype voert de CA een reeks validaties uit, zoals beschreven in de volgende sectie.
3. Goedkeuren/afwijzen van de CSR en uitgeven van het certificaat: Zodra de validaties zijn voltooid, geeft de CA het certificaat uit. De CA ondertekent het certificaat met zijn privésleutel, waarmee een 'stempel van echtheid' wordt afgegeven voor het certificaat en de publieke sleutel van de certificaathouder.
4. Certificaten beheren en intrekkenDe CA beheert ook certificaten – bijvoorbeeld door verlopen certificaten te verlengen op basis van verzoeken van certificaathouders. Indien de privésleutel van een certificaathouder wordt gecompromitteerd, kan de CA een certificaat ongeldig verklaren of intrekken. Intrekking helpt gebruikers te waarschuwen dat het certificaat niet langer vertrouwd kan worden en helpt de impact van een inbreuk te beperken.

Validaties uitgevoerd door een CA

Elke CA voert een reeks validaties uit voordat certificaten worden uitgegeven. De volgende typen validaties worden uitgevoerd:

• Domeinvalidatie (DV): Hierbij wordt gecontroleerd of de organisatie (of persoon) die een digitaal certificaat (voor een domein) aanvraagt, daadwerkelijk de eigenaar is (of de eigenaar vertegenwoordigt) van de domeinnaam. In dit geval worden geen identiteitscontroles uitgevoerd.
• Organisatie validatie (OV):Hieronder vallen aanvullende controles (naast het verifiëren van het domeinnaameigendom), zoals het valideren van de organisatie zelf en het controleren of de aanvrager door de organisatie is gemachtigd om een ​​certificaat aan te vragen.
• Uitgebreide validatie (EV):Hierbij worden de hoogste niveaus van validatie uitgevoerd, waaronder een gedetailleerde screening van het bedrijf dat het certificaat aanvraagt, waarbij onder meer de geregistreerde naam van het bedrijf, de vestigingsplaats en andere juridische gegevens worden gecontroleerd.

Vertrouwenshiërarchieën en rootcertificaten

Elke CA heeft een hoofdcertificaat, een zogenaamd vertrouwd rootcertificaat. Dit certificaat is het bovenliggende certificaat van alle digitale certificaten die door die CA worden uitgegeven en vormt de ultieme vertrouwensbasis in de CA zelf. Rootcertificaten zijn doorgaans vooraf geïnstalleerd in het besturingssysteem van het apparaat en in browsers. Rootcertificaten worden gebruikt om tussenliggende certificaten te creëren. Deze tussenliggende certificaten worden door de CA gebruikt om de digitale certificaten die door de CA worden uitgegeven, daadwerkelijk te ondertekenen.

Deze "ketening" van certificaten aan een bovenliggend certificaat, helemaal teruggaand tot aan het rootcertificaat van die CA, staat ook bekend als een vertrouwenshiërarchie of certificaathiërarchie. Deze hiërarchische aanpak is nuttig om de PKI-infrastructuur als geheel op te schalen – waarbij een bovenliggende CA andere CA's machtigt om certificaten uit te geven door het rootcertificaat van de andere CA te ondertekenen. Indien nodig kunnen certificaten die door de andere CA zijn uitgegeven, worden herleid tot het rootcertificaat van de bovenliggende CA.

CA-beveiliging

Omdat de certificeringsinstantie (CA) en haar rootcertificaat de basis vormen voor het vertrouwen in de gehele PKI-infrastructuur, moeten CA's aanzienlijk hogere beveiligingsniveaus hanteren dan andere organisaties. Dit omvat fysieke en logische beveiligingsmaatregelen, evenals het gebruik van hardwarebeveiligingsmodules (HSM's) voor sleutelbeheer. Indien een CA niet voldoet aan de verwachte beveiligingsnormen, of deze zelfs overtreft, kan het rootcertificaat door browsers, besturingssystemen en apparaatfabrikanten uit de systeemrepository worden verwijderd.

Dit resulteert in een onmiddellijke waarschuwing aan de eindgebruiker dat het certificaat voor de huidige transactie niet betrouwbaar is en de gebruiker waarschijnlijk zal aanzetten om de transactie af te breken, met negatieve gevolgen voor de bedrijfsvoering tot gevolg. Om de beveiligingseisen waaraan een CA moet voldoen te standaardiseren, zijn brancheorganisaties zoals het CA/Browserforum opgericht.

CA / Browser Forum

Dit is een vrijwillige groep van certificeringsinstanties (CA's) en browserleveranciers die samen een brancheorganisatie hebben opgericht met als doel richtlijnen te ontwikkelen voor CA-vertrouwenssystemen. Dit omvat aanbevelingen voor validatieprocedures, sleutellengtes, sleutelbeheer en encryptiealgoritmen . Twee belangrijke richtlijnen van het forum zijn de Baseline Requirements (BR's) en de Extended Validation (EV) Guidelines.

Basisvereisten zijn de basisregels waaraan elke CA zich moet houden bij het uitgeven van elk type digitaal certificaat. EV-richtlijnen bevatten aanvullende beveiligings-, technische en authenticatievereisten waaraan een CA moet voldoen om EV-certificaten uit te geven.

Woordenlijst van certificeringsinstanties

Korte, overzichtelijke definities van de termen die in dit bericht worden gebruikt.

Termijn	Definitie
Certificate Authority (CA)	Een vertrouwde derde partij die digitale certificaten uitgeeft na verificatie van de identiteit of het domeinbezit van de aanvrager.
Certificaatondertekeningsaanvraag (CSR)	Een verzoek met de publieke sleutel en identificatiegegevens van een aanvrager, ingediend bij een certificeringsinstantie (CA) om een ​​digitaal certificaat te verkrijgen.
Domeinvalidatie (DV)	Het meest basale validatieniveau van een certificeringsinstantie, waarbij alleen wordt bevestigd dat de aanvrager de domeinnaam beheert, zonder identiteitscontroles.
Organisatie validatie (OV)	Een CA-validatieniveau dat het bestaan ​​van de aanvragende organisatie en de bevoegdheid van de aanvrager om een ​​certificaat aan te vragen verifieert.
Uitgebreide validatie (EV)	Het hoogste validatieniveau van de CA, waarbij de aanvragende organisatie juridisch en zakelijk grondig wordt gescreend.
Vertrouwd rootcertificaat	Het mastercertificaat van een certificeringsinstantie (CA), dat vooraf is geïnstalleerd in besturingssystemen en browsers, vormt de basis voor het vertrouwen in elk certificaat dat de CA uitgeeft.
CA / Browser Forum	Een vrijwillige brancheorganisatie van certificeringsinstanties en browserleveranciers die basisvereisten en EV-richtlijnen vaststelt voor de uitgifte van certificaten.

Beslissingstabel van de certificeringsinstantie: concept, wanneer het ertoe doet, voorbeeld en implementatie

Concept	Als het er toe doet	Voorbeeld	Implementatieoverwegingen
Validatieniveau (DV/OV/EV)	Het kiezen van een certificeringsinstantie (CA) en certificaattype voor een publiek toegankelijke dienst.	Een bank vraagt ​​om een ​​EV-certificaat; een eenvoudige marketingwebsite gebruikt een DV-certificaat.	Stem het validatieniveau af op de gevoeligheid van de transactie, niet alleen op de kosten of de snelheid van uitgifte.
plaatsing in de vertrouwenshiërarchie	Het ontwerpen of auditeren van een PKI-architectuur met intermediaire CA's.	Een bedrijfsbrede root-CA ondertekent een intermediaire CA die alleen wordt gebruikt voor interne apparaatcertificaten.	Houd root-CA's offline en beveiligd; gebruik tussenliggende CA's voor de dagelijkse uitgifte van certificaten.
CA-beveiligingspositie	Het kiezen voor of blijven vertrouwen op een openbare of particuliere CA	Een certificeringsinstantie (CA) verliest het vertrouwen van browsers nadat deze niet voldoet aan de basisvereisten.	Evalueer het HSM-gebruik, de auditgeschiedenis en de naleving van de CA/Browser Forum-regels door een CA voordat u erop vertrouwt.
Certificaat intrekking	Er bestaat een vermoeden dat de privésleutel van een certificaat is gecompromitteerd.	Een CA trekt een certificaat in en publiceert dit naar een CRL- of OCSP-responder.	Controleer of de controle op intrekking is ingeschakeld op alle plaatsen waar het certificaat wordt gevalideerd.
Wijzigingen in de geldigheidsperiode	De frequentie van het vernieuwen van de planning wordt aangepast nu de regels van CA/Browser Forum de geldigheidsduur verkorten.	Een certificaat met een geldigheidsduur van 47 dagen moet veel vaker worden verlengd dan een certificaat met een geldigheidsduur van 200 dagen.	Automatiseer de uitgifte en verlenging van certificaten in plaats van te vertrouwen op handmatige interactie met de certificeringsinstantie.

Certificaatlevenscyclusbeheer en PKI-modernisering

Het beheren van relaties met een of meer certificeringsinstanties (CA's) is een essentieel onderdeel van elk PKI-moderniseringsprogramma . CertSecure Manager automatiseert het vinden, uitgeven en verlengen van certificaten bij meerdere CA's, inclusief certificaatautomatisering die gelijke tred houdt met de steeds korter wordende geldigheidsperioden.

Organisaties die een beheerde, in de cloud gehoste CA willen zonder die infrastructuur volledig in eigen beheer te hebben, kunnen vertrouwen op PKI-as-a-Service . Het opbouwen van een inventaris van machine-identiteiten en het uitvoeren van certificaatdetectie via CBOM Secure helpt bij het vinden van elk certificaat dat is uitgegeven door elke CA die al in uw omgeving in gebruik is. Het voltooien van een PQC- gereedheidsbeoordeling zorgt ervoor dat uw CA-relaties een migratiepad hebben naar cryptografische flexibiliteit en post-quantum handtekeningalgoritmen. Het PQC Center of Excellence van Encryption Consulting biedt begeleiding bij het plannen van die migratie.

Voor meer informatie over waarom certificaatautomatisering belangrijk is in de hele omgeving, raadpleegt u de artikelen in ons Educatiecentrum over de fasen in de levenscyclus van een certificaat en hoe u certificaatuitval kunt voorkomen . Zie ook de artikelen 'Waarom verlopen SSL-certificaten repareren?' en 'Inleiding tot certificaatverlenging – Basisbeperkingen' voor gerelateerde inhoud.

Het meten van succes en doorlopende audits

Houd bij op hoeveel certificeringsinstanties (CA's) de organisatie actief vertrouwt, of elk voldoet aan het door het beleid vereiste validatieniveau en hoe snel een ingetrokken of verlopen certificaat kan worden vervangen. Controleer de vertrouwensrelaties met CA's en de certificaatinventarissen regelmatig, elk kwartaal voor beleidsmatige factoren zoals de geldigheidseisen van CA's/Browser Forums, en continu voor het verlopen van certificaten, zodat vertrouwen in een CA nooit wordt aangenomen in plaats van geverifieerd.

Laatst bijgewerkt: augustus 2026. Laatst geverifieerd: augustus 2026. Dit bericht wordt volgens een halfjaarlijks updateschema bijgewerkt als een actuele uitleg van de basisprincipes van certificeringsinstanties, met kwartjaarlijkse controles op de veranderende geldigheid van certificaten en het beleid van CA's/browserforums.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie van het rapport 'Certificeringsinstanties'?

Een certificeringsinstantie is de vertrouwde derde partij die PKI betrouwbaar maakt: zij valideert aanvragers, geeft ondertekende certificaten uit en verankert het vertrouwen via een rootcertificaat dat door browsers en besturingssystemen wordt herkend.

Waarom is dit belangrijk voor PKI-teams binnen bedrijven?

PKI-teams moeten voor elk certificaat het juiste validatieniveau selecteren en de beveiligingsstatus van elke CA waarvan ze afhankelijk zijn, bewaken, aangezien een niet-vertrouwde CA elk certificaat dat ze heeft uitgegeven ongeldig kan verklaren.

Welke risico's nemen toe als dit onderwerp handmatig wordt behandeld?

Het handmatig beheren van CA-relaties vergroot het risico dat een validatiefout over het hoofd wordt gezien, dat een verslechterende beveiligingsstatus van een CA niet wordt opgemerkt of dat een certificaatvernieuwing wordt gemist naarmate de geldigheidsperioden korter worden.

Welke teams zouden verantwoordelijk moeten zijn voor deze verandering?

Beveiligingsarchitecten ontwerpen vertrouwenshiërarchieën en evalueren de beveiliging van certificeringsinstanties, platformteams zorgen ervoor dat root- en tussenliggende certificaten actueel blijven, PKI-beheerders volgen de validatieniveaus en relaties met certificeringsinstanties, en compliance-teams bevestigen dat de validatieniveaus voldoen aan het beleid.

Hoe houdt dit verband met certificaatlevenscyclusbeheer?

Elk certificaat dat een certificeringsinstantie (CA) uitgeeft, vereist dezelfde procedures voor ontdekking, verlenging en intrekking. Door CA-relaties te behandelen als onderdeel van één programma voor certificaatlevenscyclusbeheer, wordt voorkomen dat een certificaat over het hoofd wordt gezien.

Hoe moeten organisaties succes meten?

Houd bij op hoeveel certificeringsinstanties (CA's) de organisatie actief vertrouwt, of elk ervan voldoet aan het vereiste validatieniveau en hoe snel een ingetrokken of verlopen certificaat kan worden vervangen.

Wat moet er regelmatig gecontroleerd of gemonitord worden?

Controleer regelmatig de vertrouwensrelaties van certificeringsinstanties en de certificaatinventarissen op alle validatieniveaus, en bevestig dat de controle op intrekking is ingeschakeld waar certificaten worden gevalideerd.

Welke invloed heeft dit onderwerp op cloud-, hybride- of multi-CA PKI-oplossingen?

Organisaties die meerdere certificeringsinstanties (CA's) gebruiken in zowel cloud- als on-premises omgevingen, hebben behoefte aan gecentraliseerd inzicht in elke gebruikte vertrouwenshiërarchie. Een certificaat van een niet-getraceerde CA kan immers net zo goed ongemerkt verlopen of worden ingetrokken.

Welke veelgemaakte fouten moeten teams vermijden?

Veelgemaakte fouten zijn onder andere het gebruik van een lager validatieniveau dan een transactie rechtvaardigt, het niet monitoren van de voortdurende beveiligingsstatus van een CA en het niet automatiseren van de verlenging wanneer de geldigheidsperioden van de CA/Browser Forum korter worden.

Wat moet er elk kwartaal vernieuwd worden?

Controleer de validatievereisten aan de hand van de huidige transactiegevoeligheid, bevestig dat alle gebruikte CA's nog steeds voldoen aan de huidige basisvereisten van het CA/Browser Forum en controleer de geldigheidsperioden van de certificaten opnieuw aan de hand van het meest recente geldigheidsschema.