Reissuing an SSL certificate after a migration

An SSL certificate that worked on the old host frequently stops working immediately after a migration, even though nothing about the certificate itself changed. The usual cause is the certificate, private key, and server configuration no longer matching on the new server. The fix is a reissue, which can be as small as re-importing the correct key or as involved as generating a brand new certificate, and the right choice depends on how the move happened.

Why it breaks

A certificate is bound to a domain name, not to an IP address, so moving the site to a new IP does not invalidate it. The break almost always comes from one of three concrete mismatches:

• Private key missing or mismatched. A certificate is only as good as the key it pairs with. If the new host holds a different private key (for example, a fresh one generated during setup), the server cannot complete the handshake and clients see an error.
• Wrong file installed. A panel reinstall may install an old, renewed, or an unrelated certificate under the domain, or leave the prior host's cert in place.
• Validation is not repeatable. If the domain or its DNS moved during the migration, a certificate needs revalidation against the current DNS and site root, which a detached backup does not supply.

The appearance is always the same regardless of cause: a TLS error or a browser warning, and your TLS handshake checks point to the certificate. On the new host, the first and cheapest check is file pairing: the certificate public key must correspond to the private key on disk.

Reissue cleanly

The easiest reissue on most modern hosts lets the control panel generate a fresh certificate from the current configuration:

1. Delete the stale or failing certificate from the new server so the panel does not keep serving it.
2. Let the host run a fresh challenge against the current domain. For Let's Encrypt on your own server, certbot --nginx renew --force-renewal or the panel's renew button issues a cert that is validated against wherever DNS and the web root now point.
3. Ensure the private key the host pairs with the new certificate is generated during the same reissue, so the key and the certificate always match by construction.
4. Confirm the key matches the certificate on the command line if you imported any file manually:

openssl x509 -noout -modulus -in cert.pem | openssl md5
openssl rsa  -noout -modulus -in privkey.pem | openssl md5

When the two hashes match, the pair is coherent. Then reload the web server and check the handshake with a browser or openssl s_client. The renewal checklist covers keeping the reissued certificate current after the move.

Reuse vs re-key

If you are moving to a host where you keep the same domain and want zero disruption, you can often reuse the existing certificate and key rather than reissue. This only works when you export both the certificate and its matching private key from the old host and import that exact pair on the new one; importing the certificate without its key, or pairing it with a different key, fails immediately. Because many shared hosts issue on an IP or canonical name, a cert whose SAN or CN no longer matches the serving name still needs a reissue regardless of the key.

The standard choice is to let the new host issue a fresh certificate during setup, which validates against the live DNS and avoids all key-transfer problems. Reuse an existing export only for a quickly recovered, low-TTL move such as a temporary staging instance or an internal test domain where you control both keys. For any public site, treat a reissue after migration as the default and check the SSL for your platform and migration articles after it, because a reissued certificate on a migrating site that is not yet fully cut over can still fault until DNS and the new origin both resolve to the certificate's validated server name.