SSL Certificate Renewal and Management Without Downtime

An expired SSL certificate is one of the most avoidable outages a website can have, and one of the most embarrassing. Visitors see a full-page browser warning, search crawlers back off, payment and login flows fail, and your support inbox fills up. Nothing about your content or servers changed; a date simply passed.

SSL certificate renewal used to be an annual chore that lived in one person’s calendar. That is changing fast. Certificate lifetimes are getting shorter, so the manual approach that worked at 12 months breaks at 90 days or less. This guide explains what is changing, how to choose and install certificates, how to automate renewal safely, and how to monitor so that you find out before your visitors do.

SSL, TLS and Certificates: The Short Version

People still say “SSL”, but the protocol in use today is TLS (Transport Layer Security). A TLS certificate does two things: it lets the browser confirm it is talking to the real owner of a domain, and it enables encrypted communication. A certificate authority (CA) signs the certificate after verifying that whoever requested it controls the domain, and sometimes more than that.

Every certificate has a validity period. When it ends, browsers reject it. Nothing else about your setup has to fail for the site to be effectively down for anyone who does not click through the warning, and most visitors will not.

For background on how the underlying protocol works, the MDN explanation of Transport Layer Security is a clear reference.

Why Renewal Is Getting More Frequent

For years, publicly trusted certificates could last up to 398 days. The CA/Browser Forum, the body that sets the rules browsers and CAs follow, has approved a step-down schedule that shortens maximum validity in stages, reaching 47 days by 2029. The intermediate steps arrive in 2026 and 2027. Check the current published schedule before you plan, because dates and details can be refined; the direction is not in doubt.

Free certificates from Let’s Encrypt have long been valid for 90 days by design, precisely to force automation. Its documentation explains the reasoning: shorter lifetimes limit the damage of a compromised key and make automation the only sensible option.

The practical consequence is simple. If your renewal process involves a person remembering to do something, it will eventually fail. The question is not whether to automate, but how to do it safely and how to know if automation quietly stops working.

Choosing the Right Certificate Type

All certificate types provide the same encryption. They differ in how much the CA verifies, what they cover and what they cost.

Domain validation is enough for most business sites

A domain validated (DV) certificate proves control of the domain and nothing more. Modern browsers no longer show a special “green bar” for organisation-validated or extended-validation certificates, so the practical benefit of paying extra for them is limited for most sites. They can still matter where a contract, audit or partner requires verified organisation details.

Wildcard versus individual names

A wildcard certificate covers every first-level subdomain (*.example.com). It is convenient when you run many subdomains, but the private key is then valid for all of them, so a leak has a wider reach. Wildcards from Let’s Encrypt require DNS validation, which needs API access to your DNS provider. Individual or multi-name (SAN) certificates are often the tidier choice when you have a handful of known hostnames.

How Domain Validation Works

Understanding validation explains most renewal failures.

• HTTP validation: the CA asks your server to serve a specific file at a well-known path on port 80. It works for individual hostnames, but fails if a firewall, redirect rule or CDN blocks that path.
• DNS validation: you publish a specific TXT record. It works for wildcards and servers not reachable from the internet, but requires automated DNS changes to be reliable.
• Email validation: some commercial CAs email an approval link. It suits manual issuance, but is a poor fit for automation.

If DNS is a mystery to your team, our plain-language guide to DNS for business owners is worth a read before you automate DNS validation.

Installing a Certificate Correctly

The certificate file alone is not enough. Servers must present the full chain: your certificate plus the intermediate certificate(s) that connect it to a root the browser trusts. A missing intermediate is the most common cause of “works in Chrome, fails in an API client” complaints, because desktop browsers can sometimes fetch missing intermediates and other clients cannot.

Checklist for a clean install

1. Generate the private key on the server (or in the platform) that will use it, and keep it out of email, chat and shared drives.
2. Serve the full chain file, not the leaf certificate alone.
3. Disable obsolete protocol versions. TLS 1.2 and 1.3 are the sensible baseline.
4. Redirect HTTP to HTTPS with a single 301, and make sure internal links, canonical tags and sitemaps use the HTTPS address.
5. Enable HSTS only after you are confident every subdomain is HTTPS-ready, because it tells browsers to refuse plain HTTP for the period you set.
6. Test the result with an external scanner such as Qualys SSL Labs and fix any warnings about chain or protocols.

Mixed content is the other classic post-install problem: a page loaded over HTTPS that pulls an image or script over HTTP. Browsers block or flag it, so search your templates and database for hard-coded http:// URLs after switching.

Automating Renewal Safely

Automation removes the human dependency, but it introduces its own failure modes. Design for them.

Use the ACME protocol

ACME is the standard that clients such as Certbot and acme.sh use to request and renew certificates automatically. Many hosting control panels, load balancers and CDNs also implement it. Where your platform offers managed certificates, using them is usually the lowest-maintenance route; the platform renews and deploys without you touching a shell.

Renew early, not at the last minute

Most ACME clients renew when roughly a third of the lifetime remains. Do not override that to renew closer to expiry. An early renewal leaves weeks to notice and fix a failure.

Reload the service after renewal

A frequent silent failure: the certificate file on disk is renewed, but the web server keeps serving the old one in memory until it reloads. Configure a deploy hook that reloads the service after each successful renewal, and confirm it ran.

Plan for validation to break

Firewall changes, a new redirect rule, a DNS provider API token that expired or a moved nameserver can all stop validation. Whenever you change how traffic reaches the server, re-run a renewal test. Certbot offers a dry-run mode that exercises the full process without issuing a certificate.

Keep private keys under control

Restrict file permissions, avoid copying keys between machines and rotate keys when staff with access leave. If a key might be exposed, revoke and reissue rather than waiting for expiry.

Monitoring: Finding Out Before Your Visitors Do

Automation without monitoring is a bet that nothing will ever change. Add a cheap safety net.

• Expiry alerts from outside: use an external monitor that checks the certificate your site actually serves and warns at 21, 14 and 7 days. Checking from outside catches the “renewed on disk but not loaded” problem.
• Certificate inventory: keep a simple list of every hostname with a certificate: main site, staging, mail, API, admin panels, client sites. Forgotten subdomains cause most surprise expiries.
• Multiple recipients: alerts should reach a shared mailbox or channel, not one person’s inbox. People go on holiday and leave companies.
• Test after infrastructure changes: moving hosts, changing CDN or updating DNS are the moments automation breaks.
• Log renewal outcomes: a record of each renewal makes debugging quick when one does fail.

Certificate monitoring belongs inside your broader uptime routine. Our article on uptime, backups and monitoring covers what else to watch, and server security hardening covers protocol and key hygiene in more depth.

What to Do When a Certificate Has Already Expired

1. Confirm the cause. Check expiry with a scanner and check the server, since a renewed certificate might not be loaded.
2. Renew or reissue. With ACME, run the renewal manually and read the error output; validation failures are typically explicit.
3. Deploy and reload. Install the full chain and reload the service.
4. Verify externally. Load the site from a different network and device, and test with a scanner.
5. Look downstream. Check any services that consume the certificate: APIs, mobile apps, webhooks, email gateways.
6. Write a short post-mortem. Why did automation not catch it? Add the missing alert or inventory entry.

Search engines typically tolerate short outages without lasting damage, but a repeated pattern of errors is worse. The faster you recover, the less it matters.

Managing Certificates Across Many Sites

The risk multiplies when you look after more than one domain. Agencies, publishers and shops with regional storefronts often end up with dozens of certificates issued at different times by different people. A few habits keep that manageable.

• Standardise the method. Pick one issuance approach per hosting platform, so every site renews the same way and one runbook covers all of them.
• Record ownership. Note who registered each domain, which DNS provider holds it and where the certificate is deployed. When validation fails, this saves an hour of detective work.
• Review quarterly. Once a quarter, compare the inventory with what is actually live, and remove certificates for domains you have retired.
• Test staging separately. Staging and preview environments are frequently forgotten, and an expired certificate there blocks clients from approving work.

Who Should Own Certificate Management

Ownership is the real fix. Someone must be named as responsible, with a backup, and the responsibility should sit within a broader maintenance routine rather than a lone technical task. For small teams without in-house infrastructure staff, this is a natural item for an IT provider: our server administration service and IT maintenance contracts include certificate inventory, renewal automation and monitoring, so expiry dates are never left to memory. If you are unsure where to start, get in touch.

Frequently Asked Questions

How often do I need to renew an SSL certificate?

It depends on the issuer. Free Let’s Encrypt certificates last 90 days and are renewed automatically. Publicly trusted certificates from commercial CAs are moving to progressively shorter maximum lifetimes, so plan on automated renewal regardless of the vendor.

What happens if my SSL certificate expires?

Browsers show a full-page security warning and most visitors leave. APIs, apps and webhooks that validate certificates fail outright, and search crawlers may report errors until the certificate is replaced.

Is a free certificate as secure as a paid one?

For encryption, yes. Free domain-validated certificates use the same protocols and key strengths. Paid certificates add things such as organisation validation, support and warranties, which matter only in specific cases.

Why is my browser still showing the old certificate after renewal?

Usually the web server has not been reloaded, so it keeps serving the old certificate from memory. Add a deploy hook that reloads the service after renewal, and check with an external scanner.

Do I need a wildcard certificate?

Only if you run many subdomains and want a single certificate for all of them. A wildcard needs DNS validation and widens the impact of a key leak, so a certificate listing your specific hostnames is often safer and simpler.

How can I monitor certificate expiry?

Use an external monitor that checks the certificate your site actually serves and alerts several weeks in advance to a shared mailbox. Combine it with a maintained list of every hostname you run.

The Bottom Line

SSL certificate renewal is no longer an annual calendar reminder. With lifetimes shrinking, the only reliable setup is automated issuance, automatic service reload, external expiry monitoring and a complete inventory of every hostname you run. Choose the simplest certificate type that meets your needs, install the full chain, test after every infrastructure change and make sure a named person owns the process. Do that and an expiry date becomes a non-event instead of an outage.