SSL/TLS Certificates and HTTPS Binding

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols that secure network communications. SSL 2.0 and 3.0 are deprecated and broken (POODLE, BEAST attacks). TLS is the modern successor: TLS 1.0 (1999), TLS 1.1, TLS 1.2 (2008, still widely used), TLS 1.3 (2018, fastest and most secure — 1-RTT handshake, forward secrecy always on, removed weak ciphers). The term "SSL" is colloquially used for both protocols even when TLS is meant — "SSL certificate" is technically a TLS certificate. For IIS in production: TLS 1.2 minimum is mandatory; TLS 1.3 should be enabled on Windows Server 2022+. Disable SSL 3.0, TLS 1.0, and TLS 1.1 via Windows registry or Group Policy.

An SSL/TLS certificate is a digital document in X.509 format that binds a public key to an identity (domain name or organisation). Key fields: Subject (CN = Common Name = the primary hostname the cert is for), Subject Alternative Names (SANs — additional hostnames the cert is valid for, listed in the extensions), Issuer (the CA that signed the cert), Valid From / Valid To (validity period), Public Key (asymmetric key used in the TLS handshake), Signature (CA's signature proving the cert wasn't tampered with), Key Usage (how the key may be used — Digital Signature for RSA cert). In production: always verify the SAN field covers your hostname — browsers check SANs, not just the CN. Newer certificates only rely on SANs; CN is present but not used for hostname matching in modern browsers.

IIS uses the Windows Certificate Store, specifically the Local Computer (LocalMachine) Personal store, also called LocalMachine\My in PowerShell. Certs here are accessible to all users and services on the machine, including IIS worker processes. You can view this store in: MMC → Add Snap-in → Certificates → Computer Account → Local Computer → Personal → Certificates. Or in PowerShell: Get-ChildItem Cert:\LocalMachine\My. Certificates must be imported with their private key to the Personal store before IIS can use them for HTTPS. Certificates in other stores (Trusted Root, Intermediate CA) are part of the trust chain but are not used directly for SSL bindings — only Personal store certificates can be selected in IIS site bindings.

A certificate thumbprint is the SHA-1 hash of the certificate's DER (binary) encoded form, presented as a 40-character hexadecimal string. It is a unique identifier for a specific certificate instance. IIS uses thumbprints in two places: applicationHost.config stores the thumbprint in the site's HTTPS binding configuration. HTTP.sys SSL certificate binding (created via netsh http) uses the thumbprint as certhash to identify which certificate to load for TLS handshakes for a specific IP:port or hostname:port. When you replace a certificate (e.g., renewal), the new certificate has a new thumbprint even if the domain name and key are the same — both the IIS binding and the netsh binding must be updated to reference the new thumbprint.

SNI (Server Name Indication) is a TLS extension that allows the client to send the desired server hostname during the TLS ClientHello, before the server has sent the certificate. This allows HTTP.sys to know which site's certificate to present for the TLS handshake, even though multiple sites share the same IP address. Without SNI: the server has to commit to one certificate per IP:port combination before reading the HTTP Host header. With SNI: the server reads the SNI extension (client declares "I want shop.example.com") and selects the matching certificate from its store. IIS 8.0 introduced SNI support. In IIS Manager, SNI bindings appear with "Require SNI" checked; in netsh they use hostnameport syntax instead of ipport. All modern browsers support SNI.

SCHANNEL (Secure Channel) is the Windows security package that implements TLS/SSL protocols. HTTP.sys delegates all TLS handshaking to SCHANNEL — HTTP.sys calls SCHANNEL APIs to negotiate the TLS session, not its own code. SCHANNEL is configured via the Windows registry under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL. There you can enable/disable specific TLS protocol versions (Protocols\TLS 1.2\Server\Enabled) and cipher suites. Changes to SCHANNEL affect ALL applications using Windows TLS — not just IIS. Tools: IIS Crypto (free) provides a GUI for SCHANNEL settings with pre-built templates for PCI compliance, FIPS compliance, and best practices. Always test SCHANNEL changes on a non-production server — disabling the wrong cipher can break all HTTPS connections platform-wide.

HSTS (HTTP Strict Transport Security) is an HTTP response header that instructs browsers to always use HTTPS for requests to a domain, even if the user types HTTP or clicks an HTTP link. The browser stores the HSTS policy and automatically upgrades HTTP requests to HTTPS without making an HTTP request first (preventing SSL stripping attacks). Configure in IIS: add the header in web.config: <customHeaders><add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" /></customHeaders>. Flags: max-age (seconds the policy is stored — typically 1 year = 31536000), includeSubDomains (also applies to all subdomains), preload (allows submission to browser preload lists — permanent HTTPS enforcement even before any connection). Warning: do not set HSTS until you are certain the site will always be HTTPS and all subdomains have valid certs — reversing HSTS is nearly impossible for the max-age period.

TLS certificate chain validation is the process by which a browser verifies the server certificate is signed by a trusted CA. The chain goes: Server Cert → signed by → Intermediate CA → signed by → Root CA (in browser trust store). The server must send the full chain (server cert + all intermediates) in the TLS ServerCertificate message. If the intermediate CA certificate is missing: browsers cannot complete chain validation and display "ERR_CERT_AUTHORITY_INVALID" or "Certificate chain incomplete." On IIS: after importing a PFX, verify the chain exists in the store — the intermediate CA cert should appear in the LocalMachine\Intermediate Certification Authorities store. If missing: download the intermediate cert from the CA's AIA (Authority Information Access) URL embedded in the server cert, install it to the Intermediate CA store. Test chain: certutil -verify C:\certs\mysite.cer or use the SSL Labs Server Test.

Two methods: (1) IIS HTTP Redirect module: Site → HTTP Redirect (in IIS Manager) → enable "Redirect requests to this destination: https://$(SERVER_NAME)$(REQUEST_URI)" — however this requires careful configuration to avoid redirect loops for secure sites and doesn't pass the path properly by default. (2) URL Rewrite (preferred): requires URL Rewrite module installed. Add rule in web.config: <rules><rule name="HTTP to HTTPS" enabled="true" stopProcessing="true"><match url="(.*)" /><conditions><add input="{HTTPS}" pattern="off" ignoreCase="true" /></conditions><action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" /></rule></rules>. The condition checks if the incoming connection is NOT HTTPS; if so, redirects with 301 Permanent. Combine with HSTS header to prevent the initial HTTP connection in future visits.

SHA-1 and SHA-256 refer to the hashing algorithm used to sign the certificate. SHA-1 was deprecated by all major browsers and CAs from 2017 onwards because theoretical collision attacks were demonstrated. Any SHA-1 signed certificate is rejected by modern browsers with a security error regardless of validity. SHA-256 (part of the SHA-2 family) is the current standard — certificates should be issued with SHA-256 or SHA-384 signature. Key ID fingerprints in newer certificates use SHA-256. For IIS deployments: always ensure the certificate was issued with SHA-256 signature. The chain (intermediate CA cert) must also be SHA-256 — a SHA-256 server cert with a SHA-1 intermediate CA may still cause browser warnings. Use SSL Labs full chain test to verify all chain certificates use SHA-256.

Systematic check: 1. netsh http show sslcert hostnameport=mysite.example.com:443 — verify certhash matches the thumbprint of the new certificate. If it shows the old (expired) thumbprint: IIS Manager may have updated applicationHost.config but netsh binding was not re-created. Manually delete and re-add. 2. Get-ChildItem Cert:\LocalMachine\My | Where {$_.Thumbprint -eq "newthumb"} | Select NotAfter, Subject — confirm the new cert is actually present in the store and has a valid future expiry. 3. Check the certificate chain: is the intermediate CA cert present in LocalMachine\Intermediate? Missing intermediate = chain error. 4. Check SAN: does the cert's Subject Alternative Names include the hostname the user is accessing? A wildcard cert for *.example.com does NOT cover the root example.com. 5. Check the hostname in the browser matches what the cert was issued for — a common issue when a site moves to a new domain.

This is an SNI misconfiguration or binding conflict. Causes: 1. The site's HTTPS binding does not have SNI enabled (Require SNI unchecked). HTTP.sys falls back to the default IP:port binding (*:443 or 0.0.0.0:443) which serves a different certificate. Fix: edit the binding → check "Require Server Name Indication" → select the correct certificate. 2. Two sites have an HTTPS binding for the same hostname:port but different certs — HTTP.sys uses the first one in its internal table. Fix: remove the duplicate binding from the incorrect site. 3. The netsh SSL cert binding for this hostname:port has the wrong certificate thumbprint — points to a different cert. Fix: delete and re-add with the correct thumbprint. 4. Intermediate SSL termination (load balancer, WAF, CDN) is serving a cached/outdated certificate. Test directly on the server (curl -v --resolve "mysite:443:127.0.0.1" https://mysite) to bypass the intermediary and confirm what IIS actually sends.

This is a compatibility vs security conflict. Assessment: identify which clients are failing (check IIS logs for SCHANNEL handshake errors matching client IPs, or enable SCHANNEL event logging under Event Viewer). Common old clients requiring TLS 1.0: IE on Windows XP, old Java applications (.NET clients below 4.5 default to TLS 1.0), embedded devices, old banking middleware. Options: 1. If the old clients are internal enterprise machines: enforce OS/browser upgrades. Windows XP is EOL — this is also a serious security risk beyond TLS. 2. If external users on old browsers: document the impact, set a deprecation timeline, notify users. 3. If it's a critical business integration: enable TLS 1.1 as a temporary bridge (better than TLS 1.0, still not PCI compliant). 4. Deploy a separate IIS endpoint with TLS 1.0 enabled only for the specific integration, while keeping TLS 1.2+ on public endpoints. Never re-enable TLS 1.0 globally — isolate the exception.

Automate with win-acme (WACS — Windows ACME Simple): (1) Install WACS from https://www.win-acme.com. (2) Run wacs.exe — it detects IIS sites and prompts for domain selection. (3) It issues a Let's Encrypt certificate (or integrates with your CA via ACME protocol), installs it to the Windows certificate store, creates/updates IIS bindings, and creates the netsh SSL cert binding. (4) WACS creates a Windows Scheduled Task that runs every 60 days to auto-renew. For enterprise internal CAs (Active Directory Certificate Services): use the CertEnroll API or PowerShell ADCS module to automate CSR generation, submission to internal CA, and certificate installation. Add a monitoring script: daily check of all certs in LocalMachine\My, alert 30 days before expiry via email/Teams webhook. Track all certificates in a CMDB with owner, renewal date, and responsible team — incident-free cert management requires both automation and visibility.

Central Certificate Store (CCS) is an IIS 8+ feature that reads certificates from a UNC file share instead of the local Windows certificate store. Setup: 1. Create a file share on a highly available server (\\certstore\certs). Grant the UNC share Read access to all IIS server computer accounts. 2. Name certificates using the hostname they are for: www.example.com.pfx (IIS reads the filename to match the hostname). 3. In IIS Manager on each server → Central Certificate Store → Enable → set the UNC path, account for reading the share, and the certificate file password. 4. When creating site bindings: select "Use Centralized SSL Certificate Store" instead of selecting a cert directly. IIS automatically reads the correct .pfx file from the share based on the binding hostname. Benefit: renewing a certificate requires only uploading the new .pfx to the file share — all IIS servers in the farm immediately use the new certificate without any per-server changes. Critical: the file share must be highly available — all HTTPS connections fail if IIS cannot access the CCS share.