TLS renewed, but the website still serves the old certificate?
Renewal success is only one part of completion
A website warning after a successful TLS renewal may mean that the new certificate is not being served at the actual connection endpoint. Do not begin by asking users to bypass the warning. Separate issuance, installation in the relevant system and delivery of that certificate by the service users reach. Each stage needs its own evidence.
Domain renewal is different from certificate renewal, and certificate renewal does not automatically change DNS. Even when one provider manages all three, identify whether TLS terminates at the web server, load balancer or a front-end service such as a CDN. Otherwise, updating the back-end certificate may leave users receiving an old front-end certificate.
Check the certificate type before relying on automation
Azure App Service distinguishes uploaded certificates from certificates imported from Key Vault. Uploaded certificates do not receive an automatic binding update when replaced; Key Vault imports have the service’s synchronization and binding-update path. This illustrates why the actual certificate type and platform rules matter. Auto-renew should not be assumed to cover every machine that once received a copy.
Maintain a record for each service name and TLS termination point: hostname, environment, owner, certificate source, observed expiry and deployment method. Check the actual names used for websites, APIs and partner services separately. The register may reference secure storage locations, but should not contain private keys, passwords or secret files in a broadly shared document.
Inspect the served certificate, not only stored files
After replacement, an administrator should check the live access path using the correct hostname. Compare expiry, covered names and an identifier such as serial number or fingerprint with the intended certificate, then test authorized critical workflows such as sign-in and API connectivity. A working homepage alone may not cover subdomains or routes served by other systems.
Hypothetical example: the main site passes, but a partner system still reports warnings. Its API uses another hostname and terminates TLS on a separate load balancer. Reinstalling the main-site certificate will not fix that endpoint; inspect the API record and binding. If user groups see different results, record access paths, times and certificates before attributing the difference to browser caching.
Define completion and recovery criteria
Before making changes, record existing bindings, authorized operators, the change window and an approved recovery procedure. Avoid deleting the old certificate or binding before confirming the platform’s replacement sequence. Recovery should not restore expired certificates or keys suspected of compromise. A security incident requires a separate response from routine renewal.
Close the task when every in-scope endpoint serves the correct certificate and critical workflow tests pass. Retain dates, reviewers and unresolved follow-up items, and test that future alerts reach both the owner and backup. When discussing IT or cloud systems with Chawinnix, bring the service register and TLS paths so that maintenance covers deployment and verification.
