Privata och publika CA:er: du kanske använder fel

För ett pressat IT-team ser en publik certifikatutfärdare (CA) ofta ut som en hammare, och varje krypteringskrav som en spik. Men att använda en publik CA till varje uppgift är ett av de vanligaste sätten att sabotera produktionsmiljön i det tysta.

Vad publika CA:er är byggda för

En publik CA, till exempel DigiCert, Sectigo eller Let's Encrypt, är byggd för ett huvudsakligt scenario: när du behöver etablera förtroende med enheter som du inte styr över. Tanken är att externa användare inte ska behöva konfigurera någonting alls för att lita på din webbplats eller tjänst.

En publik CA är rimlig när:

• Du driver publika tjänster för externa användare, kunder eller partner som inte har någon befintlig förtroenderelation med din organisation
• Externa API:er eller tjänster ansluter till din infrastruktur utan särskild klientkonfiguration
• Certifikatfel skulle visas som en webbläsarvarning för slutanvändarna
• Du signerar e-post och mottagarna behöver kunna verifiera signaturen utan någon förkonfiguration

CA/Browser Forum styr vad publika CA:er får utfärda. Du lyder under regler som du inte kontrollerar, vilket för många är en rimlig avvägning i scenarierna ovan. En publik CA kan däremot bli ett problem när du använder samma certifikat för intern autentisering.

Vad privata CA:er är byggda för

En privat CA är en som du driver själv, eller som din leverantör driver åt dig. Du definierar policyn för utfärdande. Certifikaten är inte betrodda någonstans som standard. Du distribuerar rotcertifikatet från din privata CA till dina enheter och användare via grupprinciper, Intune eller din MDM-plattform, och sedan litar dina hanterade slutpunkter på certifikat som din privata CA har utfärdat.

En privat CA passar överallt där bara din egen infrastruktur behöver lita på certifikatet:

• Enhetsautentisering, som visar att en maskin är hanterad och tillhör din organisation
• Användarautentisering med certifikat, lösenordsfri inloggning, motsvarigheter till smartkort eller åtkomst till interna appar
• Skydd av Wi-Fi (802.1X) och VPN-anslutningar
• Uppsättning av ömsesidig TLS (mTLS) mellan mikrotjänster i backend
• Kodsignering av interna verktyg och skript

Du behåller full kontroll över förtroendekedjan och policyn för utfärdande, utan beroende av externa CA-regelverk.

Publik CA eller privat CA? En snabb jämförelse

Där det går fel

Det vanligaste misstaget IT-team gör är att använda certifikat från en publik CA för intern autentisering. Publika CA:er var aldrig tänkta för interna arbetsbelastningar, och två förändringar som pågår just nu gör den luckan omöjlig att ignorera.

1. Inga fler Client Authentication-EKU:er i publika TLS-certifikat

Publikt betrodda TLS-certifikat får inte längre bära Client Authentication-EKU:n. Drivet av CA/Browser Forums omröstning SC-081 och uppdateringar i de stora rotprogrammen fasar publika CA:er ut clientAuth inför den hårda gränsen i mars 2027. Om din interna enhets- eller användarautentisering bygger på publika certifikat slutar de uppsättningarna att fungera vid nästa förnyelse.

2. Snabbt krympande giltighetstid

Publika CA:er kortar hela tiden certifikatens giltighetsfönster. Enligt SC-081v3 är den publika giltighetsgränsen 200 dagar (2026), som sjunker till 100 dagar i mars 2027 och 47 dagar till mars 2029. Automatiserade verktyg klarar förnyelse var nittionde dag utan problem på publika webbservrar, men att registrera om tusentals interna bärbara datorer eller enheter var sjätte vecka är en administrativ mardröm.

En privat CA står utanför de här begränsningarna. Eftersom du sköter återkallelse direkt i din egen miljö behöver du inga konstlat korta giltighetstider eller externa valideringskontroller. Du bestämmer de giltighetstider och regler som är rimliga för ditt team.

Så avgör du vilken du ska använda

Ställ den här frågan för varje certifikat i din miljö: styr du över varje enhet eller klient som behöver validera certifikatet?

• Om ja: Använd en privat CA. Du distribuerar rotcertifikatet, styr vad som utfärdas och slipper externa regeländringar.
• Om nej: Du behöver en publik CA. Den som ansluter utifrån utan förkonfiguration behöver en CA som enheten redan litar på.

De flesta IT-avdelningar behöver till slut båda: publika certifikat för externa tjänster och privata certifikat för enheter, användare och interna tjänster.

Så passar SCEPman in

SCEPman är en molnbaserad privat CA som integreras med Microsoft Intune och Entra ID, liksom med andra MDM-plattformar via SCEP och EST. Den sköter automatiskt utfärdande av certifikat för hanterade enheter och användare.

I Intune-miljöer knyter SCEPman certifikatens giltighet till enhetens efterlevnadsstatus. En enhet som rensas eller inte längre uppfyller kraven förlorar sitt certifikat, vilket automatiskt stänger av åtkomsten till Wi-Fi, VPN och interna applikationer.

SCEPman kan också utfärda certifikat manuellt med Certificate Master. Det gör att IT-avdelningar kan ersätta certifikat från publika CA:er i interna system som webbportaler, appar och gränssnitt för enhetshantering.

Var du ska börja

Om du inte har någon privat CA, eller om du vill lämna ett äldre, lokalt Active Directory Certificate Services (ADCS), är det en bra utgångspunkt för ett samtal om SCEPman.

Testa SCEPman själv

Starta en 30-dagars testversion och se hur SCEPman utfärdar och hanterar certifikat från en privat CA för dina enheter, användare och interna tjänster, utan bördan av att driva en egen PKI.

Starta SCEPmans 30-dagars testversion

Vanliga frågor