CA/Browser Forum-mandatet: Slutet på dubbla EKU-certifikat

CA/Browser Forum-omröstningen SC-081v3 antogs enhälligt i april 2025 med stöd från alla fyra större forummedlemmar, inklusive Google, Apple, Microsoft och Mozilla , samt 25 röstande certifikatutfärdare. Denna omröstning införde en omfattande uppsättning förändringar av TLS-baskraven (TBR), där separationen för klientens utökade nyckelanvändning (EKU) var en av de mest strukturellt betydande.

Chrome Root Program Policy v1.8 , som fungerar som verkställighetsmekanism för Google Chromes rotarkiv , går längre. Den föreskriver inte bara att lövcertifikat ska vara fria från clientAuth, utan att hela PKI-hierarkier ska omorganiseras, inklusive mellanliggande CA:er som är kopplade till rötter i Chrome Root Store, och att de inte längre får bära dubbla EKU-värden. Separationen måste ske på CA-nivå, inte bara på certifikatnivå.

Innan vi går in på mandatet är det värt att förankra diskussionen i de tekniska grunderna. Utökad nyckelanvändning (EKU) är ett fält i ett digitalt X.509-certifikat som definierar de specifika syften för vilka ett certifikats offentliga nyckel får användas. System som validerar certifikat kontrollerar EKU-värden för att avgöra om ett presenterat certifikat är auktoriserat för den åtgärd som försöks.

Det finns två EKU-värderingar i centrum för detta mandat:

• Serverautentisering (OID 1.3.6.1.5.5.7.3.1): Signalerar att certifikatet är giltigt för att autentisera en server mot en klient. Det är detta din HTTPS-webbplats använder. Webbläsare söker efter denna EKU när de upprättar en TLS-anslutning.
• Klientautentisering (OID 1.3.6.1.5.5.7.3.2): Signalerar att certifikatet är giltigt för att autentisera en klient mot en server. Detta används i mTLS, enhetsautentisering och scenarier där klienten måste bevisa sin identitet snarare än bara servern.

Offentliga certifikatutfärdare utfärdade TLS-certifikat som innehöll dubbla EKU-värden . Certifikatet ser ut så här:

Ett enda certifikat skulle bära både serverAuth och clientAuth . Denna metod med dubbla EKU var bekväm; ett certifikat kunde tjäna dubbel funktion, men den var arkitekturmässigt osund, och CA/Browser Forum har nu formellt eliminerat det från offentlig PKI.

Snabbt svar: Vad är kravet på dubbel EKU-certifikat?

Mandatet för dubbla EKU-certifikat från CA/Browser Forum SC-081v3 (april 2025) och Chrome Root Program Policy v1.8 eliminerar clientAuth från offentligt betrodda TLS-certifikat. Från och med den 15 juni 2026 får ingen ny mellanliggande CA bära dubbla EKU-värden. Från och med den 15 mars 2027 måste varje nyligen utfärdat offentligt betrott TLS-lövcertifikat endast innehålla serverAuth . Klientautentisering måste flyttas till en dedikerad privat PKI-hierarki.

Key Takeaways

• CA/Browser Forum-omröstningen SC-081v3 antogs enhälligt i april 2025 med stöd från Google, Apple, Microsoft, Mozilla och 25 röstande CA:er. Chrome Root Program Policy v1.8 upprätthåller separationen på CA-hierarkinivå, inte bara på lövcertifikatnivå. Från och med den 15 juni 2026 får ingen ny mellanliggande CA som lämnas ut till CCADB bära både serverAuth och clientAuth. Från och med den 15 mars 2027 måste varje nyligen utfärdat offentligt betrott TLS-lövcertifikat endast innehålla serverAuth EKU.
• DigiCert Trust Pulse Survey (2 juli 2025) fann att 45 procent av organisationerna upplevde certifikatrelaterade driftstopp under föregående år, och 37.5 procent spårade ett avbrott till ett utgånget certifikat. Dual-EKU-mandatet introducerar ett nytt och svårare att diagnostisera felläge: ett certifikat som förnyas utan clientAuth är giltigt, inte utgånget och betrott, men misslyckas tyst med alla användningsfall för klientautentisering med generiska fel (TLS-handskakningsfel, åtkomst nekad, peer-verifieringsfel) som inte identifierar den saknade EKU:n som orsak.
• CA/Browser Forum SC-081v3 fasar också ner maximal TLS-giltighet från 200 dagar (mars 2026) till 100 dagar (mars 2027) till 47 dagar (mars 2029). Vid 47 dagars giltighet förnyas ett certifikat ungefär åtta gånger per år. Varje förnyelse av ett dubbel-EKU-certifikat som inte har migrerats till en privat PKI är ett potentiellt tyst autentiseringsavbrott. Mandatet och giltighetsminskningen sker enligt samma schema, vilket ökar risken för organisationer som försenar identifiering och migrering.
• Åtta användningsfallskategorier står inför störningar: ömsesidig TLS (mTLS), RADIUS- och IEEE 802.1X-nätverksautentisering, certifikatbaserad VPN (OpenVPN, Cisco Secure Client, Fortinet), server-till-server-kommunikation i Microsoft Exchange, fjärrskrivbord och RDP-gateway, IoT- och enhetsidentitet, API- och server-till-server-autentisering samt CI/CD- och DevOps-arbetsbelastningar. De farligaste beroendena är de odokumenterade: system som förlitar sig på clientAuth eftersom offentliga certifikat historiskt sett inkluderade det som standard, utan att det beroendet formellt registrerats.
• NIST FIPS 203, 204 och 205 (slutförda 13 augusti 2024) kräver att RSA- och elliptiska kurvalgoritmer ersätts i alla PKI-hierarkier på tidslinjen för NIST IR 8547-avveckling. Privata CA-hierarkier som är byggda för att uppfylla dual-EKU-mandatet måste också inkludera planering efter kvantmigrering för algoritmer för privata CA-nyckel. Spåra kraven för migrering av algoritmer för privata CA-nyckel genom PQC:s kompetenscentrum.

Vem borde bry sig om det dubbla EKU-mandatet

Dual-EKU-mandatet är inte en ändring av certifikatmallen. Det är en ändring av PKI-arkitekturen som kräver samordnade åtgärder från PKI-team, säkerhetsarkitekter, plattformsingenjörer, efterlevnadsteam och CISO:er. Varje team äger en distinkt del av övergången, och luckor inom vilket område som helst producerar de tysta autentiseringsfel som är mandatets primära operativa risk.

Roll	Varför det gäller	Åtgärdsobjekt
PKI- och certifikatteam	Äg den privata CA-hierarkin och separationen av certifikatmallar: Chrome Root Program Policy v1.8 kräver separation på CA-nivå, inte bara på lövcertifikatnivå, vilket innebär att PKI-team måste utforma och driva en privat hierarki med dedikerade utfärdande CA:er för klientautentisering (endast clientAuth EKU, ingen serverAuth) separat från den offentliga TLS-hierarkin (endast serverAuth); standard CA-plattformar för företag kräver explicit mallkonfiguration för att genomdriva EKU-separation och förhindra utfärdande av dubbla EKU; tidsfristen den 15 mars 2027 är absolut för nyligen utfärdade certifikat, utan möjlighet till förlängning för organisationer som inte har slutfört migreringen.	Granska hela certifikatinventeringen för alla offentligt betrodda certifikat som har både serverAuth- och clientAuth EKU-värden med hjälp av CertSecure-hanterare; utforma den privata CA-hierarkin med dedikerade utfärdande CA:er för klientautentisering, användaridentitet, enhetsidentitet och arbetsbelastningsidentitet; konfigurera certifikatmallar för att tillämpa EKU-separation (endast offentliga mallar för serverAuth, endast privata mallar för clientAuth) utan möjlighet till dubbel EKU-utgivning; använda CBOM-säkerhet för fullständig identifiering av kryptografisk egendom inklusive alla CA-utfärdade certifikat i moln-, lokala och multimolnmiljöer; utvärdera PKIaaS för den privata CA-hierarkin om den interna PKI-operationskapaciteten är begränsad
Säkerhetsarkitekter	Äg PKI-arkitekturstyrningen: mandatet kräver inte bara en ny certifikatmall utan även en ny privat CA-hierarki med egen rot-CA, utfärdande CA:er, HSM-baserad nyckelskydd, distributionsstrategi för förtroendelager, CRL/OCSP-infrastruktur och val av registreringsprotokoll. Säkerhetsarkitekter måste också utforma gränsen mellan offentliga TLS-certifikat (endast serverAuth, webbläsarbetrodda) och privata klientcertifikat (endast clientAuth, privat betrodda) för att säkerställa att inget system kan använda ett offentligt certifikat för klientautentisering eller vice versa. Post-kvantummigreringen av privata CA-nyckelalgoritmer (ECDSA till ML-DSA enligt NIST FIPS 204, slutförd 13 augusti 2024) måste också planeras vid arkitekturdesigntillfället.	Designa den privata CA-hierarkiarkitekturen: offline-rot-CA, separata utfärdande CA:er för varje användningsfall för klientautentisering (mTLS, enhet, användare, arbetsbelastning, API), HSM-baserad nyckelskydd som uppfyller FIPS 140-3 nivå 3-krav, CRL- och OCSP-infrastruktur och distributionsplan för trust store; specificera registreringsprotokoll för varje användningsfall (WSTEP för Windows AD-anslutna maskiner, ACME för molnbaserade arbetsbelastningar, SCEP för mobil/IoT, EST för generell registrering); planera post-quantum-migreringsvägen för algoritmer för privata CA-nyckelord genom PQC:s kompetenscentrum; definiera policygränsen som förhindrar att ett system använder ett offentligt TLS-certifikat för klientautentisering efter den 15 mars 2027
Plattforms- och DevOps-team	Ta ansvar för migreringen på applikationsnivå: varje system som för närvarande presenterar ett offentligt TLS-certifikat för klientautentisering måste konfigureras om för att presentera ett privat klientcertifikat istället; detta inkluderar mTLS-slutpunkter i mikrotjänstarkitekturer, RADIUS-servrar och 802.1X-autentiseringsinfrastruktur, VPN-gateways (OpenVPN, Cisco Secure Client, Fortinet), IoT-plattformar och enhetshanteringssystem, Kubernetes-tjänstnätkonfigurationer, API-gateways med certifikatbaserad klientautentisering och CI/CD-pipelines som autentiserar mot register, artefaktdatabaser och Kubernetes-kluster; plattformsteam måste också integrera privat certifikatregistrering (WSTEP, ACME, SCEP, EST) i arbetsflöden för infrastrukturprovisionering så att nya system automatiskt får privata klientcertifikat.	Mappa alla mTLS-konfigurationer, RADIUS-distributioner, VPN-gateways, Kubernetes service mesh-policyer, API-gateway-autentiseringskonfigurationer och användning av CI/CD-pipelinecertifikat för att identifiera vilka användningsfall som presenterar offentliga certifikat för klientautentisering; konfigurera om varje system för att presentera ett privat clientAuth-only-certifikat från den nya privata PKI-hierarkin; integrera registrering av privata certifikat i infrastrukturprovisioneringspipelines (cert-manager för Kubernetes, ACME för molnbaserade, WSTEP för Windows AD-anslutna); lägg till övervakning av autentiseringsframgångsfrekvens för mTLS-, RADIUS- och VPN-användningsfall för att upptäcka fel vid borttagning av clientAuth innan de blir kundpåverkande avbrott.
Compliance-team	Måste uppvisa revisionsbevis som visar att organisationen har slutfört migreringen före tidsfristen den 15 mars 2027: reglerade branscher som driftsätter mTLS (PCI DSS 4.0 krav 4), certifikatbaserad nätverksautentisering (HIPAA, DORA) eller enhetsidentitet (CMMC) riskerar efterlevnadsrisker om klientautentiseringscertifikat förnyas utan clientAuth och autentiseringsfel spåras till en icke-kompatibel certifikatutfärdandesituation; DigiCert Trust Pulse Survey (2 juli 2025) fann att 45 procent av företagen upplevde certifikatrelaterade driftstopp, och revisionsresultat relaterade till fel i certifikatstyrningen är en direkt konsekvens av oupptäckta dubbla EKU-beroenden.	Inkludera status för migrering av dubbla EKU i det kvartalsvisa bevispaketet för efterlevnad: andel offentligt betrodda certifikat som fortfarande har clientAuth, andel användningsfall för klientautentisering som migrerats till privata certifikat och autentiseringsavbrott som kan hänföras till borttagning av clientAuth; mappa mellanliggande CA-deadline den 15 juni 2026 och deadline för lövcertifikat den 15 mars 2027 till interna efterlevnadsmilstolpar; bekräfta att den privata PKI-hierarkin producerar revisionsklara certifikatstyrningsrapporter på begäran (utfärdande CA, EKU, utgångsdatum, ägare, registreringsmetod) utan manuell sammansättning; verifiera täckningen av automatisering av privat CA-registrering så att 47-dagars giltighet från mars 2029 inte introducerar skyldigheter att förnya manuella certifikat.
CISO: er	Dual-EKU-mandatet är en operativ risk på styrelsenivå: autentiseringsfel orsakade av borttagning av clientAuth kommer inte att meddelas som certifikatfel utan som TLS-handskakningsfel, meddelanden om nekad åtkomst, förlust av VPN-anslutning, offline-händelser för IoT-enheter och CI/CD-pipelinfel utan uppenbar orsak; DigiCert Trust Pulse Survey (2 juli 2025) fann att 37.5 procent av certifikatrelaterade avbrott spårades till utgångna certifikat, men felläget för dual-EKU är svårare att diagnostisera än utgång eftersom certifikatet är giltigt; den komprimerade giltighetstidslinjen (47 dagar i mars 2029) innebär att förnyelsehändelser inträffar åtta gånger per år, vilket multiplicerar exponeringen för oupptäckta beroenden.	Finansiera ett program för att upptäcka och inventera certifikat med hjälp av CertSecure-hanterare som en omedelbar prioritet, slutfört före den 15 juni 2026; finansiera byggandet av den privata PKI-hierarkin eller PKIaaS-engagemang innan den mellanliggande CA-deadline tvingar fram akuta åtgärder; kräva att status för dubbel EKU-migrering, täckning av automatisering av privat PKI-registrering och mätvärden för autentiseringsavbrott som kan hänföras till fel i certifikatsyfte rapporteras som nyckeltal på styrelsenivå; utvärdera PKI som en tjänst för att den privata CA-hierarkin ska undvika att bygga och driva HSM-infrastruktur under tidspress; föreskriva att planering för privata CA-nyckelalgoritmer efter kvantmigrering ingår i den årliga PKI-programgranskningen.

Checklista för övergång till dubbel EKU: Problem, affärspåverkan, rekommenderad åtgärd och ägare

Använd den här checklistan före den mellanliggande CA-deadline den 15 juni 2026 och den 15 mars 2027 för att identifiera övergångsluckor, förstå den affärsmässiga inverkan av varje lucka och tilldela ägarskap för åtgärden.

Utgåva	Business Impact	Rekommenderad åtgärd	Ägare
Ingen inventering av certifikat som innehåller både serverAuth- och clientAuth EKU-värden	Organisationer kan inte identifiera vilka certifikat som i tysthet kommer att förlora clientAuth vid förnyelse; upptäckt efter deadline innebär åtgärd under avbrottstryck snarare än planerad migrering; DigiCert Trust Pulse Survey (juli 2025) fann att 45 procent av företagen upplevde certifikatrelaterade driftstopp, och oupptäckta beroenden mellan dubbla EKU:er är den primära källan till dessa driftstopp för detta mandat.	Distribuera CertSecure-hanterare för fullständig certifikatidentifiering över alla CA-källor, inklusive publika CA:er, AWS Private CA, Azure Key Vault, HashiCorp Vault PKI och lokala AD CS; filtrera inventering för certifikat som bär både OID 1.3.6.1.5.5.7.3.1 och OID 1.3.6.1.5.5.7.3.2; mappa varje dubbel-EKU-certifikat till det system som presenterar det och det system som förlitar sig på det för klientautentisering; skapa en riskrankad migreringstidslinje baserad på utgångsdatum	PKI-teamet + CISO
Ingen privat PKI-hierarki för klientautentiseringscertifikat	Utan en privat CA finns det ingen kompatibel källa för endast clientAuth-certifikat; organisationer står inför en strikt deadline (15 mars 2027) utan reservkrav: offentliga CA:er kan inte utfärda clientAuth-certifikat efter det datumet, och det finns ingen respitperiod för organisationer som inte har byggt en privat CA.	Designa och driftsätt en privat CA-hierarki med dedikerade utfärdande CA:er för klientautentisering; skydda CA:s privata nycklar med FIPS 140-3 nivå 3 HSM; konfigurera certifikatmallar med endast clientAuth EKU och ingen serverAuth; alternativt anlita Encryption Consultings PKIaaS för en heltäckande privat CA som byggts, drivits och hållits kompatibel under snäva tidsfrister	PKI-teamet + säkerhetsarkitekten
Privat rot-CA inte distribuerad till alla förlitande partssystem	Klientcertifikat som utfärdas av den privata PKI:n avvisas av system som inte har installerat den privata rot-CA:n; autentiseringsfel uppstår trots att certifikatet är korrekt konfigurerat med clientAuth, eftersom det mottagande systemet inte litar på den utfärdande CA-kedjan.	Distribuera den privata rot-CA:n till alla Windows-domänanslutna system via grupprincip (arkivet för betrodda rotcertifieringsutfärdare); distribuera till Linux-system via update-ca-certificates genom Ansible, Chef eller Puppet; distribuera till mobila och IoT-system via MDM; testa autentiseringsframgång från representativa system innan produktionsarbetsbelastningar migreras; dokumentera förtroendedistributionsplanen och bekräfta täckning före varje migreringsfas.	Plattformsteamet + PKI-teamet
Användningsfall för klientautentisering vid manuell certifikatförnyelse	Vid maximal TLS-giltighet på 47 dagar från mars 2029 producerar manuell förnyelse av klientcertifikat åtta förnyelsehändelser per år per certifikat. Manuella processer med den frekvensen är operativt ohållbara och introducerar åtta avbrottsmöjligheter per certifikat per år om någon förnyelse missas eller försenas.	Registrera alla privata klientcertifikat i automatisk förnyelse med hjälp av lämpligt registreringsprotokoll: WSTEP för Windows AD-anslutna maskiner (zero-touch via GPO), ACME för molnbaserade och containerbaserade arbetsbelastningar, SCEP för mobila och IoT-enheter, EST för generell registrering; integrera registrering i infrastrukturens provisioneringspipelines så att nya system automatiskt får privata klientcertifikat utan manuell inblandning från PKI-teamet.	Plattformsteamet + PKI-teamet
Ingen övervakning av autentiseringsframgångsfrekvens för mTLS, RADIUS och VPN	Fel vid borttagning av ClientAuth presenteras som generiska fel (TLS-handskakningsfel, åtkomst nekad, peer-verifieringsfel, timeout för autentisering) som lätt kan misstas som problem med nätverk, krypteringssvit eller programkonfiguration. Utan specifik övervakning av autentiseringsframgångsfrekvensen identifieras grundorsaken först efter längre driftstopp.	Lägg till övervakning av autentiseringsframgångsfrekvens för alla mTLS-slutpunkter, RADIUS-autentiseringshändelser, VPN-anslutningsförsök och incheckningar av IoT-enheter; konfigurera aviseringar om förändringar i autentiseringsfelfrekvensen som korrelerar med certifikatförnyelsehändelser; inkludera EKU-validering i certifikathälsokontroller så att ett förnyat certifikat som saknar clientAuth flaggas innan det orsakar ett autentiseringsfel i produktion.	Plattformsteam + säkerhetsarkitekt
Privata CA-nyckelalgoritmer ingår inte i planen efter kvantmigrering	NIST FIPS 203/204/205 (slutförda 13 augusti 2024) kräver att RSA och ECC ersätts i alla PKI-hierarkier på NIST IR 8547:s tidslinje för utfasning; en privat CA-hierarki som byggts under tidsfristen för dubbel EKU utan planering efter kvantalgoritmer måste byggas om eller omkodas före utfasningsfristen, vilket förvärrar migreringsbördan.	Klassificera privata CA-nyckelalgoritmer (RSA, ECDSA P-256/P-384) mot NIST IR 8547-avvecklingsmilstolpar vid arkitekturdesigntidpunkten; planera migrering till ML-DSA (FIPS 204) för CA-signeringsnycklar; använd CBOM-säkerhet att upptäcka alla kryptografiska tillgångar i den privata PKI-hierarkin; spåra migreringskrav genom PQC:s kompetenscentrumutvärdera PQC-beredskap tjänster för en strukturerad migrationsbedömning	Säkerhetsarkitekt + PKI-team

Mandatet: Vad SC-081 och Chrome Root Program kräver

Offentliga certifikatutfärdare får inte längre utfärda TLS-servercertifikat som inkluderar clientAuth Extended Key Usage. Mellanliggande CA-certifikat som stöder både serverAuth och clientAuth och är kopplade till en offentligt betrodd rot måste tas bort.

Alla organisationer som behöver klientautentiseringscertifikat måste hämta dem från en dedikerad, specialbyggd PKI-hierarki som per definition inte kan vara en offentlig CA-hierarki som är betrodd i webbläsarens rotlager.

Det mest kritiska datumet för organisationer är den 15 juni 2026. UNDERORDNADE/mellanliggande CA-certifikat: alla nya mellanliggande certifikat som lämnas ut till CCADB på eller efter det datumet måste endast bekräfta serverAuth, och inga nya mellanliggande certifikat med dubbla EKU-certifikat får läggas till i Chrome-betrodda hierarkier.

Från och med den 15 mars 2027 måste alla nyligen utfärdade lövcertifikat som är kopplade till en Chrome-betrodd rot också vara endast serverAuth. Från och med denna tidpunkt kommer Chrome att avvisa offentliga TLS-lövcertifikat som fortfarande innehåller clientAuth EKU, och de berörda handskakningarna kommer att misslyckas. Certifikat som utfärdats före den tillämpliga tidsgränsen förblir giltiga tills de löper ut, men vid förnyelse utfärdas de på nytt utan clientAuth.

För att kvalificera sig som en dedikerad TLS-serverautentiserings- PKI-hierarki enligt denna policy:

1. Alla motsvarande oförfallet och oåterkallad underordnade CA-certifikat som drivs under en befintlig rot som ingår i Chrome Root Store MÅSTE:
   • om det lämnas ut till CCADB före den 15 juni 2026: inkludera utökad nyckelanvändning tillägg och (a) endast hävda ett extendedKeyUsage-syfte för id-kp-serverAuth eller (b) endast hävda extendedKeyUsage-ändamål för id-kp-serverAuth och id-kp-klientautentisering.
   • om det lämnas ut till CCADB den eller efter den 15 juni 2026inkluderar extendedKeyUsage-tillägget och hävdar endast ett extendedKeyUsage-syfte för id-kp-serverAuth.
   • INTE innehåller en offentlig nyckel som motsvarar något annat outgånget eller oåterkallat certifikat som hävdar olika extendedKeyUsage-värden.
2. Alla motsvarande prenumerantcertifikat utfärdade den 15 mars 2027 eller senare, MÅSTE inkludera tillägget extendedKeyUsage och endast hävda ett extendedKeyUsage-syfte för id-kp-serverAuth.

Från och med den 15 mars 2027 måste varje nyligen utfärdat offentligt betrott TLS-certifikat tjäna ett enda syfte: serverautentisering. Det får endast innehålla serverAuth EKU, med clientAuth OID helt borttaget. Det offentliga CA-certifikatet ska se ut så här:

Följande tabell anger obligatoriska och tillåtna fält för prenumerant-TLS-servercertifikat (leaf-certifikat) som utfärdats av offentligt betrodda certifikatutfärdare enligt mandatet från certifikatutfärdare/webbläsarforum, 7.1.2.7 Prenumerant-(server-)certifikatprofil:

Fält / Utvidgning	Närvaron	Tillåtna värden och krav
version	MÅSTE	v3 (heltal 2)
serienummer	MÅSTE	Positivt heltal, minst 64 bitar utdata från en CSPRNG.
subjectAltName	MÅSTE	Denna tilläggsfil MÅSTE innehålla minst en post. Varje post MÅSTE antingen vara en dNS-namn or iPad-adress som beskrivs i Avsnitt 7.1.4.2.
grundläggande begränsningar	MÅSTE	För ett prenumerantcertifikat (lövcertifikat), cA-fält MÅSTE sättas till FALSKT. söklängdBegränsning FÅR INTE vara närvarande.
nyckelanvändning	MÅSTE	Det är ett kritiskt attribut. De acceptabla nyckelanvändningsvärdena varierar beroende på om certifikatets ämneOffentlig nyckelinformation identifierar en RSA-publik nyckel eller en ECC offentlig nyckel. CA:er MÅSTE se till att nyckelanvändningen är lämplig för certifikatets offentliga nyckel. De tillåtna nyckelanvändningarna är digitalsignatur + nyckelkryptering för RSA och endast digital signatur för ECDSA
utökad nyckelanvändning	MÅSTE	Följande värde MÅSTE finnas: • id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) Följande värde FÅR INTE förekomma: • id-kp-klientautentisering (OID: 1.3.6.1.5.5.7.3.2) – Förbjudet för nyutfärdade lövcertifikat från och med 15 mars 2027 enligt Chrome Root Program Policy v1.8, avsnitt 1.3.2
certifikatpolicyer	MÅSTE	Om det finns MÅSTE certifikatpolicytillägget innehålla minst ett Policyinformation.
myndighetsinformationsåtkomst	MÅSTE	Det är inte ett kritiskt fält. • nyckelidentifierare- MÅSTE finnas. MÅSTE vara identiskt med fältet subjectKeyIdentifier för den utfärdande CA:n. • authorityCertIssuer- FÅR INTE vara närvarande • auktoritetCertSerienummer- FÅR INTE vara närvarande
ämnesnyckelidentifierare	MÅSTE	CA MÅSTE generera en ämnesnyckelidentifierare som är unik inom ramen för alla certifikat som den har utfärdat för varje unik publik nyckel
cRLDistributionPoints	MÅSTE	Detta tillägg MÅSTE finnas och FÅR INTE markeras som kritiskt. CRL-distributionspunkternas tillägg MÅSTE finnas i: • Underordnade CA-certifikat; och • Prenumerantcertifikat som 1) inte kvalificerar som ”Kortlivade prenumerantcertifikat” och 2) inte inkluderar ett tillägg för åtkomst till auktoritetsinformation med en id-ad-ocsp accessMethod.

Anmärkning om extendedKeyUsage: CA /Browser Forum TLS Baseline Requirements v2.2.8, avsnitt 7.1.2.7.10, listar fortfarande id-kp-clientAuth som FÅR, vilket är tillåtet men inte obligatoriskt på BR-nivå. Det strikta förbudet kommer från Chrome Root Program Policy v1.8, avsnitt 1.3.2 , som kräver att alla prenumerantcertifikat som utfärdas från och med den 15 mars 2027 endast innehåller id-kp-serverAuth. CA:er måste följa denna policy för att finnas kvar i Chrome Root Store, vilket gör begränsningen praktiskt taget universell.

Ballot SC-081 introducerar också en gradvis minskning av den maximala giltighetsperioden för offentligt betrodda TLS-certifikat. Giltigheten minskar till 200 dagar från mars 2026, 100 dagar från mars 2027 och 47 dagar från mars 2029. Certifikat med kortare livslängd gör automatiserad registrering via ACME, WSTEP, SCEP och EST till ett krav snarare än en bekvämlighet. Alla organisationer som förlitar sig på manuell certifikatförnyelse kommer att möta en ohållbar driftsbörda i takt med att giltighetsfönstren krymper. Detta förstärker argumenten för en hanterad privat PKI med helt automatiserad livscykelhantering inbyggd från dag ett.

Tidslinjen för den offentliga CA

Det mest kritiska datumet för organisationer är den 15 juni 2026 , då Chrome aktivt kommer att avvisa offentliga TLS-certifikat som innehåller clientAuth EKU från och med denna tidpunkt. Alla nya underordnade CA (mellanliggande CA) som lämnas ut till Common CA Database (CCADB) på eller efter detta datum får endast innehålla id-kp-serverAuth . Inga nya mellanliggande CA:er med blandade EKU-certifikat kan läggas till i Chrome-betrodda hierarkier från och med detta datum. Alla system som presenterar ett sådant certifikat i en Chrome-validerad TLS-handskakning kommer att misslyckas. Befintliga certifikat som utfärdats före detta datum förblir giltiga tills de löper ut, men när de förnyas kommer de att utfärdas utan clientAuth.

CA:er har inte väntat på den hårda deadline i mars 2027. De flesta större CA:er började ta bort clientAuth långt före den, drivet av Chromes mellanliggande CA-deadline i juni 2026, och följande är den fullständiga tidslinjen från och med juni 2026:

Datum	CA / Program	Milestone	Status
Sju 15, 2025	SSL.com	Slutar utfärda clientAuth som standard	GODKÄND
Oktober 1, 2025	DigiCert	Slutar utfärda clientAuth som standard	GODKÄND
Oktober 14, 2025	sektigo	Slutar utfärda clientAuth som standard	GODKÄND
Februari 11, 2026	Låt oss kryptera	Standard-ACME-profilen tar bort clientAuth	GODKÄND
Juni 15, 2026	Google Chrome	Avvisar offentliga TLS-certifikat med clientAuth EKU	KRITISK
July 8, 2026	Låt oss kryptera	tlsclient-profilen har avbrutits permanent	KOMMANDE
Februari 10, 2027	sektigo	Hård deadline, inga undantag	KOMMANDE
Mar 1, 2027	DigiCert	Fullständig borttagning, inga undantag	KOMMANDE
Mar 15, 2027	Chrome -rotprogram	Sista deadline för branschen	DEADLINE

Varför tas klientautentiserings-EKU bort?

Det är frestande att framställa detta mandat enbart som en börda för efterlevnaden. I verkligheten täcker det ett genuint och underskattat säkerhetsgap. Att förstå följande säkerhetsresonemang hjälper organisationer att förstå varför denna förändring tillämpas:

• Public Web PKI byggdes för att autentisera servrar till webbläsare: Processerna Domänvalidering (DV) och Organisationsvalidering (OV) som används av publika certifikatutfärdare är utformade för att verifiera domänägande och organisationsidentitet för serverautentisering. De är inte utformade för att fastställa att ett givet system är auktoriserat att agera som en klient i ett specifikt autentiseringssammanhang. Att inkludera clientAuth EKU i ett offentligt utfärdat certifikat innebär en valideringsstandard som aldrig har utförts.
• Kompromettering av privat nyckel har förstärkta konsekvenser: När ett TLS-servercertifikat innehåller både serverAuth och clientAuth, gör en komprometterad privat nyckel dubbel skada. En angripare som stjäl en servers privata nyckel kan inte bara utge sig för att vara den servern för klienter, utan också presentera certifikatet som en giltig klientautentiseringsuppgift för alla system som litar på den utfärdande certifikatutfärdaren och kontrollerar clientAuth EKU. En enda kompromiss blir lateral förflyttningskapacitet. Att ta bort clientAuth från servercertifikat eliminerar denna andra attackvektor helt.
• Separation möjliggör korrekt livscykelhantering: Servercertifikat och klientcertifikat har fundamentalt olika livscykelkrav. Servercertifikat är knutna till domännamn, förnyas på offentlig infrastruktur och hanteras av webbdriftsteam. Klientcertifikat är knutna till systemidentiteter och kräver återkallningsfunktioner som tillämpas på applikationsnivå. Att slå ihop dem till ett enda certifikat gör det svårare att hantera båda korrekt. Separation återställer tydligt ägarskap och ansvarsskyldighet.

Effekten av att ta bort klientautentiserings-EKU:n

Borttagningen av clientAuth EKU påverkar organisationer som för närvarande använder ett offentligt betrott TLS-servercertifikat för klientautentisering.

Organisationer som använder offentliga certifikat enbart för standard HTTPS- serverautentisering påverkas i allmänhet inte. Deras webbplatser, portaler och offentliga applikationer kan fortsätta att använda certifikat som endast innehåller serverAuth EKU.

Effekten uppstår när samma offentliga certifikat också används för att autentisera en användare, enhet, server, applikation eller arbetsbelastning till ett annat system. När certifikatet förnyas eller utfärdas på nytt utan clientAuth EKU, kanske det mottagande systemet inte längre accepterar det som en giltig klientautentiseringsuppgift.

Viktigt är att certifikatet fortfarande kan vara giltigt, inte ha gått ut och vara betrott. Felet uppstår eftersom certifikatet inte längre är auktoriserat för klientautentisering.

För att hjälpa dig identifiera vad som kan gå sönder och varför, visar följande tabell de potentiella påverkansområdena i din organisation.

Användningsfall	Potentiell inverkan
Ömsesidig TLS (mTLS)	Under en mTLS-anslutning kan det mottagande systemet verifiera att klientens certifikat innehåller clientAuth EKU. Om den EKU:n saknas kan certifikatet avvisas och TLS-handskakningen misslyckas. Detta kan påverka mikrotjänster, API-gateways, tjänstnät, företag-till-företag-integrationer och anpassad applikation-till-applikation-autentisering. Felet kan visas som ett generiskt TLS-handskakningsfel eller certifikatvalideringsfel snarare än ett utgångsproblem.
RADIUS, IEEE 802.1X och EAP-TLS	Vid certifikatbaserad nätverksautentisering presenterar användare eller enheter ett klientcertifikat för att bevisa sin identitet. Om autentiseringsservern kräver clientAuth EKU och det förnyade certifikatet inte innehåller det, kommer autentiseringsbegäran att misslyckas. Som ett resultat kan berörda enheter inte ansluta till företagets Wi-Fi, trådbundna nätverk eller VPN-tjänster.
OpenVPN, Cisco Secure Client och Fortinet VPN	Många certifikatbaserade VPN-distributioner kräver att det anslutande användar- eller enhetscertifikatet innehåller clientAuth EKU. Om ett offentligt certifikat som tidigare använts för VPN-autentisering förnyas utan den EKU:n kan VPN-gatewayen avvisa det. Användare kanske då inte kan upprätta en säker fjärråtkomstanslutning.
Microsoft Exchange och server-till-server-kommunikation	SMTP-anslutning, EWS och partnerkommunikationskonfigurationer använder certifikat för ömsesidig autentisering eller server-till-server-autentisering. Om den anslutande serverns certifikat förväntas stödja klientautentisering kan borttagning av clientAuth EKU störa autentiseringen eller e-postflödet. Den faktiska effekten beror på Exchange-versionen, anslutningskonfigurationen och kraven för certifikatvalidering.
Fjärrskrivbords- och RDP-gatewaymiljöer	Remote Desktop Gateway använder vanligtvis ett servercertifikat för att autentisera sig mot anslutande klienter. Miljöer som också använder certifikatbaserad klientautentisering, smartkortsautentisering eller anpassade kontroller för ömsesidig autentisering kan dock vara beroende av dedikerade klientcertifikat. Återanvändning av ett offentligt servercertifikat för ett sådant ändamål kan orsaka autentiseringsfel efter förnyelse.
IoT och enhetsidentitet	IoT-, industriella och inbäddade enheter kan använda certifikat för att autentisera mot molntjänster, hanteringsplattformar eller enhetsgateways. Om ett enhetscertifikat förnyas utan den nödvändiga clientAuth EKU:n kan plattformen avvisa enhetens identitet. Detta kan förhindra enhetsincheckning, telemetriöverföring, fjärrhantering, programuppdateringar eller kommandokörning.
API och server-till-server-autentisering	Applikationer och servrar fungerar ofta som TLS-klienter när de anropar interna eller externa API:er. Om de presenterar ett offentligt TLS-certifikat som sin klientidentitet kan det mottagande API:et avvisa certifikatet när clientAuth har tagits bort. Detta kan avbryta integrationer även om samma certifikat fortsätter att fungera normalt för inkommande HTTPS-anslutningar.
CI/CD- och DevOps-arbetsbelastningar	Byggservrar, distributionsagenter, containrar och automationsplattformar kan använda certifikat för att autentisera mot register, Kubernetes-kluster, artefaktdatabaser eller interna API:er. När ett förnyat certifikat inte längre stöder klientautentisering kan automatiserade pipelines misslyckas utan en omedelbart uppenbar certifikatrelaterad orsak.

Varför dessa fel kan vara svåra att diagnostisera

Borttagning av clientAuth ger inte nödvändigtvis ett tydligt meddelande om att EKU:n saknas. Beroende på applikation, operativsystem eller TLS-bibliotek kan felet rapporteras som:

• TLS-handskakningsfel
• Certifikatets syfte är inte tillåtet
• Certifikat som inte stöds
• Felaktigt certifikat
• nekat tillträde
• Klientidentitet avvisad
• Peer-verifiering misslyckades
• Autentiseringstimeout

Detta gör det lätt att feldiagnostisera problemet som ett problem med förtroendekedjan, utgångsdatumet, nätverket, chiffersviten eller programkonfigurationen.

Den största risken är inte begränsad till certifikat som redan är kända för att stödja ömsesidig TLS . Den inkluderar odokumenterade system som har förlitat sig på clientAuth EKU eftersom offentliga TLS-certifikat historiskt sett inkluderade den som standard.

Organisationer bör identifiera dessa beroenden innan de berörda certifikaten förnyas eller utfärdas på nytt. Att vänta tills förnyelsen sker kan leda till att ett rutinmässigt certifikatbyte blir ett oväntat avbrott som påverkar programanslutning, nätverksåtkomst, fjärråtkomst eller enhetsautentisering.

Lösningen: Övergång till en privat CA

Offentligt betrodda certifikatutfärdare begränsas från att utfärda TLS-certifikat för klientautentisering (dvs. certifikat som inkluderar clientAuth EKU). Som ett resultat kan organisationer inte längre förlita sig på offentliga TLS-certifikat för interna klientautentiseringsanvändningsfall som ömsesidig TLS, enhetsautentisering, arbetsbelastningsidentitet, API-autentisering och server-till-server-kommunikation.

En privat PKI löser denna utmaning eftersom den fungerar utanför det webbläsarbetrodda offentliga PKI-ekosystemet. Dess rot-CA är endast betrodd av de användare, enheter, applikationer och system som valts av organisationen. Därför kan organisationen utfärda dedikerade klientcertifikat som inkluderar clientAuth EKU utan att påverka eller förlita sig på offentliga webbläsarförtroenden.

Privat PKI möjliggör också korrekt åtskillnad mellan de två certifikatsyftena:

• Offentliga eller privata servercertifikat som endast innehåller serverAuth EKU
• Dedikerade privata klientcertifikat som endast innehåller clientAuth EKU (OID 1.3.6.1.5.5.7.3.2), utan serverAuth OID, som visas på skärmdumpen nedan:

Denna separation säkerställer att ett servercertifikat endast används för att autentisera en server, medan ett klientcertifikat endast används för att autentisera en användare, enhet, applikation eller arbetsstation. Det minskar effekten av att privata nycklar komprometteras och ger tydligare kontroll över utfärdande, ägande, förnyelse och återkallelse av certifikat.

Med en privat PKI kan organisationer också definiera certifikatpolicyer för att uppfylla sina specifika säkerhetskrav, inklusive identitetsvalideringsprocedurer, certifikatgiltighetsperioder, namngivningskonventioner, godkända algoritmer, krav på nyckelskydd och registreringsmetoder. Certifikat kan utfärdas och förnyas automatiskt med hjälp av protokoll som ACME, SCEP, EST, CMP, WSTEP eller Microsoft Auto-Enrollment.

Denna förändring ger organisationer möjlighet att utforma autentiseringsarbetsflöden som är skräddarsydda efter deras specifika behov, utan att begränsas av begränsningar från offentliga certifikatutfärdare. Följande avsnitt beskriver hur PKI-hierarkin bör se ut.

Hur PKI-hierarkin måste förändras

Att ta bort clientAuth EKU från offentligt betrodda TLS-certifikat är inte bara en ändring av certifikatmallen. Det kräver att organisationer separerar autentisering av offentliga servrar från intern klientautentisering på PKI-arkitekturnivå.

Enligt den nya modellen bör offentligt betrodda certifikat endast användas för att autentisera servrar till externa klienter, till exempel webbläsare som ansluter till webbplatser och offentligt riktade applikationer. Dessa certifikat innehåller endast serverAuth EKU och fortsätter att vara kedjade till en offentligt betrodd rot-CA.

Klientautentisering måste flyttas till en separat privat PKI-hierarki. Denna privata hierarki utfärdar ändamålsspecifika certifikat till användare, enheter, applikationer, arbetsbelastningar och servrar som behöver autentiseras som klienter.

Målarkitekturen bör därför inkludera:

• En offentlig TLS PKI-hierarki för internetriktade servercertifikat som endast innehåller serverAuth
• En privat offline, icke-domänansluten rot-CA skyddad med en FIPS 140-3 nivå 3-kompatibel hårdvarusäkerhetsmodul
• En eller flera privata utfärdande CA:er dedikerade till klientautentisering. HSM-stödd skydd för utfärdande CA:ers privata nycklar.
• Klientcertifikatprofiler begränsade endast till clientAuth EKU (inget serverAuth OID finns), med nyckelanvändning inställd på digitalSignature, så certifikatet kan inte användas för serverautentisering under några omständigheter.

  

• Separata certifikatprofiler för enheter, användare, arbetsbelastningar, API:er och andra identiteter
• CRL- eller OCSP-tjänster för återkallelse av certifikat, med CDP-slutpunkter konfigurerade som offentliga eller privata baserat på användningsfallet och organisationens tillgänglighetskrav.
• Automatiserad certifikatregistrering, förnyelse och återkallelse
• Distribution av den privata rot-CA:n till system som måste lita på klientcertifikaten

Med denna arkitektur kan en server som utför båda rollerna behöva två separata certifikat:

1. Ett servercertifikat som innehåller serverAuth för att acceptera inkommande TLS-anslutningar
2. Ett klientcertifikat som innehåller clientAuth för autentisering vid anslutning till ett annat system

Denna separation säkerställer att varje certifikat och privat nyckel har ett tydligt definierat syfte. Det gör det också möjligt för organisationer att tillämpa olika policyer för identitetsvalidering, livscykel, återkallelse och nyckelskydd för server- och klientidentiteter.

Att utforma, driftsätta och kontinuerligt driva denna privata hierarki kräver specialiserad PKI-expertis, säker HSM-infrastruktur, automatisering av certifikatlivscykeln, återkallningstjänster, övervakning, katastrofåterställning och löpande policyhantering. Följande avsnitt i den här bloggen går igenom exakt hur Encryption Consultings PKIaaS levererar en fullständigt hanterad privat CA som byggs, drivs och hålls kompatibel för din räkning.

PKIaaS av Encryption Consulting

Att bygga och driva en privat PKI-hierarki är inte tekniskt komplicerat i konceptet, men det är krävande i utförande, inklusive anskaffning av HSM:er, offline-root-CA-ceremonier, CDP/AIA-tillgänglighet, automatisering av certifikatlivscykeln, policydokumentation och registreringsåtgärder.

Encryption Consultings PKI-as-a-Service (PKIaaS) kan möta snäva deadlines och leverera en komplett privat PKI som en hanterad tjänst . Encryption Consulting bygger den, driver den och ser till att den uppfyller kraven, medan fullt ägande förblir ditt.

Ingen leverantörslåsning: Dina privata nycklar, CA-hierarki och certifikat förblir helt dina. Om du väljer att migrera PKI:n till din lokala miljö kommer Encryption Consulting att genomföra en formell, dokumenterad nyckelöverföringsceremoni. CA:ns privata nyckelmaterial kommer att överföras säkert till din HSM med hjälp av autentiserade, dubbelkontrollerade exportprocedurer.

Dina befintliga certifikat kommer att förbli giltiga, utan behov av omutfärdande. Hela överföringsprocessen kommer att vara fullständigt dokumenterad och granskningsbar, vilket säkerställer driftskontinuitet och fullständigt ägande.

Du äger PKI:n. Vi bygger, hanterar och driver den åt dig. Så här fungerar engagemanget.

Fas 1: Identifiering och certifikatinventering

Innan den nya PKI:n utformas tar Encryption Consulting fram en komplett bild av kundens nuvarande certifikatmiljö. Detta är avgörande eftersom många system förlitar sig på clientAuth utan att det beroendet formellt upptäcks.

Vi stöder flera metoder för certifikatidentifiering , inklusive nätverksskanning, agentlös skanning och integrationsbaserad identifiering.

Integrationsbaserad identifiering ger en auktoritativ bild av certifikatdata i realtid genom att ansluta direkt till certifikatutfärdare och molnplattformar som AWS, Microsoft Azure och Google Cloud. Den kan också undersöka applikationskonfigurationer, inklusive mTLS-inställningar, och integrera med Kubernetes-kluster, plattformar för hemlighetshantering som HashiCorp Vault och CyberArk Conjur, och CI/CD-pipelines, inklusive GitHub Actions, Jenkins och GitLab.

Ytterligare identifieringsfunktioner inkluderar passiv övervakning via proxyservrar, brandväggar och nätverksanslutningar; katalogskanning över LDAP och Active Directory; och identifiering via konfigurationshanteringsverktyg som Ansible, Chef och Puppet.

Resultatet är en komplett certifikatinventering som innehåller certifikatämnen, SAN, EKU, utfärdare och utgångsdatum. Varje certifikat som bär clientAuth mappas till både det system som presenterar det och det system som förlitar sig på det för autentisering.

Resultaten organiseras sedan i en riskrankad migreringstidslinje. Kunden får en tydlig bild av vilka system som kan komma att misslyckas, när de är i riskzonen och den potentiella affärspåverkan om ett certifikat förnyas utan clientAuth.

Fas 2: PKI-arkitekturdesign

Ingenting är byggt förrän arkitekturen har granskats och godkänts. Varje certifikatutfärdare, varje certifikatmall och varje slutpunkt för återkallelse specificeras på papper innan någon nyckel genereras.

Arkitekturen inkluderar vanligtvis en offline icke-domänansluten rot-CA och separata utfärdande certifikatutfärdare för klientautentisering, intern TLS och enhetsidentitetsautentisering. Denna separation säkerställer att klientcertifikat endast innehåller clientAuth.

Certifikatprofiler definieras för varje användningsfall, inklusive algoritmer, giltighetsperioder, ämnes- och SAN-format, nyckelanvändning, EKU, policy-OID:er och återkallningsslutpunkter. CRL- och OCSP-platser konfigureras som offentliga eller privata baserat på var certifikaten kommer att användas.

Detta skapar en tydlig, syftesdriven hierarki utan dubbla EKU-certifikat och utan oklarheter om vad varje certifikat är auktoriserat att göra.

Fas 3: Root CA-ceremoni och infrastrukturbyggande

Rot-CA:ns privata nyckel genereras och skyddas i en FIPS 140-3 nivå 3-kompatibel hårdvarusäkerhetsmodul (HSM). Rot-CA:n förblir säkert lagrad i datacentret och hålls offline mellan auktoriserade certifikatsigneringsåtgärder. För katastrofåterställning underhålls en krypterad och åtkomstkontrollerad säkerhetskopia av nyckelmaterialet i en geografiskt separat HSM-miljö.

Encryption Consulting bygger sedan den stödjande PKI-infrastrukturen, inklusive förstärkta utfärdande certifikatutfärdare, OCSP-svarare, CRL-publiceringstjänster och certifikathanteringsfunktioner.

Fas 4: Distribution i Trust Store

Certifikat som utfärdas av en privat PKI är endast betrodda när den privata rot-CA:n är installerad på varje system som validerar dem. I den här fasen distribueras det nya privata rot-CA-certifikatet till alla förlitande partssystem inom räckvidden.

Windows-domänanslutna system får rot-CA:n via grupprincip, som skickas till arkivet för betrodda rotcertifieringsutfärdare. Linux-system uppdateras med hjälp av update-ca-certificates, som distribueras via Ansible, Chef eller Puppet beroende på den befintliga konfigurationshanteringsverktygskedjan.

Efter distribution testas representativa system med hjälp av nyligen utfärdade klientcertifikat. Denna fas slutförs först efter att kunden bekräftat att certifikatkedjorna är betrodda och autentiseringen lyckas.

Fas 5: Implementering av PKIaaS-gateway

I den här fasen driftsätts PKIaaS-gatewayen, en uppsättning registrerings- och hanteringskomponenter som är installerade i klientens egen infrastruktur. Gatewayen kopplar klientens interna system till Encryption Consultings värdbaserade CA-hierarki. Alla certifikatförfrågningar går igenom den. CA:ns privata nycklar finns kvar i Encryption Consultings HSM:er hela tiden. Gatewayen hanterar endast registreringsprotokolltrafik, aldrig signeringsåtgärder.

Gatewayen exponerar en WS-Trust Enrollment Protocol (WSTEP)-slutpunkt, vilket möjliggör helautomatisk certifikatregistrering för Windows-maskiner utan någon användar- eller administratörsinteraktion. Certificate Enrollment Policy-tjänsten (CEP) är konfigurerad för att upptäcka vilka certifikatmallar den är berättigad till baserat på dess Active Directory-identitet och grupprincipmedlemskap.

Webbtjänsten för certifikatregistrering validerar begäran mot registreringspolicyn, dirigerar den via PKIaaS-gatewayen till den utfärdande certifikatutfärdaren och returnerar det signerade certifikatet direkt till maskinen, som automatiskt installerar det i rätt certifikatarkiv. Från och med GPO-konfigurationen kräver hela livscykeln, policyidentifiering, begäran, signering, installation och förnyelse, ingen manuell åtgärd.

En webbaserad instrumentpanel där behöriga användare kan begära certifikat, skicka in CSR:er, söka i certifikatförteckningen, förnya certifikat, återkalla komprometterade eller oanvända certifikat och granska certifikatstatus.

Instrumentpanelen inkluderar rollbaserad åtkomstkontroll. Certifikatshanterare kan begära eller återkalla certifikat, granskare kan granska rapporter och aktivitetsloggar, och administratörer kan hantera godkända profiler och registreringspolicyer.

Varje registrering, förnyelse, återkallelse, godkännande, konfigurationsändring och administrativ inloggning registreras i en granskbar aktivitetslogg.

Fas 6: Certifikatmigrering: System för system

När förtroende- och registreringstjänsterna är i drift börjar Encryption Consulting ersätta offentliga certifikat med dubbla EKU-certifikat med dedikerade privata klientcertifikat.

Migreringen börjar med utvecklings- och stagingmiljöer. Interna tjänster och API:er migreras sedan, följt av nätverksinfrastruktur, inklusive VPN, RADIUS och 802.1X. Affärskritiska system, inklusive Exchange, kärnapplikationer och system inom organisationen, migreras endast efter att test- och rollback-procedurer har bekräftats.

Varje certifikatbegäran skickas med lämplig registreringsmetod, till exempel WSTEP, ACME, SCEP, EST eller hanteringsinstrumentpanelen. Det nya certifikatet utfärdas endast med clientAuth EKU. Applikationen konfigureras för att presentera det nya certifikatet och ett end-to-end-autentiseringstest bekräftar att anslutningen lyckas.

Efter lyckad validering tas det gamla dubbla EKU-certifikatet bort eller återkallas där så är lämpligt, och det nya certifikatet registreras för automatisk förnyelse.

Fas 7: Löpande verksamhet och efterlevnad

Det är i den här fasen som PKIaaS ger kontinuerligt värde utöver den initiala byggprocessen.

Encryption Consultings CLM-plattform hanterar löpande certifikatutfärdande, förnyelse, återkallelse, CRL-publicering, OCSP-tillgänglighet, HSM-övervakning, infrastrukturunderhåll, säkerhetskopieringsvalidering och PKIaaS Gateway-drift.

Registreringstjänster som WSTEP, ACME, SCEP och EST underhålls kontinuerligt så att certifikat kan utfärdas och förnyas utan manuella åtgärder.

Encryption Consulting övervakar även relevanta organisationers säkerhetskrav, utvecklingar inom CA/Browser Forum, kryptografiska standarder, algoritmändringar och uppdateringar av certifikatpolicyer, såsom Post Quantum Cryptography-kompatibilitet . Om en ändring påverkar kundens miljö uppdateras PKI-konfigurationen och certifikatprofilerna före den tillämpliga tidsfristen.

Slutsats

Borttagningen av clientAuth EKU från offentligt betrodda TLS-certifikat markerar ett fundamentalt skifte i hur organisationer måste hantera certifikatbaserad autentisering. Offentliga certifikat kommer att fortsätta att säkra webbplatser och externa tjänster, men klientautentisering för användare, enheter, applikationer och arbetsbelastningar måste flyttas till en specialbyggd privat PKI. Organisationer som misslyckas med att identifiera dolda beroenden mellan dubbla EKU:er riskerar oväntade avbrott när certifikat förnyas utan clientAuth; fel som inte kommer att meddelas som certifikatfel utan som timeouts för autentisering, TLS-handskakningsfel och meddelanden om nekad åtkomst utan uppenbar orsak.

Encryption Consultings PKIaaS erbjuder en komplett väg genom denna övergång. Vi utvärderar den befintliga miljön, identifierar berörda system, designar och bygger den privata PKI:n, skyddar CA-nycklar inom HSM:er, driftsätter registreringstjänster, migrerar certifikat och hanterar miljön kontinuerligt. Automatiserad registrering via WSTEP, ACME, SCEP och EST säkerställer att certifikat utfärdas, förnyas och återkallas utan att det medför ytterligare driftsbörda.

För att börja med en kostnadsfri PKI-beredskapsbedömning, kontakta oss på [email protected] eller besök encryptionconsulting.com/pkiaas.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste slutsatsen från CA/Browser Forum-mandatet: Slutet på dubbla EKU-certifikat?

CA/Browser Forum Ballot SC-081v3 (april 2025) och Chrome Root Program Policy v1.8 eliminerar clientAuth från offentligt betrodda TLS-certifikat enligt ett fastställt schema. Från och med den 15 juni 2026 får ingen ny mellanliggande CA i en Chrome-betrodd hierarki bära dubbla EKU-värden. Från och med den 15 mars 2027 måste varje nyligen utfärdat offentligt betrott TLS-lövcertifikat endast innehålla serverAuth. Organisationer som använder offentliga certifikat för mTLS, RADIUS, VPN, IoT-enhetsidentitet eller server-till-server-autentisering måste migrera dessa användningsfall till en dedikerad privat PKI-hierarki före dessa deadlines, annars riskerar de tysta autentiseringsfel när berörda certifikat förnyas.

Varför är kravet på dubbel EKU viktigt för PKI-team på stora företag?

Företags-PKI-team står inför två konvergerande påtryckningar från samma omröstning. DigiCert Trust Pulse Survey (2 juli 2025) fann att 45 procent av organisationerna upplevde certifikatrelaterade driftstopp under föregående år; kravet på dubbel-EKU introducerar exakt det tysta felläge som producerar den driftstoppet: ett certifikat som förnyas utan clientAuth fortsätter att fungera för HTTPS men misslyckas med alla klientautentiseringsfall med generiska fel. Samtidigt minskar SC-081v3 maximal TLS-giltighet till 47 dagar i mars 2029, vilket innebär att förnyelsehändelser som exponerar dubbel-EKU-beroenden inträffar upp till åtta gånger per år snarare än en gång.

Vilka risker ökar om övergången till dubbel EKU hanteras manuellt eller reaktivt?

Fyra riskkategorier ökar: tysta autentiseringsavbrott (generiska felmeddelanden som är lätta att feldiagnostisera); oupptäckta beroenden (system som förlitar sig på clientAuth utan formell dokumentation); komprimerad reparationstid (vid 47 dagars giltighetstid är fönstret mellan förnyelse och fel sex veckor snarare än tolv månader); och luckor efter kvantmigrering (algoritmer för privata CA-nyckeln måste också migrera till ML-DSA enligt NIST FIPS 204, slutförd 13 augusti 2024; en oplanerad privat PKI är svårare att inkludera i migreringsfärdplanen).

Vilka lag bör äga övergången till dubbel EKU?

PKI- och certifikatteam äger designen av den privata CA-hierarkin och separationen av certifikatmallar. Säkerhetsarkitekter äger styrningsmodellen: distribution av privata rot-CA-förtroenden, val av registreringsprotokoll och planering efter kvantmigrering för algoritmer för privata CA-nyckel. Plattforms- och DevOps-team äger migreringen på applikationsnivå: omkonfigurering av mTLS-, RADIUS-, VPN-, IoT- och CI/CD-system. Compliance-team äger revisionsbevisen som bekräftar att migreringen är slutförd före deadline den 15 mars 2027.

Hur kopplas det dubbla EKU-mandatet till hanteringen av certifikatlivscykeln?

Mandatet är en händelse i certifikatets livscykel: varje publikt TLS-certifikat som för närvarande bär clientAuth kommer att förlora den EKU:n vid nästa förnyelse. Identifiering och inventering av certifikat är förutsättningar för säker livscykelhantering: organisationer som inte vet vilka certifikat som bär clientAuth kan inte hantera förnyelsens livscykel på ett säkert sätt utan risk för autentiseringsavbrott. CertSecure Manager tillhandahåller CLM-lagret: automatiserad identifiering av clientAuth-beroenden, policytillämpning vid utfärdande (EKU-separerade profiler), automatiserad förnyelse via WSTEP/ACME/SCEP/EST, återkallningshantering och revisionsklar rapportering.

Hur bör organisationer mäta framgång i övergången till dubbel EKU?

Viktiga mätvärden: noll offentligt betrodda certifikat som bär både serverAuth och clientAuth; 100 procent av klientautentiseringsanvändningsfallen migrerade till privata clientAuth-certifikat; noll autentiseringsavbrott hänförliga till borttagning av clientAuth vid förnyelse; täckning av automatisering av privat PKI-registrering (procentandel klientcertifikat vid automatisk förnyelse); och klassificering efter kvantumsberedskap (algoritmer för privata CA-nyckel klassificerade mot NIST IR 8547-utfasningsmilstolpar med definierad migreringstidslinje). Rapportera dessa kvartalsvis mot CA/Browser Forums deadlineschema.

Vad bör granskas eller övervakas regelbundet?

Övervaka kontinuerligt: ​​certifikatinventering för offentligt betrodda certifikat som bär både serverAuth och clientAuth, med förnyelseaviseringar som flaggar dubbla EKU-certifikat före förnyelse; framgångsfrekvenser för mTLS-, RADIUS-, VPN- och IoT-autentisering för tidig upptäckt av fel vid borttagning av clientAuth. Kvartalsvis granskning: andel användningsfall för klientautentisering som migrerats till privata certifikat; täckning av automatisering av registrering för privata CA-certifikat; klassificering av nyckelalgoritmer för privata CA-certifikat mot NIST FIPS 203/204/205 (slutförd 13 augusti 2024); fullständighet i efterlevnadsbevis för deadline den 15 mars 2027.

Hur påverkar mandatet för dubbla EKU-licenser moln-, hybrid- eller multi-CA PKI-miljöer?

Moln- och hybridmiljöer har vanligtvis den högsta tätheten av oupptäckta dubbla EKU-beroenden: mikrotjänster som använder mTLS med publika certifikat, molnbaserade arbetsbelastningar som använder certifikatbaserad autentisering till moln-API:er, Kubernetes-kluster som använder certifikat för tjänstnätidentitet och CI/CD-pipelines som autentiserar mot register. Multi-CA-miljöer behöver ett centraliserat CLM-lager som upptäcker clientAuth-beroenden över alla CA-källor, inte bara det publika CA-inventariet, inklusive AWS Private CA, HashiCorp Vault PKI och Microsoft AD CS.

Vilka vanliga misstag bör team undvika?

De vanligaste misstagen: att inte upptäcka clientAuth-beroenden innan certifikat förnyas; att behandla mandatet som en ändring av certifikatmall endast utan att separera PKI-hierarkin på CA-nivå (Chrome Root Program Policy kräver separation på CA-nivå); att inte distribuera den privata rot-CA:n till alla förlitande partssystem före migrering; att bygga en privat PKI under tidspress utan att planera för post-kvantmigrering av privata CA-nyckelalgoritmer; och att inte registrera migrerade klientcertifikat i automatiserade förnyelseprocesser som kan upprätthålla 47 dagars giltighet från mars 2029.

Vad bör uppdateras kvartalsvis?

Kvartalsvis: granska certifikatinventeringen för offentligt betrodda certifikat som fortfarande bär clientAuth; verifiera att den privata rot-CA:n har distribuerats till alla nya system som lagts till sedan den senaste granskningen; bekräfta täckning av automatisering av registrering för privata CA-er för alla användningsfall av klientautentisering; klassificera algoritmer för privata CA-nyckel mot NIST-milstolpar efter kvantumutfasning (ML-DSA enligt FIPS 204, slutförd 13 augusti 2024); verifiera att inga nya mellanliggande CA:er med dubbla EKU-certifikat har avslöjats för CCADB i Chrome-betrodda hierarkier (förbjudet från och med 15 juni 2026). För planering av migreringsalgoritmer för nyckelringar för privata CA-er efter kvantum, se PQC Center of Excellence.