CA/Browser Forum-stemming SC-081v3 werd in april 2025 unaniem aangenomen met steun van alle vier de grote forumleden, waaronder Google, Apple, Microsoft en Mozilla , en 25 stemgerechtigde certificeringsinstanties. Deze stemming introduceerde een ingrijpende reeks wijzigingen in de TLS Baseline Requirements (TBR's), waarbij de scheiding van Client Extended Key Usage (EKU) een van de meest structureel belangrijke was.
Het Chrome Root Program Policy v1.8 , dat fungeert als handhavingsmechanisme voor de rootcertificaatwinkel van Google Chrome , gaat nog een stap verder. Het schrijft niet alleen voor dat bladcertificaten geen clientAuth mogen bevatten, maar dat complete PKI-hiërarchieën moeten worden gereorganiseerd. Dit houdt in dat intermediaire CA's die verbonden zijn met rootcertificaten in de Chrome Root Store geen dubbele EKU-waarden meer mogen hebben. De scheiding moet plaatsvinden op CA-niveau, niet alleen op certificaatniveau.
Voordat we dieper ingaan op de vereisten, is het nuttig om eerst de technische basisprincipes te bespreken. Extended Key Usage (EKU) is een veld in een X.509 digitaal certificaat dat de specifieke doeleinden definieert waarvoor de publieke sleutel van een certificaat mag worden gebruikt. Systemen die certificaten valideren, controleren de EKU-waarden om te bepalen of een aangeboden certificaat geautoriseerd is voor de beoogde bewerking.
Er staan twee EKU-waarden centraal in deze opdracht:
- Serverauthenticatie (OID 1.3.6.1.5.5.7.3.1): Geeft aan dat het certificaat geldig is voor de authenticatie van een server bij een client. Dit is wat uw HTTPS-website gebruikt. Browsers controleren deze EKU bij het tot stand brengen van een TLS-verbinding.
- Clientverificatie (OID 1.3.6.1.5.5.7.3.2): Geeft aan dat het certificaat geldig is voor authenticatie van een client bij een server. Dit wordt gebruikt in mTLS, apparaatauthenticatie en scenario's waarbij de client zijn identiteit moet bewijzen in plaats van alleen de server.
Openbare certificeringsinstanties gaven TLS-certificaten uit die dubbele EKU-waarden bevatten . Het certificaat ziet er als volgt uit:
Eén certificaat bevatte zowel serverAuth als clientAuth . Deze dubbele EKU-praktijk was handig; één certificaat kon twee functies vervullen, maar het was architectonisch onverantwoord en het CA/Browser Forum heeft het nu formeel uit de openbare PKI verwijderd.
De opdracht: wat vereisen SC-081 en het Chrome Root Program?
Openbare certificeringsinstanties mogen geen TLS-servercertificaten meer uitgeven die de uitgebreide sleutelgebruiksregel clientAuth bevatten. Tussenliggende CA-certificaten die zowel serverAuth als clientAuth ondersteunen en verwijzen naar een publiekelijk vertrouwde root, moeten worden uitgefaseerd.
Elke organisatie die authenticatiecertificaten voor klanten nodig heeft, moet deze verkrijgen via een speciaal daarvoor opgezette PKI-hiërarchie. Dit kan per definitie geen openbare CA-hiërarchie zijn die wordt vertrouwd in de rootcertificatenarchieven van browsers.
De belangrijkste datum voor organisaties is 15 juni 2026. ONDERGESCHIKTE/tussenliggende CA-certificaten: elk nieuw tussenliggend certificaat dat op of na die datum aan CCADB wordt bekendgemaakt, moet alleen serverAuth bevatten, en er mogen geen nieuwe dual-EKU-tussenliggende certificaten worden toegevoegd aan de door Chrome vertrouwde hiërarchieën.
Vanaf 15 maart 2027 moet elk nieuw uitgegeven leaf-certificaat dat is gekoppeld aan een door Chrome vertrouwd rootcertificaat, ook alleen serverAuth ondersteunen. Vanaf dat moment zal Chrome openbare TLS leaf-certificaten die nog steeds de clientAuth EKU bevatten, weigeren, en de betreffende handshakes zullen mislukken. Certificaten die vóór de betreffende deadline zijn uitgegeven, blijven geldig tot de vervaldatum, maar bij verlenging worden ze opnieuw uitgegeven zonder clientAuth.
Om in aanmerking te komen als een dedicated TLS-server authenticatie PKI-hiërarchie onder dit beleid:
- Alle overeenkomstige niet verlopen en niet ingetrokken Ondergeschikte CA-certificaten die worden beheerd onder een bestaande root die is opgenomen in de Chrome Root Store MOETEN:
- indien bekendgemaakt aan de CCADB vóór 15 juni 2026: inclusief de uitgebreid sleutelgebruik uitbreiding en (a) alleen een uitgebreid KeyUsage-doel van beweren id-kp-serverAuth of (b) alleen de extendedKeyUsage-doeleinden van id-kp-serverAuth bevestigen en id-kp-clientAuth.
- indien bekendgemaakt aan de CCADB op of na 15 juni 2026: voeg de extendedKeyUsage-extensie toe en stel alleen een extendedKeyUsage-doel van id-kp-serverAuth in.
- Bevat GEEN openbare sleutel die overeenkomt met een ander, niet verlopen of niet ingetrokken certificaat dat andere extendedKeyUsage-waarden claimt.
- Alle bijbehorende abonnementscertificaten zijn uitgegeven. op of na 15 maart 2027, MOET de extendedKeyUsage-extensie bevatten en mag alleen een extendedKeyUsage-doel van id-kp-serverAuth claimen.
Vanaf 15 maart 2027 moet elk nieuw uitgegeven, publiekelijk vertrouwd TLS-certificaat slechts één doel dienen: serverauthenticatie. Het mag alleen de serverAuth EKU bevatten, waarbij de clientAuth OID volledig verwijderd moet zijn. Het openbare CA-certificaat moet er als volgt uitzien:
De volgende tabel geeft de vereiste en toegestane velden weer voor TLS-servercertificaten (leafcertificaten) uitgegeven door publiekelijk vertrouwde CA's, conform het mandaat van het CA/Browser Forum, 7.1.2.7 Abonneecertificaatprofiel (servercertificaat):
| Veld / Uitbreiding | Aanwezigheid | Toegestane waarden en vereisten |
|---|---|---|
| versie | MUST | v3 (geheel getal 2) |
| serienummer | MUST | Positief geheel getal, ten minste 64 bits uitvoer van een CSPRNG. |
| onderwerpAltNaam | MUST | Deze extensie MOET ten minste één item bevatten. Elk item MOET een van de volgende zijn: dNSName or IP-adres zoals beschreven in sectie 7.1.4.2. |
| basisbeperkingen | MUST | Voor een inschrijfcertificaat (bladcertificaat), cA veld MOET op FALSE worden ingesteld. padLenConstraint Mag niet aanwezig zijn. |
| sleutelGebruik | MUST | Het is een cruciaal kenmerk. De acceptabele waarden voor Key Usage variëren afhankelijk van of het certificaat onderwerpOpenbareSleutelInfo identificeert een RSA-publieke sleutel of een ECC publieke sleutel. Certificeringsinstanties MOETEN ervoor zorgen dat het sleutelgebruik geschikt is voor de publieke sleutel van het certificaat. De toegestane sleutelgebruiken zijn: digitale handtekening + sleutelversleuteling voor RSA, en alleen digitale handtekening voor ECDSA |
| uitgebreid sleutelgebruik | MUST | De volgende waarde MOET aanwezig zijn: • id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) De volgende waarde MAG NIET aanwezig zijn: • id-kp-clientAuth (OID: 1.3.6.1.5.5.7.3.2) – Verboden voor nieuw uitgegeven bladcertificaten vanaf 15 maart 2027 onder Chrome Root Program Policy v1.8, Sectie 1.3.2 |
| certificaatbeleid | MUST | Indien aanwezig, MOET de extensie Certificaatbeleid ten minste één certificaatbeleidsregel bevatten. Beleidsinformatie. |
| autoriteitInformatieToegang | MUST | Het is geen cruciaal vakgebied. • sleutelidentificatie- Moet aanwezig zijn. Moet identiek zijn aan het veld subjectKeyIdentifier van de uitgevende CA. • autoriteitCertificaatUitgever- MAG NIET aanwezig zijn • autorisatieCertificaatSerienummer- MAG NIET aanwezig zijn |
| onderwerpSleutelIdentifier | MUST | De CA MOET een genereren onderwerpSleutelIdentifier dat uniek is binnen het geheel van alle certificaten die het heeft uitgegeven voor elke unieke publieke sleutel |
| cRLDistributionPoints | MUST | Deze extensie MOET aanwezig zijn en MAG NIET als kritiek gemarkeerd zijn. De CRL Distribution Points-extensie MOET aanwezig zijn in: • Ondergeschikte CA-certificaten; en • Abonnementscertificaten die 1) niet kwalificeren als "kortstondige abonnementscertificaten" en 2) geen extensie voor toegang tot autoriteitsinformatie bevatten met een id-ad-ocsp accessMethod. |
Opmerking over extendedKeyUsage: De CA/Browser Forum TLS Baseline Requirements v2.2.8, sectie 7.1.2.7.10, vermeldt id-kp-clientAuth nog steeds als 'mag', toegestaan maar niet vereist op BR-niveau. Het strikte verbod komt voort uit het Chrome Root Program Policy v1.8, sectie 1.3.2 , dat vereist dat alle abonnementscertificaten die op of na 15 maart 2027 worden uitgegeven, alleen id-kp-serverAuth bevatten. CA's moeten aan dit beleid voldoen om in de Chrome Root Store te blijven, waardoor de beperking praktisch universeel is.
Stemmingsvoorstel SC-081 introduceert ook een gefaseerde verlaging van de maximale geldigheidsduur voor publiekelijk vertrouwde TLS-certificaten. De geldigheidsduur wordt vanaf maart 2026 verlaagd naar 200 dagen, vanaf maart 2027 naar 100 dagen en vanaf maart 2029 naar 47 dagen . Door de kortere geldigheidsduur van certificaten wordt geautomatiseerde registratie via ACME, WSTEP, SCEP en EST een vereiste in plaats van een gemak. Elke organisatie die afhankelijk is van handmatige certificaatvernieuwing zal te maken krijgen met een onhoudbare operationele last naarmate de geldigheidsperioden korter worden. Dit onderstreept de noodzaak van een beheerde private PKI met volledig geautomatiseerd lifecyclemanagement vanaf dag één.
De openbare CA-tijdlijn
De meest cruciale datum voor organisaties is 15 juni 2026. Vanaf dat moment zal Chrome actief openbare TLS-certificaten met de EKU clientAuth weigeren. Elke nieuwe ondergeschikte CA (tussenliggende CA) die op of na deze datum aan de Common CA Database (CCADB) wordt toegevoegd, mag alleen id-kp-serverAuth bevatten . Vanaf deze datum kunnen er geen nieuwe tussenliggende CA's met gemengde EKU's meer worden toegevoegd aan de door Chrome vertrouwde hiërarchieën. Elk systeem dat een dergelijk certificaat presenteert in een door Chrome gevalideerde TLS-handshake zal mislukken. Bestaande certificaten die vóór deze datum zijn uitgegeven, blijven geldig tot de vervaldatum, maar bij verlenging worden ze zonder clientAuth uitgegeven.
Certificeringsinstanties hebben niet gewacht tot de strikte deadline van maart 2027. De meeste grote certificeringsinstanties zijn al ruim voor die datum begonnen met het verwijderen van clientAuth, mede door de deadline van Chrome voor tussentijdse certificeringsinstanties in juni 2026. Hieronder volgt de volledige tijdlijn zoals die er in juni 2026 uitzag.
| Datum | CA / Programma | Milestone | Status |
|---|---|---|---|
| 15 September 2025 | SSL.com | Het standaard uitgeven van clientAuth-verzoeken wordt gestopt. | GESLAAGD |
| Oktober 1, 2025 | DigiCert | Het standaard uitgeven van clientAuth-verzoeken wordt gestopt. | GESLAAGD |
| Oktober 14, 2025 | Sectigo | Het standaard uitgeven van clientAuth-verzoeken wordt gestopt. | GESLAAGD |
| Februari 11, 2026 | Laten we versleutelen | Het standaard ACME-profiel verwijdert clientAuth. | GESLAAGD |
| 15 juni 2026 | Google Chrome | Verwerpt openbare TLS-certificaten met clientAuth EKU | KRITISCHE |
| July 8, 2026 | Laten we versleutelen | Het tlsclient-profiel is permanent stopgezet. | BINNENKORT |
| Februari 10, 2027 | Sectigo | Strikte deadline, geen uitzonderingen. | BINNENKORT |
| 1 maart 2027 | DigiCert | Volledige verwijdering, zonder uitzonderingen. | BINNENKORT |
| 15 maart 2027 | Chrome Root-programma | Uiterste deadline voor de sector | DEADLINE |
Waarom wordt de EKU voor clientauthenticatie verwijderd?
Het is verleidelijk om deze verplichting puur als een extra administratieve last te beschouwen. In werkelijkheid dicht het echter een reële en onderschatte beveiligingslacune. Inzicht in de volgende beveiligingsargumenten helpt organisaties te begrijpen waarom deze wijziging wordt doorgevoerd:
- De openbare web-PKI is ontwikkeld voor de authenticatie van servers door browsers: De domeinvalidatie (DV) en organisatievalidatie (OV) processen die door openbare certificeringsinstanties (CA's) worden gebruikt, zijn ontworpen om domeineigendom en organisatie-identiteit te verifiëren ten behoeve van serverauthenticatie. Ze zijn niet ontworpen om vast te stellen dat een bepaald systeem gemachtigd is om als client te fungeren in een specifieke authenticatiecontext. Het opnemen van clientAuth EKU in een openbaar uitgegeven certificaat impliceert een validatiestandaard die nooit is uitgevoerd.
- Het compromitteren van privésleutels heeft ernstige gevolgen: Wanneer een TLS-servercertificaat zowel serverAuth als clientAuth bevat, kan een gecompromitteerde privésleutel dubbele schade aanrichten. Een aanvaller die de privésleutel van een server bemachtigt, kan zich niet alleen voordoen als die server tegenover clients, maar kan dat certificaat ook presenteren als een geldige clientreferentie aan elk systeem dat de uitgevende CA vertrouwt en controleert op de clientAuth EKU. Eén enkele inbreuk leidt tot laterale verplaatsing. Het verwijderen van clientAuth uit servercertificaten elimineert deze tweede aanvalsvector volledig.
- Scheiding maakt een goed levenscyclusbeheer mogelijk: Servercertificaten en clientcertificaten hebben fundamenteel verschillende levenscyclusvereisten. Servercertificaten zijn gekoppeld aan domeinnamen, worden vernieuwd op openbare infrastructuur en beheerd door webbeheerteams. Clientcertificaten zijn gekoppeld aan systeemidentiteiten en vereisen intrekkingsmogelijkheden die op applicatieniveau worden afgedwongen. Het samenvoegen ervan tot één certificaat maakt het correct beheren van beide lastiger. Scheiding herstelt de duidelijkheid van eigenaarschap en verantwoordelijkheid.
De gevolgen van het verwijderen van de clientauthenticatie-EKU
Het verwijderen van de clientAuth EKU heeft gevolgen voor organisaties die momenteel een publiekelijk vertrouwd TLS-servercertificaat gebruiken voor clientauthenticatie.
Organisaties die openbare certificaten uitsluitend gebruiken voor standaard HTTPS- serverauthenticatie ondervinden over het algemeen geen hinder. Hun websites, portals en publiekelijk toegankelijke applicaties kunnen certificaten blijven gebruiken die alleen de serverAuth EKU bevatten.
Het probleem ontstaat wanneer hetzelfde openbare certificaat ook wordt gebruikt om een gebruiker, apparaat, server, applicatie of workload te authenticeren bij een ander systeem. Wanneer dat certificaat wordt vernieuwd of opnieuw wordt uitgegeven zonder de clientAuth EKU, accepteert het ontvangende systeem het mogelijk niet langer als een geldige clientreferentie.
Belangrijk is dat het certificaat mogelijk nog steeds geldig, niet verlopen en vertrouwd is. De fout treedt op omdat het certificaat niet langer geautoriseerd is voor clientauthenticatie.
Om u te helpen vaststellen wat er mis kan gaan en waarom, geeft de volgende tabel een overzicht van de mogelijke impactgebieden binnen uw organisatie.
| Use Case | Potentiële impact |
|---|---|
| Mutual TLS (mTLS) | Tijdens een mTLS-verbinding kan het ontvangende systeem controleren of het certificaat van de client de clientAuth EKU bevat. Als deze EKU ontbreekt, kan het certificaat worden geweigerd en mislukt de TLS-handshake. Dit kan gevolgen hebben voor microservices, API-gateways, service meshes, business-to-business-integraties en aangepaste applicatie-naar-applicatie-authenticatie. De fout kan zich voordoen als een algemene TLS-handshakefout of certificaatvalidatiefout in plaats van een vervaldatumprobleem. |
| RADIUS, IEEE 802.1X en EAP-TLS | Bij certificaatgebaseerde netwerkauthenticatie presenteren gebruikers of apparaten een clientcertificaat om hun identiteit te bewijzen. Als de authenticatieserver de clientAuth EKU vereist en het vernieuwde certificaat deze niet bevat, mislukt de authenticatieaanvraag. Hierdoor kunnen de getroffen apparaten mogelijk geen verbinding maken met bedrijfs-Wi-Fi, bekabelde netwerken of VPN-diensten. |
| OpenVPN, Cisco Secure Client en Fortinet VPN | Bij veel VPN-implementaties op basis van certificaten is het vereist dat het certificaat van de verbindende gebruiker of het apparaat de clientAuth EKU bevat. Als een openbaar certificaat dat eerder voor VPN-authenticatie werd gebruikt, wordt vernieuwd zonder die EKU, kan de VPN-gateway dit weigeren. Gebruikers kunnen dan mogelijk geen beveiligde verbinding voor toegang op afstand tot stand brengen. |
| Microsoft Exchange en server-naar-servercommunicatie | De SMTP-connector, EWS en partnercommunicatieconfiguraties gebruiken certificaten voor wederzijdse of server-naar-server-authenticatie. Wanneer van de verbindende server wordt verwacht dat het certificaat clientauthenticatie ondersteunt, kan het verwijderen van de clientAuth EKU de authenticatie of de e-mailstroom verstoren. De daadwerkelijke impact hangt af van de Exchange-versie, de connectorconfiguratie en de vereisten voor certificaatvalidatie. |
| Omgevingen voor extern bureaublad en RDP-gateway | Remote Desktop Gateway gebruikt doorgaans een servercertificaat om zich te authenticeren bij verbindende clients. Omgevingen die echter ook gebruikmaken van certificaatgebaseerde clientauthenticatie, smartcardauthenticatie of aangepaste wederzijdse authenticatiemechanismen, kunnen afhankelijk zijn van specifieke clientcertificaten. Het hergebruiken van een openbaar servercertificaat voor een dergelijk doel kan na verlenging leiden tot authenticatiefouten. |
| IoT en apparaatidentiteit | IoT-, industriële en embedded apparaten kunnen certificaten gebruiken om zich te authenticeren bij cloudservices, beheerplatformen of apparaatgateways. Als een apparaatcertificaat wordt vernieuwd zonder de vereiste clientAuth EKU, kan het platform de apparaatidentiteit weigeren. Dit kan het inchecken van het apparaat, het verzenden van telemetriegegevens, beheer op afstand, software-updates of het uitvoeren van commando's belemmeren. |
| API- en server-naar-server-authenticatie | Applicaties en servers fungeren vaak als TLS-clients bij het aanroepen van interne of externe API's. Als ze een openbaar TLS-certificaat presenteren als hun clientidentiteit, kan de ontvangende API het certificaat weigeren zodra clientAuth is verwijderd. Dit kan integraties verstoren, zelfs als hetzelfde certificaat normaal blijft werken voor inkomende HTTPS-verbindingen. |
| CI/CD- en DevOps-workloads | Buildservers, implementatieagents, containers en automatiseringsplatformen kunnen certificaten gebruiken om zich te authenticeren bij registers, Kubernetes-clusters, artifactrepositories of interne API's. Wanneer een vernieuwd certificaat de clientauthenticatie niet langer ondersteunt, kunnen geautomatiseerde pipelines vastlopen zonder dat er direct een duidelijke oorzaak is die verband houdt met het certificaat. |
Waarom deze storingen moeilijk te diagnosticeren kunnen zijn
Het verwijderen van clientAuth levert niet per se een duidelijke melding op dat de EKU ontbreekt. Afhankelijk van de applicatie, het besturingssysteem of de TLS-bibliotheek kan de fout als volgt worden gerapporteerd:
- TLS-handshake mislukt
- Certificaatdoel niet toegestaan
- Niet-ondersteund certificaat
- Ongeldig certificaat
- Toegang geweigerd
- Klantidentiteit afgewezen
- Peerverificatie mislukt
- Authenticatietime-out
Hierdoor kan het probleem gemakkelijk verkeerd worden gediagnosticeerd als een probleem met de vertrouwensketen, de vervaldatum, het netwerk, de cipher suite of de applicatieconfiguratie.
Het grootste risico beperkt zich niet tot certificaten waarvan al bekend is dat ze wederzijdse TLS ondersteunen . Het omvat ook ongedocumenteerde systemen die afhankelijk zijn van de clientAuth EKU , omdat openbare TLS-certificaten deze historisch gezien standaard bevatten.
Organisaties moeten deze afhankelijkheden identificeren voordat de betreffende certificaten worden vernieuwd of opnieuw worden uitgegeven. Wachten tot de vernieuwing kan een routinevervanging van een certificaat veranderen in een onverwachte storing die de applicatieconnectiviteit, netwerktoegang, toegang op afstand of apparaatverificatie beïnvloedt.
De oplossing: overstappen naar een private CA
Openbaar vertrouwde certificeringsinstanties mogen geen TLS-certificaten meer uitgeven voor clientauthenticatie (dat wil zeggen, certificaten die de clientAuth EKU bevatten). Hierdoor kunnen organisaties niet langer vertrouwen op openbare TLS-certificaten voor interne clientauthenticatie, zoals wederzijdse TLS, apparaatauthenticatie, workloadidentificatie, API-authenticatie en server-naar-servercommunicatie.
Een private PKI biedt een oplossing voor dit probleem, omdat deze buiten het door browsers vertrouwde publieke PKI-ecosysteem opereert. De root-CA wordt alleen vertrouwd door de gebruikers, apparaten, applicaties en systemen die door de organisatie zijn geselecteerd. Hierdoor kan de organisatie specifieke clientcertificaten uitgeven die de clientAuth EKU bevatten, zonder dat dit ten koste gaat van of afhankelijk is van het publieke browservertrouwen.
Een private PKI maakt ook een goede scheiding mogelijk tussen de twee certificaatdoeleinden:
- Openbare of privé servercertificaten die alleen de serverAuth EKU bevatten.
- Speciale privéclientcertificaten die alleen de clientAuth EKU (OID 1.3.6.1.5.5.7.3.2) bevatten, zonder serverAuth OID, zoals weergegeven in de onderstaande schermafbeelding:
Deze scheiding zorgt ervoor dat een servercertificaat alleen wordt gebruikt om een server te authenticeren, terwijl een clientcertificaat alleen wordt gebruikt om een gebruiker, apparaat, applicatie of werkstation te authenticeren. Het vermindert de impact van een inbreuk op de privésleutel en biedt meer controle over de uitgifte, het eigendom, de verlenging en de intrekking van certificaten.
Met een private PKI kunnen organisaties ook certificaatbeleid definiëren dat voldoet aan hun specifieke beveiligingsvereisten, waaronder procedures voor identiteitsvalidatie, geldigheidsperioden van certificaten, naamgevingsconventies, goedgekeurde algoritmen, vereisten voor sleutelbescherming en inschrijfmethoden. Certificaten kunnen automatisch worden uitgegeven en verlengd met behulp van protocollen zoals ACME, SCEP, EST, CMP, WSTEP of Microsoft Auto-Enrollment.
Deze verschuiving stelt organisaties in staat authenticatieworkflows te ontwerpen die zijn afgestemd op hun specifieke behoeften, zonder gebonden te zijn aan de beperkingen van openbare CA's. In het volgende gedeelte wordt beschreven hoe de PKI-hiërarchie eruit zou moeten zien.
Hoe moet de PKI-hiërarchie veranderen?
Het verwijderen van de clientAuth EKU uit publiekelijk vertrouwde TLS-certificaten is niet zomaar een wijziging van de certificaatsjabloon. Het vereist dat organisaties de authenticatie van de publieke server scheiden van de authenticatie van de interne client op het niveau van de PKI-architectuur.
Volgens het nieuwe model mogen publiekelijk vertrouwde certificaten alleen worden gebruikt voor de authenticatie van servers bij externe clients, zoals browsers die verbinding maken met websites en publiekelijk toegankelijke applicaties. Deze certificaten bevatten alleen de serverAuth EKU en de certificaatketen loopt door naar een publiekelijk vertrouwde root-CA.
Clientauthenticatie moet worden verplaatst naar een aparte, private PKI-hiërarchie. Deze private hiërarchie verstrekt doelspecifieke certificaten aan gebruikers, apparaten, applicaties, workloads en servers die zich als client moeten authenticeren.
De beoogde architectuur moet daarom het volgende omvatten:
- Een openbare TLS PKI-hiërarchie voor servercertificaten die toegankelijk zijn via internet en die alleen serverAuth-certificaten bevat.
- Een privé, offline, niet aan een domein gekoppelde root-CA, beveiligd met een FIPS 140-3 Level 3-compatibele hardwarebeveiligingsmodule.
- Een of meer particuliere certificeringsinstanties (CA's) die specifiek zijn bedoeld voor clientauthenticatie. Beveiliging van de privésleutels van de uitgevende CA's met behulp van een HSM (Hardware Security Module).
- Clientcertificaatprofielen die alleen zijn gekoppeld aan de clientAuth EKU (geen serverAuth OID aanwezig), met Key Usage ingesteld op digitalSignature, waardoor het certificaat onder geen enkele omstandigheid kan worden gebruikt voor serverauthenticatie.
- Aparte certificaatprofielen voor apparaten, gebruikers, workloads, API's en andere identiteiten.
- CRL- of OCSP-services voor het intrekken van certificaten, waarbij CDP-eindpunten openbaar of privé worden geconfigureerd, afhankelijk van het gebruiksscenario en de toegankelijkheidsvereisten van de organisatie.
- Geautomatiseerde certificaatregistratie, -vernieuwing en -intrekking
- Distributie van de private root-CA naar systemen die de clientcertificaten moeten vertrouwen.
In deze architectuur heeft een server die beide rollen vervult mogelijk twee aparte certificaten nodig:
- Een servercertificaat met serverAuth voor het accepteren van inkomende TLS-verbindingen.
- Een clientcertificaat met clientAuth voor authenticatie bij het verbinden met een ander systeem.
Deze scheiding zorgt ervoor dat elk certificaat en elke privésleutel een duidelijk omschreven doel heeft. Het stelt organisaties ook in staat om verschillende beleidsregels voor identiteitsvalidatie, levenscyclus, intrekking en sleutelbescherming toe te passen op server- en clientidentiteiten.
Het ontwerpen, implementeren en continu beheren van deze private hiërarchie vereist specialistische PKI-expertise, een veilige HSM-infrastructuur, automatisering van de certificaatlevenscyclus, intrekkingsdiensten, monitoring, noodherstel en doorlopend beleidsbeheer. In het volgende deel van deze blog wordt uitgelegd hoe de PKIaaS van Encryption Consulting een volledig beheerde private CA levert die namens u wordt gebouwd, beheerd en compliant gehouden.
PKIaaS van Encryption Consulting
Het opzetten en beheren van een private PKI-hiërarchie is conceptueel niet complex, maar de uitvoering ervan is veeleisend. Dit omvat onder andere de aanschaf van HSM's, offline root CA-ceremonies, CDP/AIA-toegankelijkheid, automatisering van de certificaatlevenscyclus, beleidsdocumentatie en inschrijvingsprocedures.
De PKI-as-a-Service (PKIaaS) van Encryption Consulting kan strakke deadlines halen en een complete private PKI leveren als beheerde service . Encryption Consulting bouwt, beheert en zorgt voor de naleving van de regelgeving, terwijl u volledig eigenaar blijft.
Geen vendor lock-in: uw privésleutels, CA-hiërarchie en certificaten blijven volledig van u. Mocht u besluiten de PKI naar uw eigen omgeving te migreren, dan zal Encryption Consulting een formele, gedocumenteerde sleuteloverdrachtceremonie uitvoeren. Het materiaal met de privésleutels van de CA wordt veilig overgedragen naar uw HSM met behulp van geauthenticeerde, dubbel gecontroleerde exportprocedures.
Uw bestaande certificaten blijven geldig en hoeven niet opnieuw te worden uitgegeven. Het volledige overdrachtsproces wordt volledig gedocumenteerd en is controleerbaar, waardoor operationele continuïteit en volledig eigendom worden gewaarborgd.
U bent eigenaar van de PKI. Wij bouwen, beheren en exploiteren deze namens u. Hieronder leggen we uit hoe onze samenwerking in zijn werk gaat.
Fase 1: Ontdekking en inventarisatie van certificaten
Voordat Encryption Consulting een nieuwe PKI ontwerpt, ontwikkelt het bedrijf een volledig overzicht van de huidige certificaatomgeving van de klant. Dit is cruciaal, omdat veel systemen afhankelijk zijn van clientAuth zonder dat deze afhankelijkheid formeel is vastgesteld.
We ondersteunen meerdere methoden voor het opsporen van certificaten , waaronder netwerkscans, scans zonder agent en op integratie gebaseerde detectie.
Integratiegebaseerde ontdekking biedt een realtime, gezaghebbend overzicht van certificaatgegevens door rechtstreeks verbinding te maken met certificeringsinstanties en cloudplatformen zoals AWS, Microsoft Azure en Google Cloud. Het kan ook applicatieconfiguraties onderzoeken, inclusief mTLS-instellingen, en integreren met Kubernetes-clusters, platforms voor geheimbeheer zoals HashiCorp Vault en CyberArk Conjur, en CI/CD-pipelines, waaronder GitHub Actions, Jenkins en GitLab.
Aanvullende detectiemogelijkheden omvatten passieve monitoring via proxies, firewalls en netwerktaps; directoryscanning via LDAP en Active Directory; en detectie via configuratiebeheertools zoals Ansible, Chef en Puppet.
De output is een complete inventaris van certificaten met daarin de onderwerpen, SAN's, EKU's, uitgevers en vervaldatums van de certificaten. Elk certificaat dat clientAuth bevat, wordt gekoppeld aan zowel het systeem dat het presenteert als het systeem dat er voor authenticatie op vertrouwt.
De bevindingen worden vervolgens georganiseerd in een risicogerangschikte migratietijdlijn. De klant krijgt een duidelijk beeld van welke systemen mogelijk uitvallen, wanneer ze risico lopen en wat de potentiële impact op de bedrijfsvoering is als een certificaat wordt verlengd zonder clientAuth.
Fase 2: PKI-architectuurontwerp
Er wordt niets gebouwd voordat de architectuur is beoordeeld en goedgekeurd. Elke CA, elk certificaatsjabloon en elk intrekkingspunt wordt op papier gespecificeerd voordat er ook maar één sleutel wordt gegenereerd.
De architectuur omvat doorgaans een offline, niet aan een domein gekoppelde root-CA en afzonderlijke uitgevende CA's voor clientauthenticatie, interne TLS en authenticatie van apparaatidentiteit. Deze scheiding zorgt ervoor dat clientcertificaten alleen clientAuth bevatten.
Certificaatprofielen worden gedefinieerd voor elk gebruiksscenario, inclusief algoritmen, geldigheidsperioden, onderwerp- en SAN-formaten, sleutelgebruik, EKU, beleids-OID's en intrekkings-eindpunten. CRL- en OCSP-locaties worden geconfigureerd als openbaar of privé, afhankelijk van waar de certificaten zullen worden gebruikt.
Dit zorgt voor een duidelijke, doelgerichte hiërarchie zonder dubbele EKU-certificaten en zonder onduidelijkheid over waarvoor elk certificaat bevoegd is.
Fase 3: Ceremonie voor de hoofdcertificeringsinstantie en infrastructuuropbouw
De privésleutel van de Root CA wordt gegenereerd en beveiligd in een FIPS 140-3 Level 3-compatibele Hardware Security Module (HSM). De Root CA blijft veilig gehost in het datacenter en wordt offline gehouden tussen geautoriseerde certificaatondertekeningsbewerkingen. Voor noodherstel wordt een versleutelde en met toegangscontrole beveiligde back-up van het sleutelmateriaal bewaard in een geografisch gescheiden HSM-omgeving.
Encryption Consulting bouwt vervolgens de ondersteunende PKI-infrastructuur op, inclusief beveiligde certificeringsinstanties, OCSP-responders, CRL-publicatieservices en mogelijkheden voor certificaatbeheer.
Fase 4: Distributie van de Trust Store
Certificaten uitgegeven door een private PKI worden alleen vertrouwd wanneer de private root-CA is geïnstalleerd op elk systeem dat ze valideert. In deze fase wordt het nieuwe private root-CA-certificaat gedistribueerd naar alle systemen van de vertrouwende partijen binnen het toepassingsgebied.
Windows-systemen die lid zijn van een domein ontvangen de root-CA via Groepsbeleid, die wordt opgeslagen in de opslagplaats voor vertrouwde rootcertificeringsinstanties. Linux-systemen worden bijgewerkt met behulp van `update-ca-certificates`, dat wordt geïmplementeerd via Ansible, Chef of Puppet, afhankelijk van de bestaande configuratiebeheertoolchain.
Na de distributie worden representatieve systemen getest met behulp van nieuw uitgegeven klantcertificaten. Deze fase is pas voltooid nadat de klant heeft bevestigd dat de certificaatketens betrouwbaar zijn en de authenticatie is geslaagd.
Fase 5: Implementatie van de PKIaaS-gateway
In deze fase wordt de PKIaaS Gateway geïmplementeerd, een set componenten voor inschrijving en beheer die in de eigen infrastructuur van de klant worden geïnstalleerd. De gateway vormt de brug tussen de interne systemen van de klant en de door Encryption Consulting gehoste CA-hiërarchie. Alle certificaataanvragen lopen via de gateway. De privésleutels van de CA blijven te allen tijde in de HSM's van Encryption Consulting; de gateway verwerkt alleen verkeer via het inschrijvingsprotocol en nooit ondertekeningsbewerkingen.
De gateway biedt een WS-Trust Enrollment Protocol (WSTEP)-eindpunt, waardoor volledig geautomatiseerde certificaatinschrijving voor Windows-machines mogelijk is zonder tussenkomst van gebruiker of beheerder. De Certificate Enrollment Policy-service (CEP) is geconfigureerd om te bepalen voor welke certificaatsjablonen de machine in aanmerking komt op basis van de Active Directory-identiteit en het groepsbeleidslidmaatschap.
De webservice voor certificaatinschrijving valideert het verzoek aan de hand van het inschrijvingsbeleid, stuurt het via de PKIaaS-gateway door naar de uitgevende certificeringsinstantie en stuurt het ondertekende certificaat rechtstreeks terug naar de machine, die het vervolgens automatisch in het juiste certificaatarchief installeert. Vanaf de GPO-configuratie vereist de volledige levenscyclus – beleidsdetectie, aanvraag, ondertekening, installatie en verlenging – geen handmatige tussenkomst meer.
Een webgebaseerd dashboard waar geautoriseerde gebruikers certificaten kunnen aanvragen, CSR's kunnen indienen, de certificaatinventaris kunnen doorzoeken, certificaten kunnen verlengen, gecompromitteerde of ongebruikte certificaten kunnen intrekken en de certificaatstatus kunnen bekijken.
Het dashboard omvat op rollen gebaseerde toegangscontrole. Certificaatbeheerders kunnen certificaten aanvragen of intrekken, auditors kunnen rapporten en activiteitenlogboeken bekijken en beheerders kunnen goedgekeurde profielen en inschrijvingsbeleid beheren.
Elke inschrijving, verlenging, intrekking, goedkeuring, configuratiewijziging en beheerdersaanmelding wordt vastgelegd in een controleerbaar activiteitenlogboek.
Fase 6: Certificaatmigratie - Systeem voor systeem
Zodra de vertrouwens- en registratiediensten operationeel zijn, begint Encryption Consulting met het vervangen van de openbare dual-EKU-certificaten door speciale privéclientcertificaten.
De migratie begint met de ontwikkel- en testomgevingen. Vervolgens worden interne services en API's gemigreerd, gevolgd door de netwerkinfrastructuur, inclusief VPN, RADIUS en 802.1X. Bedrijfskritieke systemen, zoals Exchange, kernapplicaties en systemen binnen de organisatie, worden pas gemigreerd nadat de test- en terugdraaiprocedures zijn bevestigd.
Elke certificaataanvraag wordt ingediend via de juiste inschrijfmethode, zoals WSTEP, ACME, SCEP, EST of het beheerdashboard. Het nieuwe certificaat wordt alleen met de clientAuth EKU uitgegeven. De applicatie wordt geconfigureerd om het nieuwe certificaat te presenteren en een end-to-end authenticatietest bevestigt dat de verbinding succesvol is.
Na een succesvolle validatie wordt het oude dual-EKU-certificaat, indien van toepassing, verwijderd of ingetrokken en wordt het nieuwe certificaat automatisch verlengd.
Fase 7: Lopende werkzaamheden en naleving
In deze fase levert PKIaaS ook na de initiële implementatie nog steeds toegevoegde waarde.
Het CLM-platform van Encryption Consulting beheert continu de uitgifte, verlenging en intrekking van certificaten, de publicatie van CRL's, de beschikbaarheid van OCSP's, HSM-monitoring, infrastructuuronderhoud, back-upvalidatie en PKIaaS Gateway-activiteiten.
Inschrijvingsdiensten zoals WSTEP, ACME, SCEP en EST worden continu bijgehouden, zodat certificaten zonder handmatige tussenkomst kunnen worden afgegeven en verlengd.
Encryption Consulting houdt ook de beveiligingsvereisten van relevante organisaties, ontwikkelingen binnen CA/Browser Forums, cryptografische standaarden, algoritmeaanpassingen en updates van certificaatbeleid in de gaten, zoals compatibiliteit met post-kwantumcryptografie . Wanneer een wijziging de omgeving van de klant beïnvloedt, worden de PKI-configuratie en certificaatprofielen vóór de betreffende deadline bijgewerkt.
Conclusie
Het verwijderen van de clientAuth EKU uit publiekelijk vertrouwde TLS-certificaten markeert een fundamentele verschuiving in de manier waarop organisaties certificaatgebaseerde authenticatie moeten beheren. Publieke certificaten blijven websites en externe services beveiligen, maar clientauthenticatie voor gebruikers, apparaten, applicaties en workloads moet overstappen naar een speciaal daarvoor ontworpen private PKI. Organisaties die er niet in slagen verborgen dual-EKU-afhankelijkheden te identificeren, lopen het risico op onverwachte storingen wanneer certificaten worden vernieuwd zonder clientAuth. Deze storingen zullen zich niet manifesteren als certificaatfouten, maar als authenticatietime-outs, TLS-handshakefouten en berichten over geweigerde toegang zonder duidelijke oorzaak.
De PKIaaS-oplossing van Encryption Consulting biedt een compleet traject voor deze transitie. We beoordelen de bestaande omgeving, identificeren de getroffen systemen, ontwerpen en bouwen de private PKI, beschermen CA-sleutels binnen HSM's, implementeren registratieservices, migreren certificaten en beheren de omgeving continu. Geautomatiseerde registratie via WSTEP, ACME, SCEP en EST zorgt ervoor dat certificaten worden uitgegeven, verlengd en ingetrokken zonder extra operationele lasten.
Om te beginnen met een gratis PKI-gereedheidsbeoordeling, kunt u contact met ons opnemen via [email protected] of naar encryptionconsulting.com/pkiaas gaan.
