IIS certificate renewal: a new certificate still needs the right HTTPS binding

IIS SSL certificate renewal is complete when the correct HTTPS binding serves the replacement certificate and clients can use the application. Importing a certificate into Windows is one step. It does not, by itself, establish that every site or server is presenting the new certificate.

The starting question is where TLS terminates. If a load balancer or CDN handles the public connection, its certificate is separate from the one on IIS. Verify the layer you intend to renew before changing a Windows binding.

Map the hostname to the HTTPS binding

Record the IIS site, IP address, port, hostname, and selected certificate. Include whether the binding uses Server Name Indication, commonly called SNI, or a centralized certificate store.

Microsoft's IIS binding reference describes the binding information and SSL flags. Those details matter when several sites share a server. Changing the wrong binding can update a different application while the intended site continues serving its old certificate.

Keep a record of the previous binding and certificate identity before a change. If a renewal tool manages the binding, find its configuration rather than adding a second competing method manually. Two installers changing the same site make the next renewal harder to predict.

Confirm the certificate and private key are usable

Before selecting the replacement, confirm that its names cover the hostname clients use and that its validity window includes the current time. Check that the intended machine context has access to the matching private key.

A certificate imported without its matching private key is not equivalent to a usable server identity. A PFX package and a public certificate file contain different material. Follow the issuance method and Windows deployment procedure your team uses, and handle any private-key package through controlled storage.

Inspect the chain as well. A certificate that works in one administrator's browser may still fail on a client with a different trust store or cached intermediates. The live verification stage is where this difference becomes visible.

Renew without changing unrelated binding settings

Use a documented change process for the server's IIS version and certificate storage model. A practical sequence is:

1. Record the current binding and certificate fingerprint or thumbprint.
2. Obtain the replacement through the existing CA or ACME workflow.
3. Make the certificate and matching key available through the intended Windows certificate store or centralized store.
4. Select the replacement for the intended HTTPS binding, where the storage model requires it.
5. Preserve the hostname, port, IP, and SNI settings unless the change explicitly requires something different.
6. Verify a fresh TLS connection and the application's behavior.

Do not use a blanket server restart as a substitute for identifying the right binding. Follow your deployment method's reload requirements and avoid interrupting unrelated sites without a reason.

Verify with the hostname, including on each node

Use the name users enter, rather than testing only the server's IP address. SNI allows the requested hostname to influence the selected certificate, so an IP-only check can examine a different site.

For a server farm, test the public path and verify each deployment target through an appropriate direct route. Keep the intended hostname in the TLS handshake even when connecting to a specific node. Compare the observed certificate identity and expiry with the replacement.

Then exercise a harmless application path, such as loading the sign-in page. A successful handshake cannot prove that the application behind it is functioning. Keep the observation time and test location with the renewal record.

Keep Remote Desktop certificates in a separate runbook

An IIS certificate change should not be assumed to update Remote Desktop services. If the same Windows host also provides an RD Gateway or other RDS role, inventory that service and its certificate assignment separately.

The host name, role, deployment method, and client check can be different. Record the owner and recovery path for each. The device renewal checklist gives a broader view of Windows and appliance targets without treating them as one binding.

Fix the failure at the right stage

If IIS still serves the old certificate, check the binding, selected certificate, test hostname, and upstream termination point. If one user gets an error while another succeeds, investigate the chain, trust store, DNS route, and node reached before issuing another certificate.

If the replacement is unusable, restore the recorded binding to a known valid configuration when possible. Do not remove the previous working certificate until verification and your recovery window are complete. See the troubleshooting guide for a stage-by-stage diagnosis.

Automate the binding and the proof

A useful automation path includes issuance, installation, binding selection, live verification, and failure notification. Observe one scheduled renewal before expanding to more sites. Pair the job with certificate monitoring so that a stale binding cannot hide behind a successful CA order.

IIS and Windows Server are in Certonomy's published launch scope. Review the renewal workflow and founding access if your team wants to manage those installs alongside client firewalls and web servers.