Setting up an SSL certificate on Microsoft IIS looks simple in the wizard, but the details – binding order, SNI configuration, intermediate chains – are exactly where things quietly break weeks or months later. This guide walks through the full process on IIS 8.5 through IIS 10, plus the mistakes that show up again and again in production environments.
A typical scenario: a Windows admin inherits an internal application server running IIS, generates a CSR through the IIS Manager console, gets the certificate issued by an internal CA or public provider, and imports it. The site works in the browser that day. Three months later, a partner integration starts throwing certificate chain errors – because the intermediate certificate was never installed correctly, and Windows happened to cache a valid chain from a different site on the same machine. This kind of delayed failure is common enough on IIS that it deserves its own section below.
Generating the CSR and requesting the certificate
Open IIS Manager, select the server node, and double-click Server Certificates. From the Actions pane, choose Create Certificate Request. Fill in the common name (must match the exact domain, including any subdomain), organization details, and select a bit length – 2048-bit RSA is the practical minimum today; some CAs now default to offering ECC keys as well.
Save the resulting .txt request file and submit it to your certificate authority. Once issued, return to Server Certificates and use Complete Certificate Request, pointing IIS to the returned certificate file. IIS will only accept this file if it was generated from the matching CSR on that same server – a common source of “the certificate request that generated this certificate cannot be found” errors when admins request certificates on one machine and try to install them on another.
Installing the intermediate certificate chain correctly
This is where most IIS setups quietly fail. The public certificate alone is not enough – IIS needs the full chain (intermediate and, in some cases, cross-signed root) to present to connecting clients. If the CA delivers a .p7b or .pfx bundle, IIS usually imports the chain automatically. If you’re handed separate .crt files, the intermediates need to go into the Windows certificate store manually via certlm.msc, under Intermediate Certification Authorities.
A missing intermediate rarely breaks Chrome or Firefox on desktop, because they cache intermediates from other sites and can sometimes build the chain themselves via AIA fetching. It absolutely breaks older mobile browsers, many API clients, curl without additional flags, and payment gateways – which is exactly why this mistake surfaces as “works for me” complaints from a subset of users rather than an obvious outage. Reviewing how to detect and resolve certificate chain issues is worth doing right after installation, not after the first complaint ticket.
Binding the certificate to the site
Under Site Bindings, add or edit an HTTPS binding, select port 443, and choose the certificate from the dropdown. If the server hosts multiple HTTPS sites on the same IP, enable Server Name Indication (SNI) in the binding – without it, IIS can only serve one certificate per IP:port combination, and additional sites will present the wrong certificate or fail the handshake entirely. SNI has been standard on IIS since version 8, but it still gets skipped on servers migrated from older Windows Server versions where it wasn’t available. If you’re unsure whether your binding setup needs it, the mechanics are covered in more depth in this piece on what SNI is and why it matters for SSL configuration.
Restart the site (or run iisreset if bindings don’t take effect immediately) and test from an external client, not just localhost – IIS will happily serve a broken chain to a local browser that already trusts the intermediate from cache.
Common myth: “the padlock means it’s configured correctly”
A green padlock only confirms the browser accepted the certificate presented for that specific connection – nothing more. It doesn’t confirm the chain is complete, that weak cipher suites like TLS 1.0 or RC4 aren’t still enabled in the Windows Schannel configuration, or that every bound hostname on the server is covered. IIS servers are notorious for having legacy protocols still enabled at the OS level, inherited from a Windows Server image that predates any hardening pass. Checking the padlock and closing the ticket is how chain and protocol issues sit undetected until an external audit or a client’s security team flags them.
Verifying the setup properly
After binding, don’t rely on the browser alone. Use an external SSL checker that tests from outside your network, confirms the full chain, and flags any weak protocols or ciphers still active. This step matters more on IIS than on many other platforms because Windows Server’s default TLS/cipher configuration varies by OS version and patch level, and IIS doesn’t always surface that clearly in its own management console. For a structured way to confirm nothing was missed, see this walkthrough on how to verify SSL certificate installation is correct.
It’s also worth disabling SSL 3.0 and TLS 1.0/1.1 via the registry or a tool like IIS Crypto if the server hasn’t been hardened recently – these are frequently still enabled by default on older Server builds and quietly downgrade your effective security posture even with a perfectly valid certificate installed.
Keeping it working after the initial setup
IIS doesn’t renew certificates automatically unless it’s paired with something like win-acme for ACME-based renewal, or an internal CA with autoenrollment configured via Group Practice. Manually issued certificates from a public CA need someone to remember the expiration date, generate a new CSR, and repeat the chain installation – every single renewal cycle repeats the same failure points described above. Ongoing monitoring that checks expiration, chain validity, and protocol configuration on a schedule catches the drift that a one-time setup review can’t.
Frequently asked questions
Why does my IIS site show a certificate error on some devices but not others?
This is almost always an incomplete intermediate chain. Devices and browsers with a cached copy of the intermediate certificate from another site will connect fine; those without it, including many mobile browsers and API clients, will reject the connection.
Do I need a separate certificate for each site on the same IIS server?
Not if SNI is enabled – a single server can host multiple HTTPS sites with different certificates on the same IP and port. Without SNI enabled on the binding, each site needs its own IP address or you’ll run into certificate mismatch errors.
Can I use a wildcard certificate across multiple IIS sites?
Yes, a wildcard certificate can be bound to multiple sites on the same server as long as they’re all subdomains covered by the certificate. Just be aware that a single expired wildcard certificate then takes down every bound site simultaneously, which raises the stakes on tracking its renewal date.
Getting the certificate bound and the padlock showing is the easy part of SSL on IIS. The chain, the protocol configuration, and the renewal process are where long-term reliability actually gets decided – and they’re worth a second look even on servers that have “always worked fine.”