How to renew an SSL certificate: a step-by-step guide

To renew an SSL certificate you issue a fresh certificate before the current one expires and install it on every server that serves it. There is no way to extend a certificate in place — the dates are signed into the certificate itself, so renewal always means a brand-new cert, almost always with a new key pair. This guide walks the two paths that actually matter: automated renewal with Let's Encrypt (the recommended default for most sites) and manual renewal with a paid CA, plus the per-platform install-and-reload steps people forget, how long it takes, and how to verify it worked.

What renewing a certificate actually means

A certificate is a signed statement that says "this public key belongs to this hostname, and it is valid from notBefore until notAfter." Those dates are baked in and protected by the CA's signature. You cannot edit them, push the expiry out, or re-stamp the same file — any change would invalidate the signature. So "renewing" is a slight misnomer: you are requesting a new certificate for the same hostnames and swapping it in.

In practice the new certificate also carries a new private key. Automated tooling like certbot generates a fresh key on each renewal by default, which is good hygiene — it limits the blast radius if a key is ever compromised. The hostnames (the Subject Alternative Names) stay the same, so clients see no change other than a later notAfter date. If you understand why certificates expire in the first place, the renewal cadence makes more sense; see SSL certificate validity period for the why behind shrinking lifetimes.

The fastest path: automated renewal with Let's Encrypt + certbot

If your certificates come from Let's Encrypt (or any ACME CA), you should not be renewing by hand at all. The certbot client handles issuance, renewal, and — with a deploy hook — reloading your server. Once it's set up correctly, renewal is a background event you never think about.

Test renewal without touching anything

Before trusting automation, confirm it would succeed. The --dry-run flag runs the full renewal against Let's Encrypt's staging environment without writing new certificates or counting against rate limits:

sudo certbot renew --dry-run

A healthy result looks like this:

Processing /etc/letsencrypt/renewal/example.com.conf
Account registered.
Simulating renewal of an existing certificate for example.com

Congratulations, all simulations succeeded. The following certificates have been renewed:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)

If the dry run fails, fix it now — during a real renewal you have far less margin.

Run the actual renewal

certbot renew checks every certificate certbot manages and only renews the ones close to expiry — by default when less than a third of the certificate's lifetime remains (so roughly the last 30 days of a 90-day cert, and proportionally sooner for shorter-lived certs). This dynamic threshold was introduced in Certbot 4.0.0, replacing the old fixed 30-day window. Running it early is harmless; it simply reports nothing to do.

sudo certbot renew

Reload the server automatically with a deploy hook

A renewed certificate on disk does nothing until the web server reloads and reads the new file. This is the single most common renewal failure. Use --deploy-hook so certbot reloads your server immediately after a successful renewal:

sudo certbot renew --deploy-hook "systemctl reload nginx"

The hook only fires when a certificate is actually renewed, so it won't reload on every cron tick. You can also set deploy_hook permanently in each cert's renewal config under /etc/letsencrypt/renewal/.

Let the timer run it for you

Modern certbot installs a systemd timer (or a cron entry) that runs certbot renew twice a day automatically. Confirm it's active:

systemctl list-timers | grep certbot

If your system uses cron instead of systemd, the equivalent entry lives in /etc/cron.d/certbot and looks like this:

0 */12 * * * root certbot -q renew

Twice-daily checks sound excessive for a cert valid for months, but the redundancy is the point: if one run is blocked by a transient DNS or network error, the next run catches it well before expiry.

Manual renewal with a paid CA

Commercial CAs (DigiCert, Sectigo, GlobalSign, and the like) issue DV, OV, and EV certificates that often aren't ACME-automatable, so renewal is a manual workflow. The steps are always the same.

1. Generate a new key and CSR

A Certificate Signing Request (CSR) bundles your new public key and your domain details for the CA to sign. Generate a fresh 2048-bit (or 4096-bit) key and CSR in one command:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/C=US/ST=California/L=San Francisco/O=Example Inc/CN=example.com"

-nodes leaves the key unencrypted so your server can read it at boot without a passphrase prompt. Guard example.com.key carefully — it is the secret half of the new certificate. For multi-host certs you'll add SANs via a config file rather than -subj.

2. Submit the CSR and complete validation

Paste the CSR into the CA's renewal form. The CA then re-validates that you control the domain:

• DV (Domain Validation) — prove control via an email, a DNS TXT record, or a file served over HTTP. Automated and fast.
• OV (Organization Validation) — DV checks plus a light business verification (registration records, a phone callback).
• EV (Extended Validation) — the heaviest vetting, with legal and operational checks on the organization.

3. Download and install

The CA emails or provides the signed certificate plus its intermediate (chain) certificates. Combine the leaf and intermediates into a fullchain.pem and install it alongside the private key from step 1. The exact paths and directives depend on your platform — covered next.

Install and reload, per platform

Installing the new files is only half the job. The server keeps serving the old certificate from memory until you reload it. This reload step is where most "I renewed but it's still expired" reports come from.

Nginx

Point ssl_certificate at your fullchain.pem and ssl_certificate_key at the new key, then reload:

sudo nginx -t && sudo systemctl reload nginx

nginx -t validates the config first so a typo doesn't take the server down. Full directive and path details are in the Nginx guide.

Apache

Update SSLCertificateFile and SSLCertificateKeyFile in your vhost, then reload gracefully:

sudo apachectl configtest && sudo systemctl reload apache2

See the Apache guide for the exact config block, including how to handle the chain on older Apache versions.

AWS ACM

AWS Certificate Manager auto-renews certificates it issued, as long as the domain is still validated (DNS validation makes this fully hands-off). You don't generate a CSR or reload anything — ACM rotates the cert on the load balancer or CloudFront distribution for you. You only act manually for imported certificates, which ACM cannot renew; those you re-import. The AWS guide covers both cases and the validation records that keep auto-renewal working.

Windows IIS

Import the renewed certificate (often a .pfx bundling key and chain) into the machine certificate store, then rebind it to the HTTPS site so IIS serves the new one. Walk through the binding steps in the IIS guide.

How long does it take to renew an SSL certificate?

The answer depends almost entirely on validation level, not on the renewal mechanics:

• DV certificates — minutes. ACME issuance with certbot typically completes in seconds; a manual DV renewal is bounded by how fast you can satisfy the email, DNS, or HTTP challenge.
• OV certificates — usually a day or two, since the CA performs business verification on top of domain control.
• EV certificates — up to a week (sometimes more), because legal and organizational vetting involves humans and third-party records.

The takeaway: never start an OV or EV renewal the day before expiry. Begin OV at least a week out and EV two to three weeks out, so a validation hiccup doesn't run you past the notAfter date.

How often should you renew an SSL certificate?

You renew whenever the current certificate nears expiry — but that window keeps shrinking. Publicly trusted TLS certificates have dropped from years to a maximum of 398 days, and the CA/Browser Forum has set a path that takes the cap down to roughly 47 days by 2029. As lifetimes shorten, renewing by hand every few weeks stops being realistic.

That is why automation is now effectively mandatory rather than a nice-to-have. A 90-day Let's Encrypt certificate renewed by certbot's timer needs zero human attention; a 47-day cert renewed by hand is an outage waiting to happen. The practical rule: automate renewal wherever the CA supports ACME, and aim to renew at roughly two-thirds of the certificate's lifetime so there's always a generous buffer. The reasoning behind these caps is laid out in the validity period guide.

Verify after renewing

Renewal isn't done when the file lands on disk — it's done when clients see the new certificate. Confirm the live notAfter date advanced by querying the server itself, not the file:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates

notBefore=Jun  5 00:00:00 2026 GMT
notAfter=Sep  3 23:59:59 2026 GMT

If notAfter still shows the old date, the server is serving from cache — reload it. While you're there, confirm the served chain is complete (a renewed leaf with a missing or stale intermediate is a classic post-renewal break):

echo | openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null \
  | grep -E "s:|i:"

You should see the leaf followed by at least one intermediate. For more ways to read the live expiry, see how to check an SSL certificate's expiration date, and for the full set of inspection flags, the openssl reference. A neutral, outside-in view from the SSL check tool catches edge problems the server itself can't see.

Common pitfalls

A renewal that "didn't work" almost always traces to one of these:

• Renewed but never reloaded. The new cert is on disk; the running process still holds the old one in memory. Reload (don't just restart blindly) so the server reads the new files. This is the number-one cause of an "expired" site whose files look current.
• Incomplete chain after renewal. Installing only the leaf and forgetting the intermediates leaves clients unable to build a path to a trusted root. Browsers may paper over it via cached intermediates while strict API clients fail. See the certificate chain explained and install fullchain.pem, not cert.pem.
• Let's Encrypt rate limits. Scripting issuance in a loop, or retrying a broken renewal repeatedly, can hit the per-domain limit (currently 50 certificates per registered domain per week, with tighter duplicate-certificate limits). Use --dry-run, which runs against staging and never counts against the limit, to debug.
• Clock and DNS issues. A server whose clock is wrong can consider a freshly issued cert "not yet valid," and a stale DNS or CAA record can make the CA refuse to issue. Confirm time sync (timedatectl) and that your DNS validation records actually resolve before blaming the certificate.
• Already past expiry. If clients are already failing with cert_has_expired, renew immediately and reload — and treat the missed renewal as a monitoring gap to close, not just a one-off fix.

For the bigger picture on staying ahead of every cert you run, the SSL certificate monitoring complete guide covers the checks worth automating alongside renewal.

Monitor it automatically

Automated renewal still fails quietly — a deploy hook that didn't fire, an imported ACM cert nobody flagged, a reload that was skipped. SSLNudge checks your certificates every day and alerts you well before expiry, so a stalled renewal surfaces as a notice instead of an outage. Add your domains once and let the daily check confirm every renewal actually went live. Sign in to start monitoring.