Many of my friends run small businesses. Some own restaurants. Their websites show a menu, hours, a phone number, and directions. Others run small garages and use a website to tell customers about oil changes, inspections, tires, or repairs.
They are busy serving customers, managing employees, ordering supplies, and keeping the doors open. They are not trying to become website-security specialists.
Some have told me they pay about $20 a year for basic hosting. Then a free security certificate fails to renew, browsers warn customers away, and fixing the site becomes a $150 support call. I also know people who paid $50 or more for a commercial certificate because the available choices were not clear.
Those numbers are personal examples from people I know. They are not market averages. Hosting, certificate, and support prices vary, and a support call may involve much more than installing a file. Someone may have to recover access, work out where the domain and site are hosted, reissue the certificate, install it, and test the result.
What the certificate does
A TLS certificate helps a browser authenticate the website it reached and establish an encrypted HTTPS connection. If the certificate expires, a site that has not otherwise changed can suddenly present a security warning. A customer looking for tonight's menu or tomorrow's inspection may simply leave.
Certificate lifetimes are also getting shorter. The current industry maximum is 200 days. It falls to 100 days for certificates issued on or after March 15, 2027, and to 47 days on or after March 15, 2029 (https://cabforum.org/working-groups/server/baseline-requirements/requirements/).
Let's Encrypt currently uses 90 days for its default classic profile and 45 days for its optional tlsserver profile (https://letsencrypt.org/ca/docs/profiles/). Shorter lifetimes limit how long a compromised certificate remains useful. They also make calendar reminders and other manual renewal habits less dependable.
Where renewal fails
ACME already provides a standard way to prove control of a domain and automate certificate issuance (https://www.rfc-editor.org/info/rfc8555/). Mature ACME clients exist for common servers and operating systems, and Let's Encrypt advises against manual renewal workflows because they increase the chance of a missed renewal (https://letsencrypt.org/docs/client-options/).
The remaining trouble is often the handoff around that automation.
The domain may be registered with one company, DNS may be managed somewhere else, and the website may sit on an old hosting account with a different control panel. The person helping the business might be able to upload files but lack permission to activate a certificate. A client can successfully obtain a new certificate while the public site continues serving the old one.
Every component can appear healthy from its own control panel while the customer still sees a warning. That is the part I want to make easier.
What I want CertBaton to handle
CertBaton is the working name for an open-source project I am exploring. The name fits because many failures happen while responsibility passes from the certificate authority to the ACME client, the host, and the person trying to confirm that the change worked.
I do not want to invent another certificate authority or replace mature ACME clients. CertBaton should begin by checking whether the hosting platform already handles renewal correctly. If it does, the right answer may be to leave it alone and monitor the public site.
When native automation is missing, the project could coordinate an established ACME client with the host's supported deployment method. After renewal, it should connect to the public address and confirm which certificate customers are actually receiving. If something fails, the person helping the business needs a useful explanation, not a green check beside only one step of the process.
That work also has to respect security boundaries. A simple tool should not demand broad DNS or hosting credentials when a narrower permission will do. It should be clear about what it can change, what it cannot verify, and when a person needs to step in.
I am still early in this project, and I would rather learn from real failures than pretend one connector will work for every host.
If you maintain a small website for a friend, family member, or local business, where does certificate renewal usually break?
Also available on LinkedIn