Windows 11 24H2 brød med TLS 1.3 — hvad det betyder for danske udviklere og hvordan du håndterer det

Introduktion
Windows 11 24H2 og Windows Server 2025 indførte ændringer i måden TLS 1.3 håndteres i Windows (via Schannel/http.sys). Ændringen forbedrer sikkerhed og ydeevne — men har samtidig gjort, at nogle webserver- og udviklingsscenarier, som forventer at kunne anmode om klientcertifikater “senere” i sessionen (renegotiation/post-handshake), nu fejler. For danske udviklere, it-drift og virksomheder kan det betyde fejl 500 ved autentificering, brudte testflows og problemer med interne løsninger, der bruger klientcertifikater. Denne artikel forklarer konsekvenserne, hvordan du finder fejlen, og gennemgår sikre, praktiske workarounds med fordele/ulemper — målrettet danske omgivelser.

Hvad skete der? Kort forklaring

• I ældre TLS-versioner (fx TLS 1.2) kunne en server bede om klientcertifikat midt i en allerede etableret session via såkaldt renegotiation.
• TLS 1.3 fjernede den klassiske renegotiation. I stedet findes en post-handshake klientautentifikation, men de fleste klienter og browsersupport er begrænset.
• Microsofts implementering i Windows 11 24H2/http.sys afviser nu scenarier, hvor klientcertifikatet ikke leveres i det oprindelige handshake, hvilket medfører fejl (http.sys returnerer “not supported”, IIS ender fx med HTTP 500).
• Problemet rammer især IIS og IIS Express (udviklermiljøer) og systemer, hvor klientcertifikater anvendes dynamisk efter sessionstart.

Hvorfor det berører danske virksomheder og udviklere

• Mange danske organisationer bruger klientcertifikater til interne webapps, smart-card autentifikation, agent- eller maskin-til-maskin autentifikation og enkelte custom SSO-/eID-flows. Selv hvis offentlige eID-løsninger (fx MitID) ikke direkte er påvirket, kan interne integrations- og testmiljøer være det.
• Devs der kører IIS Express lokalt på Windows 11 24H2 kan opleve at udviklings- og testscenarier med klientcertifikater pludselig fejler. Det kan blokere CI/CD, integrationstests og lokal fejlsøgning.

Sådan opdager og reproducerer du problemet (hurtigt)

1. Symptom: HTTP 500 ved kald, hvor server forsøger at kræve/indhente klientcertifikat.
2. Tjek IIS-loggene for 500-fejl og kodenummer. Aktivér Failed Request Tracing (FREB) for detaljer.
3. Se i Event Viewer → System for Schannel-relaterede fejl (Schannel under Source). Disse logs kan indikere TLS-afvisning.
4. Reproducer med et udviklingsmiljø på en maskine med Windows 11 24H2 eller Server 2025. Hvis en identisk opsætning på ældre Windows (eller med TLS 1.2) virker, peger det mod TLS1.3/http.sys-ændring.

Tre praktiske workarounds — rækkefølge efter anbefaling og risikovurdering
Nedenfor får du konkrete muligheder: fra mest anbefalede til mest risikable. Test altid i et ikke-produktionsmiljø først og tag backup af konfiguration/registry.

1. Bedste løsning: Sørg for at klientcertifikatet efterspørges i det indledende TLS-handshake

• Hvorfor: Bevarer TLS1.3 (bedre sikkerhed/ydelse) og fjerner behovet for post-handshake. Dette er den mest sikre og langsigtede løsning.
• Hvordan (konceptuelt): Konfigurer binding/SSL i http.sys / IIS så klientcertifikatet anmodes ved initialt handshake (dvs. på TCP/TLS-bindingen), ikke senere. For servere hvor du selv styrer bindingen (fx native http.sys bindinger), aktiver client certificate negotiation ved bind-time.
• Eksempel på netsh-kommando (som udgangspunkt — erstat IP, port, cert-hash og APPID):
  • Vis bindings:
    netsh http show sslcert
  • Opdater eller tilføj sslcert med clientcertnegotiation:
    netsh http add sslcert ipport=0.0.0.0:443 certhash=THUMBPRINT appid={YOUR-GUID} certstorename=MY clientcertnegotiation=enable
  • Eller opdatér en eksisterende binding (brug show først):
    netsh http update sslcert ipport=0.0.0.0:443 clientcertnegotiation=enable
• Bemærk: Kommandoerne ovenfor kræver admin-rettigheder. Brug show for at få nøjagtige værdier at erstatte. Test straks efter ændring.

Fordele: Bevarer sikkerheden i TLS1.3. Mindre driftspåvirkning.
Ulemper: Kræver kontrol over bindinger; ikke altid muligt i generiske hostingmiljøer eller i visse IIS Express-opsætninger.

2. Midlertidig løsning: Deaktiver TLS 1.3 for serversiden (kun til test/udvikling)

• Hvorfor: Tvinger systemet tilbage til TLS1.2-oppførsel, hvor renegotiation understøttes, og mange workflows fungerer som før.
• Hvordan (eksempel via Registry — KUN i testmiljøer og med backup):
  • Deaktiver server-side TLS1.3:
    reg add “HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.3Server” /v Enabled /t REG_DWORD /d 0 /f
  • Deaktiver client-side TLS1.3 (hvis relevant):
    reg add “HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.3Client” /v Enabled /t REG_DWORD /d 0 /f
  • Genstart serveren eller tjenesten efter ændring.
• Fordele: Hurtigt at rulle ud for at få ting til at virke igen.
• Ulemper: Reducerer sikkerhed/ydelse. Ikke en langtidsholdbar løsning i produktion.

Advarsel: Ændring af Schannel-registre påvirker hele serverens TLS-opførsel. Backup registreringsdatabasen først, og brug kun i kontrollerede miljøer indtil Microsoft laver en officiel rettelse eller du har ændret app/opsætning.

3. Alternativ: Fjern krav om klientcertifikat fra applikationen (kun hvis muligt)

• Hvorfor: Hvis krav om klientcert er unødvendigt i dit miljø (fx kun for udvikling), kan du simpelthen sætte appen til Accept eller Ignore i stedet for Require.
• Hvordan: I IIS SSL Settings sættes “Require SSL” og “Client certificates” til Accept i stedet for Require, eller fjern klientcert-kravet i appens konfiguration.
• Fordele: Meget lav risiko og hurtig.
• Ulemper: Fjerner autentifikation/krav — ikke acceptabelt i produktion eller hvor klientcert er nødvendig for sikkerhed.

Andre praktiske råd og alternativer

• Kør dine klientcert-baserede tests i en separat VM eller container, som kører ældre Windows build eller Linux-baseret webserver, indtil permanent løsning findes. Det er en god midlertidig strategi i CI/CD.
• Overvej at sætte en reverse proxy (fx NGINX eller en Application Gateway) foran IIS, som håndterer TLS-terminering og klientautentifikation, hvis din arkitektur tillader det. En proxy kan give mere fleksibilitet i håndteringen af TLS/sertifikater.
• Hold øje med Microsofts Tech Community/IIS-supportblog og Windows-opdateringer — Microsoft har erkendt problemets omfang og diskuterer løsninger. Meld fejl til Microsoft Support hvis I er påvirket (særligt for servere i produktion).

Checklist til implementering (hurtig opsummering)

• Identificer hvilke applikationer/miljøer, der bruger klientcertifikater.
• Reproducer problemet i dev/test og bekræft Schannel/http.sys-logs.
• Prioriter løsninger: 1) Ændre binding/opsætning så cert efterspørges i initial handshake; 2) Midlertidig deaktivering af TLS1.3 i test; 3) Fjern klientcert-krav i ikke-produktionsmiljøer.
• Test ændringer grundigt. Overvåg efter implementering (FREB, IIS-logs, Event Viewer).
• Planlæg permanent løsning: opdatér opsætning, CI-pipelines og dokumentation.

Konklusion
Microsofts ændring i TLS 1.3-implementeringen prioriterer sikkerhed og ydeevne, men har desværre introduceret kompatibilitetsproblemer for scenarier, der er afhængige af post-handshake klientcertifikatafhentning. For danske udviklere og it-drift betyder det, at I skal gennemgå jeres klientcert-baserede flows, opdatere serverbindinger til at anmode om certifikater i det oprindelige handshake eller midlertidigt justere TLS-versioner i testmiljøer. Den mest robuste løsning er at sikre, at klientcertifikater behandles under initial handshake — det bevarer TLS1.3’s fordele uden at gå på kompromis med sikkerheden. Husk altid at teste i isolerede miljøer, tage backups og følge Microsofts løbende opdateringer.

OFTE STILLEDE SPØRGSMÅL (FAQ)

Q: Hvordan ser jeg hurtigt om mit IIS/IIS Express er påvirket af dette problem?
A: Kig efter HTTP 500-fejl ved klientcert-auth flows, tjek Event Viewer → System for Schannel-relaterede fejl, og lav et testkald fra en maskine med Windows 11 24H2. Aktiver Failed Request Tracing i IIS for at få mere detaljer om hvor i flowet fejlen opstår.

Q: Er det sikkert at deaktivere TLS 1.3 som workaround?
A: Det er en fungerende, men risikabel midlertidig løsning. Deaktivering af TLS 1.3 reducerer sikkerhed og potentielt ydeevne. Brug kun i testmiljøer eller som kortvarig nødløsning, og sørg for at rulle indstillingen tilbage, når en bedre løsning er implementeret.

Q: Skal jeg ændre produktionsservere nu, eller holder jeg mig til monitors og tests?
A: Start med at identificere om nogen produktionstjenester reelt er påvirket (logs, brugerklager). Hvis produktionen er påvirket og krav om klientcert ikke kan ændres hurtigt, kan en målrettet konfiguration af bindinger (request client cert ved handshake) eller en kontrolleret midlertidig deaktivering af TLS1.3 være nødvendigt. Prioriter sikkerhed og test alle ændringer grundigt — helst i staging før produktion.

Original kilde, samt kredit for billedmateriale