Browser not prompting for certificate - IIS 10.0

Question

I have an application that was working fine in IIS 8.5 which used this setting in the web.config file for a client certificate login (smartcard) for a path. I had to migrate this application to IIS 10.0 and everything is working except the application does not prompt for the certificate and just simply throws an error in the code that there is no certificate.

I have double checked and triple checked all the settings in IIS, the certificate is the same, the SSL settings are the same. The application is a simple .netcore application and it works perfectly with the exception of the certificate prompt. Is there something that is different in IIS 10 than 8.5 that I could be missing. The portion of the web.config that enables the browser to prompt the certificate I believe is this part here. The developer who did this is not longer with us and I would appreciate any help for this. Is there something that I need to check in IIS other than what I have already checked?

I went through some other posts and made sure that the root and intermediary certificate are in the cert store etc. The app itself loads fine with the SSL certificate.

<location path="SmartCard"> <system.webServer> <security> <access sslFlags="Ssl,SslNegotiateCert" /> </security> </system.webServer> 

Answer 1

All things being equal, it should work the same!

That's the key part though - perhaps not all things are equal above the level of the web.config? (or below - that web.config will apply only to a SmartCard folder which is part of the same HTTP URL path, based on that location tag)

Windows\System32\InetSrv\config\ApplicationHost.config tends to accrue things over time and people make server-level configuration changes they forget.

So, possible options:

• Check that there's a server certificate with private key installed and that the site bindings include HTTPS

  • I know you've mentioned using the site over SSL works - this should prove that

• Dump out the effective settings for the site from working server and compare with dumped settings for nonworking server

  • for bonus points, something like Web Deployment Tool might help with that
  • manual method:
    • APPCMD LIST CONFIG http://site/pathabovesmartcard/ /text:* >working.txt (on working server)
    • APPCMD LIST CONFIG http://site/pathabovesmartcard/ /text:* >NONworking.txt (on... you guessed it, the nonworking server!)
    • and then compare them with a text editor or a judicious eye
    • leave out /text:* if you prefer XML

• Add to that NETSH SHOW SERVICESTATE comparison from each for a quick review of HTTP.SYS queues

That's actually the expurgated version - you can also look at the complete contents of applicationhost.config unfiltered by site (and organized sensibly at first, then linearly with subsequent changes) in Windows\System32\InetSrv\Config, and that might be easier (or way harder).

Answer 2

Wow, this took me DAYS to figure out.

Related question: https://stackoverflow.com/questions/2518314/make-iis-require-ssl-client-certificate-during-initial-handshake

I had an IIS 8.5 website on Windows Server 2012 R2 with client certificate authentication set up:

<system.webServer> <security> <access sslFlags="Ssl, SslNegotiateCert, SslRequireCert" /> </security> </system.webServer> 

(This is "Require client certificates" under SSL Settings in your IIS site)

Note this can be set using appcmd as well:

C:\Windows\system32\inetsrv\appcmd.exe set config 'Default Web Site' -section:system.webServer/security/access /sslFlags:'Ssl, SslNegotiateCert, SslRequireCert' /commit:apphost 

(Change Default Web Site to your site name)

I have this set up for Cloudflare mTLS Authenticated Origin Pull.

I am migrating to IIS 10 on Windows Server Core 2022 and I had everything migrated except for client cert authentication.

For completeness' sake:

1. Imported Cloudflare Root CA to Cert:\LocalMachine\Root store, used to sign the Origin Certificate
2. Imported Cloudflare Pull Root CA to Cert:\LocalMachine\Root store, used to sign (presumably) the client certificate Cloudflare presents during an origin pull TLS handshake
3. Imported Cloudflare Origin Certificate (.pfx) to Cert:\LocalMachine\My and marked as Exportable and granted Read file permissions to the private key for BUILTIN\IIS_IUSRS group.

Besides the read permissions for the private key, I had performed all these steps on my IIS 8.5 configuration awhile ago, so these were the same steps I did for IIS 10. All confirmed with PowerShell.

If I set my HOSTS file to my hostname and my IIS 8.5 origin IP address, I could see that IIS was prompting the browser for a client certificate.

However, it would not show up for my IIS 10 site and I was racking my brain because all the config looked equivalent. I did what TristanK suggested even and compared applicationhost.config files. Both had equivalent configuration.

It wasn't until I came across this blog talking about using netsh and clientcertnegotiation, and how the TLS handshake works for client certificate authentication.

Once I executed this:

netsh http show sslcert 

I saw that for my HTTPS binding Negotiate Client Certificate was Disabled.

SSL Certificate bindings: ------------------------- Hostname:port : myhost.com:443 Certificate Hash : <cert hash> Application ID : {GUID} Certificate Store Name : MY Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled Reject Connections : Disabled Disable HTTP2 : Not Set Disable QUIC : Not Set Disable TLS1.2 : Not Set Disable TLS1.3 : Not Set Disable OCSP Stapling : Not Set Enable Token Binding : Not Set Log Extended Events : Not Set Disable Legacy TLS Versions : Not Set Enable Session Ticket : Not Set 

The WEIRD part was that it was ALSO disabled on my Windows Server 2012 R2 box.

But then I came across Wayne Weeke's answer and he mentions this:

Since the discovery of the MITM attack arround SSL Renegotiation, the answer in alot of circles has been to hangup on renegotitation requests.

And Server Renegotiation was mentioned in another related question from back in 2003.

I don't know for sure what changed between 2012 R2 and 2022, but it's more than a coincidence I think. Perhaps some SCHANNEL registry key got tweaked.

Sure enough, as soon as I updated the https binding and enabled clientcertnegotiation, Cloudflare lit up and my local HOSTS binding was prompting for a certificate on the migrated site.

I was able to update my binding in-place like this:

http update sslcert hostnameport=myhost.com:443 certstorename=MY certhash=hash clientcertnegotiation=enable 

It kept failing until I added certstorename and the certhash specifically, though the command help does not make this clear. Certainly removing and re-adding probably works as mentioned too.

I know this is a lot of information, but I've always found it helpful when someone includes the full context of solving the problem -- perhaps others looking to configure Cloudflare Origin Pull on IIS 10 will find this answer in the future.

Note 1: Initially while diagnosing this I enabled Failed Request Tracing and saw I was getting a 403.7, which means the client certificate was not found. I did not put two and two together and verify that my new 2022 origin was actually prompting for a client cert. If I had, this answer might have made more sense which I found 2 days ago, which mentions using netsh and clientcertnegotiation=enabled.

Note 2: There may be an additional IIS configuration to do a one-to-one or many-to-one IIS client certificate mapping too specifically for Cloudflare mTLS Authenticated Origin Pull, but it works without that. Technically, I think IIS will accept any cert signed by a trusted CA by default (which happens to include Cloudflare since I installed it).