Hoppa till innehĂĄll

47-dagarscertifikaten är på väg. Är du redo?

Agera nu →

Att välja ett certifikatregistreringsprotokoll: ACME vs. EST vs. SCEP vs. CMP

Certifikat Lifecycle Management

Protokoll för certifikatregistrering avgör hur ett system begär, erhåller, förnyar och återkallar ett digitalt certifikat utan att en människa är inblandad. Under större delen av PKI:s historia var valet av protokoll en detalj på kontoret, eftersom certifikat varade i ett år eller mer, och en person bekvämt kunde hantera förnyelser manuellt. Den eran är över. Förkortningen av publika TLS-certifikats livslängder har gjort protokollval till en operativ nödvändighet, och det protokoll du väljer nu avgör om din certifikattillgång skalas eller kollapsar under volymen av förnyelser. Kortare livslängder driver också hela ekosystemet mot kryptoagilitet, eftersom certifikat som omsätts med några veckors mellanrum gör det mycket enklare att lansera nya algoritmer när postkvantstandarder anländer.

Den här artikeln jämför de fyra protokoll som dominerar registrering av företagscertifikat: ACME, EST, SCEP och CMP. Var och en utformades för en annan värld: webbautomation, modern enhetsregistrering, äldre nätverksutrustning och fullständig livscykelhantering för företag. Den praktiska verkligheten är att de flesta stora miljöer behöver mer än ett. Vi kommer att gå igenom varför tidslinjen har gjort detta brådskande, hur varje protokoll fungerar, var varje protokoll passar in och hur man planerar en protokollstrategi som överlever övergången till kortlivade certifikat.

Varför är detta viktigt nu?

Tre krafter samverkar för att göra certifikatautomation brådskande samtidigt: certifikatens livslängder kollapsar, fönstret för att återanvända valideringsbevis krymper, och webbläsares ekosystem gör automatisering till ett villkor för förtroende. Tillsammans förvandlar de protokollval från en backoffice-optimering till ett kortsiktigt operativt krav, och de belönar team som standardiserar automatiserbara protokoll långt innan de hårda deadlines anländer.

200-dagarsklippan är tvångsfunktionen

CA /Browser Forum godkände omröstningen SC-081v3 i april 2025, vilket innebär en gradvis minskning av livslängden för offentliga TLS-certifikat. Enligt omröstningen sänks den maximala livslängden till 200 dagar från och med den 15 mars 2026, till 100 dagar från och med den 15 mars 2027 och till 47 dagar från och med den 15 mars 2029. I praktiken implementerar certifikatutfärdare det första steget något tidigt och konservativt, där DigiCert utfärdar certifikat med en maximal giltighetstid på 199 dagar från och med den 24 februari 2026.

Dessa rubriksiffror är maximimängder för valsedlar; CA:er utfärdar vanligtvis en dag kortare, vilket är anledningen till att 200 blir 199, eftersom giltigheten mäts på sekunden, och även en enda sekund över gränsen räknas som felaktig utfärdande. 200-dagarsfasen är fortfarande överlevbar med disciplinerade manuella processer, men det är det sista steget. Övergången till 100 dagar 2027 och övergången till 47 dagar 2029 gör manuell förnyelse ohållbar, så teamen inför automatisering nu snarare än att vänta.

Domänvalideringen krymper också

Livstid är bara halva chansen. Den period under vilken bevis för domänkontrollvalidering kan återanvändas krymper i samma takt och minskar från 398 dagar idag till 200 dagar år 2026, 100 dagar år 2027 och bara 10 dagar i slutfasen, vilket innebär nästan kontinuerlig domänomvalidering vid varje förnyelse. Ett protokoll som automatiserar utfärdande men inte validering löser inte problemet. ACME:s utmaningssvarsvalidering är attraktiv just för att den automatiserar både validering och utfärdande.

Chrome kräver automatiseringsstöd

Webbläsarekosystemet förstärker tidslinjen. Sedan februari 2024 har Chrome Root Program endast accepterat nya CA-ansökare om de stöder minst en automatiserad lösning för utfärdande och förnyelse av certifikat för varje certifikattyp de utfärdar, vilket gör ACME till en grundläggande förväntan och tar bort manuella CSR- och e-postbaserade förnyelsearbetsflöden från nya offentliga PKI. En separat Chrome-ändring, som träder i kraft den 15 juni 2026, kräver att offentligt betrodda TLS-certifikat begränsas till serverautentisering, vilket flyttar klientautentisering och mTLS-användningsfall till privata PKI och ytterligare ökar värdet på protokoll som kan automatisera enhets- och användarregistrering. Automatisering går från att vara en konkurrensfördel till ett villkor för deltagande.

Certifikathantering

Förhindra certifikatavbrott, effektivisera IT-verksamheten och uppnå flexibilitet med vår certifikathanteringslösning.

De fyra protokollen förklarade

Fyra protokoll dominerar registrering av företagscertifikat, och vart och ett byggdes för ett annat problem, från webbautomation till fullständig hantering av företagslivscykeln. Avsnitten nedan förklarar hur ACME, EST, SCEP och CMP fungerar, vad som säkrar dem och var var och en passar in, innan de ställs sida vid sida.

ACME (RFC 8555)

Den automatiserade certifikathanteringsmiljön (ACME), definierad i RFC 8555 och banad av Let's Encrypt, automatiserar certifikatlivscykeloperationer för webbbaserade tjänster och ligger nu till grund för de flesta offentligt betrodda TLS-certifikat. Dess avgörande styrka är automatiserad domänkontrollvalidering genom challenge-response (HTTP-01, DNS-01 och TLS-ALPN-01), och den använder enkel JSON över HTTPS säkrad med JWS. Ursprungligen byggd för offentliga webbcertifikat används den i allt högre grad för intern PKI, och tillägg som External Account Binding och ACME Renewal Information (ARI) håller den relevant allt eftersom livslängden krymper.

EST (RFC 7030)

Enrollment over Secure Transport (EST), definierat i RFC 7030, är ​​ett enklare, standardiserat alternativ till CMP som använder HTTPS och förlitar sig på TLS för säkerhet snarare än meddelandeskydd på protokollnivå. Det stöder registrering, återregistrering, hämtning av CA-certifikat och generering av nyckel på serversidan, och utbyter PKCS#10-förfrågningar mot PKCS#7-svar. EST passar moderna enheter som redan har en HTTPS-stack, särskilt MDM och IoT, även om den stacken kan vara tung på resursbegränsade enheter.

SCEP (RFC 8894, Informationsdokument)

Simple Certificate Enrollment Protocol (SCEP) dök upp i slutet av 1990-talet för registrering av nätverksenheter och blev allmänt implementerat i routrar, switchar och VPN-koncentratorer, med hjälp av HTTP-transport med kryptografisk meddelandesyntax och, i Microsoft-miljöer, vanligtvis exponerat via NDES. Dess ålder visar sig i en svagare säkerhetsmodell, begränsad funktionalitet och föråldrad kryptografi, och eftersom RFC 8894 endast är informationsbaserad snarare än standardbaserad, ersätts SCEP stadigt av EST. Det är fortfarande nödvändigt för äldre utrustning som inte stöder något annat, så det säkraste är att avgränsa det och ersätta det enligt en definierad tidslinje.

CMP (RFC 4210)

Certificate Management Protocol (CMP), standardiserat i RFC 4210, tillhandahåller den mest omfattande livscykelhanteringen av de fyra: dess meddelanden har sitt eget skydd oberoende av transporten, vilket möjliggör verklig end-to-end-säkerhet för initiala förfrågningar, förnyelser, återkallelser, nyckelgenerering och nyckelåterställning. En Lightweight CMP Profile (RFC 9483, 2023) utökar den till resursbegränsade och industriella tillämpningar. CMP är väl etablerat inom telekommunikation, där 3GPP specificerar det för mobil nätverksutrustning, men dess kostnad är komplexitet, kräver ASN.1-hantering och med begränsat kommersiellt CA-stöd.

Jämförelse sida vid sida

ProtokollStandardTransport/säkerhetBästa passformLivscykelomfattning
ACMERFC 8555JSON över HTTPS, JWSWebbservrar, lastbalanserare, DevOps, molnUtfärdande och förnyelse, automatiserad DCV
ESTRFC 7030HTTPS, TLS ömsesidig autentiseringModerna enheter, MDM, IoT med HTTPSRegistrering, återregistrering och hämtning av CA
SCEPRFC 8894 (Informativ)HTTP med CMSÄldre routrar, switchar, brandväggarEndast grundläggande registrering och förnyelse
CMPRFC 4210Transportoberoende, meddelandenivåKomplext företag, myndigheter, försvarHel livscykel inkl. nyckelåterställning

Risker och fallgropar

Att slarvigt välja eller använda registreringsprotokoll introducerar sina egna fellägen, särskilt under den nya förnyelsetakten. Tabellen nedan sammanfattar de risker som oftast spårar ur ett certifikatprogram när livslängden förkortas, med varför var och en är viktig och vad den tenderar att kosta.

UtmaningVarför det spelar rollKonsekvens
Manuell förnyelse i stor skala200-dagarscertifikat blir 100 och sedan 47.Avbrott och missade förnyelser i takt med att volymen ökar.
ProtokollspridningOlika segment behöver olika protokoll.Operativ komplexitet och fragmenterad insyn.
Äldre SCEP-beroendeGamla enheter stöder inget annat.Svag kryptografi och en begränsad PQC-färdplan kvarstår.
ValideringsflaskhalsarÅteranvändningen av DCV krymper mot 10 dagar.Förnyelsen misslyckas om valideringen inte är automatiserad.
CA-arkitekturfelmatchningCMP och EST ställer krav på CA-sidan.Protokoll kan inte eftermonteras utan problem.

Förnyelsematematiken är oförlåtande

Under kortare livslängder ökar den operativa belastningen kraftigt. Tänk dig en organisation som hanterar ungefär 1 000 certifikatförnyelser per år idag: under en 47-dagarsregim genererar samma inventering över 8 000 förnyelsehändelser per år, eftersom varje certifikat måste utfärdas på nytt mycket oftare. Ingen manuell process absorberar en åttafaldig ökning. Merparten av den belastningen förblir osynlig tills den misslyckas, eftersom varje förnyelse är en begäran om certifikatsignering, en domänvalidering, en utfärdande och en distribution som alla måste lyckas utan att någon tittar på. Protokollbeslutet avgör om den volymen hanteras automatiskt eller blir en återkommande källa till avbrott och akut brandbekämpning efter arbetstid.

Gap i den inbyggda plattformen driver team mot SCEP

En vanlig och underskattad begränsning är själva utfärdandeplattformen. Microsoft AD CS har inte direkt stöd för ACME, EST eller CMP; dess inbyggda automatiserade registrering är begränsad till automatisk registrering av Windows-klienter och till SCEP via Network Device Enrollment Service (NDES), vilket effektivt begränsar blandade tillgångar till SCEP och manuell webbregistrering. Team som vill ha ACME-automatisering men kör AD CS behöver ofta en ytterligare plattform eller gateway för att överbrygga klyftan, vilket är ett medvetet designbeslut snarare än ett sent sådant.

Implementering bästa praxis

Att välja registreringsprotokoll är sällan binärt; de flesta företag kör minst två parallellt, där vart och ett betjänar ett annat segment. Målet är inte att standardisera på ett enda protokoll, utan att matcha varje protokoll till de arbetsbelastningar det bäst betjänar, samtidigt som hantering och insyn hålls enhetlig på en enda plattform, till exempel Encryption Consultings CertSecure Manager.

  • Använd ACME för webb-TV: För webbservrar, lastbalanserare, omvända proxyservrar och alla internet-baserade tjänster där domänkontrollvalidering är lämpligt är ACME det självklara valet och det som den förkortade livslängdslinjen mest direkt gynnar.
  • Använd EST för moderna enheter: Där enheter stöder HTTPS men inte behöver CMP:s hela livscykel, erbjuder EST en praktisk mellanväg för MDM och IoT, och är den rekommenderade efterföljaren till SCEP för nya implementeringar.
  • Använd CMP för komplexa företagslivscykler: Där du behöver fullständig livscykelkontroll, nyckelĂĄterställning och transportoberoende meddelandeskydd över olika certifikatprofiler, särskilt inom myndigheter, försvar och reglerade branscher, är CMP det starkaste alternativet.
  • Behandla SCEP som en övergĂĄngsfunktion: BehĂĄll SCEP endast för äldre nätverksutrustning utan EST- eller CMP-klient och planera en migreringsväg mot EST för enheter som kan stödja det. Ta bort SCEP-slutpunkter allt eftersom hĂĄrdvaran uppdateras. Säkra ytor där SCEP fortfarande körs, sĂĄ att migreringen kan prioriteras.
  • Designa CA-arkitektur för de protokoll du behöver: Eftersom CMP:s proof-of-possession och EST:s ömsesidiga TLS ställer krav pĂĄ CA-sidan, designa protokollstöd i CA:n frĂĄn början snarare än att eftermontera den. Encryption Consultings PKI- och CLM-rĂĄdgivningstjänster hjälper till att utforma detta frĂĄn dag ett.
  • Konsolidera pĂĄ en plattform med flera protokoll: Implementera en plattform som Encryption Consultings CertSecure-hanterare som stöder alla fyra protokoll frĂĄn ett enda gränssnitt, sĂĄ att du fĂĄr enhetlig insyn oavsett hur varje certifikat utfärdades, istället för att köra ett separat registreringssystem per protokoll, vilket fragmenterar insynen och mĂĄngfaldigar driftskostnaderna.
  • Lasttest innan deadlines sätter fart: För certifikat över ungefär tiotusen är flaskhalsen ofta HSM-signeringshastighet, CA-databasens prestanda och nätverkslatens snarare än själva protokollet, sĂĄ testa end-to-end-utgivning under realistisk volym lĂĄngt innan en deadline tvingar fram problemet. Encryption Consultings HSM-as-a-Service och rĂĄdgivningsteam hjälper till att dimensionera och validera den kapaciteten.

Vad betyder det för säkerhetsteam?

Övergången till automatiserad registrering berör nästan alla team som utfärdar eller använder certifikat, inte bara PKI-gruppen. Ansvarsområdena skiljer sig åt beroende på roll, men den förkortade livslängden ökar insatserna för dem alla, eftersom en missad förnyelse nu dyker upp som ett användarvänligt avbrott mycket snabbare än den gjorde under de årliga certifikatens era.

  • PKI-team eget protokollval och CA-arkitekturbesluten som avgör vilka protokoll som ens är möjliga, omrĂĄdet Encryption Consultings PKI och CLM rĂĄdgivningstjänster mest direkt stöd.
  • DevSecOps-team förlita sig pĂĄ ACME för att utfärda och förnya certifikat inom pipelines utan mänsklig inblandning när livslängden krymper, ett arbetsflöde CertSecure-hanterare automatiserar frĂĄn början till slut.
  • Molnsäkerhetsteam behöver automatiserad utfärdande över Kubernetes, lastbalanserare och hanterade tjänster där certifikatbortfallet är högst, vilket CertSecure Manager utfärdar och spĂĄrar frĂĄn ett gränssnitt.
  • IAM-team bryr sig om EST och CMP för registrering av enhets- och användaridentiteter, särskilt för mTLS och server-till-server-autentisering, vilket Encryption Consultings PKI-som-en-tjänst kan underbygga.
  • Infrastrukturingenjörer underhĂĄlla det befintliga nätverket där SCEP fortfarande finns, med hjälp av CBOM-säkerhet att inventera den innan man planerar dess slutliga utbyte.
  • CISO: er bär avbrotts- och efterlevnadsrisken om manuell förnyelse fortsätter in i 100-dagars- och 47-dagarsfaserna, och förlitar sig pĂĄ den insyn som CBOM Secure och CertSecure Manager ger för att svara gentemot styrelser och revisorer för certifikatdriven driftstopp.

Certifikathantering

Förhindra certifikatavbrott, effektivisera IT-verksamheten och uppnå flexibilitet med vår certifikathanteringslösning.

Hur kan krypteringskonsulting hjälpa till?

Att välja rätt registreringsprotokoll är bara det första steget; att använda det i den skala som 200-dagars- och 47-dagarscertifikat kräver är där de flesta team behöver hjälp. Encryption Consulting tillhandahåller plattformen, insynen och expertisen för att omvandla protokollstrategi till pålitliga, automatiserade operationer.

  • CertSecure-chef: VĂĄr plattform för hantering av certifikatlivscykeln utfärdar, förnyar och spĂĄrar certifikat över ACME, EST, SCEP och CMP frĂĄn ett enda gränssnitt, sĂĄ att automatisering och insyn inte fragmenteras mellan protokoll.
  • CBOM-säker: Kryptografisk identifiering och en kryptografisk materiallista katalogiserar varje certifikat, de protokoll det använder och de system som är beroende av det, sĂĄ att du vet vad som mĂĄste gĂĄ över till automatiserad registrering före nästa deadline.
  • PKI-som-en-tjänst: Styrd privat PKI för interna tjänster och enheter där kortlivade offentliga certifikat inte är lämpliga, med de registreringsprotokoll som ditt dödsbo kräver inbyggda.
  • HSM-som-en-tjänst: HĂĄrdvarubaserat skydd för signeringsnycklarna bakom de protokoll som din CA exponerar, utan kostnaden för att upprätthĂĄlla din egen HSM-egendom.
  • PKI- och CLM-rĂĄdgivningstjänster: Praktisk hjälp med att designa CA-arkitektur, välja protokoll och migrera bort frĂĄn äldre SCEP, sĂĄ att protokollstöd byggs in frĂĄn början snarare än eftermonteras.

Tillsammans gör dessa det möjligt för en organisation att utfärda certifikat från en styrd, automatiserad grund med flera protokoll och absorbera krympande livslängder och skiftande valideringsregler som rutinmässiga operationer. För att bedöma er beredskap för 200-dagars- och 47-dagarsfaserna, prata med Encryption Consulting om en färdplan för certifikatidentifiering och automatisering.

Slutsats

De fyra registreringsprotokollen existerar eftersom certifikatutfärdande spänner över väldigt olika världar, och inget enda protokoll betjänar dem alla. ACME har blivit ryggraden i automatiserad webbcertifikatutfärdande och det protokoll som den förkortade livslängden mest direkt belönar; EST är den moderna enhetens efterföljare till det åldrande SCEP; CMP är fortfarande det mest kompletta livscykelprotokollet för komplexa och reglerade miljöer; och SCEP finns kvar endast där äldre utrustning inte lämnar något alternativ.

Övergången till 200-dagars certifikat i mars 2026, och till 47-dagars certifikat senast 2029, har avgjort den underliggande frågan: manuell förnyelse är avslutad och automatisering är obligatorisk. Välj ACME för webb-TV, EST för moderna enheter, CMP för hela företagets livscykel och behandla SCEP som ett protokoll att begränsa och migrera bort från. De organisationer som klarar sig bäst kommer att behandla detta inte som ett engångsprojekt utan som en permanent övergång till automatiserad, policydriven utfärdande. Kör dem från en enda hanteringsplattform med en tydlig kryptografisk inventering under, och den krympande certifikatlivslängden blir en hanterbar operativ förändring snarare än en stående risk för avbrott.

I slutändan är övergången till kortlivade certifikat mindre en deadline för att överleva än en ny verksamhetsmodell att anta. Organisationer som behandlar varje livstidsförkortning som en engångsföreteelse kommer att fortsätta med brandbekämpning; de som bygger in automatiserad, protokollmedveten utfärdande i sin infrastruktur kommer att absorbera 200-dagars-, 100-dagars- och 47-dagarsstegen som rutin. Det praktiska första steget är synlighet: att känna till varje certifikat i bolaget, vilket protokoll det använder och vilket system som är beroende av det. Därifrån förvandlas en krympande certifikatlivslängd från en återkommande källa till avbrott till en förutsägbar, välstyrd bakgrundsprocess genom att matcha varje arbetsbelastning med rätt protokoll och köra dem alla från en hanterad plattform.