An IIS certificate renewal is complete only when the intended client endpoint presents the replacement certificate with a trusted chain and correct hostname. Check TLS termination, the actual HTTP.sys binding and intermediate certificates, then verify from the client path before retiring the old material.
This article uses an IIS 10 application as its reference. It is source-researched and untested; no certificate or binding was changed. Microsoft’s older IIS SSL guides provide useful mechanics, but their legacy protocol settings and sample troubleshooting fixes are not a modern security baseline.
Find every place the connection terminates
Draw the path from the client hostname through any public gateway, proxy or load balancer to the application. Record where the client-facing TLS connection ends and whether another encrypted connection begins towards the backend.
A certificate renewed on the backend cannot change the one presented by a separate frontend. Similarly, renewing the public endpoint does not prove that a proxy’s connection to IIS still validates the backend correctly.
Inventory each relevant hostname, listener address, port, server or node, current certificate identifier and owner. Include private access paths used by staff or integrations. Do not assume a browser and a scheduled integration use the same name or trust configuration.
For a multi-node service, determine how certificates and bindings reach each node. One successful connection may have reached only the already-correct server. The acceptance plan needs a supported way to verify every intended serving node or termination point.
Check the replacement before changing a binding
Verify that the replacement covers the intended DNS names, has the required server-authentication purpose, has an acceptable validity period and chains to a trusted issuer for the actual clients. Use current client and issuing-CA requirements for name validation. Do not rely on a certificate’s friendly display name.
Microsoft’s IIS SSL setup guide distinguishes obtaining an appropriate certificate, creating an HTTPS binding and testing a request. Its examples also discuss validity, server identity and issuer trust. Treat those as separate checks, even when a certificate-management tool performs several steps together.
Confirm that the corresponding private key is available to the intended termination service through the supported certificate store or key provider. Microsoft’s server-certificate troubleshooting guidance describes missing-key and listener-configuration failures. A public certificate imported without its key does not establish a working server endpoint.
Record a non-secret certificate identifier, the expected names and validity dates. Keep exported private-key material and passwords in approved custody, not in the change record or article folder. If a certificate is non-exportable or uses a specialised key provider, the recovery and deployment method must respect that design.
Do not broaden filesystem or private-key permissions speculatively. Establish which component needs access and which supported store/provider it uses. Advice for an application process is not automatically applicable to the Windows HTTP listener’s key access.
Verify the chain and client trust
An endpoint can present the right leaf certificate but still fail because the required intermediate certificates are missing or misconfigured. Microsoft’s intermediate-certificate guidance explains that clients validate the server’s certificate chain and that server-side intermediate configuration affects authentication.
Test from a representative client with its normal trust policy. A successful connection from the administrator’s workstation does not prove that older integration clients, managed devices or private-domain clients trust the same chain.
Where an internal CA is used, follow the organisation’s established trust-distribution process. Do not tell users to click through warnings or install an arbitrary certificate as a trusted root. Certificate renewal should preserve server identity assurance, not train users to ignore it.
Keep chain validation and reachability separate. A blocked validation dependency or a client with different trust state needs its own investigation. Do not disable revocation checking, hostname validation or certificate verification to turn the test green.
Review the exact IIS binding
In IIS Manager, select the intended site and inspect its bindings. Record the protocol, address, port, hostname and selected certificate, together with the relevant SSL binding mode. Microsoft’s binding schema defines these fields and the version history of the schema.
Server Name Indication, or SNI, allows the TLS connection to identify a requested hostname for certificate selection. A test made only to an IP address can exercise a different binding from the named application. Preserve the application hostname in the test.
Check whether the deployment uses an ordinary certificate-store binding or a centralised certificate store. Do not apply the steps for one mode to the other without verifying the configured design. The binding source documents these as different modes S2.
Save the current binding details through the approved configuration-record process. Establish the intended change and its scope before opening a modifying dialogue. A similarly named site or an overlapping listener can affect more applications than the one being renewed.
This article supplies no binding-deletion or replacement command. The exact listener, certificate identifier and affected sites must be reviewed first. The source documentation’s examples do not establish that it is safe to remove a live listener on an unspecified machine.
Read the binding and test the presented chain
A conventional IIS certificate binding identifies a specific certificate. Importing a replacement alone does not establish that the binding changed; the approved renewal process or automation must update it. Centralised certificate-store bindings use a different selection mechanism and need their own inspection S1, S2.
Untested Windows diagnostic in an authorised elevated Command Prompt R1:
netsh http show sslcert
Compare the relevant IP:port or hostname:port entry, certificate hash and store with the intended replacement. This reads HTTP.sys bindings, not the certificate served by an external proxy. Keep output restricted because it exposes endpoint configuration.
Microsoft instructs operators to update the intermediate issuing certificates when renewing the leaf certificate S4. Inspect Certificates (Local Computer) → Intermediate Certification Authorities. A renewal may introduce a different intermediate; the presence of last year's chain is insufficient. Do not import an unverified certificate or turn off validation to clear a warning.
Record IIS binding flags as well as its certificate. The reference lists SNI and centralised-store flags, plus controls for HTTP/2, OCSP stapling, QUIC, TLS 1.3 over TCP and legacy TLS; availability depends on IIS/Windows version S2. Preserve the effective configuration instead of copying flag values between releases.
For an approved external probe, this untested OpenSSL 3.5 command supplies SNI, checks the hostname and stops on certificate verification errors R2:
openssl s_client -connect app.example.test:443 -servername app.example.test -verify_hostname app.example.test -verify_return_error -showcerts
It opens a TLS connection and displays the server-supplied certificates; end the interactive session after collecting evidence. Verification uses that client's trust configuration. -showcerts alone is not proof of a valid chain, and success does not establish revocation checking or the business operation. Compare the leaf serial/validity and chain with the approved replacement, then repeat from representative client locations.
Make a staged change with a usable return path
Have the certificate and application owners approve the exact replacement and test plan. Use a staging environment or a controlled node where the architecture permits it. Confirm that the prior certificate and binding remain available for a supported reversal while they remain valid and permitted by policy.
Apply the specific binding update through the installed, supported management interface. Record the resulting configuration. Do not bundle certificate renewal with cipher-policy changes, a DNS migration and an application upgrade unless the wider change has been designed and rehearsed as a whole.
Where a service reload or restart is required, follow the component’s documented behaviour and agreed outage plan. Do not restart all IIS services by default merely because a certificate was imported. The operational effect depends on the termination component and deployment method.
If the replacement fails validation, preserve the error and restore the previous approved binding where that remains a valid recovery route. An expired or revoked previous certificate is not a usable rollback just because its file still exists. Record that constraint before the window begins.
Test the certificate actually presented
Open a fresh connection from the representative client using the normal application hostname. Inspect the presented certificate’s identifier, validity and chain. Compare these with the approved replacement rather than assuming a successful page load proves the new certificate was selected.
Then perform the expected application operation. A TLS handshake can succeed while authentication, redirects or backend calls fail. Include any supported integration client whose connection path or trust store differs materially from the browser.
For load-balanced services, verify the intended nodes through the approved test mechanism. Record which node or termination point each observation covers. Repeated requests that all land on one node are not evidence about the others.
For a proxy-to-backend TLS hop, inspect its validation separately. Confirm that the proxy uses the correct backend identity and accepts the replacement under its normal trust policy. The public browser’s certificate view cannot observe that internal hop.
Keep the results factual: presented certificate, tested hostname, client type, path, application result and time. No certificate renewal or successful handshake is claimed by this article.
Retire old material only after dependency review
Before removing the previous certificate or key material, check whether another site, service, listener or recovery procedure still references it. A certificate visible in several places is not necessarily an unused duplicate.
Retain or destroy sensitive material according to the approved security and recovery policy. This article does not prescribe keeping private keys indefinitely, nor deleting them as immediate cleanup. The decision must consider both exposure and valid dependencies.
Ensure monitoring checks the presented endpoint certificate, not only the newest certificate in a local store. Assign an owner for renewal, deployment and verification. Automated issuance is useful, but it does not prove every serving binding was updated.
Keep the certificate path in the application’s operating record. The next operator should be able to identify who renews the certificate, where it terminates and how acceptance is measured without reconstructing the architecture during an expiry incident.
Limitations
IIS 10 and the cited OpenSSL 3.5 client are reference scopes; other termination products and centralised stores differ. This article does not describe a NetLeverage-managed renewal service. No certificate import, binding change or private-key export is performed.
Acceptance checklist
- Every TLS termination point and required hostname identified.
- Replacement key, leaf identity and intermediate chain approved.
- Actual binding and protocol flags recorded before and after change.
- Representative clients receive and trust the intended certificate; application test passes.
Learning notes
- Importing a certificate and presenting it to clients are separate events.
- A valid leaf certificate still needs the correct key, chain and binding.
- Each TLS hop and materially different client path needs its own acceptance evidence.
Related reading: IIS 502 and 503 Errors: Find the Failing Request Layer; DNS Changed but Users Still Reach the Old Application; Server Up, Application Unusable: Build Better Health Checks.
Sources and review status
Sources accessed 30 October 2026. Exact displayed dates, scope and claim mapping are in the accompanying evidence file. Revised after independent review; independent recheck pending. All examples remain untested and no lab validation is claimed.
- How to Set Up SSL on IIS 7 or later | Microsoft Learn
- Binding <binding> | Microsoft Learn
- Troubleshooting SSL related issues (Server Certificate) - Internet Information Services | Microsoft Learn
- Configure intermediate certificates in Internet Information Services (IIS) - Internet Information Services | Microsoft Learn
Additional revision sources: