Opdatering marts 2026:
Google Chrome Root Program har udskudt deadline til 15. marts 2027. DigiCert fjerner clientAuth EKU fra alle nye certifikater den 1. marts 2027. Siden 1. oktober 2025 udsteder DigiCert kun serverAuth som standard, men clientAuth kan stadig vælges til ved bestilling.
Client Authentication forsvinder fra offentlige SSL-certifikater
CA/Browser Forum vedtog i 2024 Ballot SC-081, der ud over reduktionen af certifikaters levetid også fjerner "Client Authentication" fra Extended Key Usage (EKU) i offentlige SSL/TLS-certifikater.
Ændringen indfases per CA: DigiCert fjerner Client Auth EKU helt fra 1. marts 2027, Let's Encrypt fjernede det som standard i februar 2026, og andre CA'er følger inden Chrome Root Programs deadline den 15. marts 2027.
Hvis du bruger dine SSL-certifikater til andet end server-TLS, bør du begynde at planlægge.
Hvad er Extended Key Usage?
Extended Key Usage (EKU) er et felt i X.509-certifikater, der angiver, hvilke formål certifikatet må bruges til. Et typisk SSL-certifikat har i dag to EKU-værdier:
| EKU | OID | Formål |
|---|---|---|
| Server Authentication | 1.3.6.1.5.5.7.3.1 |
Tillader brug som server-certifikat i TLS |
| Client Authentication | 1.3.6.1.5.5.7.3.2 |
Tillader brug som klient-certifikat i TLS |
Server Authentication er kerneformålet, mens Client Authentication historisk er blevet medtaget, fordi mange produkter krævede det, og det ikke skadede at have det med.
Hvorfor fjernes Client Authentication?
CA/Browser Forum har tre argumenter:
- Princippet om mindste privilegium. Et SSL-certifikat er designet til at identificere en server. At det samtidig kan bruges til at identificere en klient, udvider angrebsfladen unødvendigt. Hvis et servercertifikats private nøgle kompromitteres, kan angriberen ikke kun udgive sig for serveren, men også bruge certifikatet til klientgodkendelse mod andre systemer.
- Klarere adskillelse. Klientcertifikater bør udstedes specifikt til det formål med passende validering og nøglehåndtering. At genbruge et servercertifikat til klientgodkendelse er en genvej, der omgår denne adskillelse.
- Forenklet profil. TLS Server Certificate Profile i de nye Baseline Requirements er strammet op. Færre EKU-værdier giver CA'erne og browserne enklere validering.
Tidsplan for ændringen
| CA | Dato | Bemærkning |
|---|---|---|
| Let's Encrypt | Februar 2026 | Standard-profil uden clientAuth fra 11-02-2026. Midlertidig tlsclient-profil til 08-07-2026. |
| GlobalSign | 13. september 2026 | Skift til TLS-dedikerede rødder (R46/E46) der ikke understøtter clientAuth |
| DigiCert | 1. marts 2027 | Inkl. RapidSSL, GeoTrust, Thawte. Siden 01-10-2025 kun serverAuth som standard, clientAuth kan vælges til. Fra 01-03-2027 fjernes muligheden helt. |
| Sectigo | Marts 2027 (estimat) | Forventes at følge samme deadline |
| Google Chrome | 15. marts 2027 | Nye offentlige TLS-certifikater må kun indeholde serverAuth EKU. Eksisterende certifikater påvirkes ikke. |
Chrome Root Programs deadline den 15. marts 2027 er den reelle hårde grænse. Fra denne dato må nye offentlige TLS-certifikater kun indeholde serverAuth EKU. Eksisterende certifikater med clientAuth beholder deres EKU og forbliver trusted indtil de udløber.
Certifikater udstedt før CA'ernes ændringsdato beholder deres Client Auth EKU og forbliver trusted indtil de udløber. Kun nye udstedelser (og genudstedelser) efter datoen mangler det.
Med den samtidige reduktion af SSL-levetid til 200 dage (fra marts 2026) vil alle certifikater i omløb mangle Client Auth EKU inden for et år efter ændringen.
Hvem er påvirket?
Du er påvirket, hvis du bruger dit SSL-certifikat til:
- VPN-godkendelse: Mange VPN-løsninger (OpenVPN, Cisco AnyConnect, Fortinet SSL VPN) kan konfigureres til at kræve et klientcertifikat ved login. Hvis det er det samme certifikat som webserveren bruger, stopper det med at virke.
- Mutual TLS (mTLS): API'er og microservices, der bruger mTLS til at verificere begge parter i en forbindelse. Hvis servercertifikatet også bruges som klientcertifikat i udgående kald, fejler det.
- RDP Gateway: Windows Remote Desktop Gateway kan bruge certifikatet til både server- og klientgodkendelse.
- Exchange Server: Interne Exchange-forbindelser (server-til-server) bruger i nogle konfigurationer Client Auth EKU.
- RADIUS/802.1X: Netværksgodkendelse via EAP-TLS, hvor servercertifikatet også fungerer som klientidentitet.
Du er ikke påvirket, hvis du kun bruger SSL-certifikatet til HTTPS på en webserver. Det er langt det mest almindelige scenarie, og det kræver kun Server Authentication EKU.
Deadline: 15. marts 2027
Fra denne dato må nye offentlige TLS-certifikater ikke indeholde Client Authentication EKU. Eksisterende certifikater beholder deres EKU til udløb. Hvis du bruger Client Auth i dag, skal du planlægge overgangen.
Hvad skal du gøre?
Hvis du bruger Client Auth EKU, har du flere muligheder:
1. Dedikerede klientcertifikater fra en privat CA
Den mest robuste løsning er at oprette en intern CA (f.eks. via Active Directory Certificate Services, step-ca eller OpenSSL) og udstede dedikerede klientcertifikater til de pågældende systemer.
Fordele: fuld kontrol over EKU, levetid og udstedelsespolitik. Ingen afhængighed af eksterne CA'er. Ingen løbende omkostninger ud over driften af CA-infrastrukturen.
Ulempe: kræver infrastruktur til at drive en intern CA og distribuere certifikater.
For simple scenarier med få servere kan et selvsigneret certifikat med Client Auth EKU være tilstrækkeligt. Du mister central administration, men slipper for at drive en fuld CA. Hvert selvsigneret certifikat skal tilføjes individuelt som trusted på de modtagende systemer.
Vil du have fordelene ved en privat CA uden selv at drive infrastrukturen, tilbyder flere kommercielle CA'er managed private CA-tjenester (f.eks. DigiCert ONE, GlobalSign Atlas). Du betaler en løbende licens og får en hosted CA med API-adgang, certifikatstyring og automatisk udstedelse. Det giver mening for større organisationer med mange klientcertifikater, men er overkill for et par VPN-servere.
2. Separate servercertifikater til mTLS
Hvis du bruger mTLS mellem interne services, kan du udstede certifikater fra en privat CA til det formål og beholde det offentlige SSL-certifikat til kundevendt TLS.
3. Tjek din konfiguration nu
Mange systemer, der tilsyneladende kræver Client Auth EKU, kan konfigureres til at fungere uden det. Tjek dokumentationen for din VPN, load balancer eller application gateway. Ofte er kravet en standardindstilling, der kan slås fra.
4. Kontakt os
Hvis du er usikker på, om dine systemer bruger Client Auth EKU, er du velkommen til at kontakte os. Vi kan hjælpe med at identificere afhængigheder og planlægge migreringen.
Tidslinje og anbefaling
Begynd med at identificere, hvilke systemer der bruger Client Auth EKU:
- Gennemgå din VPN-konfiguration. Kræver den klientcertifikat?
- Søg i konfigurationsfiler efter references til Client Authentication eller OID 1.3.6.1.5.5.7.3.2.
- Test med et certifikat uden Client Auth EKU i et testmiljø, før ændringen rammer produktion.
- Planlæg overgangen til dedikerede klientcertifikater, hvis det er nødvendigt.