As far as I can tell, there is no way in IIS to force a client certificate during the initial TLS handshake
this statement is incorrect. In IIS, under Web Site -> SSL Settings ->
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
After setting up a Windows Server 2022, IIS's Client Certificate Authentication doesn't work with Edge. It does work properly with Firefox, after turning on the "post-authentication handshake".
As far as I can tell, there is no way in IIS to force a client certificate during the initial TLS handshake. Usually this makes sense, since the configuration can be specified on a directory (and/or hostname) basis, so whether authentication is needed at all is only known at the time of the HTTP request itself. However, TLS 1.3 by default can't perform authentication after the initial handshake; this is only possible if the client (i.e. browser) indicates it supports post-handshake authentication.
And indeed: after enabling post-handshake authentication in Firefox, client certificate authentication succeeded. However, Edge does not seem to support the post-handshake authentication at all.
As a result, client certificate authentication doesn't seem to work at all on Windows Server 2022. Even if the browser falls back to TLS 1.2, the same problem seems to exist.
Is there any way to get client certificate authentication working properly in Windows Server 2022 (without disabling TLS 1.3)? How is this functionality supposed to still function, with these limitations?
Thanks in advance!
As far as I can tell, there is no way in IIS to force a client certificate during the initial TLS handshake
this statement is incorrect. In IIS, under Web Site -> SSL Settings ->
this statement is incorrect. In IIS, under Web Site -> SSL Settings ->
Thanks for your answer!
This is how I have it configured. I've done this on the website and on each of the individual directories under the wwwroot (e.g. "/css/"), since client authentication during the handshake is theoretically impossible if the subdirectories won't require authentication (as the request itself would determine whether authentication is necessary).
However, even when the website and all its directories require authentication, IIS still doesn't seem to prompt for the client certificate during the handshake.
Am I missing something - or misconfiguring something - that could somehow intervene with authentication during the handshake?
couple of things:
1) if you configure SSL Settings on site level, it is propagated down to all nested levels (applications, virtual folders, files, etc.). There is no need to configure SSL settings on individual level unless you want to target only them.
2) Microsoft Edge don't prompt for certificate if only one suitable certificate is found. Edge prompts only when multiple matching certificates found. Exact behavior is configured in Control Panel\Internet Options -> Security -> Internet Zone
Thanks again for your answer!
I've verified that Edge doesn't send the CertificateRequest through Wireshark, so this is not a matter of Edge not prompting for a certificate. Also, this is confirmed by Firefox starting to work after enabling post handshake authentication. With Firefox I've confirmed (also through Wireshark) that a CertificateRequest is sent, but after the handshake.
So by the looks of it, even the configuration you're proposing uses a post-handshake authentication.
Regarding point 1: we did have differences configured per-directory before, but those are changed to be consistent for this question.
One thing to try -- assign that web site to Local Intranet/Trusted Sites zone in Internet Options control panel applet.