Introduction

Replacing a default certificate usually means two separate jobs: install the new certificate and update the application or server so it stops presenting the old one. The exact command depends on the platform, but the underlying process is always the same: locate where the current certificate is configured, replace the certificate and key or keystore reference, reload the service, and verify what clients now receive.

Start by Identifying Where the Certificate Is Used

Many systems do not store the active certificate in just one place. A web server might reference a PEM certificate and private key, a Java service might use a JKS or PKCS12 keystore, and a load balancer may hold the certificate in its own control plane.

So before deleting anything, answer these questions:

1. Which process is currently serving TLS?
2. Where is that process configured to load its certificate from?
3. Is there an intermediate certificate chain file involved?
4. Does another proxy sit in front and terminate TLS earlier?

If you skip this step, you can replace the wrong file and still see the old certificate in production.

Example: Replacing an Nginx Certificate

A common server-side example is Nginx. The active certificate is typically declared in the site configuration.

1server {
2    listen 443 ssl;
3    server_name example.com;
4
5    ssl_certificate     /etc/nginx/certs/example/fullchain.pem;
6    ssl_certificate_key /etc/nginx/certs/example/privkey.pem;
7}

To switch to a different certificate, install the new certificate files, update the paths if necessary, test the configuration, and reload Nginx.

sudo nginx -t
sudo systemctl reload nginx

If the file names remain the same and you overwrite the certificate files deliberately, the config may not need to change. If the new certificate lives at a different path, update the config first.

Verification Matters More Than File Copying

After the reload, confirm what the server actually presents.

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

This tells you the subject, issuer, and validity dates of the certificate clients now receive. That check catches cases where:

• the old service was never reloaded
• another proxy is still presenting the old certificate
• the chain file is wrong
• the new certificate was installed on the wrong host

Removing the Old Default Certificate Safely

Do not delete the old certificate before the new one is live and verified. Keep a backup long enough to roll back if the replacement fails.

A safe sequence is:

1. Back up the current certificate and key material.
2. Install the new certificate.
3. Update the service configuration.
4. Test the configuration syntax.
5. Reload or restart the service.
6. Verify with openssl or a browser.
7. Remove the old certificate only after successful validation.

This keeps recovery simple if the new certificate or chain is incorrect.

Common Pitfalls

• Replacing the certificate file but forgetting to reload the service that uses it.
• Updating the wrong server because TLS is actually terminated by a proxy or load balancer upstream.
• Installing the leaf certificate without the required intermediate chain.
• Deleting the old certificate too early, which removes the easiest rollback path.
• Verifying only in a browser cache instead of using a direct TLS inspection command.

Summary

• Find the real TLS termination point before changing anything.
• Replace both configuration references and certificate material as required by the platform.
• Reload the service and verify the live certificate with openssl or an equivalent tool.
• Keep the old certificate until the new one is confirmed working.
• Treat certificate replacement as a controlled deployment step, not just a file copy.