When you switch hosting, does the old TLS certificate still work? Discover why authentication doesn't follow the domain instantly

When you move a website, you might think everything changes instantly. In reality, the TLS certificate could stay active longer. Managed TLS platforms generate keys and certificates on your behalf. When you decide to switch hosting or CDN, the old certificate continues to work until it expires. No platform automatically revokes or replaces it. This creates a window where both the old and new services can authenticate the same domain. During this time, browsers might still accept the old certificate, even if they point to the new hosting. The situation is safe but can confuse users and leave a small risk of man-in-the-middle attacks. Researchers have observed this behavior in several providers, highlighting the need for faster revocation mechanisms. Understanding this transition helps protect your online presence better.

Managed TLS platforms simplify key management by delegating the generation, storage, and renewal of X.509 certificates to a third‑party provider. This model relies on a provider‑controlled Certificate Authority (CA) that issues certificates bound to the domain name rather than to the domain owner’s private keys. When a domain is delegated to such a platform, the provider installs a CA‑signed TLS certificate on the origin servers, allowing clients to establish HTTPS connections without manual intervention.

Migrations away from a managed‑TLS provider can happen for various reasons: switching CDNs, adopting a new hosting service, or consolidating multiple domains under a single certificate manager. The study monitored eight popular platforms using a controlled measurement environment. For each domain, researchers first obtained a certificate issued by the platform, then redirected DNS to a new infrastructure run by a competitor while keeping the old certificate active. Server logs and TLS handshake patterns were observed for the full validity period of the certificate (up to 90 days).

Results show that none of the monitored platforms revoked the delegated certificate, issued a new one, or activated certificate‑pinning mechanisms after migration. The original servers continued to present the same certificate, and clients that still resolved the old IP address (or cached stale DNS) completed the TLS handshake without errors. Only after the certificate’s natural expiration did the old authentication material disappear, allowing the new provider to issue a fresh certificate.

From a security perspective, this creates an "authentication window" where multiple entities control the same domain cryptographically. An attacker who gains access to the legacy infrastructure could continue to present a valid certificate, bypassing controls that rely solely on DNS for authority. Services that depend on certificate pinning or out‑of‑band verification (such as mobile apps) might also keep trusting obsolete keys, enlarging the attack surface.

To mitigate this risk, providers are exploring faster revocation mechanisms: HTTP‑based status protocols (OCSP Push, Must‑Staple), blockchain‑based revocation, and ephemeral keys that are automatically discarded after a provider change. Domain owners can adopt practices like automatic certificate rotation, continuous trust monitoring, and using multiple CAs for critical services. Understanding the gap between DNS control and key control is essential for building a resilient PKI in the cloud era.