SSL certificate not showing in IIS bindings: how to import, bind and fix it

Why IIS hides a certificate from the bindings list

The SSL certificate drop-down in the Add Site Binding dialogue does not list every certificate on the machine. It lists certificates in the local computer's Personal store (also shown as My) or the Web Hosting store that have a matching private key on this server. A certificate without its private key is useless to a web server, because the server cannot prove it owns the certificate, so IIS leaves it out.

That gives three questions to answer when a certificate is missing:

• Is the certificate in the Local Computer store, rather than your own user account's store?
• Is it in Personal or Web Hosting, rather than Trusted Root, Intermediate or Other People?
• Does it have a private key? In the Certificates snap-in, a certificate with a key shows a small key on its icon and the text You have a private key that corresponds to this certificate on its General tab.

If the answer to any of these is no, the certificate will not show in IIS. If the certificate does show and still does not work, the problem is in the binding: the wrong host name, SNI not ticked, or another site on the same IP and port taking priority. For the general picture of certificate errors outside IIS, see fixing SSL errors.

The common causes

How to check the certificate and its key

Open PowerShell as administrator and list the certificates in the local Personal store with their key status:

Get-ChildItem Cert:\LocalMachine\My |
  Select-Object Subject, Thumbprint, HasPrivateKey, NotAfter, @{n='DNS';e={$_.DnsNameList -join ', '}} |
  Format-List

Find your certificate by its subject or DNS names. If HasPrivateKey is False, IIS will not offer it. Also check NotAfter for the expiry date and the DNS list for every hostname you need.

To see what HTTP.sys, the part of Windows that actually handles TLS for IIS, has bound to each address:

netsh http show sslcert

Entries labelled IP:port are bindings without SNI, which apply to every hostname on that address. Entries labelled Hostname:port are SNI bindings for one hostname. The certificate hash shown should match the thumbprint of the certificate you expect.

Repairing the link to a private key

If the key does exist on this machine, for example because the CSR was made here but the response was imported as a plain file, certutil can join them again. Use the certificate's serial number or thumbprint:

certutil -repairstore my "1a2b3c4d5e6f7081"

A message that the encryption test passed means the key was found and linked. Refresh Server Certificates in IIS and the certificate now appears. If certutil cannot find a key, it was never on this server, and you need either a PFX from the machine that made the CSR or a new request.

Importing a certificate the right way

The safest format for IIS is a PFX (also called PKCS#12) file, which carries the certificate, its private key and usually the intermediate certificates in one password-protected file. In IIS Manager, select the server, open Server Certificates and choose Import. Pick the PFX, enter its password and choose the Personal or Web Hosting store.

The same import in PowerShell:

$pw = Read-Host -AsSecureString -Prompt "PFX password"
Import-PfxCertificate -FilePath C:\certs\example.pfx `
  -CertStoreLocation Cert:\LocalMachine\My -Password $pw

Building a PFX from PEM files

If your authority or another server gave you separate PEM files, combine them with OpenSSL. OpenSSL 3 encrypts the PFX with modern AES settings by default, which older Windows Server versions such as 2016 cannot read, so add -legacy when the target is an older server:

openssl pkcs12 -export -out example.pfx \
  -inkey privkey.pem -in cert.pem -certfile chain.pem -legacy

Keep the PFX file and its password safe, and delete copies from download folders once imported. Anyone with both can run a site as your domain.

Setting up HTTPS bindings with SNI

In IIS Manager, select the site, choose Bindings, then Add. Set Type to https, IP address to All Unassigned, port 443, and enter the host name, for example www.example.com. Tick Require Server Name Indication, choose the certificate and save. Add a separate binding for each hostname the site answers to, such as the bare domain and www.

The same binding in PowerShell, using the WebAdministration module:

Import-Module WebAdministration
New-WebBinding -Name "Example Bakery" -Protocol https -Port 443 `
  -HostHeader "www.example.com" -SslFlags 1
$cert = Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.DnsNameList -contains "www.example.com" } | Select-Object -First 1
(Get-WebBinding -Name "Example Bakery" -Protocol https -HostHeader "www.example.com").AddSslCertificate($cert.Thumbprint, "my")

-SslFlags 1 turns on SNI. Without it, the binding is an IP and port binding, and only one certificate can be used for all sites on that address and port. IIS warns you if another site already uses the same non-SNI binding, and saving replaces the certificate for both sites, which is a common way to break a second site by accident.

Worked example: the certificate that vanished

An agency created a CSR for www.example.com on a staging server, ordered the certificate, then ran Complete Certificate Request on the live server. The certificate appeared in Server Certificates, then disappeared after a refresh, and never showed in the bindings list.

1. Get-ChildItem Cert:\LocalMachine\My on the live server showed the certificate with HasPrivateKey set to False.
2. certutil -repairstore my with its serial number reported that no key was found, confirming the key lived on staging.
3. On the staging server, the agency completed the request there, then exported the certificate as a PFX with its private key and the full chain.
4. They imported the PFX on the live server into Local Machine, Personal. HasPrivateKey now showed True.
5. They added https bindings for example.com and www.example.com with SNI ticked, then confirmed with netsh http show sslcert that two Hostname:port entries carried the right hash.
6. A request with curl -vI https://www.example.com showed the new certificate and no TLS error.

The fix, step by step

Edge cases worth knowing

• Let's Encrypt on IIS. ACME clients for Windows, such as win-acme, request the certificate, import it with its key and update the bindings for you, and set up a renewal task. Check the task runs, because a renewed certificate must be rebound each time.
• Wrong hostname on the certificate. If the certificate shows but browsers report a name mismatch, the certificate does not list that hostname; see hostname mismatch fixes.
• Missing intermediate. Windows can sometimes fetch a missing intermediate itself, but phones and crawlers may not. Install it under Intermediate Certification Authorities on the server, as covered in untrusted certificate fixes.
• Old certificate still served after renewal. The binding still points at the old thumbprint. Edit the binding and choose the new certificate, or rebind it with PowerShell.

Keeping IIS certificates working

Always generate the CSR and complete the request on the same server, or work with PFX files from the start. Keep a note of each certificate's thumbprint and which bindings use it, and check expiry dates with the PowerShell listing above before they run out. After the certificate works, add an HTTP to HTTPS redirect with the URL Rewrite module, as shown in HTTPS redirects, and set security headers such as HSTS in web.config, as shown in security headers on IIS. Then run the security audit on each hostname.