Borttagning av clientAuth EKU: Var mTLS bryts och hur man migrerar till privat PKI

Ditt mTLS-nätverk kan klara varje hälsokontroll, förnya varje certifikat enligt schemat och ändå sluta autentisera klienter över natten. Ingenting hackas. Ingenting löper ut i förtid. Ett certifikat förnyas helt enkelt, kommer tyst tillbaka utan att ha ett Extended Key Usage-värde, och nästa handskakning som är beroende av det misslyckas. Det är formen av clientAuth-nedgången, och den är redan igång.

TL; DR Chrome Root Program Policy v1.8, avsnitt 1.3.2, tar bort clientAuth Extended Key Usage (EKU) från offentligt betrodda TLS-lövcertifikat. Nya underordnade certifikatutfärdare har varit tvungna att vara endast serverAuth sedan den 15 juni 2026, och varje nytt offentligt lövcertifikat måste vara endast serverAuth senast den 15 mars 2027. Din certifikatutfärdare avslutar nästan säkert före Chromes egen deadline. DigiCert, Sectigo, Let's Encrypt, Google Trust Services och SSL.com har alla satt tidigare interna avstängningar, vissa så tidigt som i september 2025. Felet är tyst av sig självt: befintliga certifikat fortsätter att fungera tills de går ut, så avbrottet visas vid nästa rutinmässiga förnyelse, inte på något policydatum, och det kan dyka upp timmar eller dagar senare på orelaterad infrastruktur. Att återutfärda eller fästa lövcertifikatet kommer inte att rädda dig. Verifierare beräknar den effektiva EKU:n som skärningspunkten för varje certifikat i kedjan, så när din utfärdande hierarki blir endast serverAuth, slutar lövets clientAuth OID att användas även om det fortfarande är tryckt på certifikatet. Den varaktiga lösningen är en privat PKI som du styr för klient- och maskinidentitet, byggd internt eller konsumerad som PKI-as-a-Service, migrerad genom en plan i fyra faser utan driftstopp.

Key Takeaways

• Känn till mandatet: Chrome Root Program Policy v1.8 är källan. Den 15 juni 2026 trädde redan i kraft hierarkier för underordnade CA:er med ett enda syfte. Den 15 mars 2027 är den hårda gränsen för lövcertifikat. Din egen CA klipps sannolikt över tidigare än något av datumen.
• Lager nu, inte vid förnyelsetidpunkten: Hitta alla clientAuth-konsumenter i mTLS, service mesh, IoT, VPN, 802.1X, SIP och äldre maskin-till-maskin-system.
• Hoppa över återvändsgränderna: Flaggor för att delta, återutgivningar i sista minuten och root-filer som inte är webbläsare försenar bara klippan. En privat PKI är det enda alternativet som ger dig EKU:er och utgivningspolicyer som du faktiskt kontrollerar.
• Kontrollera hela kedjan, inte bara bladet: En mellanliggande förlorande clientAuth kan förstöra ett lövcertifikat innan lövcertifikatets egen förnyelse någonsin anländer.
• Sök bortom ditt eget certifikatlager: Certifikattransparensloggar uppdagar bortglömda och skugg-IT-certifikat som dina egna register missar.
• Migrera medvetet: Upptäck, designa, driftsätt och byt sedan kapacitet med parallellt förtroende och validera hela kedjan i mellanlagring innan en produktionsförnyelse tvingar fram problemet åt dig.

Vad som faktiskt förändras

I åratal kunde ett offentligt betrott TLS-certifikat bära två värden för utökad nyckelanvändning samtidigt: id-kp-serverAuth (OID 1.3.6.1.5.5.7.3.1) och id-kp-clientAuth (OID 1.3.6.1.5.5.7.3.2), enligt definitionen i RFC 5280 avsnitt 4.2.1.12. Ett enda certifikat kunde avsluta HTTPS som en server och även autentisera som en klient i mTLS-, tjänst-till-tjänst- och maskinidentitetsflöden.

Enligt Chrome Root Program Policy v1.8, avsnitt 1.3.2, försvinner den dubbla rollen. Nya offentligt betrodda TLS-lövcertifikat kommer endast att ha serverAuth. Befintliga certifikat med dubbla funktioner förblir giltiga tills de löper ut, men varje förnyelse som utfärdas efter din certifikatutfärdares tillämpningsdatum kommer som standard att vara serverAuth-only.

Två datum är viktiga på policynivå: nya underordnade CA:er som lämnats ut till CCADB har varit tvungna att vara endast serverAuth-authentifierade sedan den 15 juni 2026, och varje prenumerantcertifikat (lövcertifikat) som utfärdats den 15 mars 2027 eller senare måste hävda endast serverAuth. Google lade först fram uppdelningen på bordet vid CA/Browser Forums F2F-63-möte i oktober 2024, och kodifierade den sedan som en Chrome Root Program-policy snarare än en CA/Browser Forum-omröstning. Chrome representerar fortfarande ungefär två tredjedelar av den globala webbläsarmarknaden, så en offentlig CA som ignorerar Chromes rotprogram riskerar att förlora förtroendet för större delen av webben, och varje större CA behandlar policyn som obligatorisk.

Den här artikeln förutsätter att du redan vet så mycket. För den fullständiga mandathistoriken, CA/Browser Forums roll och Chromes policytext avsnitt för avsnitt, se Encryption Consultings dedikerade uppdelningar av Chrome Root Program Policy v1.8 och CA/Browser Forums mandat . Följande är den del som den här förändringen hoppar över mest: exakt var din infrastruktur går sönder, hur du hittar varje certifikat som är i riskzonen och hur du flyttar klientidentiteten någonstans varaktigt innan en förnyelse tvingar fram problemet i produktionen.

Din CA:s deadline, inte Chromes, är din verkliga deadline.

Offentliga certifikatutfärdare ligger långt före Chromes egna tillämpningsdatum. Befintliga certifikat fortsätter att fungera tills de löper ut, men den första förnyelsen efter din certifikatutfärdares avstängning sker endast med serverautentisering, och det är då klientautentiseringen tyst bryts.

certifikatutfärdare	clientAuth avstängd som standard	Hård avstängning (ingen clientAuth utfärdad)
DigiCert	October 1, 2025	1 mars 2027 (alla DigiCert-varumärken)
sektigo	October 7, 2025	10 februari 2027, inga undantag
Låt oss kryptera	11 februari 2026 (standard ACME-profil)	8 juli 2026 (tlsClient-bryggprofilen har tagits ur bruk)
Googles betrodda tjänster	10 november 2025 (CSR:er avvisade)	13 april 2026, inga undantag
SSL.com	September 15, 2025	Anpassad till Chrome, 15 mars 2027

Kolla din egen CA:s rådgivningssida direkt; flera av dessa datum har redan flyttats tidigare än vad som ursprungligen meddelades en gång, och CA:er är inte blyga för att påskynda ytterligare.

Varför splitten faktiskt är rätt beslut

Det är frestande att behandla detta som byråkratisk churn från en webbläsarleverantör. Det är det inte, och det är värt att förstå varför innan du bygger runt det, eftersom samma logik bör forma hur du utformar den privata PKI du migrerar till.

Validering är inte auktorisering: Utfärdande av offentliga certifikat bevisar domänkontroll, genom metoder som ACME HTTP-01 och DNS-01 enligt definitionen i RFC 8555 avsnitt 8.3 och 8.4, eller organisationsidentitet för OV- och EV-certifikat, enligt baskrav avsnitt 3.2.2.4. Inget av detta verifierar att ett givet system är auktoriserat att agera som en klient mot din infrastruktur. Ett offentligt clientAuth-certifikat annonserade alltid en förtroendeegenskap som den utfärdande CA:n aldrig validerade.

Dubbel EKU fördubblar explosionsradien för en stulen nyckel: Ett certifikat som innehåller både serverAuth och clientAuth innebär att en komprometterad privat nyckel låter en angripare utge sig för att vara din server och röra sig i sidled som en betrodd klient, med samma nyckel för båda. Att separera certifikat, nycklar och livscykler efter syfte tar bort den andra attackvägen helt och hållet. Det är minsta behörighet tillämpad på certifikat, inte en ny idé, som bara äntligen tillämpas på EKU-nivå.

Där mTLS-handskakningen faktiskt bryts

Det här är den detalj som de flesta förklarar om den här ändringen som hoppas över, och det är den som är viktigast när du felsöker en sida klockan 02:00.

I en ömsesidig TLS-handskakning skickar servern CertificateRequest, klienten svarar med sitt certifikat och skickar sedan CertificateVerify, en signatur som bevisar att den innehar motsvarande privata nyckel (detta är TLS 1.3-flödet; TLS 1.2 lägger till ett okrypterat ClientKeyExchange-steg däremellan, men felpunkten är identisk). Verifieraren gör två helt separata kontroller här, och att slå ihop dem är där de flesta obduktioner går fel.

Först körs sökvägsvalidering enligt definitionen i RFC 5280 avsnitt 6, och kedjan till en betrodd rot bygger och kontrolleras. Detta steg godkänns. Certifikatkedjan är helt giltig. RFC 5280 definierar själva EKU-tillägget i avsnitt 4.2.1.12, men det kräver inte att en verifierare kontrollerar EKU:s syfte som en del av sökvägsvalideringen.

Den ändamålskontrollen läggs till ovanpå den specifika TLS-implementeringen, vilket inte krävs av RFC. Stora bibliotek, inklusive OpenSSL, Javas JSSE, Gos crypto/tls och Rusts rustls, tillämpar alla EKU-ändamålsvalidering som standard: de letar efter clientAuth i det presenterade certifikatet, hittar det inte och avvisar certifikatet direkt. Detta är ett hårt autentiseringsfel, inte en varning, och det händer vanligtvis så snart verifieraren utvärderar klientcertifikatets EKU, ofta direkt vid certifikatmeddelandet snarare än bara efter CertificateVerify. Ingen applikationsdata flödar innan denna kontroll körs.

Tillämpningen är avsiktlig, inte oavsiktlig. Gos egen ärendehantering dokumenterar ett fall (golang/go#23884) där ett serverAuth-only-klientcertifikat korrekt avvisades under RequireAndVerifyClientCert på Go 1.9.4, och sedan felaktigt accepterades efter en Go 1.10-regression. Gos ansvariga behandlade regressionen som en bugg och fixade den, vilket är en ungefär så tydlig bekräftelse som man kan få på att EKU-tillämpning är det avsedda standardbeteendet i hela ekosystemet, inte ett edge-fall som man kan lita på att ignoreras.

Kedjefällan: Att återutge lövet kommer inte att rädda dig

Här är detaljen som fångar team som tror att de har köpt sig tid. Verifierare som Chrome och de underliggande TLS-stackarna kontrollerar inte bara lövcertifikatets EKU. De validerar hela kedjan, och den effektiva EKU:n för ett certifikat är skärningspunkten mellan de syften som tillåts av varje certifikat i sökvägen ovanför det.

Tänk dig ett lövcertifikat som fortfarande listar både serverAuth och clientAuth, utfärdat under en mellanliggande CA som har migrerat till en serverAuth-only-hierarki:

{ serverAuth } ∩ { serverAuth, klientAuth } = { serverAuth }

Lövets clientAuth OID är fortfarande tryckt på certifikatet. Det ignoreras helt enkelt, eftersom inget certifikat ovanför lövet får innehålla en EKU som exkluderar clientAuth för att överleva längre ner i kedjan. Tystnad fungerar: ett mellanliggande CA-certifikat utan EKU-tillägg alls är obegränsat. Det är en explicit EKU som utelämnar clientAuth som bryter allt under det.

Den praktiska konsekvensen: du kan inte hålla clientAuth vid liv genom att återutfärda eller fästa ditt befintliga lövcertifikat när din utfärdande CA:s hierarki övergår till endast serverAuth. En mellanhand kan förlora clientAuth-funktion för allt under det innan ett enskilt lövcertifikats eget förnyelsedatum infaller. Om du bara spårar lövcertifikatens utgångsdatum spårar du fel klocka.

Vilka arbetsbelastningar bryts tyst

Sprängningsradien är bredare än vad de flesta certifikatinventeringar antar, och tillämpningen varierar beroende på leverantör, vilket är just det som gör detta svårt att avgränsa från enbart ett kalkylblad.

Arbetsbelastning	Varför det beror på clientAuth	Verkställighetsanteckningar
mTLS / tjänstnät	Sidovagnar autentiserar sig mot varandra med klientcertifikat för öst-västlig trafik	Vanligtvis strikta; där avbrotten är mest synliga
Partner- och B2B-API:er	Gateways presenterar klientcertifikat för att bevisa identitet i mTLS mellan organisationer	Avtalsmässigt strikt i de flesta integrationer
IoT och enhetsidentitet	Varje enhet presenterar ett klientcertifikat för att bevisa vilken flottmedlem den är	Strikt; enhetsflottor är svåra att uppdatera snabbt
VPN-klientautentisering	Klienter autentiserar sig mot gatewayen med ett certifikat (OpenVPN, AnyConnect, Fortinet)	Leverantörsberoende, generellt strikt
Wi-Fi / 802.1X (EAP-TLS)	Ansökarens (enhets) certifikat innehåller vanligtvis clientAuth	RFC 5216 §5.3 rekommenderar kontrollen men accepterar ingen EKU alls
SIP / SBC / enhetlig kommunikation	Vissa operatörer kräver clientAuth för Session Border Controller-förtroende	Operatörsberoende; Microsoft Teams Direct Routing-dokument accepterar för närvarande SBC-certifikat utan clientAuth
Lastbalanserare	Kontrollera klientcertifikat, men tillämpa endast clientAuth om det uttryckligen har konfigurerats	F5 BIG-IP tillämpar endast EKU-syfte om en administratör aktiverar den regeln
Äldre maskin-till-maskin-mellanprogramvara	Äldre system förväntar sig ett dubbelfunktionscertifikat för båda rollerna	Ofta svårast att patcha; ofta oägd av något nuvarande lag

Den ärliga slutsatsen här är att tillämpningen verkligen är leverantörsberoende. Verifiera din egen stack istället för att anta att alla arbetsbelastningar i den här tabellen går sönder samma dag; en del av det kan fortsätta att halta på grund av en teknikalitet tills en framtida uppdatering också täcker den luckan.

Det tysta misslyckandemönstret

Den farligaste egenskapen med denna förändring är att ingenting meddelar den. Felsekvensen ser ut så här:

1. Policydagen är inne: Ingenting händer. Befintliga certifikat med dubbla EKU-certifikat förblir giltiga tills de individuellt upphör att gälla.
2. Veckorna går: Implementeringarna ser helt stabila ut. Automatiserade ACME-förnyelser fortsätter att köras exakt som de alltid har gjort.
3. En rutinmässig förnyelse utlöses: Certifikatet förnyas utan problem, men det returneras endast som serverAuth. Det är ett helt giltigt certifikat. Det saknar bara den funktion som var viktig för den här arbetsbelastningen.
4. Nästa mTLS-handskakning misslyckas: EKU-kontrollen avvisar certifikatet nästa gång det används för klientautentisering, vilket kan vara timmar eller dagar efter förnyelsen, på infrastruktur som ser helt orelaterad till den som förnyade certifikatet.

Eftersom rotationen är automatiserad från början till slut kan en enda förnyelsecykel hos en certifikatutfärdare ta ner ett helt servicenät, och det är verkligen svårt att diagnostisera, eftersom certifikatet klarar alla kontroller utom den som faktiskt spelar roll. Kedjevalideringen lyckas. Utgångsdatumet är okej. Signaturen är giltig. Det är endast serverAuth, och ingen tittade efter det specifika fältet.

Hur du hittar din klientautentiseringsexponering

Du kan inte migrera det du inte har hittat. Sex sätt att bygga upp ett riktigt lager, ungefär i ansträngningsordning:

1. Inventering per EKU: Räkna upp alla offentligt utfärdade TLS-certifikat du innehar och flagga allt som bär clientAuth. Ett kryptografiskt arbetsflöde (CBOM) skalar detta över en stor databaser.
2. Sök efter loggar för certifikattransparens: Chromes policy kräver CT-loggning för alla offentligt betrodda TLS-certifikat, så en aggregator som crt.sh returnerar hela utfärdandehistoriken för dina domäner, inklusive glömda eller skugg-IT-certifikat som ingen minns att de begärt.
3. Kontrollera hela kedjan, inte bara bladet: Verifiera vad din utfärdande CA:s mellanliggande leverantörer faktiskt hävdar. Funktionen kan dö hos mellanliggande leverantör innan lövets egen förnyelse.
4. Kartlägg beroendegrafen: Identifiera vilka ömsesidiga autentiseringsflöden i din miljö som faktiskt förbrukar clientAuth, inte bara vilka certifikat som bär EKU:n.
5. Bekräfta stöd för dubbla certifikat per applikation: Kan varje applikation ha separata klient- och servercertifikat, eller antar den att ett certifikat gör båda? Om den inte kan det är det en leverantörsdiskussion som bör påbörjas nu, inte i mars 2027.
6. Automatisera identifiering med en CLM-plattform: Manuella kontroller skalas inte utöver ett fåtal certifikat. En plattform för hantering av certifikatlivscykeln inventerar EKU:er kontinuerligt, inte bara när någon kommer ihåg att granska.

Tre kommandon täcker de flesta snabbkontroller, alla portabla över Windows, Linux och macOS:

# Läs EKU-tillägget från en certifikatfil på disken openssl x509 -in cert.pem -noout -ext utökad nyckelanvändning   # Kontrollera EKU:n på ett certifikat som presenteras av en aktiv TLS-slutpunkt echo | openssl s_client -connect :443 -servernamn 2>/dev/null \ | openssl x509 -noout -ext utökad nyckelanvändning   # Lista EKU:er för varje certifikat i ett Java/PKCS12-nyckellager keytool -lista -v -nyckelbutik -butikstyp PKCS12

Det du letar efter i utdata är strängen TLS Web Client Authentication, eller det råa OID:t 1.3.6.1.5.5.7.3.2. Om det finns där idag och certifikatet kom från en offentlig CA, behandla det som exponerat.

Varför de vanliga lösningarna är återvändsgränder

Tre frestande genvägar, och där var och en tar slut.

Flaggor för anmälan: Både DigiCert och Sectigo erbjuder fortfarande registreringsknappar som håller clientAuth aktivt, för tillfället. Dessa knappar försvinner vid varje certifikatutfärdares hårda slutdatum, även för förnyelser av certifikat du redan innehar. Detta är inte en lösning. Det är en nedräkning med ett fast slutdatum.

Tidig återutgivning: Om du ger ut clientAuth idag håller du certifikatet aktivt i ytterligare en livslängd. Men publika certifikats livslängder krymper mot 47 dagar i mars 2029 enligt CA/Browser Forum Ballot SC-081v3, så din nästa förnyelse kommer fortfarande efter gränsen. Klippan närmar sig varje gång du använder det här tricket; den försvinner aldrig.

Icke-webbläsarrötter: Hierarkier som X9 PKI stöder fortfarande dubbla EKU-certifikat, men Chrome och Firefox litar inte på dem automatiskt. Du skulle behöva distribuera det förtroendet till varje förlitande enhet själv, vilket byter ett certifikatproblem mot ett fullständigt förtroendefördelningsproblem. Det är sällan en bättre byte.

Mönstret för alla tre: klientidentitet var aldrig det primära syftet med förtroende på offentliga webbsidor. Det baserades på ett certifikat som byggdes för ett annat ändamål. Den varaktiga lösningen är en förtroendemodell som du faktiskt styr.

Expertens åsikt: Bygg den separation du ville ha ändå

Här är den del som är värd att säga tydligt: ​​den här migreringen är en bra ursäkt för att bygga den arkitektur du förmodligen borde ha haft redan. En privat PKI specialbyggd för klient- och maskinidentitet ger dig EKU- och profilkontroll som offentliga certifikatutfärdare aldrig skulle erbjuda: serverAuth- och clientAuth-profiler med ett enda syfte som standard, en dubbel EKU-profil som endast behålls som en avsiktlig, tillfällig migreringsbrygga snarare än en permanent vana, och certifikatlivslängder mätt i timmar till dagar när utfärdandet är automatiserat, vilket är en säkerhetsuppgradering, inte en börda.

Det frikopplar dig också från offentlig churn som du inte kontrollerar. 47-dagars livstidsschemat och vad nästa policyskifte för rotprogrammet än visar sig vara, sluta vara din nödsituation, eftersom de förlitande parterna är dina, förtroendeankrarna finns i dina egna butiker och reglerna är de du skriver. Och eftersom du kontrollerar hierarkin blir hybrid- och ML-DSA-postkvantprofiler något du kan testa nu, inför det offentliga ekosystemets egen PQC-utrullning, snarare än ett separat framtida projekt.

Inget av det betyder att man går tillbaka till att utfärda certifikat med dubbla funktioner fritt. Samma logik om minsta privilegier som motiverade att dela upp serverAuth från clientAuth i publika TLS gäller även inom din egen hierarki.

Vad en privat PKI i produktionsklass faktiskt kräver

”Bygg en privat certifikatutfärdare” är lätt att säga och genuint svårt att driva på ett bra sätt. Att göra det dåligt innebär att man får en deadline för ett avbrott. Sex krav som skiljer en privat PKI i produktionsklass från en certifikatutfärdare som blir sin egen incident:

Krav	Vad det egentligen betyder
HSM-skyddat nyckelmaterial	Root- och utfärdande CA-nycklar genererade och lagrade i FIPS 140-3-validerade HSM:er, root hålls offline, med dokumenterade nyckelceremonier
Utgivningsnivå byggd för dataflöde	Anpassad för verklig certifikatvolym med hög tillgänglighet; stöd för ACME, SCEP och EST så att automatiserad utfärdande håller jämna steg med korta livslängder
Infrastruktur för återkallelse	CRL-distributionspunkter och OCSP-svarare; häftning hjälper till att validera servercertifikat, men klientcertifikatkontroller i mTLS är vanligtvis verifieringsinitierade CRL- eller OCSP-sökningar
Fästade certifikatprofiler	Varje profil fäster explicita EKU:er, algoritmer och giltighetsperioder, med klient- och serverroller separerade av profil eller sub-CA
CP/CPS och revisionsberedskap	En certifikatpolicy, en certifieringspraxis, viktiga certifieringsprotokoll och mallar för styrning som håller måttet för en extern bedömare
Livscykelsynlighet och automatisering	Kontinuerlig identifiering plus automatisk förnyelse och rotation; manuell spårning kan inte hålla jämna steg med certifikat mätta i timmar eller dagar

Att uppfylla alla sex krav kräver verklig ingenjörsinsats, kontinuerligt operativt engagemang och specialiserad kryptografisk expertis som de flesta interna team inte har bemannade att bära ensamma. Det är den ärliga anledningen till att många organisationer väljer en hanterad PKI (PKIaaS) istället för att starta detta från grunden.

Planen för migrering utan driftstopp

Fyra faser, utformade så att ingenting bryts medan förtroendet byter ägare. Den styrande regeln under alla fyra: underhåll dina gamla och nya certifikatkedjor parallellt under övergångsfönstret, återkalla ingenting förrän alla konsumenter litar på den nya kedjan och slutför migreringen före din certifikatutfärdares ikraftträdandedatum, inte på det.

Fas	Fokus	Konkreta steg
01. Upptäck	Hitta exponering	Inventering av lövcertifikat per EKU, kartlöv och mellanliggande kedjor, identifiera varje mTLS-flöde, registrera tidslinjer för förnyelse
02. utformning	Definiera profiler	Ställ in explicita EKU:er, separera klient- och serverprofiler, definiera algoritmer och nyckelstorlekar, utforma CRL/OCSP-strategin
03. Installera	Bygg förtroende	Distribuera rot- och utfärdandenivån (eller utöka via PKIaaS där det är lämpligt), automatisera ACME-, SCEP- och EST-registrering, distribuera förtroendeankare
04. Klipp över	Byt säkert	Kör gamla och nya kedjor parallellt, validera fullständiga sökvägar i mellanlagring, rotera certifikat gradvis, dra tillbaka äldre förtroenden efter att implementeringen har bekräftats

Två fellägen att explicit designa mot: migrering på verkställighetsdatumet istället för före det, och återkallelse av den gamla kedjan innan alla konsumenter faktiskt har anammat den nya. Båda förvandlar en planerad migrering till ett avbrott.

Hur Encryption Consultings PKIaaS passar in i denna migrering

I driftsättningsfasen ovan går de flesta team antingen snabbt fram eller stannar upp i månader för att anskaffa hårdvara, bemanna dygnet runt-verksamhet och skriva CP/CPS-dokumentation från grunden. PKI-as-a-Service från Encryption Consulting är byggt för att eliminera den flaskhalsen: en fullständigt hanterad, högtillgänglig PKI för en enda klient, med CA-nycklar säkrade i FIPS 140-3 nivå 3 HSM:er, och CertSecure Manager , EC:s CA-agnostiska plattform för hantering av certifikatlivscykel, som läggs ovanpå för övergripande insyn och automatisering.

Grund: Din rot-CA, underordnade CA:er och OCSP/CRL-tjänster är fullständigt hostade, utan någon lokal CA-plats att underhålla. HSM-as-a-Service innebär att EC tillhandahåller och underhåller FIPS 140-3 Level 3-hårdvaran; CA-nycklar finns kvar i HSM:en och kan aldrig exporteras till programvara, medan nyckelkontroll och äganderätt förblir din.

Drift: CertSecure Manager ger fullständig insyn i certifikaten och automatiserar identifiering, registrering, förnyelse och återkallelse av publika, privata och PKIaaS-utfärdade certifikat, via ACME, SCEP och EST. Eftersom tjänsten är helt hanterad övervakar EC CA-hälsa, CRL-förnyelse, HSM-status och certifikatutgång dygnet runt, vilket upptäcker problem innan de blir den typ av tysta avbrott som beskrivs tidigare i det här inlägget.

Styrning: EC tillhandahåller CP/CPS-dokumentation och mallstyrning, rollbaserad åtkomstkontroll och bevittnade, dokumenterade nyckelceremonier, samma styrning som en bedömare kommer att begära under revisionen. Certifikatprofiler är specialbyggda för just denna migrering, med kryptoagilitet utformad så att hybrid- och PQC-klara certifikatprofiler är tillgängliga allt eftersom standarder utvecklas, snarare än ytterligare ett migreringsprojekt längre fram.

Kartlagd mot fyrfasritningen: Discovery och Design är vanligtvis en gemensam övning med ditt team; Deployment är där PKIaaS gör det tyngsta lyftet, och etablerar en styrd hierarki på veckor snarare än de månader som en från grunden-byggnad vanligtvis tar; och Cutover stöds av CertSecure Managers automatisering så att parallellkedjeutrullning inte förvandlas till en manuell, felbenägen utrullning.

Vanliga frågor om partihandel med mat och dryck

Vad är clientAuth EKU och varför tas den bort från offentliga TLS-certifikat?

clientAuth Extended Key Usage (OID 1.3.6.1.5.5.7.3.2) låter ett TLS-certifikat autentiseras som en klient, utöver serverAuths roll att autentisera en server för webbläsare. Chrome Root Program Policy v1.8 tar bort det från offentliga lövcertifikat eftersom offentlig utfärdande endast validerar domän- eller organisationsidentitet, aldrig klientauktorisering, och eftersom ett certifikat med dubbla funktioner fördubblar vad en stulen nyckel kan göra.

Är min riktiga deadline i Chrome den 15 mars 2027, eller något annat?

Nästan säkert något tidigare. Offentliga CA:er, inklusive DigiCert, Sectigo, Let's Encrypt, Google Trust Services och SSL.com, har alla satt sina egna gränsvärden inför Chromes tillämpningsdatum, flera redan under 2025. Kontrollera din specifika CA:s rådgivningssida snarare än att planera enbart kring det branschövergripande datumet.

Kan jag fortsätta att använda clientAuth genom att utfärda eller fästa mitt nuvarande certifikat?

Nej. Verifierare beräknar den effektiva EKU:n som skärningspunkten för varje certifikat i kedjan. När din utfärdande CA:s hierarki övergår till endast serverAuth kan ett mellanliggande certifikat exkludera clientAuth för allt under det, och att återutfärda eller fästa lövcertifikatet ändrar inte det.

Vad går fel först när clientAuth försvinner från mina certifikat?

Allt som beror på ömsesidig TLS för maskin- eller klientidentitet: service mesh-sidokärnor, partner-API-gatewayer, IoT-enhetsflottor, VPN-klienter och alla belastningsutjämnare eller mellanprogram som uttryckligen konfigurerats för att tillämpa clientAuth EKU. Felet visas inte på tillämpningsdatumet; det visas vid nästa certifikatförnyelse och nästa mTLS-handskakning efter det.

Hjälper migrering till en privat PKI också med post-kvantumberedskap?

Ja, indirekt men användbart. Eftersom du kontrollerar hierarkin kan du testa hybrid- och ML-DSA-certifikatprofiler i din egen privata PKI långt före det publika certifikatekosystemets egen utrullning efter kvantumsgränsen, vilket gör denna migrering till ett försprång snarare än ett andra, separat projekt senare.

Redo att se var du står?

Gå igenom checklistan för identifiering ovan mot din egen certifikattillgång den här veckan. När du är redo att designa och driftsätta den privata PKI-sidan, se hur PKI-as-a-Service mappar till just denna migrering , eller prata med Encryption Consultings PKI-team om en identifierings- och migreringsbedömning.