How to Migrate a Site Without Breaking Its SSL Certificates

To migrate a site without breaking its SSL certificates, you need to understand that the certificate itself is rarely the thing that breaks. What breaks is the chain of trust between the browser and your new server: the private key that must match the certificate, the intermediate certificates the server must send, the hostname the certificate was issued for, and the TLS configuration that decides which protocols and ciphers are acceptable. Get those four things right on the new host and the migration is invisible to visitors. Get any one of them wrong and you get a warning page, a mixed-content banner, or a silent failure that only shows up on older clients.

What actually travels when you migrate site SSL certificate material

A certificate is public. The private key is not, and it is the piece people lose. Before you touch DNS, locate the key on the old server and confirm it matches the certificate. On a typical Linux host the files live under /etc/ssl, /etc/pki/tls, or wherever your web server or control panel put them. The check is a modulus comparison:

openssl x509 -noout -modulus -in /etc/ssl/certs/example.com.crt | openssl md5
openssl rsa  -noout -modulus -in /etc/ssl/private/example.com.key | openssl md5
# both lines must print the same hash

If the hashes differ, you have the wrong key and nothing downstream will work. Copy the key with restrictive permissions (chmod 600, owned by root) and never place it in a web-accessible directory. If the key is encrypted with a passphrase, decide now whether the new server can supply that passphrase at boot, because an unattended restart will otherwise leave the service down.

Next, the chain. Browsers trust a root certificate baked into their store, but servers almost never send the root. They send the leaf plus one or more intermediates. If your new server sends only the leaf, desktop browsers may paper over the gap by fetching the missing intermediate, while mobile clients and command line tools fail outright. Verify what the old server sends and reproduce it:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
# look at the "Certificate chain" section and the "Verify return code" line

A return code of 0 (ok) means the chain is complete as presented. Anything else, including unable to get local issuer certificate, tells you an intermediate is missing. Assemble the full chain file in the right order, leaf first, then intermediates, and point your server's certificate directive at that bundle rather than at the bare leaf.

Reconfigure the new server before you move DNS

The safest migration keeps the old host serving traffic while you prove the new one works. Point a hosts file entry or a staging hostname at the new server's IP and test against it directly. The TLS handshake does not care about DNS as long as the SNI hostname and the certificate's subject match, so you can validate everything early.

Check the certificate's subject alternative names. A certificate issued for the bare domain does not cover www unless the SAN list says so. If visitors reach the site at both names, both must appear in the certificate, and your server block must present the same certificate for both. On nginx the relevant directives look like this:

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/ssl/certs/example.com.fullchain.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
}

Apache uses SSLCertificateFile for the leaf and chain, and SSLCertificateKeyFile for the key. Whatever the server, confirm the configuration parses before reloading: nginx -t or apachectl configtest. A reload with a broken config can take the whole site down, not just TLS.

Then test the negotiated result from outside, against the new IP, with SNI set explicitly:

openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

Read the dates. If the certificate expires soon, renew it before the cutover rather than after, when you will be debugging under pressure. Renewal on the new host depends on how the certificate was issued. If it came from an automated client, reinstall and re-run that client on the new server so the renewal timer and the challenge path live where traffic will land. If it is a manual certificate, you need a new certificate order or a reissue, and you cannot simply copy an existing one indefinitely.

Mixed content is the failure that survives a clean handshake

Even with a perfect certificate, a site can break after migration because the HTML references resources over plain HTTP. The browser loads the page over HTTPS, then refuses or downgrades the insecure subresources, and the padlock disappears. This is not a certificate problem, but it is the symptom users report as one.

Search the codebase and database for hardcoded http:// URLs pointing at your own domain. Content management systems often store the site URL in a database row, so a copied database carries the old scheme and hostname with it. Update those values, then load the site in a browser and watch the developer console for mixed-content warnings. The Content-Security-Policy header with a upgrade-insecure-requests directive can paper over stragglers, but fix the source rather than relying on it.

Also confirm the redirect from HTTP to HTTPS still works on the new server. A missing or misordered redirect rule leaves visitors on plain HTTP, where the certificate is never exercised at all.

Cut over, then verify from the outside

Lower the DNS TTL well before the move so the change propagates quickly, then switch the records. After propagation, test the public hostname, not the IP, and check the response headers as well as the handshake. Look for the Strict-Transport-Security header if you use it, and make sure the Location header on the HTTP response points at the HTTPS URL.

Keep the old server's certificate and key archived for a while, and keep the old host answering until you are confident nothing still resolves there. If you use certificate transparency monitoring or expiry alerts, update the endpoints they watch so you do not lose renewal warnings during the transition.

Your next step is to run the two openssl checks above against the old server today, before you schedule anything. Record the chain order, the SAN list, and the expiry date. That baseline is what the new server has to match, and having it written down turns a stressful cutover into a checklist you can tick off in an afternoon.