3

After upgradeing to Windows 11, a local ASP.Net application is no longer prompting me for my CAC and so I cannot access the site via https. I can access it fine via http. I did some looking around and my bindings were set to a cert with the friendly name 'IIS Express Development Certificate' but when I looked for that in my certificate store, or 'localhost' which it is issued by I believe, it doesn't show up. So I went ahead and created a new self-signed cert via powershell:

New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -DnsName "localhost" -FriendlyName "IIS Dev Express Take 2" -NotAfter (Get-Date).AddYears(10)

I copied this to my trusted root certificate authorities and intermediate authorities folders in my certficicate store and selected this new certificate in my bindings, but still have the same issue. At this point I'm not sure what else I can try to resolve this issue.

Just to add a bit more since I've been working on this for a few days now:

I've tried removing and adding back server certificates a number of times, copying them from my personal store to trusted store and intermediate store, etc. I've tried copying a coworker's applicationhost.config file, or at least the parts specific to authentication that were different from mine. I've tried running the site directly from Visual Studio rather than stand-alone in IIS. I even tried removing and re-adding IIS Express, which regenerated the IIS Express Development Certificate that was the one installed originally. It doesn't seem to matter what I do. The application has the following:

 _cert = Context.Request.ClientCertificate;
                        if (_cert.IsPresent)
                        {
                            transferCACLoginToConsent = ProcessCAC();
                        }

But it never gets to the innercode because Context.Request.ClientCertificate always evaluates to false as I'm stepping through this, and without prompting the user for a CAC/client certificate.

Levi Wallach
  • 369
  • 5
  • 17
  • The prompt only happens when Windows/browser find valid **client certificates** and would like you to choose from. That has nothing to do with **server certificates** such as the IIS Express one. Thus, to troubleshoot properly, make sure you fully understand the concepts of certificates and how mutual SSL/TLS works internally. – Lex Li Feb 11 '22 at 19:43
  • Ok, but I'm being prompted by other applications/sites hosted elsewhere for my CAC, just as I was before my Win 11 upgrade, it's only my local IIS application instance that suddenly is not prompting for my CAC after the Win 11 update. – Levi Wallach Feb 12 '22 at 03:01
  • It is difficult to reproduce your problem, I suggest you open a case via: https://support.microsoft.com. – samwu Feb 15 '22 at 09:39
  • I have the same problem. Same certificates works fine on windows 10, while not prompting on windows 11. Initially I thought it might be configuration issue, but re-verified all settings. IIS installed components and re-install all certs. – Kamran Asim Mar 08 '22 at 17:27

2 Answers2

2

For me it worked when I checked "Disable TLS 1.3 over TCP" in the Edit bindings.

IIS edit binding window

Marko Jankovic
  • 38
  • 3
1

I too have now run into this issue, also after upgrading to Windows 11. I don't fully understand the problem yet, but believe I can offer you a substantial work around. The issue is tied up with TLS, and the defaults used by Windows - TLS 1.2 for Windows 10 and TLS 1.3 for Windows 11. I was able to restore my local site's CAC authentication/authorization by modifying the Registry to force TLS 1.2. (Obviously a long term or permanent solution will entail allowing TLS 1.3 to work; I intend to continue work on that front.)

Specifically, under the existing Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\ key, add (as necessary) TLS 1.2 and TLS 1.3 keys, and then under those two new keys add a Server key for each of them. In the new Server keys, add a DWORD with the name Enabled, and set it to 1 for the TLS 1.2 path, and leave it as 0 (the default) for the TLS 1.3 path.

This site will walk you through those edits: https://thesecmaster.com/how-to-enable-tls-1-2-and-tls-1-3-on-windows-server/. It has you also creating Client keys and DisabledByDefault DWORDs, but I didn't find those necessary.

Since this solution does entail edits to you system registry, it would be prudent to export its state beforehand for revertability. I exported my 'before' \Protocols branch.

Chris Anderson
  • 21
  • 2