How to Renew an SSL Certificate: A Complete Guide
SSL certificates don't last forever. Every website running HTTPS relies on one, and when it expires, browsers immediately flag the site as "Not Secure" — breaking visitor trust and potentially killing traffic overnight. Renewing an SSL certificate is a routine maintenance task, but the exact steps vary depending on where your certificate lives, who issued it, and how your server is configured.
What Happens When an SSL Certificate Expires?
An SSL/TLS certificate is a digital credential that encrypts the connection between a web server and a visitor's browser. Certificate Authorities (CAs) issue them with fixed validity periods — currently capped at 398 days for publicly trusted certificates (roughly 13 months).
When a certificate expires:
- Browsers display security warnings that most users won't bypass
- Search engine rankings can drop
- Email services tied to the domain may reject connections
- API integrations and payment processors may fail silently
Renewal isn't optional for any live, user-facing site.
The General SSL Renewal Process
Regardless of your setup, renewal follows the same core sequence:
- Generate a new Certificate Signing Request (CSR) — a block of encoded text containing your domain and organization details
- Submit the CSR to your Certificate Authority
- Complete domain validation (and identity validation for higher-tier certs)
- Receive and install the new certificate on your server
- Verify the installation and confirm the new expiry date
The devil is in the details of each step — and those details depend heavily on your environment.
Where Your Certificate Lives Changes Everything 🔐
Managed Hosting Panels (cPanel, Plesk, etc.)
If your site runs on shared hosting with a control panel, renewal is often semi-automated. Most hosts offer AutoSSL or integration with Let's Encrypt that renews certificates silently in the background. If you're using the host's built-in SSL tool:
- Log into cPanel or your host's dashboard
- Navigate to SSL/TLS or Security
- Select Manage SSL or AutoSSL
- Trigger a renewal or confirm auto-renewal is enabled
If AutoSSL is on, you may not need to do anything manually — but it's worth confirming the renewal actually completed before the expiry date.
Certbot and Let's Encrypt (Linux Servers)
Let's Encrypt is a free CA widely used on VPS and dedicated servers. If you installed your certificate using Certbot, renewal is handled via command line:
sudo certbot renew This checks all installed certificates and renews any expiring within 30 days. Most administrators set this to run automatically via a cron job or systemd timer. The command to test without making changes:
sudo certbot renew --dry-run After renewal, your web server (Apache or Nginx) typically needs to reload its configuration to apply the new certificate:
sudo systemctl reload nginx or
sudo systemctl reload apache2 Cloud Providers and CDNs (AWS, Cloudflare, Azure)
Cloud-managed certificates add another layer. Services like AWS Certificate Manager (ACM), Cloudflare, and Azure App Service can handle renewal entirely automatically — but only when your DNS validation records are still in place.
If you originally validated via DNS (a TXT or CNAME record added to your domain's DNS zone), that record must remain intact for automatic renewal to succeed. Deleting it breaks the renewal chain without any obvious warning until the certificate expires.
Manual Renewal from a Paid CA (DigiCert, Sectigo, GlobalSign)
Extended Validation (EV) and Organization Validation (OV) certificates require human review and can't be renewed automatically. The process involves:
- Logging into your CA account and initiating renewal
- Generating a new CSR (server-side or via the CA's tool)
- Submitting business documentation for OV/EV
- Downloading the renewed certificate and its intermediate chain
- Installing both on your server and updating your web server config
Missing the intermediate certificate bundle is one of the most common installation errors — it causes some browsers and mobile devices to show errors even when the primary cert is valid.
Key Variables That Affect Your Renewal Path
| Factor | Impact on Renewal |
|---|---|
| Certificate type (DV / OV / EV) | Determines validation complexity and time |
| Hosting environment | Dictates manual vs. automated renewal |
| Single domain vs. wildcard vs. multi-SAN | Affects CSR structure and cost |
| DNS management location | Critical for automated DNS validation |
| Web server software | Determines install and reload commands |
| Auto-renewal configuration | Determines whether any manual action is needed |
How Far in Advance Should You Renew? ⏱️
Best practice is to begin the renewal process 30 to 60 days before expiry. Most CAs send email reminders at 90, 60, and 30 days out — but only to the address on file when the certificate was originally issued. If that inbox is unmanned or the address has changed, those warnings disappear silently.
For automated systems like Certbot, the 30-day renewal window is built in. For manual renewals, earlier is always safer — most CAs allow renewal well before the current certificate expires, and the new validity period starts from the original expiry date, not the renewal date, so you don't lose time.
Verifying the Renewed Certificate
After installation, always verify the new certificate is live and correct. Free tools like SSL Labs' SSL Test or browser developer tools (padlock icon → Certificate details) will show:
- The new expiry date
- Whether the full certificate chain is valid
- Which domains are covered
- The issuing CA
A failed or misconfigured installation often looks identical to a working one from the server side — it's the client that sees the error.
The Part That Varies by Setup
The process above is well-defined at each step — but which steps apply to you, and in what order, depends entirely on your hosting environment, the type of certificate you hold, who manages your DNS, and whether you've set up any automation. A developer running Nginx on a cloud VPS has a completely different renewal path than a small business owner on shared hosting, who in turn has nothing in common with an enterprise team managing EV certificates across multiple subdomains. The mechanics are the same; the execution looks nothing alike.