IIS SSL Certificate: Install, Bind & Renew

Our IIS web server support team installs and renews certificates on IIS as routine work, and the same three tickets keep coming back: the certificate that disappears after completing the request, the missing intermediate that only fails on some clients, and the expired certificate nobody was watching. This page documents the full path — CSR, completing the request, the HTTPS binding, SNI, chain issues, Let's Encrypt automation, renewal, and the errors in between.

How IIS stores SSL configuration

Two places, and troubleshooting is easier when you know which one is broken. The binding itself (site, IP, port, host name) is stored in applicationHost.config. The certificate association is stored in the HTTP.sys configuration, because on IIS 7 and later HTTP.sys handles TLS in kernel mode. You can view the HTTP.sys side directly:

netsh http show sslcert

If a binding exists in IIS Manager but HTTPS connections fail, compare the two: the binding must be present in applicationHost.config, and HTTP.sys must hold a valid certificate hash and store name for that IP:port. The certificate itself lives in the Local Machine Personal store (internally named MY) and must include its private key.

Step 1: Create the CSR in IIS Manager

Skip this step if your CA or provider gives you a PFX file — go straight to the import section below. A CSR is only needed when the CA expects you to generate the key pair yourself.

1. In IIS Manager, select the server node (not a site) and open Server Certificates.
2. In the Actions pane, click Create Certificate Request.
3. Fill the Distinguished Name fields. Common name is the fully qualified domain name the certificate protects (for example www.example.com); the rest — Organization, Organizational unit, City, State, Country — describe your company. The CN must match what users type in the browser, or the browser rejects it.
4. On the Cryptographic Service Provider page, keep the Microsoft RSA provider and set bit length to 2048 or higher. 1024 is refused by public CAs.
5. Save the request as a text file and submit its contents to the CA.

Note the machine you created the CSR on. The private key was generated on that machine and stays there — the issued certificate can only be completed on the same server, unless you later export a PFX and move it.

Step 2: Complete the certificate request

The CA returns a certificate file (typically .cer or .crt). Back in Server Certificates, click Complete Certificate Request, browse to the file, and give it a friendly name. The friendly name is only a label shown in binding dropdowns — pick something with the domain and expiry year so future you can tell certificates apart.

If the certificate disappears after completing the request

The classic IIS certificate problem: you complete the request, the certificate appears in the list, you press F5 and it is gone. What happened is that the certificate was placed in the store without being linked to its private key, and IIS drops unusable entries from the list. The fix is to repair the key association. Open the certificate in the Certificates MMC (Local Computer, Personal), copy its serial number from the Details tab, then run from an elevated prompt:

certutil -repairstore my "SERIAL_NUMBER"

If certutil reports the repair succeeded, refresh IIS Manager and the certificate is back, now showing "You have a private key that corresponds to this certificate" in MMC. If certutil cannot find a matching key, the CSR was generated on a different machine — reissue against a new CSR from this server, or export a PFX from wherever the key actually lives.

Alternative: import a PFX

When the certificate and private key already exist as a .pfx file (exported from another server, or issued by a provider that generates the key for you), you do not need a CSR at all. Either use Server Certificates > Import in IIS Manager, or from the command line:

certutil -f -p "PFX_PASSWORD" -importpfx My C:certsexample.pfx

My is the Local Machine Personal store. After import, verify the private key came with it — the certificate icon in MMC shows a key overlay, and certutil -store my lists the entry with a key container. A PFX imported without its key produces the same disappearing-certificate behavior described above.

Step 3: Add the HTTPS binding

1. Select the site in IIS Manager and click Bindings in the Actions pane.
2. Click Add, set Type to https. Port defaults to 443; leave it unless you have a reason.
3. Enter the Host name for the site.
4. Select the certificate in the SSL certificate dropdown (identified by friendly name) and click OK.

SNI: multiple HTTPS sites on one IP

Without Server Name Indication, HTTP.sys associates one certificate per IP:port pair — the client's requested host name is encrypted inside the TLS handshake, so the server cannot pick a certificate by name. That meant one certificate (or one wildcard/SAN certificate) per IP address. IIS 8.0 on Windows Server 2012 added SNI support: check Require Server Name Indication on the binding, and HTTP.sys selects the certificate by the host name the client sends in the TLS ClientHello. In practice:

• One HTTPS site on the server: leave SNI unchecked, nothing changes.
• Multiple HTTPS sites sharing an IP with different certificates: check SNI on each binding and set the host name. Every current browser and client library sends SNI.
• If bindings conflict — two non-SNI bindings on the same IP:port — IIS warns that adding the binding will overwrite the existing certificate association, and the site configured second silently takes over the IP:port. This is the usual cause of "the wrong certificate is being served."

Missing intermediate certificates

Symptom: the site works in your desktop browser but fails on mobile devices, curl, or API clients with an "unable to verify the first certificate" or untrusted-chain error. Desktop browsers cache intermediates from other sites and paper over the gap; strict clients do not. The server is supposed to send the full chain — leaf plus intermediates — and it builds that chain from the local store.

Fix: download the intermediate certificate from your CA, open mmc.exe, add the Certificates snap-in for Computer account, and import the intermediate into Intermediate Certification Authorities. Restart the site (or run iisreset) so Schannel rebuilds the chain. Verify from outside with an SSL checker or openssl s_client -connect host:443 -servername host from a Linux box — the output lists every certificate the server actually sent.

Let's Encrypt on IIS

Let's Encrypt issues free 90-day certificates over the ACME protocol, and the established ACME client for IIS is win-acme — an actively maintained ACMEv2 client that reads your IIS bindings, requests certificates for the host names it finds, installs them, updates the bindings, and registers a Windows scheduled task that renews before expiry. The initial run is an interactive console menu; after that, renewal is unattended. The 90-day lifetime is a feature here: it forces the automation to exist, which is the opposite of the annual-renewal calendar entry that someone eventually misses. For public-facing sites without compliance requirements that mandate a specific CA, this is the lowest-maintenance option on IIS.

Renewal

Renewing a commercial certificate is the same mechanics as the original install, and it does not require downtime:

1. Rekey vs renew: a renewal keeps the same key pair alive for another term; a rekey generates a new CSR and new private key. Most CAs treat both the same at issuance, and generating a fresh CSR (rekey) is the cleaner habit — keys should not live for many years, and it also sidesteps any private-key problem on the server.
2. Complete the new certificate (or import the new PFX) alongside the old one. Both can sit in the Personal store simultaneously; give the new one a friendly name with the new expiry year.
3. Edit the existing HTTPS binding and switch the SSL certificate dropdown to the new certificate. The change takes effect immediately for new connections — no iisreset, no dropped site.
4. Confirm the served certificate from a browser or netsh http show sslcert, then delete the expired certificate from the store once nothing references it.

After the binding serves HTTPS correctly, redirect HTTP to HTTPS at the server level rather than in application code — the standard pattern is a URL Rewrite rule, covered in IIS URL Rewrite.

TLS protocol and cipher configuration

None of this is configured in IIS. Protocol versions and cipher suites are controlled by Schannel, the Windows TLS stack, through registry keys under HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols — documented in the TLS registry settings reference — and they apply to every Schannel consumer on the machine (IIS, SQL Server endpoints, RDP), not just the website you were thinking about.

Current state of the defaults: Windows Server 2022 supports TLS 1.3 and enables TLS 1.2 and 1.3 by default, but TLS 1.0 and 1.1 are still enabled unless you disable them. Microsoft has deprecated TLS 1.0 and 1.1, with the versions disabled by default starting in newer Windows releases (Windows 11 24H2 and Windows Server 2025) — on 2016/2019/2022 the disabling is your job. Editing Schannel registry keys by hand is error-prone and a wrong entry can lock RDP out; the widely used free tool IIS Crypto (Nartac Software) presents the same registry settings as checkboxes with sane templates. Whatever the method, changes require a reboot, and disabling TLS 1.0/1.1 should be preceded by checking what still connects with them (old .NET Framework clients pinned below 4.6.2 are the usual casualty).

Common errors

Checking expiry across all sites

Expiry surprises are a monitoring failure, not a certificate failure. This PowerShell lists every certificate bound in IIS with days remaining:

Import-Module WebAdministration
Get-ChildItem IIS:SslBindings | ForEach-Object {
    $cert = Get-ChildItem "Cert:LocalMachineMy" |
        Where-Object Thumbprint -eq $_.Thumbprint
    [pscustomobject]@{
        Site      = ($_.Sites.Value -join ',')
        HostPort  = "$($_.Host):$($_.Port)"
        Subject   = $cert.Subject
        Expires   = $cert.NotAfter
        DaysLeft  = [int]($cert.NotAfter - (Get-Date)).TotalDays
    }
} | Sort-Object DaysLeft | Format-Table -AutoSize

Run it from a scheduled task that alerts under 30 days, or fold it into existing monitoring. Certificates that IIS serves but that were bound directly via netsh (non-IIS services on the same box) will not appear here — check netsh http show sslcert for those.

When to hand it over

Certificate work is low-frequency and high-blast-radius: a botched renewal takes the site down for every visitor at once, and chain or Schannel problems surface only on the clients you did not test. Our IIS support team handles certificate installs, renewals, SNI multi-site setups, chain repairs, and TLS hardening as standard cases, with an engineer on live chat 24/7. Background on the platform itself is in What is IIS.