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.
Mandatet: vad kräver SC-081 och Chrome Root Program?
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 har 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:
- 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.
- 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 certifikatutfärdarens/webbläsarforumets mandat, 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 såsom ömsesidig TLS, enhetsautentisering, arbetsbelastningsidentitet, API-autentisering och server-till-server-kommunikation. Som ett resultat kan organisationer inte längre förlita sig på offentliga TLS-certifikat för interna klientautentiseringsanvändningsfall så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 måste PKI-hierarkin 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:
- Ett servercertifikat som innehåller serverAuth för att acceptera inkommande TLS-anslutningar
- 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.
