TLS/HTTPS: Bindings, SNI & the Centralized Certificate Store

Web Servers Fundamentals Chapter 7 covered TLS termination generically across all three servers — certificates, chain of trust, the handshake itself. What it didn't cover is that IIS's actual certificate model is genuinely different from Apache's and Nginx's: neither a loose .pem file nor a plaintext private key sitting in a config directory, but an entry in the Windows Certificate Store, referenced by a binding rather than a file path.

The Windows Certificate Store, Not a File Path

Apache's SSLCertificateFile/SSLCertificateKeyFile and Nginx's ssl_certificate/ssl_certificate_key both point directly at files on disk. IIS instead expects a certificate to already be installed into the Windows Certificate Store — typically the Local Computer's Personal store (certlm.msc, or the Cert:\LocalMachine\My PowerShell path) — after which it's identified purely by its thumbprint, a SHA-1 hash uniquely fingerprinting that specific certificate:

An HTTPS binding then references that thumbprint rather than a file path — the private key never sits in a plaintext file anywhere IIS's own configuration touches, since the Windows Certificate Store manages the key material itself, with its own export/access permissions independent of web.config or applicationHost.config entirely.

HTTPS Bindings and SNI

Server Name Indication (SNI) is what makes it possible to bind several different certificates to the same IP address and port 443, each for a different hostname — the client's browser sends the requested hostname in cleartext as part of the TLS handshake itself, before encryption is established, letting IIS pick the matching certificate before the rest of the handshake proceeds. This exact mechanism is what allows dozens of HTTPS sites to share one IP address, the same underlying idea Web Servers Fundamentals Chapter 7 covered generically for name-based HTTPS virtual hosting. Before SNI support (IIS 8 and earlier lacked it entirely), each distinct certificate genuinely needed its own dedicated IP address, since the server had no way to know which hostname was being requested until after the handshake had already committed to one certificate.

The binding dialog's "Require Server Name Indication" checkbox is a real, consequential choice, not a formality: enabling it means very old clients that predate SNI support (legacy libraries, some old embedded devices) simply cannot connect at all, since they never send a hostname during the handshake for IIS to match against. Leaving it unchecked keeps a single "default" certificate for connections that don't specify SNI, at the cost of not being able to host multiple independent certificates cleanly on that same IP/port combination.

The Centralized Certificate Store (CCS): A Different Feature Entirely

It's easy to conflate this with the Windows Certificate Store just covered, because the name is so similar — but IIS's Centralized Certificate Store (CCS) is a genuinely separate, optional feature, aimed specifically at large-scale multi-tenant hosting with many sites and certificates. Instead of installing every certificate individually into the Windows Certificate Store and configuring a binding referencing its thumbprint, CCS stores certificates as .pfx files in one shared folder (often a UNC network path, shared across a web farm), named by convention after the hostname they belong to:

IIS looks up the correct .pfx file dynamically at handshake time, based on the SNI hostname, rather than requiring a pre-configured binding entry per certificate — genuinely useful in a hosting environment adding and removing tenant certificates constantly, where manually managing individual store entries and bindings for each one doesn't scale.

Hands-On Exercises