Uppdatering mars 2026:
Google Chrome Root Program har skjutit upp deadline till 15 mars 2027. DigiCert tar bort clientAuth EKU från alla nya certifikat den 1 mars 2027. Sedan 1 oktober 2025 utfärdar DigiCert bara serverAuth som standard, men clientAuth kan fortfarande väljas till vid beställning.
Client Authentication försvinner från offentliga SSL-certifikat
CA/Browser Forum antog 2024 Ballot SC-081, som förutom att korta certifikatens giltighetstid också tar bort "Client Authentication" från Extended Key Usage (EKU) i offentliga SSL/TLS-certifikat.
Varje CA inför ändringen för sig: DigiCert tar bort Client Auth EKU helt från 1 mars 2027, Let's Encrypt tog bort det som standard i februari 2026, och andra CA:er följer efter före Chrome Root Programs deadline den 15 mars 2027.
Om du använder dina SSL-certifikat till annat än server-TLS bör du börja planera.
Vad är Extended Key Usage?
Extended Key Usage (EKU) är ett fält i X.509-certifikat som anger vilka ändamål certifikatet får användas till. Ett typiskt SSL-certifikat har idag två EKU-värden:
| EKU | OID | Ändamål |
|---|---|---|
| Server Authentication | 1.3.6.1.5.5.7.3.1 |
Tillåter användning som servercertifikat i TLS |
| Client Authentication | 1.3.6.1.5.5.7.3.2 |
Tillåter användning som klientcertifikat i TLS |
Server Authentication är huvudändamålet. Client Authentication har traditionellt tagits med eftersom många produkter krävde det och det inte skadade att ha med.
Varför tas Client Authentication bort?
CA/Browser Forum har tre argument:
- Principen om minsta möjliga behörighet. Ett SSL-certifikat är avsett att identifiera en server. Att det samtidigt kan användas för att identifiera en klient utökar angreppsytan i onödan. Om ett servercertifikats privata nyckel komprometteras kan angriparen både utge sig för servern och använda certifikatet för klientautentisering mot andra system.
- Tydligare separation. Klientcertifikat bör utfärdas specifikt för det ändamålet med lämplig validering och nyckelhantering. Att återanvända ett servercertifikat för klientautentisering är en genväg som kringgår denna separation.
- Förenklad profil. TLS Server Certificate Profile i de nya Baseline Requirements har stramats åt. Färre EKU-värden ger CA:erna och webbläsarna enklare validering.
Tidsplan för ändringen
| CA | Datum | Anmärkning |
|---|---|---|
| Let's Encrypt | Februari 2026 | Standardprofil utan clientAuth från 11-02-2026. Tillfällig tlsclient-profil till 08-07-2026. |
| GlobalSign | 13 september 2026 | Byte till rotcertifikat enbart för TLS (R46/E46) som inte stöder clientAuth |
| DigiCert | 1 mars 2027 | Inkl. RapidSSL, GeoTrust, Thawte. Sedan 01-10-2025 bara serverAuth som standard, clientAuth kan väljas till. Från 01-03-2027 tas möjligheten bort helt. |
| Sectigo | Mars 2027 (uppskattning) | Förväntas följa samma deadline |
| Google Chrome | 15 mars 2027 | Nya offentliga TLS-certifikat får bara innehålla serverAuth EKU. Befintliga certifikat påverkas inte. |
Chrome Root Programs deadline den 15 mars 2027 är den faktiska slutgränsen. Från detta datum får nya offentliga TLS-certifikat bara innehålla serverAuth EKU. Befintliga certifikat med clientAuth behåller sin EKU och förblir betrodda tills de löper ut.
Certifikat utfärdade före CA:ernas ändringsdatum behåller sin Client Auth EKU och förblir betrodda tills de löper ut. Bara nya utfärdanden (och återutfärdanden) efter datumet saknar den.
Eftersom giltighetstiden sedan 15 mars 2026 är högst 199 dagar kommer alla certifikat i omlopp att sakna Client Auth EKU inom ett år efter ändringen.
Vem påverkas?
Du påverkas om du använder ditt SSL-certifikat för:
- VPN-autentisering: Många VPN-lösningar (OpenVPN, Cisco AnyConnect, Fortinet SSL VPN) kan konfigureras att kräva ett klientcertifikat vid inloggning. Om det är samma certifikat som webbservern använder slutar det fungera.
- Mutual TLS (mTLS): API:er och mikrotjänster som använder mTLS för att verifiera båda parter i en anslutning. Om servercertifikatet också används som klientcertifikat i utgående anrop misslyckas det.
- RDP Gateway: Windows Remote Desktop Gateway kan använda certifikatet för både server- och klientautentisering.
- Exchange Server: Interna Exchange-anslutningar (server-till-server) använder i vissa konfigurationer Client Auth EKU.
- RADIUS/802.1X: Nätverksautentisering via EAP-TLS, där servercertifikatet också fungerar som klientidentitet.
Du påverkas inte om du bara använder SSL-certifikatet för HTTPS på en webbserver. Det är det överlägset vanligaste scenariot, och det kräver bara Server Authentication EKU.
Deadline: 15 mars 2027
Från detta datum får nya offentliga TLS-certifikat inte innehålla Client Authentication EKU. Befintliga certifikat behåller sin EKU tills de löper ut. Om du använder Client Auth idag måste du planera övergången.
Vad ska du göra?
Om du använder Client Auth EKU har du flera alternativ:
1. Dedikerade klientcertifikat från en privat CA
Den mest hållbara lösningen är att sätta upp en intern CA (t.ex. via Active Directory Certificate Services, step-ca eller OpenSSL) och utfärda dedikerade klientcertifikat till de berörda systemen.
Fördelar: full kontroll över EKU, giltighetstid och utfärdandepolicy. Inget beroende av externa CA:er. Inga löpande kostnader utöver driften av CA-infrastrukturen.
Nackdel: kräver infrastruktur för att driva en intern CA och distribuera certifikat.
För enkla scenarier med få servrar kan ett självsignerat certifikat med Client Auth EKU vara tillräckligt. Du förlorar central administration, men slipper driva en fullständig CA. Varje självsignerat certifikat måste läggas till som betrott på vart och ett av de mottagande systemen.
Vill du ha fördelarna med en privat CA utan att själv driva infrastrukturen erbjuder flera kommersiella CA:er privat CA som tjänst (till exempel DigiCert ONE och GlobalSign Atlas). Du betalar en löpande licens och får en CA som leverantören driftar, med API-åtkomst, certifikathantering och automatiskt utfärdande. Det är lämpligt för större organisationer med många klientcertifikat, men överdrivet för ett par VPN-servrar.
2. Separata servercertifikat för mTLS
Om du använder mTLS mellan interna tjänster kan du utfärda certifikat från en privat CA för det ändamålet och behålla det offentliga SSL-certifikatet för kundvänd TLS.
3. Kontrollera din konfiguration nu
Många system som till synes kräver Client Auth EKU kan konfigureras att fungera utan det. Kontrollera dokumentationen för din VPN-lösning, lastbalanserare eller application gateway. Ofta är kravet en standardinställning som kan stängas av.
4. Kontakta oss
Om du är osäker på om dina system använder Client Auth EKU är du välkommen att kontakta oss. Vi kan hjälpa till att identifiera beroenden och planera migreringen.
Tidsplan och rekommendation
Börja med att identifiera vilka system som använder Client Auth EKU:
- Gå igenom din VPN-konfiguration. Kräver den klientcertifikat?
- Sök i konfigurationsfiler efter referenser till Client Authentication eller OID 1.3.6.1.5.5.7.3.2.
- Testa med ett certifikat utan Client Auth EKU i en testmiljö innan ändringen slår igenom i produktion.
- Planera övergången till dedikerade klientcertifikat om det behövs.