Uitschakelen TLS 1.3 binnen IIS op specifieke site

[wildhagen]

Wij hebben hier een server (Windows 2022) met (o.a.) een IIS server. Deze host meerdere (circa 15) websites.

Deze server werkt op zich prima, maar één van de websites blijkt niet te werken met TLS 1.3, de applicatie geeft dan een HTTP 403.7 "Forbidden: Client certificate required". Ook al geef je een (valide) client certificate mee, dan nog werkt het niet.

Zet je op de https binding met de hand het vinkje voor "Disable TLS 1.3" zonder verder iets anders aan te passen (anders dan een recycle van de app pool), dan werkt het meteen wél goed.

Deze website werkte eerder wel goed, op een Windows 2016 Server (die zijn we aan het migreren ivm komende end-of-life voor 2016), maar die kende uiteraard nog geen TLS 1.3

Nu kunnen we natuurliijk dat vinkje gewoon aan laten, maar het probleem is dat alle websites periodiek opnieuw opgebouwd worden, en dan staat het vinkje dus weer uit. En elke paar dagen dat vinkje handmatig gaan zetten is natuurlijk ook niet ideaal.

Nu heb ik dit gevonden:

code:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

Echter, dan schakel je TLS 1.3 op álle websites uit. Dat willen we eigenlijk ook weer niet, want op die ene website na werken de andere websites wel gewoon prima.

Heeft iemand een methode om die die instelling voor één specifieke website aan te zetten? Dit mag een registry-instelling, een powershell statement of voor mijn part een old-fashioned .cmd/.bat zijn. Als we het maar kunnen schedulen met een scheduled task boeit ons dat niet zoveel.

Op Internet kan ik hier helaas vrij weinig over vinden...

[Question Mark]

Deze al gezien (resolution 2)?

Client certificate authentication may be enabled where it is not required. If you intended only to require Transport Layer Security (TLS)/SSL communications, then you need only a server certificate. You can disable client certificate authentication by using the resolution in

https://support.microsoft.com/help/942067

[wildhagen]

Question Mark schreef op dinsdag 2 juni 2026 @ 16:26:
Deze al gezien (resolution 2)?


[...]

https://support.microsoft.com/help/942067

Tnx, die had ik idd gevonden, maar die optie staat al op Ignore:



Die resolution gaat ervan uit dat hij op Required staat (door hem dan op Accept te zetten) maar dat lijkt hier helaas niet van toepassing.

[Question Mark]

wildhagen schreef op dinsdag 2 juni 2026 @ 16:32:
[...]
Die resolution gaat ervan uit dat hij op Required staat (door hem dan op Accept te zetten) maar dat lijkt hier helaas niet van toepassing.

Nee toch, je moet hem juist op "accept" zetten...

On the SSL Settings page, select the Accept option under Client certificates.

Het klinkt idd. onlogisch, maar goed. De officiele oplossing is naar "accept", terwijl "ignore" logischer is. (ik roep dit overigens compleet ongetest, maar heb wel vaker rare dingen in MS docu gezien).

[ Voor 20% gewijzigd door Question Mark op 02-06-2026 16:37 ]

[Dennism]

Misschien met netsh http de specifieke binding aanpassen? Zie bijv. https://learn.microsoft.c...ndows-commands/netsh-http (even zoeken op tls)

Anders misschien met een registry tracker / process explorer achtige tool proberen te achterhalen waar de aanpassing wordt weggeschreven wanneer je het vinkje in de UI zet.

[Drardollan]

wildhagen schreef op dinsdag 2 juni 2026 @ 16:22:
Nu kunnen we natuurliijk dat vinkje gewoon aan laten, maar het probleem is dat alle websites periodiek opnieuw opgebouwd worden, en dan staat het vinkje dus weer uit. En elke paar dagen dat vinkje handmatig gaan zetten is natuurlijk ook niet ideaal.

Waarom moet je de configuratie binnen IIS dan ook opnieuw opbouwen? Je kan toch gewoon naar een bestaande website deployen? Dan heb je niks te maken met de instellingen verder, die zet je eenmalig goed.

[Drardollan]

Question Mark schreef op dinsdag 2 juni 2026 @ 16:35:
[...]

Nee toch, je moet hem juist op "accept" zetten...


[...]


Het klinkt idd. onlogisch, maar goed. De officiele oplossing is naar "accept", terwijl "ignore" logischer is. (ik roep dit overigens compleet ongetest, maar heb wel vaker rare dingen in MS docu gezien).

Volgens mij lees je dat verkeerd, je moet hem op Accept zetten als Require niet goed gaat. Maar Ignore zou ook gewoon moeten werken. Of lees ik het dan fout?

[Drardollan]

Weet je zeker dat er niets in de web.config zit qua instelling die een client certificaat vereist cq. instellingen aanpast? Ervaring leert dat niet alle opties die je daar in zit goed worden weergegeven in GUI (bijvoorbeeld bij IP restricties de Proxy mode).

Het aanpassen middels scripting lijkt mij een weg die je niet moet willen volgen, zal je altijd zien dat het script pas uren na een wijziging draait. Of je moet elke minuut gaan checken. Dan zou ik er nog eerder voor kiezen om een 2e server neer te zetten puur voor deze site zodat je heel TLS1.3 kan uitschakelen. Al heb ik ook het gevoel dat de applicatie gewoon niet goed werkt, ik heb zulk gedrag nog nooit gezien en dit lijkt mij ook niet normaal voor een applicatie/website om dit te vragen als het niet expliciet aanstaat.

Het klinkt in ieder geval niet logisch om TLS1.3, wat de toekomst heeft en aan te bevelen is om te gebruiken, uit te schakelen om deze redenen. Elke applicatie zou daar zonder problemen mee moeten kunnen werken, het is qua techniek niet anders dan TLS1.0, 1.1 of 1.2.

[ Voor 72% gewijzigd door Drardollan op 02-06-2026 17:10 ]

[wildhagen]

Allen dank voor het meedenken. Ik ben nu uitgewerkt, maar ga er morgen eens verder in duiken. Mocht ik nog verdere opmerkingen hebben dan laat ik het weten.

Als een van jullie suggesties de Heilige Graal was laat ik het uiteraard ook weten!

Drardollan schreef op dinsdag 2 juni 2026 @ 16:57:
[...]

Waarom moet je de configuratie binnen IIS dan ook opnieuw opbouwen? Je kan toch gewoon naar een bestaande website deployen? Dan heb je niks te maken met de instellingen verder, die zet je eenmalig goed.

Even hier concreet op inhaken: hier hebben we helaas geen invloed op. Dit is hoe de (extern ontwikkelde) applicatie is opgebouwd. DIe bouwt periodeek, en sowieso na elke update, alles compleet opnieuw op includief config files, webservices, windows services en registry instellingen. En daarna nog wat rechten op het filesysteem en op de private key van wat certificaten in de My-store van de server.

Op zich werkt het, los van dat vinkje, allemaal prima. Het draait al sinds Windows Server 2008 zo (dit is al de 2e migratie: Win2008 -> Win2016 -> Win2022) die deze applicatie mee maakt. De applicatie is zo oud dat hij volgens mij nog met TLS 1.1. of 1.2 werkt oid, en dat was tot nu toe geen probleem, omdat TLS 1.3 pas met Win2022 geintroduceerd is lopen we er nu pas tegenaan.

(En nee: geen Windows 2025, daar zijn we inmiddels redelijk hard van genezen, wat een wanprodukt qua (in)stabiliteit, incompatibiliteit en non-performance, wij rollen nu alles uit naar 2022, eerst 2016 -> 2022, later doen we nog de 2019->2022 migraties).

[ Voor 7% gewijzigd door wildhagen op 02-06-2026 17:45 ]

[Kaalus]

Recent nog wat gewerkt met IIS en volgens mij worden de website specifieke instellingen het bestand web.config opgeslagen in XML formaat.
Ik zou die er eens naast houden en zowel voor als na het omzetten van het TLS 1.3 vinkje bekijken. Grote kans dat er een waarde in dat bestand weggeschreven wordt.

Zodra je die gevonden hebt kun je met een paar regels PowerShell die specifieke variabele wel weer goed zetten na een deploy van de applicatie. Eventueel in taakplanner hangen en dan zou je er geen omkijken meer naar moeten hebben.

[Drardollan]

Kaalus schreef op dinsdag 2 juni 2026 @ 19:59:
Recent nog wat gewerkt met IIS en volgens mij worden de website specifieke instellingen het bestand web.config opgeslagen in XML formaat.
Ik zou die er eens naast houden en zowel voor als na het omzetten van het TLS 1.3 vinkje bekijken. Grote kans dat er een waarde in dat bestand weggeschreven wordt.

Zodra je die gevonden hebt kun je met een paar regels PowerShell die specifieke variabele wel weer goed zetten na een deploy van de applicatie. Eventueel in taakplanner hangen en dan zou je er geen omkijken meer naar moeten hebben.

Zover ik weet zit deze instelling niet in de web.config.

[wildhagen]

Dennism schreef op dinsdag 2 juni 2026 @ 16:53:
Misschien met netsh http de specifieke binding aanpassen? Zie bijv. https://learn.microsoft.c...ndows-commands/netsh-http (even zoeken op tls)

Jij wint de wasmachine!

Heb dit commando gedraaid:



En die doet het:



Hij zet hem dus idd uit. Aparte is wel dat ik dat in de GUI niet terug zie, daar staat het vinkje nog "gewoon" uit. Maar het werkt wel....

Ideaal is het allemaal niet, en eigenlijk wil je TLS 1.3 ook niet uitschakelen zoals @Drardollan al terecht opmerkt, maar deze applicatie kan er echt niet mee overweg.

Er wordt wel gewerkt aan een andere oplossing zodat deze constructie niet meer nodig is, maar ik heb er (gezien de ervaringen met deze leverancier) geen vertrouwen in dat dit voor januari 2027 (de end-of-life date van Windows 2016) helemaal operationeel gaat zijn. Dan is dit het minste van twee kwaden.

Iedereen bedankt voor het meedenken!

[Kaalus]

Mooi dat je een oplossing gevonden hebt!

Mocht je het nog op een andere manier aan willen pakken dan kun je ook het bestand C:\Windows\System32\inetsrv\Config\applicationHost.config bewerken.
Zoek daar de naam van je site op en pas onder bindings de SSL opties aan:

XML:

<bindings>
    <binding protocol="http" bindingInformation="*:80:" />
    <binding protocol="https" bindingInformation="*:443:" sslFlags="32" />
</bindings>

Waar sslFlags="32" de waarde is om TLS1.3 uit te schakelen en "0" de standaardwaarde.
Wanneer je deze optie gebruikt veranderd het vinkje wel mee binnen de IIS console. Deze oplossing is wellicht ook wat makkelijker te scripten omdat je enkel op de site naam hoeft te zoeken.