Job tls-certbot-auto-renewal-repair-self-managed-server · revised 11 October 2026
Repair automatic certificate renewal on a server you manage yourself
On a server you run, Let's Encrypt renewal is repaired so a dry run passes, the schedule is confirmed, the web server reloads the new certificate, and an expiry alert you own is tested.
You might be seeing
- Browsers show an expired-certificate warning on a site you run yourself
- The renewal command fails, or succeeds but the site still serves the old certificate
- Nobody can say what schedule runs the renewal, or whether it runs at all
No passwords, keys, card details or admin invites needed to start.
What usually happened
Renewal on a self-managed server can fail in several separate places: the challenge cannot reach port 80, a redirect or firewall rule blocks it, DNS no longer points at the server, a hook does not reload the web server, the scheduled job is missing, or repeated failed attempts hit a rate limit. A certificate that renewed on disk is not the one visitors receive until the server reloads.
Who it’s for: A founder or developer who runs their own Linux server, issued a free certificate with certbot or a similar client once, and found that renewal fails or the site still serves an old certificate.
Usually starts when: The certificate expired, a renewal error appeared in a log, or an expiry warning arrived and nobody knows whether renewal is scheduled.
The result: On one server the certificate for the named hostnames validates over the challenge method in use, a renewal dry run that includes the reload hook passes, the schedule that runs renewal is identified and enabled, the web server serves the renewed certificate after a reload hook, and an expiry alert that runs outside the server, in an account or on a machine you own, reaches you in a test.
Check whether this job fits
Four checks that decide whether this fixed job fits. Your answers stay on this page unless you choose to email them.
Checks you can run yourself
List the certificates certbot manages
Run on the server. It only reads and shows expiry dates, names and paths.
sudo certbot certificatesLook for: The expiry date of each certificate, and whether the names are the ones you serve. An expired or soon-to-expire date means renewal has not worked.
See what schedules renewal
Run on the server. It lists timers and does not change anything.
systemctl list-timers | grep -i certbotLook for: A certbot timer with a next run time. No line may mean a cron job runs it, or that nothing does.
What you get
- A cause statement with the log lines or command output that show it
- The changed configuration or hook, the dry-run result and the identified schedule
- The served-certificate check from outside, and the expiry alert settings or script with the result of its test
Included
- One server and up to three hostnames on one certificate lineage, issued by Let's Encrypt with certbot or a compatible client
- Diagnosis of the challenge path (port 80, redirects, firewall, DNS), the renewal configuration, the scheduled job and the reload hook
- The smallest fix for the cause found, and a renewal dry run against the staging server
- An outside expiry check that emails a named address, run from a monitoring account or a machine that you own and that is not this server, tested with a lowered threshold. It needs no account in our name. If you already have the website monitoring job for this hostname, that certificate alert is checked instead of building a second one
Not included
- Shared or managed hosting with a control panel: that is the expired-certificate job for managed hosts
- Wildcard certificates that need DNS provider API access, unless you already run the DNS-based challenge and want it repaired
- Extended-validation or organisation certificates bought from a seller
- Web server hardening or TLS protocol and cipher review
- Any guarantee that future renewals succeed
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The renewal dry run completes without error for every name in scope, using the staging server.
Evidence: The dry-run output.
sudo certbot renew --dry-runThe handover identifies what runs renewal (a timer or a scheduled job) and the command shows it enabled with a next run time.
Evidence: The timer or scheduled-job listing.
After a reload, the certificate served from outside for each hostname is valid, covers the name and has an expiry date later than before the repair.
Evidence: Certificate details from outside before and after.
echo | openssl s_client -connect yourbusiness.co.uk:443 -servername yourbusiness.co.uk 2>/dev/null | openssl x509 -noout -datesThe reload hook reloads only the named web server, and a dry run that also runs deploy hooks shows it was called, because by default a dry run does not run deploy hooks.
Evidence: The hook file and the dry-run output with the hook's execution. The web server reloads during this run, so it happens in the agreed window.
sudo certbot renew --dry-run --run-deploy-hooksAn outside expiry alert, lowered for the test so that it fires, reaches the named address, and it runs from the account or machine you named, not from this server.
Evidence: The alert settings, where it runs, and the received test message.
echo | openssl s_client -connect yourbusiness.co.uk:443 -servername yourbusiness.co.uk 2>/dev/null | openssl x509 -noout -checkend 1209600
Sign-off. You sign off when the dry run passes, the schedule is identified, the served certificate is checked from outside and the alert test arrives. Payment follows sign-off.
If it fails. If the dry run does not pass or the served certificate is wrong after the agreed fix, you do not pay for this fixed scope and you keep the cause statement. If the cause is outside the server, such as a provider firewall or the domain, we say so with the evidence.
When it fits, and when we stop
It fits when
- You have administrator access to the server that holds the certificate, or can run commands that we send
- The hostnames are public and the server is the intended destination of their DNS records
- You can tell us which challenge method was used when the certificate was issued, or the renewal configuration shows it
- A reload of the web server is allowed in an agreed window
We stop and tell you if
- The domain itself has expired or is held by someone who will not change DNS
- Port 80 cannot reach the server and the DNS-based challenge is not an option you can operate
- There are signs of compromise, such as redirects to other sites
- The certificate is not from Let's Encrypt-style automation but is a purchased one managed by someone else
What could go wrong
Each changed file or rule is listed with its previous contents. Restoring them returns the server to its earlier configuration. The dry run uses the staging server and does not replace the live certificate.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Repeated live renewal attempts while debugging hit a rate limit and block issuance. | Use the staging server and the dry run for every test. Let's Encrypt documents separate limits for failed validations and for repeated certificates. |
| A change to a redirect or firewall rule breaks the site or opens a port that was closed. | Change one rule at a time with an existing session kept open and the provider console at hand, test from outside after each, and let the reviewer check the final rule list. |
| The certificate renews on disk but the web server keeps serving the old one. | Test a deploy hook that reloads the server, and verify the certificate served from outside, not the file on disk. |
An independent reviewer checks that no firewall or redirect change opens more than the challenge needs, that the reload hook only reloads the named web server, and that no credential appears in the handover.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the hostnames, the web server, the challenge method and the test window in writing
- Read the certificate list, the renewal configuration and the last renewal log, and test the challenge path from outside
- Name the cause: challenge reachability, DNS, redirect, firewall, hook, schedule or rate limit
- Prepare the smallest fix and test renewal with the dry run against the staging server
- Independent review, especially any firewall, redirect or hook change
- Your administrator applies it with an existing session kept open and the provider console at hand, and reloads; we check the certificate served from outside and set up and test the expiry alert where you chose to run it
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Hosting, platform and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
To have certificates, packages and services reviewed each month on this server, ask about the monthly server patch and review service.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Certbot's documentation describes the renewal dry run, hooks and how to find the scheduled job; a developer comfortable with the command line can follow it. eff-certbot.readthedocs.io
- Let's Encrypt explains each challenge type and its requirements, which helps you see which one your server can use. letsencrypt.org
Questions
Is this the same as the expired-certificate job for managed hosting?
No. That job is for a host with a control panel. This one is for a server you run yourself, where the cause can be a firewall, a redirect, a hook or a missing schedule.
Will it renew by itself from now on?
We test the dry run and the schedule. A dry run passing today does not guarantee every future renewal, which is why the outside alert is part of the job.
Do you need my private key?
Never. We need command output and redacted configuration.
What if I use a CDN in front of the server?
It can change which certificate visitors see and how the challenge arrives. Tell us in the enquiry so we scope it correctly.
Do I need a monitoring account in your name for the expiry alert?
No. The alert runs in an account or on a machine you own, other than the server being repaired. If you already have the website monitoring job for this site, its certificate alert is used and this job checks that it reaches the right address.
Send an enquiry
Send us
- The hostnames, the web server (for example nginx) and the date the warning started
- The last renewal error text, with account details removed
- Whether DNS, a firewall, a CDN or a redirect changed recently
- Do not send private keys, account files or server logins in the first enquiry
Later, once you agree
- The output of the certificate list and renewal dry-run commands, or a time-limited administrator account that you create and revoke
- The renewal configuration for the certificate, with any API credentials removed
- The address for the expiry alert, the account or machine you own where the check will run, and the window for a web server reload
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You own the server, the domain and the certificate account. We read command output and redacted configuration, prepare the fix and hand it to your administrator, or work through a time-limited account that you create and revoke, agreed in writing. We never ask for private keys or DNS provider credentials in the first enquiry.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “tls-certbot-auto-renewal-repair-self-managed-server” as the subject.