SSL Certificate Renewal for Small Businesses
Plan certificate renewal, test validation and deployment separately, protect DNS access and monitor the certificate actually served by your site.

Automate renewals with an ACME client where your certificate authority (CA) supports it. Set up Certbot or a similar tool with a deploy hook to renew certificates and, where required, reload the services that use them. Keep monitoring expiry and failed renewal attempts. Where ACME is not available, generate a fresh certificate signing request (CSR), submit it to your CA, complete validation, install the issued certificate and reload your services. Whichever path you take, always check the live endpoint afterwards to confirm the new certificate is actually being served.
TL;DR:
- Check renewal timing, validation access and deployment for your actual server. A deploy hook is needed only where the chosen installer or service requires it.
- Renewal timing depends on the certificate lifetime, client and CA. Start validation early and leave time to resolve a failed attempt.
- Manual renewals for non-ACME CAs involve generating a new CSR, revalidation, and installing fresh certificates, which must be done well before expiry.
- Where a reload is required, verify it succeeds and check the certificate served by the live endpoint. Keep expiry alerts and renewal logs.
- Using ARI support in ACME clients can help avoid rate limits during mass certificate revocations.
Table of Contents
- Quick checklist: what to do when a certificate is close to expiring
- Automated renewal with ACME: setup, testing and reliability
- Manual renewal with paid CAs: CSR, validation and issuance
- Install the new certificate, reload services and verify it’s live
- Diagnose and fix common renewal problems
- How long certificates last and how to schedule renewals
- Our take: automate first, call in help when complexity grows
- Getting SSL renewal sorted without the recurring hassle
- FAQ
- Sources
Quick checklist: what to do when a certificate is close to expiring
Before anything else, check the certificate’s notAfter date and issuer, then confirm whether your CA supports ACME.
- Run
openssl x509 -enddate -issuer -noout -in cert.pemto see the exact expiry date and issuer. - If ACME is supported, confirm your client is installed, check the renewal timer is active, and run a dry run before trusting it
- If ACME is not supported, generate a new CSR, submit the renewal request, and start validation early, particularly for OV or EV certificates.
- Once the new certificate is issued, install it everywhere it is needed, reload every affected service, and verify from an external client.
- A missed reload can leave a service presenting the old certificate even after a new file has been installed.
- Treat every renewal as a fresh certificate issuance, not an extension of the old one, according to Certbot’s documentation.
Automated renewal with ACME: setup, testing and reliability
For domain-validated (DV) certificates, ACME automation can reduce repetitive renewal work, but it still needs validation, deployment and expiry monitoring. Check the renewal timer supplied by your Certbot installation before adding a job. Many installations already schedule renewals. Certbot 4.0.0 and later normally consider a certificate due when less than one-third of its lifetime remains; certificates lasting ten days or less use a half-lifetime threshold. Use the behaviour documented for your installed version and CA rather than a fixed calendar reminder.
- If you administer the server, follow the current official installation instructions for your operating system and web server. On managed hosting, first check the provider’s existing certificate automation; do not install a second renewal system without its agreement.
- Choose your validation method: HTTP-01 if your web root is reachable on port 80, or DNS-01 if you need wildcard support or your server sits behind a firewall.
- Confirm the systemd timer or cron entry is active so renewal runs automatically.
- Add
--deploy-hookpointing to a script that reloads nginx, Apache or your reverse proxy once renewal succeeds. - Run
certbot renew --dry-runto test renewal validation against staging. Deploy hooks do not run by default. After reviewing and authorising the hook’s effects,certbot renew --dry-run --run-deploy-hooksalso runs applicable deploy hooks using the current active certificate. Hooks can reload real services; a successful dry run does not prove that a later production certificate was installed or served. Check the public endpoint separately after an actual renewal.
Pro Tip: Keep the deploy hook scoped to the services that actually use this certificate, and validate their configuration before a reload. Check hook errors and the public certificate independently of Certbot’s renewal result.
Beyond the basic renewal loop, ACME Renewal Information (ARI) matters for anyone running automation at scale. The IETF published ARI as RFC 9773, which lets a CA suggest an optimal renewal window to the client rather than leaving every certificate on the same fixed schedule. This is particularly useful if a CA needs to revoke certificates in bulk: ARI-aware clients get an early signal to renew ahead of the rest of the queue, and Let’s Encrypt exempts qualifying ARI replacement orders from its rate limits; following a suggested date alone is not sufficient. If you manage more than a handful of certificates, check whether your ACME client supports ARI and enable it.
For Let’s Encrypt, qualifying ARI replacement orders can be exempt from rate limits; other CAs and non-ARI orders have their own rules, as described by Let’s Encrypt.
Wildcard certificates add a wrinkle: they require DNS-01 validation, which means your ACME client needs a DNS plugin with API access to your provider, or a delegated _acme-challenge CNAME record. A CNAME delegates validation to another zone; that target still needs the required TXT updates. Use narrowly scoped DNS credentials, protect them outside public files and verify that your client supports the chosen delegation. Certbot’s manual plugin requires authentication hooks for automatic renewal.
Manual renewal with paid CAs: CSR, validation and issuance
When your CA or hosting platform does not provide a supported automated renewal route, follow its renewal, CSR and validation process. OV or EV alone does not determine whether automation is available.
- Follow your CA and server’s current key and CSR requirements, including every required domain name. Protect the private key, keep it out of email and tracked files, and confirm the issued certificate matches it.
- Submit the CSR through your CA’s portal as a renewal request, then be ready to revalidate domain or organisation ownership, since renewal does not skip this step.
- For OV certificates, expect the CA to re-check business registration details; EV certificates typically require supporting documents and a more thorough review.
- Start early enough to meet your CA’s current validation requirements and resolve problems. Do not assume a universal DV, OV or EV turnaround or leave renewal until the last day.
- Once issued, download both the leaf certificate and the intermediate chain supplied by the CA, ready for installation.
Every renewal, DV, OV or EV, produces a brand-new certificate rather than extending the life of the old one, so the install and verification steps below apply regardless of validation type.
Install the new certificate, reload services and verify it’s live
Renewal can fail during validation, issuance, installation or deployment. Verify each stage.
- Place the full chain (leaf certificate plus intermediates) and the matching private key in your server’s certificate directories, then update the relevant directives in your nginx, Apache or IIS configuration if the file paths have changed.
- Trigger a reload, not just a save: nginx, Apache and most reverse proxies keep the old certificate loaded in memory until the process is told to reload or restart.
- Run
openssl s_client -connect yourdomain.com:443 -servername yourdomain.comand check thenotAfterdate has moved forward and the chain is complete; an online checker gives a second confirmation from outside your network. - If your site sits behind a CDN or load balancer, or on managed hosting, check which certificates that provider manages automatically and which you own. The public edge can terminate TLS separately from your origin; inspect both where applicable before changing a provider-managed certificate.
Pro Tip: Where your server requires a reload, a tested deploy hook can handle it after successful renewal. Endpoint monitoring checks whether deployment actually worked.
Diagnose and fix common renewal problems
Most renewal failures fall into a handful of predictable categories, so work through them in order rather than guessing.
- Check whether the server process was actually reloaded after installation; if not, reload it and recheck the live endpoint before looking anywhere else.
- Confirm the installed file includes the intermediate certificates, not just the leaf: install
fullchain.pemrather thancert.pemalone, since a missing intermediate is a frequent cause of browser warnings even when the leaf is valid. - For ACME failures on HTTP-01, confirm port 80 is reachable from the public internet; for DNS-01, check your DNS API credentials are current and that propagation has finished before the challenge runs.
- If you hit a CA rate limit, check whether your client supports ARI-suggested renewal windows, which can carry an exemption, follow the CA’s Retry-After instruction instead of repeatedly forcing renewal; contact CA support if a limit is blocking an urgent renewal.
- Test validation in staging, test deployment separately with its service effects understood, and review logs. Protect credentials and private keys when sharing error details; Certbot’s renewal documentation show the same handful of causes recurring.
Pro Tip: Keep a plain-text log of every renewal attempt, including timestamps and the command used, so a recurring failure pattern becomes obvious rather than a fresh mystery each time.
Use currently supported validation methods and the CA’s official documentation. A proposed challenge method is not evidence that your present client or CA supports it.
How long certificates last and how to schedule renewals
Certificate lifetimes have been shrinking for years under CA/Browser Forum rules, and the trend is continuing, so renewal scheduling needs to assume shorter windows rather than longer ones going forward.
| Certificate type | Typical validation lead time before renewal |
|---|---|
| DV (domain validated) | Follow the client and CA renewal window; allow time for failed validation |
| OV (organisation validated) | Confirm the CA’s organisation validation requirements and lead time |
| EV (extended validation) | Confirm the CA’s extended validation requirements and lead time |
The CA/Browser Forum’s baseline requirements limit publicly trusted TLS certificates issued from 15 March 2026 to before 15 March 2027 to 200 days. The scheduled maximum is 100 days from 15 March 2027 and 47 days from 15 March 2029; CAs may issue shorter certificates, which is why relying on calendar reminders alone becomes riskier each year.
Follow your installed client’s supported renewal logic or the CA’s supported ARI process. Do not assume one timing rule fits every certificate or guarantees renewal. Keep DNS validation records in place and current if you rely on DNS-01 for automated renewal, and set up a monitoring alert as a backup in case the automation itself fails silently.
Our take: automate first, call in help when complexity grows
For a small business running one or two sites, supported automation can reduce repetitive work and missed-renewal risk. Keep an accountable owner, expiry alerts, renewal logs and public endpoint checks. A successful dry run is useful evidence, not a guarantee of future renewal or deployment.
The calculation changes once you are juggling multiple certificates, wildcard domains needing DNS API access, or a small team with no spare time to debug a failed cron job. At that point, review who is responsible, what access is authorised and whether a scoped setup or investigation would help. Cost and support scope depend on the actual environment.
hostme.ie
Getting SSL renewal sorted without the recurring hassle
We help set up ACME automation properly, including DNS API integration for wildcard certificates, dry runs against staging, and deploy hooks that reload your server the moment a renewal succeeds. For businesses on managed hosting, certificate installation and rotation can be handled as part of keeping the site running, not as a separate fire drill every few months.
- Setup, testing, ongoing monitoring and recovery responsibilities should be agreed for the actual hosting environment. No uninterrupted-renewal guarantee is implied.
- Manual CSR and validation processes for OV or EV certificates where ACME isn’t an option can be handled.
- The live endpoint should be checked after every install to confirm the chain is complete and the certificate is actually being served.
If renewals keep landing on your desk at the worst possible time, our Security & SSL service is built to take that off your plate, and it pairs naturally with our web hosting if you’d rather have one place handle both. Message us on WhatsApp to discuss your current setup and agree any paid assessment or project scope.
FAQ
How often do SSL certificates need to be renewed?
It depends on the certificate’s validity period, which has been shrinking under CA/Browser Forum rules. Most DV certificates from Let’s Encrypt are renewed automatically well before expiry, while other CA and certificate products have their own validity and automation options. Monitor the expiry of the certificate actually served by your site.
How do I renew my SSL certificate?
If your CA supports ACME, an appropriately configured client can handle validation and renewal. Installation depends on the selected installer or deployment hook; verify the public endpoint separately, as Certbot’s own documentation explains. Otherwise, generate a new CSR, submit it through your CA’s portal, complete validation and install the issued certificate manually.
What will the validity period of an SSL certificate be in 2026?
For publicly trusted TLS certificates issued from 15 March 2026 to before 15 March 2027, the maximum is 200 days. Certificates issued before that interval have their own applicable limit, and a CA may issue shorter certificates. Check the current CA/Browser Forum requirements and your certificate’s expiry date.
What happens if I don’t renew my SSL certificate?
Visitors will see browser warnings telling them the connection isn’t secure, and some browsers or automated clients may refuse the connection. Do not bypass a certificate warning; have the responsible provider or administrator investigate and renew it safely.
Sources
- Certbot user guide
- Let’s Encrypt challenge types
- Let’s Encrypt rate limits and ARI renewals
- CA/Browser Forum TLS Baseline Requirements


