Certificate based authentication fails if TLS v1.3 enforced on Windows Server 2022

[ahpala]

PROBLEM SUMMARY
The customer requires that VCert must support TLS v1.3 for use cases. In testing the VCert using certificate based (API) authentication we found that unless "Disable TLS 1.3 over TCP" is checked in IIS site binding configuration, the certificate authentication is unsuccessful.

STEPS TO REPRODUCE

1. Create a VCert Playbook to request certificate using certificate authentication.
2. Ensure Windows Host computer is has TLS v1.3 enabled for Windows system configuration.
3. Ensure "Disable TLS 1.3 over TCP" is NOT checked in IIS site binding configuration
   4/. Execute VCert to request the certificate,

EXPECTED RESULTS

VCert should successfully complete the request for certificate and retrieve the newly enrolled certificate.

ACTUAL RESULTS

The following error is reported (IP addresses obfuscated):
wsarecv: An existing connection was forcibly closed by the remote host."}
github.com/Venafi/vcert/v5/pkg/playbook/app/service.ValidateTPPCredentials
/Users/justin.hansen/repos/github/beardedprincess/vcert/pkg/playbook/app/service/tokenService.go:63
main.doRunPlaybook
/Users/justin.hansen/repos/github/beardedprincess/vcert/cmd/vcert/playbook.go:136
github.com/urfave/cli/v2.(*Command).Run
/Users/justin.hansen/go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/command.go:274
github.com/urfave/cli/v2.(*Command).Run
/Users/justin.hansen/go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/command.go:267
github.com/urfave/cli/v2.(*App).RunContext
/Users/justin.hansen/go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/app.go:332
github.com/urfave/cli/v2.(*App).Run
/Users/justin.hansen/go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/app.go:309
main.main
/Users/justin.hansen/repos/github/beardedprincess/vcert/cmd/vcert/main.go:159
runtime.main
/usr/local/go/src/runtime/proc.go:250
2024-09-20T13:59:58.390+0100 ERROR vcert/playbook.go:138 invalid tpp credentials {"error": "Post "https://mdafcven001.prestige.dev/vedauth/authorize/certificate": read tcp 10..xx.xx.xx:57707->10.xx.xx.xx:443: wsarecv: An existing connection was forcibly closed by the remote host."}

ENVIRONMENT DETAILS

Environment detail provided above in "steps to reproduce". This was observed on Venafi TLS Protect Datacenter 24.1 hosted on Windows Server 2022 standard edition.

COMMENTS/WORKAROUNDS

Currently there is no workaround known to ensure TLS v1.3 is used.

[Pmaraveyias]

Took a look at this and can't find anything that would prevent TLS 1.3 from working. Additionally we have users who have successfully tested vcert playbooks with "Disable TLS 1.3 over TCP" not checked. In order to dig a bit deeper into this, would it be possible to run a simple curl GET request from the client server to rule out other (e.g. network/proxy) issues?

If a (redacted) playbook can be provided I can help put together a curl command that matches (as closely as possible) the commands vcert is running.

[ahpala]

Gents,

Please note the following post for a "workaround" that I have currently advised the customer to follow:

https://techcommunity.microsoft.com/t5/iis-support-blog/windows-server-2022-iis-web-site-tls-1-3-does-not-work-with/ba-p/4129738