Een soevereine PKI on-premise certificate authority is een volledig intern beheerde infrastructuur waarmee een organisatie zelf digitale certificaten uitgeeft, beheert en intrekt, zonder afhankelijkheid van externe commerciële of hyperscaler-gehoste vertrouwensankers. Voor gereguleerde organisaties in de overheid, zorg en rechtspraktijk is dit onderscheid geen luxe maar een compliancevereiste.
Waarom externe certificate authorities een soevereiniteitsrisico vormen
Wie certificaten betrekt van een commerciële CA die onder Amerikaans recht valt, stelt zich bloot aan de reikwijdte van de CLOUD Act (18 U.S.C. § 2713) en de Foreign Intelligence Surveillance Act. Die wetgeving kan Amerikaanse autoriteiten het recht geven metadata en sleutelinformatie op te vragen, ook als de infrastructuur fysiek buiten de VS staat.
Hyperscalers zoals Microsoft (via Azure Key Vault) en AWS (via ACM) bieden managed CA-diensten aan, maar de beleidscontrole, de auditlogs en de ultieme beschikking over de rootsleutel liggen dan buiten de organisatie. Voor entiteiten die vallen onder de BIO2 (Baseline Informatiebeveiliging Overheid versie 2) of NEN 7510 is dat onverenigbaar met de vereiste dat sleutelbeheer aantoonbaar en controleerbaar in eigen hand blijft.
Daarnaast introduceert afhankelijkheid van een externe CA operationele risico’s: als de CA een intrekkingsevent afkondigt, een rootcertificaat depreceert of haar diensten beëindigt, worden alle uitgereikte certificaten onvertrouwd. In 2023 ondervonden tientallen Europese organisaties uitval nadat een commerciële CA onverwachts een intermediaire root roteerde.
Een on-premise PKI-hiërarchie opzetten met open-source tooling
De basisarchitectuur van een interne PKI bestaat uit minimaal twee lagen: een offline root CA en een of meer online intermediate CA’s die de dagelijkse uitgifte verzorgen.
Keuze van open-source CA-software
Drie volwassen open-source oplossingen zijn beschikbaar voor gereguleerde omgevingen:
| Product | Sterkste toepassing | Compliance-voordelen |
|---|---|---|
| EJBCA (Keyfactor) | Complexe, multi-tier PKI voor overheid en zorg | Ondersteunt ETSI EN 319 411, eIDAS, HSM-integratie |
| Step CA (Smallstep) | Geautomatiseerde uitgifte via ACME, DevOps-omgevingen | ACME-protocol, JWK, korte certificaatlevensduur |
| OpenXPKI | Enterprise-hiërarchieën met complexe policy-workflows | Workflow-engine voor CP/CPS-afdwinging, auditlogs |
Beveiliging van de root CA
De root CA mag nooit permanent online zijn. De industrie-standaard, vastgelegd in NIST SP 800-57 Part 1 (sleutelbeheer), schrijft voor dat de privésleutel van een root CA wordt opgeslagen in een FIPS 140-2 Level 3 of hoger gecertificeerde Hardware Security Module (HSM). De fysieke toegang tot de HSM en het omgevende systeem moet gelogd, bewaakt en geauditeerd worden via een vier-ogen-principe. Na het uitreiken van de intermediate CA-certificaten wordt de root CA air-gapped bewaard, met de HSM in een kluis die voldoet aan minimaal Klasse III fysieke beveiliging.
Het Certificate Policy (CP) en het Certification Practice Statement (CPS) zijn geen optionele documentatie maar operationele vereisten. ETSI EN 319 411, de Europese norm voor CA-operaties, vereist dat elke CA een gepubliceerd en geauditeerd CPS heeft. Zonder deze documenten voldoet een interne PKI formeel niet aan de kwalificatievereisten voor gebruik in hoge-betrouwbaarheidstoepassingen.
Normatieve eisen: NIS-2, BIO2, NEN 7510 en ETSI
Meerdere normen stellen concrete eisen aan de betrouwbaarheid van interne PKI-infrastructuur, elk vanuit een andere invalshoek.
De NIS-2-richtlijn (EU 2022/2555), geïmplementeerd in Nederland via de Cyberbeveiligingswet, verplicht organisaties in essentiële en belangrijke sectoren tot risicogebaseerde beveiligingsmaatregelen voor netwerk- en informatiesystemen. Certificaatbeheer valt expliciet onder de vereiste “integriteitsmaatregelen voor de supply chain” (artikel 21). Organisaties moeten aantonen dat de herkomst en betrouwbaarheid van cryptografische componenten controleerbaar is.
BIO2 schrijft in de beheersmaatregelen rond cryptografie voor dat sleutelbeheer uitsluitend plaatsvindt met goedgekeurde algoritmen en sleutellengtes, en dat de sleutellevenscyclus volledig gedocumenteerd en auditeerbaar is. Een extern gehoste CA waarbij de auditlogs niet volledig toegankelijk zijn voor de eigen organisatie, voldoet hier niet aan.
NEN 7510 (informatiebeveiliging in de zorg) sluit aan bij ISO/IEC 27001 maar voegt sectorspecifieke eisen toe voor de beschikbaarheid en integriteit van systemen die patiëntgegevens verwerken. De norm vereist dat toegang tot systemen cryptografisch authenticeerbaar is en dat certificaten tijdig worden verlengd, met een aantoonbaar proces voor intrekking.
“Organisaties moeten nu beginnen met de inventarisatie van hun cryptografische assets. Wie wacht tot kwantumcomputers operationeel zijn, is te laat.” (Lydia Kostopoulos, Senior Advisor Emerging Technology, publiek geciteerd tijdens BSidesLV)
Stapsgewijze migratie van externe naar soevereine PKI
Een migratie verloopt in vijf herkenbare fasen, waarbij elke fase zijn eigen risico’s en beslissingspunten heeft.
Fase 1: Inventarisatie. Breng alle bestaande certificaten in kaart, inclusief de uitgevende CA, vervaldatum, sleutelalgoritme en het systeem waarop het certificaat is geïnstalleerd. Tools zoals Keyfactor Command, OpenSSL-scripts of EJBCA’s discovery-module bieden hier ondersteuning.
Fase 2: PKI-ontwerp en beleidsdocumentatie. Stel het CP en CPS op voordat de eerste technische component live gaat. Bepaal de hiërarchie (twee of drie lagen), de geldigheidsperiodes per certificaattype en de naamgevingsconventies voor subjects.
Fase 3: Technische opbouw. Installeer de root CA in een air-gapped omgeving met HSM. Genereer de rootsleutel, onderteken de root CA zelf en geef de intermediate CA-certificaten uit. Breng de intermediate CA online en configureer OCSP en CRL-distributiepunten.
Fase 4: Uitrol van vertrouwen. Distribueer het root CA-certificaat naar alle endpoints, browsers, besturingssystemen en applicaties via Group Policy (Windows), MDM of Ansible/Puppet. Zonder dit stap zullen interne certificaten als onbetrouwbaar worden gemarkeerd.
Fase 5: Gefaseerde vervanging. Vervang externe certificaten per applicatiecluster, te beginnen met interne systemen zonder publieke toegang. Handhaaf tijdelijk een parallelle werking waarbij externe certificaten nog geldig zijn totdat alle interne vertrouwensdistributie is bevestigd.
“Een interne PKI zonder formele beleidsstructuur (CP/CPS) is geen PKI maar een sleutelrommela. Beleid en techniek moeten samen ontworpen worden.” (Jan Schaumann, Senior Systems Engineer en PKI-specialist, USENIX LISA)
Post-quantum cryptografie en de impact op interne PKI
De PQC-transitie is geen toekomstige zorg maar een huidige planningsverplichting. NIST publiceerde in 2024 de definitieve standaarden voor drie kwantumveilige algoritmen: ML-KEM (CRYSTALS-Kyber), ML-DSA (CRYSTALS-Dilithium) en SLH-DSA (SPHINCS+). Organisaties die nu langlevende sleutelparen genereren, riskeren dat die sleutels retrograde ontsleuteld worden zodra krachtige kwantumcomputers beschikbaar zijn, een aanvalsvector die bekend staat als “harvest now, decrypt later”.
De aanbevolen aanpak is een hybride certificaatstrategie: combineer een klassiek algoritme (ECDSA P-256 of RSA-2048) met een PQC-algoritme in hetzelfde certificaat. Zo blijven systemen die nog geen PQC ondersteunen functioneren, terwijl kwantumveiligheid al wordt geboden aan systemen die het wel begrijpen. EJBCA ondersteunt hybride certificaatuitgifte al in recente versies. Step CA biedt experimentele PQC-ondersteuning via externe crypto-providers.
Statistiek: NIST verwacht dat organisaties uiterlijk rond 2030 hun cryptografie volledig moeten hebben gemigreerd om retrograde ontsleuteling te beperken (NIST PQC-standaardisatieproject, 2024).
Certificaatlevenscyclus, intrekking en verlenging in een soevereine omgeving
Het beheer van certificaatlevenscycli in een air-gapped of semi-offline omgeving vraagt om expliciete procedureafspraken, omdat de automatiseringsmogelijkheden beperker zijn dan in een volledig online hyperscaler-omgeving.
Statistiek: Organisaties zonder geautomatiseerd certificaatbeheer ervaren gemiddeld 4 tot 5 niet-geplande uitval-incidenten per jaar door verlopen certificaten (Ponemon Institute / Keyfactor State of Machine Identity Report 2023).
Voor intrekking zijn twee mechanismen beschikbaar: de Certificate Revocation List (CRL) en het Online Certificate Status Protocol (OCSP). In een air-gapped root CA-omgeving is realtime OCSP niet uitvoerbaar vanuit de root zelf. De gangbare oplossing is een periodiek bijgewerkte CRL, die via een gecontroleerd proces (een ondertekende, geïsoleerde data-overdracht) naar een online CRL Distribution Point wordt overgebracht. De intermediate CA kan wel een live OCSP-responder aanbieden omdat die semi-online staat.
Statistiek: Meer dan 80% van de onderzochte datalekken in 2023 had een verband met misbruikte inloggegevens of sleutels (IBM Cost of a Data Breach Report 2023). Correct certificaatbeheer, inclusief tijdige intrekking, is een directe risicoreductiemaatregel.
Automatische verlenging via het ACME-protocol (ondersteund door Step CA en EJBCA) vermindert het risico op menselijk verzuim. Zelfs in een gereguleerde omgeving is ACME intern inzetbaar voor servers en services, mits de CA zelf goed beveiligd is. Kortlevende certificaten (24 tot 72 uur) in combinatie met ACME elimineren de noodzaak voor handmatige verlenging en verminderen de vensters waarbinnen een gecompromitteerd certificaat schade kan aanrichten.
Veelgestelde vragen
Mag een overheidsorganisatie certificaten van een Amerikaanse commerciële CA gebruiken voor interne systemen?
Juridisch is dat in veel gevallen mogelijk, maar de CLOUD Act (18 U.S.C. § 2713) verplicht Amerikaanse bedrijven onder bepaalde omstandigheden gegevens af te staan aan de Amerikaanse overheid, ook als die buiten de VS zijn opgeslagen. Voor systemen met bijzondere persoonsgegevens of staatsgeheimen raadt BIO2 een volledig interne of Europese PKI-oplossing aan.
Wat is het verschil tussen een root CA en een intermediate CA in een interne PKI-hiërarchie?
De root CA vormt het vertrouwensanker en wordt na uitgifte van de intermediate CA offline bewaard, bij voorkeur air-gapped in een HSM. De intermediate CA verzorgt de dagelijkse certificaatuitgifte en staat wel online. Als de intermediate CA gecompromitteerd raakt, blijft de root CA onaangetast en kan een nieuwe intermediate CA worden uitgegeven.
Welke open-source tooling is het meest geschikt voor een overheids- of zorgomgeving?
EJBCA biedt de meest uitgebreide ondersteuning voor ETSI EN 319 411 en eIDAS, wat het geschikt maakt voor gereguleerde omgevingen met hoge compliance-eisen. Step CA is lichter en DevOps-vriendelijk voor geautomatiseerde uitgifte via ACME. OpenXPKI richt zich op enterprise-hiërarchieën met complexe beleidsworkflows. De keuze hangt af van de complexiteit van de hiërarchie en de mate van automatisering die gewenst is.
Wanneer moet een organisatie beginnen met het uitrollen van post-quantum certificaten?
Voor langlevende certificaten en sleutelparen, langer dan vijf jaar, is het verstandig nu al hybride certificaten te overwegen die zowel een klassiek als een PQC-algoritme bevatten. Zo blijft backward compatibility gewaarborgd terwijl de migratie al begint. NIST adviseert volledige migratie uiterlijk rond 2030.
Hoe organiseer je certificaatintrekking in een air-gapped PKI-omgeving?
In een air-gapped omgeving is realtime OCSP vanuit de offline root CA niet uitvoerbaar. De gangbare aanpak is een periodiek bijgewerkte CRL die via een gecontroleerd datadragerproces naar een online distributiepunt wordt overgebracht. Voor de intermediate CA, die semi-online is, kan wel een OCSP-responder actief zijn. De maximale intrekkingsvertraging moet gedocumenteerd worden in het CPS.
