Private versus publieke CA's: misschien gebruik je de verkeerde

Voor een IT-team onder druk lijkt een publieke certificaatautoriteit (CA) vaak een hamer, en elke versleutelingseis een spijker. Maar een publieke CA voor elke klus gebruiken is een van de meest voorkomende manieren om de productie stilletjes onderuit te halen.

Waarvoor publieke CA's zijn gebouwd

Een publieke CA (zoals DigiCert, Sectigo of Let's Encrypt) is ontworpen voor één hoofdscenario: wanneer je vertrouwen moet opbouwen met apparaten die je niet zelf beheert. Het idee is dat externe gebruikers aan hun kant niets hoeven te configureren om je site of dienst te vertrouwen.

Een publieke CA is logisch wanneer:

• Je publiek toegankelijke diensten draait voor externe gebruikers, klanten of partners zonder bestaande vertrouwensrelatie met je organisatie
• Externe API's of diensten verbinding maken met je infrastructuur zonder aangepaste clientconfiguratie
• Certificaatfouten bij eindgebruikers als browserwaarschuwing zouden verschijnen
• Je e-mails ondertekent en ontvangers de handtekening moeten kunnen verifiëren zonder voorafgaande configuratie

Het CA/Browser Forum bepaalt wat publieke CA's mogen uitgeven. Je bent onderworpen aan regels waarover je geen controle hebt, wat voor veel organisaties een redelijke afweging is voor de scenario's hierboven. Een publieke CA kan een probleem worden zodra je diezelfde certificaten voor interne authenticatie gebruikt.

Waarvoor private CA's zijn gebouwd

Een private CA is er een die je zelf draait, of die je leverancier namens jou draait. Jij bepaalt het uitgiftebeleid. De certificaten worden nergens standaard vertrouwd. Je distribueert het rootcertificaat van je private CA naar je apparaten en gebruikers via Group Policy, Intune of je MDM-platform, en je beheerde endpoints vertrouwen de certificaten die je private CA uitgeeft.

Een private CA is de juiste keuze voor alles waarbij alleen je eigen infrastructuur het certificaat hoeft te vertrouwen:

• Apparaatauthenticatie, waarmee je aantoont dat een machine beheerd wordt en bij je organisatie hoort
• Authenticatie met gebruikerscertificaten, wachtwoordloos inloggen, smartcardequivalenten of toegang tot interne apps
• Het beveiligen van Wi-Fi (802.1X) en VPN-verbindingen
• Het opzetten van mutual TLS (mTLS) tussen backend-microservices
• Code signing voor interne tools en scripts

Je houdt volledige controle over de vertrouwensketen en het uitgiftebeleid, zonder afhankelijk te zijn van externe CA-governance.

Publieke CA of private CA? Een snelle vergelijking

Waar het misgaat

De meest voorkomende fout van IT-teams is publieke CA-certificaten gebruiken voor interne authenticatie. Publieke CA's waren nooit bedoeld voor interne workloads, en door twee verschuivingen die nu gaande zijn is dat gat niet langer te negeren.

1. Geen Client Authentication-EKU's meer op publieke TLS

Publiek vertrouwde TLS-certificaten mogen de Client Authentication-EKU niet langer bevatten. Aangedreven door Ballot SC-081 van het CA/Browser Forum en updates van de grote rootprogramma's faseren publieke CA's clientAuth uit, vooruitlopend op de harde deadline van maart 2027. Leunt je interne apparaat- of gebruikersauthenticatie op publieke certificaten, dan werken die opstellingen bij je volgende verlenging niet meer.

2. Snel krimpende geldigheidsduur

Publieke CA's verkorten de geldigheidsduur van certificaten voortdurend. Onder SC-081v3 is de publieke geldigheidslimiet vastgezet op 200 dagen (2026), dalend naar 100 dagen in maart 2027 en 47 dagen in maart 2029. Geautomatiseerde tools kunnen verlengingen van 90 dagen op publieke webservers prima aan, maar duizenden interne laptops of apparaten elke zes weken opnieuw enrollen is een administratieve nachtmerrie.

Een private CA valt buiten die beperkingen. Omdat je de intrekking rechtstreeks binnen je eigen omgeving regelt, heb je geen kunstmatig korte geldigheidsduur of externe validatiecontroles nodig. Jij stelt de geldigheidsperioden en regels in die voor je team logisch zijn.

Hoe je bepaalt welke je gebruikt

Stel voor elk certificaat in je omgeving de vraag: beheer je elk apparaat of elke client die dit certificaat moet valideren?

• Zo ja: gebruik een private CA. Je distribueert het root-CA-certificaat, bepaalt wat er wordt uitgegeven en bent niet langer overgeleverd aan externe regelwijzigingen.
• Zo nee: dan heb je een publieke CA nodig. Wie van buitenaf verbinding maakt zonder voorafgaande configuratie, heeft een CA nodig die zijn apparaat al vertrouwt.

De meeste IT-afdelingen hebben uiteindelijk beide nodig: publieke certificaten voor extern gerichte diensten, private certificaten voor apparaten, gebruikers en interne diensten.

Hoe SCEPman hierin past

SCEPman is een cloud-native private CA die integreert met Microsoft Intune en Entra ID, en via SCEP en EST ook met andere MDM-platformen. Het verzorgt de automatische certificaatuitgifte voor beheerde apparaten en gebruikers.

In Intune-omgevingen koppelt SCEPman de geldigheid van certificaten aan de compliancestatus van het apparaat. Een apparaat dat wordt gewist of buiten compliance raakt, verliest zijn certificaat en daarmee automatisch de toegang tot Wi-Fi, VPN en interne applicaties.

SCEPman kan met Certificate Master ook handmatig certificaten uitgeven. Daarmee kunnen IT-afdelingen publieke CA-certificaten vervangen in interne systemen zoals webportalen, apps en beheerinterfaces voor apparaten.

Waar je begint

Heb je geen private CA of wil je weg van het verouderde on-premises Active Directory Certificate Services (ADCS), dan is dat een goed startpunt voor een gesprek over SCEPman.

Probeer SCEPman zelf

Start een proefperiode van 30 dagen en zie hoe SCEPman private CA-certificaten uitgeeft en beheert voor je apparaten, gebruikers en interne diensten, zonder de last van een eigen PKI.

SCEPman 30 dagen uitproberen

Veelgestelde vragen