0

I'm trying to get IIS 8.5 on windows Server 2012 R2 to actually use the central certificate store, but i can't figure it out.

I have two instances of IIS setup using shared configuration and NLB, these will be acting as frontend reverse proxies (this works). I want to add SSL termination to them though, this is where I'm having issues.

I've setup a Central Certificate Store. I've tried wildcard and specific certs for domains. I've tried adding explicit bindings for certs. I've tried editing the bindings in the applicathost.config to not have a specific domain (from google searches).

Without a default SSL site, IIS sends a connection RST (inspected via wireshark). With a default SSL site, IIS resigns everything using whatever that certificate is, it doesn't bother with the SNI part, or look at the central certificate store.

Is there anyway to debug IIS as to what decisions it is making?. I see the certificates loaded in the central certificate store, but they are never being used.

Here is the results of netsh http show sslcert

IP:port                      : 0.0.0.0:443
Certificate Hash             : 223ee4d18cd634a3227a492de0f50665120a3554
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
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

IP:port                      : 0.0.0.0:8172
Certificate Hash             : 223ee4d18cd634a3227a492de0f50665120a3554
Application ID               : {00000000-0000-0000-0000-000000000000}
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

Central Certificate Store    : 443
Certificate Hash             : (null)
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name       : (null)
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

What's baffling is the first binding has a hostname, but other hosts get signed with that cert, that's never going to work because the CN/FQDN will always be wrong, so I have no idea why IIS is doing this.

1 Answer 1

0

If I go by this blog here, it details how HTTP.sys does the decision making. Specifically, the "How CCS works" section describes that the IP:Port binding takes precedence.

So, to address the why the management certificate is being displayed even though the binding has a hostname: This is because your default binding is not using SNI. When SNI is not used, the decision to choose the certificate that will be sent to the client will be done via the TCP/IP layer's IP and Port. If the handshake is successful, then the HTTP Host header should be read to determine which website binding the request belongs to.

The blog also suggests that CCS works based on filenames. E.g.: hostname generating a filename like hostname.pfx. Having said that, I would recommend to remove that default binding and running Process Monitor. This will give you an idea if HTTP.sys is probing the CCS store location for a specific filename. If so, you can then rename the pfx file accordingly, adjust permissions if it's a permission issue or correct any password specified for the pfx files or to access the store location itself.

1
  • Thank you for noting the default binding, i have been 24 hrs trying this and after disabling the default site all ssl started to work. Thank you Nov 28, 2023 at 18:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .