De implementatie van digitale certificaten en PKI is de afgelopen jaren ingrijpend veranderd. Certificaten zijn niet langer synoniem met SSL/TLS; conformiteitseisen zoals sterkere verificatievereisten en regelgeving voor digitale handtekeningen (bijv. eIDAS) hebben de rol van PKI in bedrijven aanzienlijk uitgebreid.

Aangezien het gebruik van PKI is toegenomen, gaat het niet langer enkel over het aantal en type van de benodigde certificaten, maar wordt er ook aandacht besteed aan aangepaste PKI-implementaties. Een groot deel van het gesprek gaat over ondergeschikte CA's, ook wel verlenende of tussenliggende CA's genoemd, en waarom een organisatie er zelf een zou willen. In dit artikel gaan we hier verder op in.

Wat zijn CA-hiërarchieën en waarom hebben we ze nodig?

Voordat we het over tussenliggende/ondergeschikte CA's hebben, is het waarschijnlijk een goed idee om uw kennis over CA-hiërarchieën even op te frissen. Zoals u weet zijn CA's entiteiten die digitale certificaten uitgeven, maar weinig mensen weten dat een CA eigenlijk uit een reeks CA's bestaat. Hoewel mensen naar een bedrijf als GlobalSign verwijzen als een publieke CA (enkelvoud), gaat het in werkelijkheid over meerdere CA's. Deze CA-hiërarchie creëert een vertrouwensketen waar alle certificaten van de eindentiteit op vertrouwen.

 

Voorbeeld van CA-hiërarchieën

• Het aantal niveaus tussen de certificaten van de root- en de eindentiteit en de algemene complexiteit van de hiërarchie kunnen sterk variëren, afhankelijk van de omgeving. Zo hebben een aantal van onze klanten in het IoT- en industriële internetruimte die identiteitscertificaten voor apparaten integreren in hun productieprocessen aangepaste hiërarchieën geïmplementeerd met wederzijds vertrouwen, afzonderlijke ondergeschikte CA's voor elke onderdeel in de toeleveringsketen, locatiespecifieke CA's en nog meer. Ongeacht hoe complex de hiërarchie is, deze bestaat altijd uit drie belangrijke componenten:

  • Root CA – de root CA is het hoogste niveau van de hiërarchie en dient als vertrouwensanker. Een eindentiteitscertificaat wordt pas vertrouwd als de root CA waaraan het gekoppeld is, ingesloten is in het besturingssysteem, de browser, het apparaat of een andere entiteit die het certificaat valideert. Root CA's zijn zwaar beveiligd en blijven offline (meer informatie hieronder).
  • Ondergeschikte CA's – deze bevinden zich tussen de root- en eindentiteitscertificaten en hun belangrijkste doel is de soorten certificaten definiëren en autoriseren die kunnen worden aangevraagd bij de root CA. In openbare hiërarchieën moet u bijvoorbeeld ondergeschikte SSL en S/MIME CA's scheiden. Een ander veelvoorkomend scenario is aparte ondergeschikte CA's voor verschillende locaties of één ondergeschikte CA voor certificaten met ECC-sleutels en één voor RSA-sleutels.

  Opmerking: er kunnen zich een of meerdere ondergeschikte CA's tussen een root CA en eindentiteitscertificaten bevinden. Onderschikte CA's die zich tussen de root CA en een andere ondergeschikte CA bevinden, worden soms tussenliggende CA's genoemd (zie de vertakking uiterst rechts in het bovenstaande schema).

  • Eindentiteitscertificaten – dit zijn de certificaten die zijn geïnstalleerd op servers, machines, cryptografische hardware en apparaten (bijv. SSL/TLS uitgegeven voor servers, code ondertekenen, clientcertificaten uitgegeven voor individuelen voor e-mailversleuteling, digitale ondertekening, authenticatie).

  Elke entiteit wordt ondertekend door de entiteit die zich een niveau hoger in de hiërarchie bevindt om de eerder vermelde vertrouwensketen te creëren. De root CA is zelf ondertekend en ondertekent alle ondergeschikte CA's die zich direct eronder bevinden. Deze ondertekenen op hun beurt de entiteiten onder hen, hetzij andere ondergeschikte CA's of de uiteindelijke eindentiteitscertificaten.

  U kunt deze hiërarchie in actie zien door de details van een certificaat te bekijken. Als u bijvoorbeeld naar een website gaat die SSL/TLS gebruikt (kijk naar HTTPS aan het begin van de adresbalk) en het certificaat bekijkt, ziet u het certificaatpad. In het onderstaande voorbeeld ziet u:

  • De root CA – "GlobalSign Root CA – R3".
  • Ondergeschikte CA – "GlobalSign Extended Validation CA – SHA256 – G3".
  • Eindentiteitscertificaat – www.globalsign.com

  

Voorbeeld van certificaatpad voor openbaar vertrouwd SSL/TLS-certificaat in Chrome.

Waarom hebben we CA-hiërarchieën nodig?

Waarom hebben we CA-hiërarchieën nodig?

U vraagt zich misschien af waarom we deze vertrouwensketen eigenlijk nodig hebben. Elke CA in de hiërarchie kan tenslotte certificaten uitgeven, dus waarom geven we geen certificaten uit vanaf de root? Waarom al deze aparte entiteiten?

Dat heeft te maken met wat er gebeurt als een CA gecompromitteerd wordt. Dat zou niet mogen gebeuren als de juiste controles worden uitgevoerd, maar als dit toch gebeurt, moeten de CA zelf en alles 'eronder' – alle ondergeschikte CA's en uitgegeven certificaten – worden ingetrokken. Dit is een behoorlijk groot probleem voor root CA's omdat deze, als vertrouwensankers, overal moeten worden gedistribueerd en ingevoegd. Om te zorgen dat nieuwe eindentiteitscertificaten opnieuw vertrouwd worden, moeten opnieuw aanvragen worden verstuurd naar de individuele rootprogramma's van Microsoft, Mozilla, Google, Apple (en de rest), wat behoorlijk veel tijd kan kosten. Als de root openbaar vertrouwd moet zijn, moet deze gedistribueerd worden naar elke browser, elk besturingssysteem, elk apparaat, elke console, elke e-mailclient, elke toepassingssuite enz. – een enorm lange lijst! Bovendien kan het updaten van roots die in de code van apparaten zijn vastgelegd of die niet op afstand toegankelijk zijn voor problemen zorgen (bv. Point of Sale-systemen, geldautomaten, netwerktelefoons enz.).

Daarom is de beste werkwijze eindentiteitscertificaten uitgeven vanaf de ondergeschikte CA's (en voor openbaar vertrouwde roots verbiedt het CA/Browser Forum het uitgeven van roots volledig). In het geval van een aantasting, beperkt u wat uiteindelijk moet worden ingetrokken en vervangen. Als een van uw ondergeschikte CA's gecompromitteerd is, hoeft u 'enkel' deze en de ondergeschikte certificaten in te trekken. Certificaten die zijn uitgegeven vanaf andere ondergeschikte CA's blijven onaangetast en hoeven niet opnieuw te worden gedistribueerd naar uw vertrouwensankers (i.e. root CA's). Dit is ook de reden voor de extreme veiligheidsmaatregelen rond root CA's en waarom deze offline moeten blijven – als er iets gebeurt met uw root CA, zorgt dat voor veel problemen. Deze mag alleen worden geactiveerd als u een nieuwe ondergeschikte CA of Certificate Revocation List (CRL) moet ondertekenen.

Waarom zou u uw eigen ondergeschikte CA willen?

U weet nu wat ondergeschikte of tussenliggende CA's zijn en wat hun plaats in de bredere CA-architectuur is. Nu gaan we het hebben over waarom organisaties hun eigen ondergeschikte CA willen – een toegewezen ondergeschikte CA op hun naam. Dit zijn enkele van de meest voorkomende redenen:

Cliënt Authenticatie

Certificaat-gebaseerde cliëntauthenticatie valideert certificaten vaak op basis van een ondergeschikte CA. Door een exclusieve ondergeschikte CA te hebben, kunt u beperken wie certificaten heeft die toegang verlenen tot een systeem. Deze ondergeschikte CA's kunnen privé of openbaar vertrouwd zijn, afhankelijk van de behoeften van de organisatie.

SSL-inspectie/decryptie

Om ervoor te zorgen dat apparaten voor SSL-inspectie de inhoud kan decoderen en opnieuw kan coderen, moeten deze wanneer nodig certificaten kunnen uitgeven. Dit betekent dat ze hun eigen ondergeschikte CA nodig hebben en dat deze niet openbaar vertrouwd mag zijn.

Lees onze gerelateerde blog voor meer informatie over ondergeschikte en root CA's voor SSL-inspectie.

Certificaten voor speciale toepassingen

Sommige certificaattypes, zoals SSL/TLS en EV Code Signing, worden gereguleerd door de Baseline Requirements van het CA/Browser Forum, waarin zaken zoals de geldigheidsperiode en sleutellengte zijn vastgelegd. Alle openbaar vertrouwde certificaten moeten aan deze richtlijnen voldoen. Certificaten die zijn uitgegeven onder privé hiërarchieën hoeven echter niet te voldoen aan deze vereisten en kunnen verouderde toepassingen en unieke configuraties ondersteunen, zoals langere geldigheidsperiodes en kortere sleutellengtes.

Opmerking: Als u alleen privé SSL/TLS-certificaten, maar geen toegewezen ondergeschikte CA, nodig heeft, biedt GlobalSign ook gedeelde (niet-toegewezen) privé vertrouwde certificaten aan via onze IntranetSSL-dienst.

Aangepaste profielen

U kunt een ondergeschikte CA zo configureren dat deze voldoet aan uw specifieke behoeften met betrekking tot uitgebreid sleutelgebruik, certificaatbeleid, CRL-distributie, kortdurende certificaten en meer.

Branding

Voor bedrijven die certificaten aanbieden aan hun eindklanten of deze bundelen in hun diensten, kan een toegewezen ondergeschikte CA op hun eigen naam bijkomende branding mogelijkheden bieden. We zien dit het vaakst bij organisaties die SSL/TLS-certificaten aan hun eindklanten aanbieden (bijv. hostingbedrijven, websiteontwikkelaars, e-commerce platformen) waar de aanwezigheid van hun eigen publiek vertrouwde ondergeschikte CA's betekent dat zij bestelpagina's en certificaten kunnen leveren.

Hoe uw eigen ondergeschikte CA realiseren – interne vs. gehoste PKI

Als uw eigen ondergeschikte CA de oplossing voor uw problemen is, is de volgende logische vraag hoe u dit kunt realiseren. Net zoals voor zoveel andere aspecten van technologie tegenwoordig, kunt u er zelf een creëren of een SaaS-oplossing gebruiken.

Als u openbaar vertrouwen nodig heeft, is deze discussie eigenlijk niet relevant – dan moet u met een openbare CA werken. Voor privé toepassingen, zoals eerder vermeld en andere toepassingen die uniek zijn voor het bedrijf, is een interne CA nog steeds een optie.

Waarom zou u uw eigen CA beheren?

In het verleden was het niet ongewoon dat grote bedrijven zelf PKI implementeerden, doorgaans met behulp van een Microsoft CA en Certificate Services. Naar de algemene doelstellingen die gelden voor de meeste discussies over doe-het-zelf versus SaaS, zoals meer controle en beveiliging, zijn een aantal van de PKI-specifieke motivaties:

• De mogelijkheid om verbinding te maken met Active Directory voor het automatisch registreren en op de achtergrond installeren van certificaten voor alle gebruikers en eindpunten die deel uitmaken van het domein – zo verliest u aanzienlijk minder tijd met het levenscyclusbeheer van certificaten.
• Het is gratis – Microsoft CA-diensten zijn inbegrepen bij Windows Enterprise Server, zodat u niet hoeft te betalen voor individuele certificaten en andere ondersteunende diensten.
• Ze hebben geen publiek vertrouwen nodig – uitgaande van het vorige punt: waarom zou een bedrijf betalen voor openbaar vertrouwde certificaten als ze niet-openbare certificaten gratis kunnen krijgen?
• Toegewezen ondergeschikte CA's – door uw eigen PKI te beheren, kunt u uw eigen ondergeschikte CA's aanmaken en zorgen dat alleen uw bedrijf er toegang toe heeft.

Nieuwe diensten van externe CA's hebben outsourcing tot een optie gemaakt

Ik zei eerder 'in het verleden' omdat er nog steeds veel bedrijven zijn die hun eigen interne CA's beheren en er nog steeds een aantal geldige redenen zijn om dit te doen, maar veel van de bovenstaande factoren zijn echter niet meer relevant dankzij de innovaties van openbare CA's. Integratie met Active Directory, andere automatiseringsmechanismen, de mogelijkheid om uw eigen ondergeschikte CA (openbaar vertrouwd of niet) te hebben – dit alles is nu beschikbaar via vele openbare CA's.

De verborgen kosten van interne PKI

Voor het geval dat u denkt dat ik de kostenfactor uit het oog ben verloren en iedereen aanraadt om het feit te negeren dat Microsoft CA's gratis zijn, is 'gratis' hier niet echt correct. Hoewel u niet hoeft te betalen voor MS CA-diensten of de certificaten, komt er veel meer kijken bij het beheren van uw eigen CA, wat de totale gebruikskosten aanzienlijk kan opdrijven.

U heeft bijvoorbeeld personeel nodig om de CA en hardware te beheren om uw root en ondertekeningssleutels op te slaan. Als u weet dat een enkele Hardware Security Module (HSM) 20.000 dollar kan kosten en u er meerdere nodig heeft voor redundantie, weet u dat deze verborgen kosten niet onbeduidend zijn.

Beveiligings- en PKI-overwegingen voor het beheer van uw eigen CA

Maar de belangrijkste overwegingen in de discussie over interne vs. gehoste PKI zijn voor mij de beveiliging van de infrastructuur, de beschikbaarheid en het bijhouden van de basiseisen. Wanneer u uitbesteedt, moet de openbare CA dit allemaal regelen en kunt u zich concentreren op uw kernactiviteiten. Als u het intern wilt regelen, moet u rekening houden met het volgende:

• hoe u uw offline root beschermt en opslaat;
• een CRL- en OCSP-intrekkingsinfrastructuur creëren en beheren;
• een noodherstelplan om de activiteiten te herstellen;
• beleid voor levenscyclusbeheer en procedure om ervoor te zorgen dat alleen geautoriseerde gebruikers toegang hebben, certificaten niet verlopen en uw hiërarchie correct wordt onderhouden;
• hoe u kunt voldoen aan de verschillende controles van netwerkvereisten en rootprogramma's (als u openbaar vertrouwen nodig heeft) en hoe u de naleving van de verschillende netwerkvereisten kunt handhaven.

Als u wilt zien hoe de beveiligingsinfrastructuur van GlobalSign werkt, klikt u hier.

Dit alles betekent: als u uw eigen interne CA wilt beheren, ga dan zeker uw gang! Maar wees u bewust van alles wat hierbij komt kijken en weet dat er externe CA's bestaan die u kunnen helpen uw doelstellingen te bereiken (zoals automatisering, integratie met Active Directory, persoonlijke hiërarchieën, aangepaste certificaatprofielen, gehoste intrekkingsservices, toegewezen ondergeschikte CA's, enz.) zonder dat u zelf moet instaan voor het PKI-beheer.

In het bijzonder, moet u vooral weten dat als u voor toegewezen ondergeschikte CA's kiest (openbaar of privé, voor een of meerdere van de bovenliggende redenen), er gehoste opties bestaan! U hoeft geen PKI-expert te zijn om PKI te gebruiken; u hoeft alleen maar te weten met wie u kunt praten.

Als u een toegewezen ondergeschikte CA en/of interne PKI overweegt voor de eerder besproken toepassingen, moet u weten dat uitbesteding aan een externe CA een optie is. CA's en vertrouwensankers beheren, zowel openbaar als privé, is wat wij doen – wij nemen het u graag uit handen. Neem contact met ons op als u vragen heeft.