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 utöver reduktionen av certifikatens livslängd också tar bort "Client Authentication" från Extended Key Usage (EKU) i offentliga SSL/TLS-certifikat.
Ändringen införs per CA: 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 innan 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 kärnändamålet, medan Client Authentication historiskt har inkluderats eftersom många produkter krävde det, och det inte skadade att ha med det.
Varför tas Client Authentication bort?
CA/Browser Forum har tre argument:
- Principen om minsta privilegium. Ett SSL-certifikat är designat för 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 inte bara utge sig för servern, utan också 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 weblä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 TLS-dedikerade rötter (R46/E46) som inte stödjer 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 verkliga hårda grä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 trusted tills de löper ut.
Certifikat utfärdade före CA:ernas ändringsdatum behåller sin Client Auth EKU och förblir trusted tills de löper ut. Bara nya utfärdanden (och omutfärdanden) efter datumet saknar det.
Med den samtidiga reduktionen av SSL-livslängd till 200 dagar (från mars 2026) 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 microservices 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 till utgång. 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 robusta lösningen är att skapa 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, livslängd 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 individuellt som trusted på de mottagande systemen.
Vill du ha fördelarna med en privat CA utan att själv driva infrastrukturen erbjuder flera kommersiella CA:er managed privat CA-tjänster (t.ex. DigiCert ONE, GlobalSign Atlas). Du betalar en löpande licens och får en hostad CA med API-åtkomst, certifikathantering och automatisk utfärdning. 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, 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.