Score:1

IIS serves wrong cert using SNI or CCS

bd flag

I have 3 websites all using the same IP in IIS 10. I first setup the https bindings to use SNI with 'all assigned' IP addresses on port 443 using the correct certificate. All the certs are known good. Only one website gets served the correct SSL cert. The other two get served the same cert as the working site. So then I switched to CCS. Loaded all my certs in the same folder with the correct names. Changed the sites from SNI to CCS. Still only the one site works. Tried cleaning the client cache. By the way this all worked fine for months until this past weekend and I made no changes to the server. May have gotten a Windows 2019 update Any suggestions on what I can do next? Here are the netsh results The site that works has a wildcard cert from Sectigo. The other two are from Let's Encrypt. The domain names on all three are different.

IP:port                      : 0.0.0.0:8172
Certificate Hash             : d97778af0d232c0c2494eee481df37e5127425c9
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
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
Disable Legacy TLS Versions  : Not Set

IP:port                      : 192.168.20.34:443
Certificate Hash             : 211a5fb41e576e85c023f68452d77a91fc13b1eb
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
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
Disable Legacy TLS Versions  : Not Set

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
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
Disable Legacy TLS Versions  : Not Set
Lex Li avatar
vn flag
Did you verify your Windows HTTP API settings via `netsh`?
dcol avatar
bd flag
Yes they all look good using 'netsh http show sslcert'
Lex Li avatar
vn flag
Then what if you modify `hosts` file on that server (to emulate the three domains locally) and test the three sites with a browser on the server itself? Does that give the same error?
dcol avatar
bd flag
Tried that. So what I did was move those sites to a new IP on the same server. Now they work. I cannot use the same IP for all three sites even with SNI or CCS
Michael Hampton avatar
cz flag
That defeats the whole purpose of SNI, which was to allow multiple HTTPS sites to use the same IP. There is still a problem here. I'm a Linux admin though, so I can't tell you what exactly it is. Someone ought to be able to do so, though.
Lex Li avatar
vn flag
@dcol "Tried that" so what's the result? Anyway, since changing an IP address in bindings resolves the issue, I guess you have something wrong on DNS settings. But how that issue happened is still unknown. If I were you, I should have captured TLS handshake packets and analyzed further to learn the cause (the handshake packets contain enough information on how SNI/CCS should respond). But now you at least found a solution.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.