Private vs. offentlige CA'er: du bruger måske den forkerte

For et presset it-team ligner en offentlig certifikatmyndighed (CA) tit en hammer, og så ligner ethvert krav om kryptering et søm. Men at bruge en offentlig CA til alting er en af de mest udbredte måder at ødelægge produktionen på, uden at nogen opdager det.

Det, offentlige CA'er er bygget til

En offentlig CA, for eksempel DigiCert, Sectigo eller Let's Encrypt, er lavet til ét hovedscenarie: når du skal etablere tillid til enheder, du ikke selv styrer. Idéen er, at eksterne brugere ikke skal konfigurere noget som helst for at have tillid til dit websted eller din tjeneste.

En offentlig CA giver mening, når:

• Du driver offentligt tilgængelige tjenester for eksterne brugere, kunder eller partnere, der ikke har et tillidsforhold til din organisation i forvejen
• Eksterne API'er eller tjenester forbinder til din infrastruktur uden særlig klientkonfiguration
• Certifikatfejl ville vise sig som en browseradvarsel hos slutbrugerne
• Du signerer e-mails, og modtagerne skal kunne verificere signaturen uden at konfigurere noget på forhånd

CA/Browser Forum bestemmer, hvad offentlige CA'er må udstede. Du er underlagt regler, du ikke selv styrer, og for mange er det et rimeligt bytte i de scenarier ovenfor. En offentlig CA kan blive et problem, når du bruger de samme certifikater til intern autentificering.

Det, private CA'er er bygget til

En privat CA er en, du selv driver, eller en, din leverandør driver for dig. Du fastlægger politikken for udstedelse. Certifikaterne er ikke betroet nogen steder som udgangspunkt. Du udruller din private CA's rodcertifikat til dine enheder og brugere via gruppepolitik, Intune eller din MDM-platform, og dine administrerede endepunkter stoler så på certifikater, der er udstedt af din private CA.

En privat CA er det rigtige valg alle de steder, hvor kun din egen infrastruktur skal have tillid til certifikatet:

• Enhedsautentificering, altså bevis for at en maskine er administreret og tilhører din organisation
• Brugerautentificering med certifikater, adgangskodefrit login, smartcard-lignende løsninger eller adgang til interne apps
• Sikring af Wi-Fi (802.1X) og VPN-forbindelser
• Opsætning af gensidig TLS (mTLS) mellem backend-mikrotjenester
• Kodesignering af interne værktøjer og scripts

Du beholder fuld kontrol over tillidskæden og udstedelsespolitikken, uden at være afhængig af, hvordan eksterne CA'er styres.

Offentlig CA eller privat CA? En hurtig sammenligning

Når det går galt

Den mest udbredte fejl, it-teams begår, er at bruge certifikater fra en offentlig CA til intern autentificering. Offentlige CA'er har aldrig været tænkt til interne workloads, og to udviklinger lige nu gør det hul umuligt at overse.

1. Ingen Client Authentication-EKU'er på offentlige TLS-certifikater

Offentligt betroede TLS-certifikater må ikke længere bære en Client Authentication-EKU. Drevet af CA/Browser Forums afstemning SC-081 og opdateringer i de store rodprogrammer udfaser de offentlige CA'er clientAuth inden den endelige frist i marts 2027. Hvis din interne autentificering af enheder eller brugere bygger på offentlige certifikater, holder de opsætninger op med at fungere ved næste fornyelse.

2. Hastigt faldende levetid

Offentlige CA'er skærer hele tiden ned på certifikaternes gyldighedsperiode. Under SC-081v3 er den offentlige grænse sat til 200 dage (2026), faldende til 100 dage i marts 2027 og 47 dage i marts 2029. Automatiske værktøjer klarer fint fornyelser hver 90. dag på offentlige webservere, men at registrere tusindvis af interne bærbare og enheder på ny hver sjette uge er et administrativt mareridt.

En privat CA ligger uden for de rammer. Fordi du håndterer tilbagekaldelse direkte i dit eget miljø, har du ikke brug for kunstigt korte levetider eller eksterne valideringskontroller. Du fastsætter selv de gyldighedsperioder og regler, der giver mening for dit team.

Sådan vælger du den rigtige

Spørg dig selv for hvert certifikat i dit miljø: styrer du hver eneste enhed eller klient, der skal validere certifikatet?

• Hvis ja: Brug en privat CA. Du udruller rod-CA'ens certifikat, bestemmer hvad der bliver udstedt, og slipper for at være underlagt eksterne regelændringer.
• Hvis nej: Du har brug for en offentlig CA. En, der forbinder udefra uden forudgående konfiguration, har brug for en CA, deres enhed allerede stoler på.

De fleste it-afdelinger ender med at have brug for begge dele: offentlige certifikater til udadvendte tjenester og private certifikater til enheder, brugere og interne tjenester.

Sådan passer SCEPman ind

SCEPman er en cloud-native privat CA, der integrerer med Microsoft Intune og Entra ID og med andre MDM-platforme via SCEP og EST. Den håndterer automatisk certifikatudstedelse til administrerede enheder og brugere.

I Intune-miljøer binder SCEPman certifikatets gyldighed til enhedens compliancestatus. En enhed, der bliver nulstillet eller falder ud af compliance, mister sit certifikat og får dermed automatisk lukket adgangen til Wi-Fi, VPN og interne applikationer.

SCEPman kan også udstede certifikater manuelt med Certificate Master. Det giver it-afdelinger mulighed for at erstatte certifikater fra offentlige CA'er på tværs af interne systemer som webportaler, apps og grænseflader til enhedsadministration.

Sådan kommer du i gang

Hvis du ikke har en privat CA, eller hvis du gerne vil væk fra ældre, lokalt installerede Active Directory Certificate Services (ADCS), er det et godt afsæt for en snak om SCEPman.

Prøv SCEPman selv

Start en prøveperiode på 30 dage, og se, hvordan SCEPman udsteder og administrerer certifikater fra en privat CA til dine enheder, brugere og interne tjenester, uden at du skal drive din egen PKI.

Start 30-dages prøveperiode med SCEPman

Ofte stillede spørgsmål