Your 5-Step Guide to Replacing TLS Certificates in 2025

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain_com.key -out yourdomain_com.csr

When you run the command, you'll be prompted for information like your Country, State, Organization Name, and most importantly, the Common Name. The Common Name must be the fully qualified domain name (FQDN) you want to secure (e.g., www.yourdomain.com).

Security First: The .key file is your private key. It's the secret that proves your identity. If it's compromised, an attacker can impersonate your server. Keep it secure and set its file permissions so only the root or web server user can read it.

Step 3: Choose, Purchase, and Validate Your New Certificate

Now you take your CSR to a Certificate Authority (CA) to get your new certificate. But which type do you need? The choice primarily comes down to the level of trust and validation you want to display to your users.

Comparing Certificate Types

Here’s a quick comparison to help you decide:

Feature	Domain Validated (DV)	Organization Validated (OV)	Extended Validation (EV)
Validation Method	Automated check of domain control (Email, DNS, or HTTP file)	Manual check of organization's legal existence and domain control	In-depth vetting of the organization's legal, physical, and operational existence
Issuance Time	Minutes	1-3 Business Days	2-7+ Business Days
Trust Indicator	HTTPS & Padlock Icon	HTTPS & Padlock, with organization name visible in certificate details	HTTPS & Padlock, with organization name more prominent in certificate details
Best For	Blogs, personal sites, internal services where brand trust isn't paramount	Business websites, e-commerce, APIs where establishing brand identity is important	Banks, financial institutions, large enterprises requiring the highest level of trust
Cost	$ (or free with CAs like Let's Encrypt)	$$	$$$

After you purchase your chosen certificate and submit your CSR, the CA will begin the validation process. For a DV certificate, this is as simple as adding a specific DNS record or uploading a file to your web server. For OV and EV, expect them to verify your business through official records.

Step 4: The Main Event – Installation & Configuration

Once validation is complete, the CA will provide you with your new certificate files. This is the most technical step, but it’s straightforward if you follow a clear process.

You'll typically receive at least two files: your server certificate (e.g., yourdomain_com.crt) and an intermediate/chain certificate (e.g., ca-bundle.crt). The intermediate certificate chains your cert back to the CA's trusted root.

Server Configuration

First, always back up your current web server configuration file!

1. Upload your new certificate files and the private key you generated in Step 2 to a secure directory on your server (e.g., /etc/ssl/certs/).
2. Update your web server's configuration to point to these new files.

Example for Nginx:

In your site's server block (e.g., /etc/nginx/sites-available/yourdomain.conf), update these two lines. Note: It's common practice to concatenate your certificate and the CA bundle into a single file.

# Concatenate your cert and the CA's bundle first:
# cat yourdomain_com.crt ca-bundle.crt > yourdomain_com_chain.crt

server {
    listen 443 ssl;
    server_name www.yourdomain.com;

    ssl_certificate /path/to/your/yourdomain_com_chain.crt; # New chained certificate
    ssl_certificate_key /path/to/your/yourdomain_com.key;  # Your private key
    ...
}

Example for Apache:

In your virtual host file (e.g., /etc/apache2/sites-available/yourdomain-ssl.conf), update these directives:

<VirtualHost *:443>
    ServerName www.yourdomain.com

    SSLEngine on
    SSLCertificateFile /path/to/your/yourdomain_com.crt;         # New certificate
    SSLCertificateKeyFile /path/to/your/yourdomain_com.key;      # Your private key
    SSLCertificateChainFile /path/to/your/ca-bundle.crt;       # The CA's bundle
    ...
</VirtualHost>

After saving your configuration changes, run a syntax check (nginx -t or apachectl configtest) and then gracefully restart your web server service to apply the new certificate.

Step 5: Verify, Clean Up, and Automate for Next Time

You're not done just yet! Verification is a non-negotiable final step to ensure everything is working correctly.

Verify the Installation

1. Browser Check: Open your website in a new incognito window to avoid caching issues. Click the padlock icon in the address bar and inspect the certificate. Confirm that the "Valid from" and "Valid to" dates reflect your new certificate.
2. Online SSL Checker: Use a tool like the Qualys SSL Labs Server Test. This free service provides a deep analysis of your TLS configuration, giving you a grade from A+ to F. It will immediately flag common problems like a missing intermediate certificate (a "chain issue").

Clean Up and Reminders

Once you've confirmed the new certificate is working perfectly, you can safely delete the old, expired certificate files from your server to avoid confusion later. More importantly, update your inventory spreadsheet from Step 1 with the new expiration date.

Set a calendar reminder for the next renewal! Don't just set one for the day before it expires. Set reminders for 90, 60, and 30 days out to give yourself plenty of time.

Think Automation

For many use cases, especially with DV certificates, manual renewal should be a thing of the past. Look into using the ACME protocol with a client like Certbot, which works with free CAs like Let's Encrypt. It can fully automate the process of obtaining and renewing certificates, eliminating the risk of human error and expired-certificate-emergencies.

---

Key Takeaways

Replacing a TLS certificate doesn't have to be a fire drill. By following these five steps—Audit, Generate CSR, Validate, Install, and Verify—you create a predictable, low-stress process. A well-maintained certificate inventory, combined with a move towards automation, is the foundation of a healthy and secure web presence.