FreeCert: a lightweight ACME management module for shared hosting and cPanel

Client dev
1

Hi everyone,

I’ve been building a lightweight module for a very specific problem: managing ACME certificates on shared hosting and cPanel environments without repeating the same shell workflow over and over.

It’s called FreeCert, and the goal is not to replace existing ACME clients, but to make them easier to use in constrained real-world hosting setups.

The project is available at certificates.biz.

FreeCert is a lightweight PHP module that can be installed directly on a website and used to manage certificate issuance and renewal through an existing ACME workflow, currently based on acme.sh.

This is not a new CA, and it is not meant to compete with mature ACME clients.
It is a thin operational layer built for environments where users technically can issue certificates, but the process is still too manual, fragmented, and repetitive.

Why I built it

In many shared hosting environments, users often have just enough access to make ACME work, but not enough tooling to make it convenient.

That usually means:

  • running commands manually
  • repeating the same steps every few months
  • copying certificate files by hand
  • managing multiple small sites with no reusable interface
  • depending too much on terminal access for routine operations

I wanted to explore whether a small installable module could make this workflow cleaner and more reusable.

What FreeCert does

FreeCert is installed directly on the target website and works on the current site/domain where it is deployed.

The current design includes:

  • lightweight PHP module
  • built for shared hosting and cPanel-like environments
  • local issuance and renewal using acme.sh
  • current domain detection from the installed site
  • local logs
  • update checks for the module itself
  • semiautomatic certificate workflow
  • no arbitrary free-form domain input for certificate issuance

Authorization model

One of my main design goals was to avoid creating a generic public “issue certificates for anything” tool.

So the module uses an external authorization layer called Librya.

The workflow is:

  1. the user authenticates
  2. the module detects the current domain
  3. the module checks whether that domain is registered and approved for that user
  4. only then are SSL actions allowed

This keeps the module tied to the real site where it is installed, instead of turning it into an open certificate panel.

What I’d love feedback on

I’d really appreciate technical feedback on a few points:

  1. Does this architecture make sense for shared hosting and cPanel use cases?
  2. Are there obvious security pitfalls in using a lightweight management layer around an existing ACME client workflow?
  3. Does this feel like a useful niche for people managing multiple small websites on constrained hosting?
  4. If the project becomes mature enough, would it make sense to present it as a niche ACME management option for this type of environment?

I’m not trying to replace mature ACME clients.

The goal is to make certificate management more practical in a specific class of hosting environments where people often end up doing everything manually even when ACME support is technically available.

If useful, I can also share more details about:

  • module structure
  • authorization flow
  • update mechanism
  • local execution flow
  • current UI and workflow decisions

Thanks in advance for any feedback.

2

Welcome to the Let's Encrypt Community! :slightly_smiling_face:

So you built a layer on top of acme.sh? :thinking:

Could have its uses.

I do already offer CertSage for this niche as a freestanding ACME client that has been proven and trusted for many years that offers fully-automated renewals.

3

Thanks Griffin, that makes sense.
:waving_hand:
Yes, it’s essentially a lightweight layer built around acme.sh, but with a narrower goal.

I’m not really trying to replace established ACME clients like CertSage. The idea is more to make Let’s Encrypt easier to use in a specific hosting/module context for users who prefer a very simple integrated workflow.

So I’d describe it as complementary rather than competing.

4

FWIW, my immediate feedback for you from my experience in this area, having not reviewed your code, is:

  • Automatically detecting (sub)domain names in cPanel to cover with a certificate is quite challenging because cPanel is not aware of the actual subdomain names of any domain name. It maintains a set of "assumed" subdomain names that it assumes exist for its own purposes. This set never includes subdomains a user has created for their own purposes.
  • Why is an authorization model needed in a shared hosting environment where there's typically only one user? Is this workflow accessible from the internet?
  • Does the module update check actually update the module without user interaction? If so, this could be a concerning security and operational risk that could break a user's setup since your module would likely not have any awareness of the particularities of users' setups.
  • Shared hosting users using panels for configuration are often not especially technically savvy and will likely not be comfortable with installing and configuring such "workflows", which makes "automatic" decisions outside the users awareness a blessing and a curse. You'll need to be ready to support your work. :slightly_smiling_face: We regulars in this community try to be as helpful as we can for help-seekers, but we must balance the burden of support placed upon us by the projects of others.
5

Thank you, these are very useful points.

You are absolutely right about subdomain detection. In practice, cPanel can only expose a limited/assumed set, so my module should not pretend to discover every user-defined subdomain automatically. I will make that clearer and keep automatic coverage conservative, with user review where needed.

Regarding the authorization model: the main idea was not multi-user separation in the classic sense, but adding a safety layer before sensitive actions are executed inside the hosting environment. That said, I understand your point that in a typical shared-hosting context this can easily become unnecessary complexity, so I may simplify that part.

The workflow is intended to stay inside the hosting environment and not be openly exposed as a public internet-facing service.

About updates: I agree this is one of the most sensitive areas. My intention is not to push blind unattended changes that could break user setups. I am already reconsidering this part so that update checks can notify the user first, and any actual module update can remain explicit, reviewable, and user-initiated.

And yes, I fully agree with your final point: simplicity is critical here. If the target users are not highly technical, then the module should avoid hidden automation, avoid surprising behavior, and stay as transparent as possible. I also understand that if I publish something in this area, I need to be ready to support it myself and not offload that burden onto the community.

I appreciate the candid feedback. It is genuinely helpful for shaping the project in a safer and more realistic way.

6

It's interesting and we''ll see many more such ACME tools now that they are much easier to generate with coding agents.

I've had a quick look at the code and my main impression was that if you are technical enough to use all this then you probably already have certs sorted out, but you'll know better than me if there is a market for this solution.

7

That is a fair point.

I agree that coding agents will lead to many more ACME tools being created. But I also think this is exactly the kind of area where AI can help you move faster while still making it very easy to make a mess if you do not understand the underlying logic.
With certificates and shared hosting workflows, not knowing what you are doing can quickly create confusion, bad automation, or broken setups. So AI helps, but only in the hands of someone who understands the operational risks.
And yes, you may be right that highly technical users already have this solved. My question is whether there is still a useful middle ground for users who want something simpler and more integrated.