Vad är en SCEP-tjänst? Hur fungerar SCEP-protokollet?

SCEP, eller Simple Certificate Enrollment Protocol, är ett protokoll för certifikathantering med öppen källkod som står för , vilket automatiserar uppgiften att utfärda certifikat. Utfärdande av certifikat för offentlig nyckelinfrastruktur (PKI) kräver en process för informationsutbyte med en betrodd certifikatutfärdare (CA) . Detta krävs för att autentisera informationen som användaren tillhandahåller, såsom domännamn och identiteter som är kopplade till certifikatet. Genom att automatisera denna process gör SCEP det enkelt och snabbare för IT-teamet att registrera certifikat på enheter utan att behöva utbyta informationen manuellt. Med hjälp av en URL för att utbyta information och en delad hemlighet för att kommunicera med certifikatutfärdaren kan en enhet enkelt registrera sig för ett certifikat.

Snabbt svar: Vad är SCEP och hur fungerar det?

SCEP (Simple Certificate Enrollment Protocol) är ett öppet protokoll som automatiserar certifikatregistrering för hanterade enheter. En enhet använder en SCEP-URL och en delad hemlighet för att skicka en certifikatsigneringsbegäran till en certifikatutfärdare via en SCEP-gateway. Efter att certifikatutfärdaren autentiserat begäran utfärdar den ett signerat certifikat som distribueras till enheten, vanligtvis via en MDM. Detta eliminerar manuellt certifikatutbyte på företagsnivå.

Sammanfattning

SCEP låter IT- och PKI-team automatisera certifikatutfärdande för stora grupper av hanterade enheter istället för att manuellt utbyta certifikatförfrågningar med en CA för varje slutpunkt. Det fungerar via en SCEP-URL, en delad hemlighet och en certifikatsigneringsbegäran som vidarebefordras via en SCEP-gateway, med det resulterande signerade certifikatet distribuerat via Mobile Device Management (MDM). Även om SCEP är snabb att distribuera, är dess beroende av en statisk delad hemlighet också dess största svaghet, vilket är anledningen till att organisationer i allt högre grad jämför det med EST, ACME och CMP/CMC innan de standardiserar ett protokoll för enhetsregistrering. Det här inlägget behandlar hur SCEP fungerar från början till slut, förutsättningar, distributionssteg, valideringskontroller, vanliga fel, återställningssteg och hur SCEP passar in i ett bredare program för hantering av certifikatlivscykeln.

Vem borde bry sig om SCEP

SCEP-registrering berör identitets-, mobilitets- och efterlevnadsteam lika mycket som den berör själva PKI:n. Här är vad varje roll bör göra.

PKI-administratörer

Konfigurera SCEP-gatewayen/NDES-slutpunkten, hantera policyn för rotation av delade hemligheter och se till att den utfärdande certifikatutfärdarens certifikatkedja publiceras korrekt till varje registreringsenhet.

Säkerhetsarkitekter

Utvärdera om SCEP:s modell för delade hemligheter uppfyller organisationens risktolerans, eller om EST/ACME:s starkare autentiseringsmodell är motiverad för den aktuella enhetspopulationen.

Plattformsteam

Äga MDM-konfigurationsprofilen (SCEP-URL, delad hemlighet, certifikatmallinställningar) och enhetens onboarding-arbetsflöde som skickar profilen till hanterade slutpunkter.

Compliance-team

Bekräfta att delade SCEP-hemligheter roteras enligt en definierad kadens och att certifikatgiltighetsperioder och nyckelstorlekar i konfigurationsprofilen uppfyller policy- och regelkrav.

CISO: er

Spåra SCEP:s kända exponering för privilegieskalering som en riskpost och sponsra utvärdering av EST eller ACME för enhetspopulationer där den delade hemlighetsmodellen inte längre är acceptabel.

Varför detta är viktigt: Data och deadlines

Enligt DigiCerts Trust Pulse Survey (2 juli 2025) upplevde nästan hälften av företagen ett certifikatrelaterat avbrott under det senaste året, och 18.5 % av de drabbade organisationerna rapporterade förluster som översteg 250 000 dollar – varav 37.5 % av dessa incidenter var specifikt kopplade till utgångna certifikat. SCEP-utfärdade enhetscertifikat är lika utsatta för denna risk som alla andra certifikattyper om förnyelsen inte automatiseras och spåras.

CA/Browser Forums omröstning SC-081v3, godkänd den 11 april 2025, fasar ner maximal giltighetstid för offentliga TLS-certifikat till 200 dagar från och med den 15 mars 2026, 100 dagar från och med den 15 mars 2027 och 47 dagar från och med den 15 mars 2029. Även om denna omröstning styr offentliga TLS-certifikat snarare än interna SCEP-utfärdade enhetscertifikat direkt, återspeglar den branschens bredare rörelse mot kortare certifikatlivslängder och automatiserad förnyelse – samma disciplin som hindrar SCEP-distributioner från att orsaka enhetsavbrott vid förnyelsetidpunkten.

NIST slutförde sina post-kvantkryptografistandarder — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA) — den 13 augusti 2024. Organisationer som planerar kryptoagila PKI-arkitekturer för post-kvantkrypteringsövergången bör utvärdera om deras SCEP-gateway och utfärdande CA kan stödja PQC-klara algoritmer innan de standardiserar enhetsregistreringsprotokoll på lång sikt.

Förutsättningar innan SCEP distribueras

• En fungerande utfärdande certifikatutfärdare som kan behandla SCEP-formaterade certifikatsigneringsförfrågningar.
• En SCEP-gateway eller NDES-slutpunkt (Network Device Enrollment Service) som kan nås av de enheter som ska registreras.
• En säkert genererad, skiftlägeskänslig SCEP-delad hemlighet, distribuerad endast till MDM:n och aldrig exponerad för slutanvändare.
• En MDM-plattform som kan pusha en SCEP-konfigurationsprofil (certifikatmall, nyckelstorlek, nyckelanvändning, SAN, giltighetsperiod) till hanterade enheter.
• En publicerad rot- och mellanliggande CA-certifikatkedja som enheter kan lita på före registrering.

Hur fungerar SCEP?

1. SCEP-URL: URL:en för Simple Certificate Enrollment Protocol gör det möjligt för en enhet att kommunicera med certifikatutfärdaren för att hämta ett registreringscertifikat.
2. SCEP Delad hemlighet: Ett skiftlägeskänsligt, säkert lösenord används som en SCEP-delad hemlighet mellan CA och SCEP-servern för att autentisera identiteter och domäner som är associerade med CA-certifikatet.
3. SCEP-certifikatsigneringsbegäran: Efter att ha konfigurerat och delat SCEP-gatewayen respektive den delade hemligheten kan användare skapa och distribuera en konfigurationsprofil som gör det möjligt för hanterade enheter att automatiskt registrera sig för certifikat genom att skicka en certifikatregistreringsbegäran till certifikatutfärdaren via SCEP-gatewayen. Ett signerat certifikat utfärdas till enheten efter autentisering.
4. SCEP-signeringscertifikat: Det SCEP-signerade certifikatet laddas upp av Mobile Device Management (MDM), där hela certifikatkedjan (rot-CA, mellanliggande CA, slutentitetscertifikat) ingår.

SCEP-enhetsregistreringsprocess

Följande steg krävs för registrering av SCEP-enheter på MDM:er:

1. Lägg till SCEP-URL
2. Lägg till delad SCEP-hemlighet
3. Ladda upp SCEP-certifikatet, som måste signeras.
4. Ställ in SCEP-konfigurationen.
5. Definiera valfri applikationsspecifik certifikatinställning.
6. Ange vilken enhet som ska ta emot certifikaten.

Efter autentisering av CA kommer ett signerat certifikat att distribueras på den begärda enheten.

SCEP-certifikatkonfigurationsprofil

När administratören konfigurerar en SCEP-server kan hen anpassa SCEP-implementeringen genom att ställa in antalet tillgängliga certifikategenskaper i certifikatkonfigurationsprofilen. Certifikategenskaperna anges nedan:

• Namn på certifikatmallen
• Certifikattyp
• Ämnesnamn (detta hänvisar till den enhet som begär certifikatet, det kan vara ett e-postadress-ID, servernamn eller IP-adress för enheten.)
• Certifikatets giltighetstid (detta avser den tid som certifikatet är giltigt, om det inte återkallas.)
• Hashing-algoritm
• Rot-CA-certifikat
• Nyckelanvändning (detta avser användningen av nyckeln, oavsett om det är för digital signatur, nyckelkryptering eller båda.)
• Nyckelstorlek (detta avser nyckelns storlek, till exempel 1024-bitars eller 2048-bitars)
• Alternativt ämnesnamn (detta avser alternativa uppgifter om ämnet, såsom DNS, URI, UPN etc.)

SCEP kontra EST

EST står för Enrollment over Secure Transport. Det är en utveckling av SCEP och använder Transport Layer Security (TLS) för autentisering av klientsidor. Både SCEP och EST används för att automatisera certifikatregistreringsprocessen, men skillnaden är att SCEP använder Shared Secret-protokollet och CSR:er för att registrera certifikat, medan EST använder TLS för autentisering. EST använder TLS för att säkert transportera meddelanden och certifikat, medan SCEP använder PkcsPKIEnvelope-kuvert för att säkra meddelandena.

SCEP kontra ACME

ACME står för Automated Certificate Management Environment . Både SCEP och ACME är samma sak inom certifikathantering. ACME använder nyckelpar, även kända som auktoriseringsnycklar, för validering av certifikatutfärdaren och organisationen. ACME installerar verktyget för certifikathantering för att generera auktoriseringsnycklar.

SCEP jämfört med CMP och CMC

CMP står för Certificate Management Protocol och CMC står för Certificate Management CMS. Både SCEP och EST används för registrering och utfärdande av certifikat, medan CMP och CMC används för certifikathantering, såsom förnyelse, status och återkallelse av certifikat.

Valideringskontroller efter SCEP-registrering

• Bekräfta att enheten tog emot ett signerat certifikat med förväntat ämnesnamn och alternativt ämnesnamn.
• Verifiera att hela certifikatkedjan (rot-CA, mellanliggande CA, slutentitetscertifikat) finns och är betrodd på enheten.
• Kontrollera att certifikatets giltighetsperiod, nyckelstorlek och hashalgoritm matchar konfigurationsprofilen.
• Bekräfta att SCEP-gatewayloggarna visar en lyckad autentiseringshändelse för registreringsbegäran.
• Testa att enheten kan autentisera mot den avsedda tjänsten (Wi-Fi, VPN eller applikation) med hjälp av det nyligen utfärdade certifikatet.

Vanliga fel och felsökning

Fel / Symptom	Troligtvis orsak	Fast
Registreringsbegäran avvisad av CA	Felaktig eller utgången delad SCEP-hemlighet	Återskapa den delade hemligheten och uppdatera MDM-konfigurationsprofilen
Enheten litar inte på det utfärdade certifikatet	Rot-/mellanliggande CA-kedja har inte publicerats till enheten	Skjut hela CA-kedjan till enheten före eller bredvid SCEP-profilen
Registreringen går ut på tiden	SCEP-gateway/NDES-slutpunkten kan inte nås från enhetens nätverk	Verifiera nätverksrouting, brandväggsregler och gateway-tillgänglighet
Certifikat utfärdat med fel alternativt ämnesnamn	Felkonfigurerad certifikatmall eller konfigurationsprofilvariabler	Korrigera SAN-mappningen i certifikatmallen och registrera dig igen
Upprepade registreringsfel på många enheter	Delad hemlighet exponerad eller registreringsbegäranden med CA-hastighetsbegränsande	Rotera den delade hemligheten omedelbart och granska begränsningsinställningarna för CA-registrering

Återställningssteg

1. Ta bort SCEP-konfigurationsprofilen från berörda enheter via MDM-konsolen.
2. Återkalla alla certifikat som utfärdats under den misslyckade registreringsfönstret via den utfärdande certifikatutfärdaren.
3. Rotera den delade SCEP-hemligheten om det misstänks att felet komprometteras eller upprepas.
4. Återställ den tidigare fungerande SCEP-gateway/NDES-konfigurationen från säkerhetskopian.
5. Skicka den korrigerade konfigurationsprofilen till en liten pilotenhetsgrupp innan en fullständig ny utrullning.

Referenstabell för SCEP-distribution

Förutsättning	Kommando/konfiguration	Valideringskontroll	Vanligt fel	rollback	Ägare
Utfärdande CA nåbar	Konfigurera SCEP-gateway/NDES-slutpunkt	Bekräfta att gatewayen svarar på registreringsförfrågningar	Registreringen går ut på tiden	Återställ tidigare gateway-konfiguration	PKI-administratörer
Delad hemlighet genererad	Ange skiftlägeskänslig delad SCEP-hemlighet i MDM-profil	Verifiera hemliga matchningar på CA och MDM	Registreringsbegäran avvisad	Rotera och omfördela delad hemlighet	PKI-administratörer
CA-kedjan publicerad	Skicka rot-/mellanliggande CA-certifikat till enheten	Bekräfta att enheten litar på hela kedjan	Enheten litar inte på utfärdat certifikat	Återställ CA-kedjan, registrera enheten igen	Plattformsteam
Certifikatmall konfigurerad	Ange ämnesnamn, SAN, nyckelstorlek, giltighetsperiod	Bekräfta att utfärdat certifikat matchar mallen	Fel SAN eller nyckelstorlek utfärdad	Korrigera mallen, återkalla den och utfärda den på nytt	PKI-administratörer / säkerhetsarkitekter
MDM-profil distribuerad	Skicka SCEP-konfigurationsprofilen till hanterade enheter	Bekräfta att enheten tar emot ett signerat certifikat	Upprepade fel på många enheter	Ta bort profil, rotera hemlighet, testa om utrullning	Plattformsteam

Certifikatlivscykelhantering och PKI-modernisering

SCEP automatiserar utfärdandet, men de certifikat som utfärdas måste fortfarande spåras, förnyas och återkallas precis som alla andra certifikat i miljön. CertSecure Manager tillhandahåller certifikatidentifiering och livscykelautomation för SCEP-utfärdade enhetscertifikat och alla andra certifikattyper, vilket minskar gapet som orsakar tysta utgångar och enhetsavbrott.

Organisationer som standardiserar enhetsregistrering i en hybrid- eller multi-CA-miljö kan förlita sig på PKI-as-a-Service för molnbaserad PKI-modernisering som stöder SCEP, EST och ACME konsekvent över utfärdande CA:er. Innan en SCEP-utrullning skalas upp är det värt att bygga en maskinidentitetsinventering genom CBOM Secure och genomföra en PQC- beredskapsbedömning, så att certifikatidentifiering för enhetsregistrering också bygger kryptoflexibilitet för övergången efter kvantum. Encryption Consultings PQC Center of Excellence erbjuder vägledning om hur man sekvenserar dessa initiativ.

För mer information om varför certifikatautomatisering är viktigt i alla miljöer, se våra artiklar i utbildningscentret om stegen i ett certifikats livscykel och hur man undviker certifikatavbrott.

Mätning av framgång och pågående revisioner

Spåra andelen hanterade enheter som registrerats via SCEP vid första försöket, antalet registreringsmisslyckade per utrullning och hur länge den aktuella delade hemligheten har använts sedan den senaste rotationen. Granska SCEP-gatewayloggar, CA-utgivningsloggar och instrumentpaneler för enhetscertifikats utgång regelbundet – kvartalsvis för rotationspolicyn för delade hemligheter och kontinuerligt för certifikatets utgång – för att upptäcka förnyelsemisslyckade enheter innan de orsakar enhetsavbrott.

Slutsats

SCEP Gateway API kan användas för att distribuera certifikat till alla hanterade enheter. SCEP Gateway API gör det möjligt för hanterade enheter att enkelt registrera sig för certifikat på egen hand, men det ökar också säkerhetsrisken. Mobila enheter som använder SCEP för registrering av digitala certifikat kan vara sårbara för en Privilege Escalation Attack. EST är utvecklingen av SCEP, som är säkrare och använder TLS för autentisering av enheter på klientsidan.

Senast uppdaterad: augusti 2026. Senast verifierad: augusti 2026. Det här inlägget följer en kvartalsvis uppdateringskadens med tanke på dess kopplingar till föränderliga certifikatprotokollstandarder och leverantörsriktlinjer.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste slutsatsen från Vad är SCEP-tjänsten? Hur fungerar SCEP-protokollet?

SCEP automatiserar certifikatregistrering för hanterade enheter med hjälp av en SCEP-URL och en delad hemlighet för att begära ett signerat certifikat från en CA via en SCEP-gateway, vanligtvis distribuerad via MDM. Det eliminerar manuellt certifikatutbyte i stor skala, men dess modell med delade hemligheter är en känd svag punkt jämfört med EST eller ACME.

Varför är detta viktigt för PKI-team på stora företag?

SCEP-utfärdade certifikat är fortfarande en del av organisationens totala certifikatpopulation och behöver samma livscykelhantering, automatisering av förnyelser och övervakning av utgångsdatum som alla TLS- eller kodsigneringscertifikat för att undvika enhetsavbrott.

Vilka risker ökar om detta ämne hanteras manuellt?

Att manuellt hantera delade SCEP-hemligheter och certifikatförnyelser ökar risken för en inaktuell, överdelad hemlighet som möjliggör obehörig registrering och ökar chansen att utgångna enhetscertifikat går obemärkt förbi tills enheterna förlorar anslutningen.

Vilka lag borde ta över den här förändringen?

PKI-administratörer äger SCEP-gatewayen och den delade hemliga policyn, plattformsteam äger MDM-konfigurationsprofilen och enhetsutrullningen, säkerhetsarkitekter utvärderar protokollvalet och efterlevnadsteam verifierar att rotations- och giltighetspolicyer följs.

Hur kopplas detta till hantering av certifikatlivscykeln?

Varje certifikat som SCEP utfärdar till en enhet måste fortfarande spåras, förnyas och återkallas. Att behandla SCEP-utfärdade certifikat som en del av samma certifikatlivscykelhanteringsprogram som andra certifikattyper förhindrar en ohanterad, isolerad population av enhetscertifikat.

Hur bör organisationer mäta framgång?

Spåra andelen framgångsrika registreringar vid första försöket, antal misslyckade registreringar per utrullning och hur länge den delade SCEP-hemligheten har använts sedan den senaste rotationen.

Vad bör granskas eller övervakas regelbundet?

Granska regelbundet SCEP-gateway- och CA-utgivningsloggar för avvikande registreringsmönster, historik över delad hemlig rotation och instrumentpaneler för enhetscertifikats utgång för att upptäcka förnyelsefel innan de orsakar avbrott.

Hur påverkar detta ämne moln-, hybrid- eller multi-CA PKI?

Organisationer med hybrid- eller multi-CA PKI behöver SCEP-utfärdade certifikat för att vara konsekvent betrodda över varje utfärdande CA och nätverkssegment, vilket kräver centraliserad certifikatidentifiering och en konsekvent förtroendekedja i hela miljön.

Vilka förutsättningar krävs innan implementering?

En fungerande utfärdande CA, en nåbar SCEP-gateway/NDES-slutpunkt, en säkert genererad delad hemlighet, en MDM som kan pusha en SCEP-konfigurationsprofil och en publicerad rot-/mellanliggande CA-kedja som enheter kan lita på före registrering.

Vilka vanliga fel bör administratörer vara uppmärksamma på?

Håll utkik efter registreringsförfrågningar som avvisats på grund av en felaktig eller utgången delad hemlighet, enheter som inte litar på det utfärdade certifikatet eftersom CA-kedjan inte publicerades, registreringstimeouts från en oåtkomlig SCEP-gateway och certifikat som utfärdats med fel alternativt ämnesnamn på grund av en felkonfigurerad mall.