How to change Certificate on Microsoft IIS

IIS sites use HTTPS bindings that ultimately become HTTP.sys SSL bindings. Replacing the certificate means importing a PFX into the Local Computer store and changing each applicable binding's certificate hash. Merely importing the PFX leaves the old certificate active.

Before you begin

• Have the PFX password and a certificate with a private key, Server Authentication EKU, and SANs for every hostname on the binding.
• Record the site's IP address, port, host name, SNI setting, certificate store, and old thumbprint. Export applicationHost.config or take an IIS configuration backup.
• Identify whether Centralized Certificate Store (CCS) is enabled. CCS selects a PFX by hostname and uses a different replacement workflow.
• Plan how to test through every load balancer and directly against each IIS node.

Understand IIS bindings and HTTP.sys

An ordinary IIS binding is identified by IP, port, and optional host name. With SNI, the TLS ClientHello hostname lets multiple certificates share an IP and port. Without SNI, only one certificate can own a given IP:port combination. IIS writes the binding for HTTP.sys; you normally manage it through IIS Manager or the WebAdministration module, not by editing netsh http state separately.

Applications that self-host HTTP.sys outside IIS are different. Their owner may create an IP:port or hostname:port binding directly with netsh http add sslcert; changing an IIS site does not change that application.

Step-by-step certificate replacement

1. Import the PFX into Certificates (Local Computer) > Personal > Certificates, or:

   $password = Read-Host "PFX password" -AsSecureString
   $cert = Import-PfxCertificate -FilePath C:\secure\site.pfx `
     -CertStoreLocation Cert:\LocalMachine\My -Password $password
   $thumbprint = $cert.Thumbprint

2. In IIS Manager, select the server and open Server Certificates. Confirm the new certificate is present and has the expected expiration date.

3. Select Sites > <site> > Bindings. Edit the exact https binding. Preserve its IP address, port, host name, and Require Server Name Indication value; select the new certificate and save.

   A PowerShell alternative for an existing binding is:

   Import-Module WebAdministration
   $site = "Default Web Site"
   $hostName = "www.example.com"
   $binding = Get-WebBinding -Name $site -Protocol https -Port 443 -HostHeader $hostName
   $binding.AddSslCertificate($thumbprint, "My")

4. Repeat for every binding and every web server node. A certificate selected for one site is not automatically selected for another site.

5. For CCS, replace the correctly named PFX in the configured central store instead of assigning a conventional certificate hash. Preserve the CCS naming and password rules, and verify that every server can still read the share.

6. Inspect HTTP.sys after the change:

   Get-WebBinding -Protocol https | Format-List bindingInformation,sslFlags,certificateHash,certificateStoreName
   netsh http show sslcert

Product-specific considerations

Changing a normal IIS HTTPS binding is effective for new TLS handshakes and does not normally require an application-pool recycle, IIS restart, or server reboot. Existing TLS connections can continue using the session negotiated before the change. Avoid iisreset as a routine certificate step: it interrupts all IIS sites on the server.

If an application caches certificate state above IIS, follow that product's guidance. Exchange, for example, documents scenarios in which restarting IIS is recommended for an Outlook on the web authentication-cookie certificate when Layer 4 load balancing is used. That is an Exchange behavior, not a general IIS binding requirement.

For a direct HTTP.sys owner, first identify the application's documented AppID and binding. A typical replacement preserves all existing flags:

netsh http show sslcert hostnameport=service.example.com:443
netsh http delete sslcert hostnameport=service.example.com:443
netsh http add sslcert hostnameport=service.example.com:443 `
  certhash=<new-thumbprint> certstorename=MY appid={<existing-app-id>}

Deleting before adding creates a brief unbound interval. Do this only for a known non-IIS HTTP.sys application and preserve its client-certificate, revocation, and SNI options.

Verify the new certificate

Test the hostname rather than only the server IP so SNI selects the intended binding:

openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts

Check the leaf fingerprint, SANs, expiration, and returned intermediate chain. Test each node by temporarily resolving the hostname to that node or using a load-balancer maintenance pool.

Rollback

Edit the binding and reselect the old certificate, or restore the IIS configuration backup. Re-test the actual hostname. Keep the old certificate and private key until every binding, node, health check, and dependent application is verified.

Common problems

• The certificate was imported into Current User or has no private key.
• SNI or the host name was accidentally cleared while editing the binding.
• A second site without SNI already owns the IP:port.
• The administrator changed IIS while the application owns a separate HTTP.sys binding.
• The site serves the right leaf but omits an intermediate certificate.
• A load balancer is still routing to a node that was not updated.

Automating certificate replacement with aethercert

The aethercert IIS deploy target imports the certificate into the Windows store and creates or updates the selected HTTPS binding. It preserves the product distinction: it automates IIS bindings, not arbitrary third-party HTTP.sys registrations.

See Deploy targets for the fields this preset takes, what it needs on the host, and how far it has been verified.

Sources

• Microsoft IIS binding reference
• Microsoft IIS PowerShell SSL configuration
• Microsoft Learn: netsh http