Getting TLS Certificates Without Installing Anything: acme.sh in Pure Shell
You've probably been there: you need a TLS certificate for a server, a container, or some odd appliance, and the "official" ACME clients want you to install a package manager dependency, pull in a runtime, or drag along an entire ecosystem of libraries. What if the client itself was just a shell script? That's the premise behind acme.sh, an ACME protocol client written purely in shell.
What It Does
acme.sh implements the ACME protocol—the same protocol behind Let's Encrypt and other certificate authorities—entirely in shell script. It's not a wrapper around a compiled binary or a thin shell frontend for a Python or Go library. The whole client is shell.
The README describes it plainly as "An ACME Protocol Client Written Purely in Shell." That single sentence is doing a lot of work: it means the tool runs wherever a POSIX-ish shell runs, without a language runtime sitting underneath it.
The CI badges in the README tell you how seriously the project takes that portability claim. The build matrix covers FreeBSD, OpenBSD, NetBSD, macOS, Ubuntu, Windows, Solaris, DragonFlyBSD, MidnightBSD, GhostBSD, OmniOS, OpenIndiana, Tribblix, Haiku, Hurd, and OpenEuler. That's not a casual list—that's a project that treats "runs on your weird operating system" as a first-class feature rather than an afterthought.
Why It's Cool
Zero runtime dependencies changes the deployment story. Most certificate automation assumes you can install a package. But plenty of environments don't have a package manager you control, or they're running an OS where the "supported" client was never built. A pure shell client sidesteps all of that. If you can run a shell script, you can request a certificate.
The platform coverage is genuinely unusual. Look at that badge list again. Solaris and its descendants. The BSDs, including the more obscure ones like MidnightBSD, GhostBSD, and Tribblix. Haiku. GNU Hurd. OpenEuler. These are exactly the environments where mainstream tooling tends to lag or never arrive at all. The project's CI isn't just testing Linux and calling it done—it's actively verifying that the client works across a huge spread of Unix-like systems.
Windows is in the matrix too. That's worth pausing on. A shell-based ACME client with a Windows CI job suggests the project is thinking about environments that aren't the typical Linux server, without asking those users to adopt a completely different tool.
Shell as a constraint, not a limitation. There's a certain kind of engineering discipline in choosing the most boring, most universally available tool for the job. Shell is everywhere. It's inspectable—you can open the script and read exactly what it's doing. There's no compiled artifact to trust, no supply chain of transitive dependencies to audit. For a tool that handles private keys and talks to certificate authorities, that transparency has real value.
It fits the automation grain. Certificate issuance and renewal are inherently scheduled, unattended operations. A client that's a single script drops naturally into cron jobs, init scripts, and minimal container images without adding a runtime layer to your attack surface or your image size.
How to Try It
The README is the source of truth here, and it's worth reading in full at the repository. The general shape of getting started looks like this:
- Head to the repository: https://github.com/acmesh-official/acme.sh
- Follow the installation instructions in the README for your platform. Because the project supports such a wide range of systems, the README is the right place to find the method that matches your environment rather than assuming one universal command.
- Once installed, the client handles the ACME flow—issuing certificates and, as you'd expect from an ACME client, renewing them.
- Check the CI badges for your platform if you want confirmation that your specific OS is covered before you commit to it.
If you're evaluating it for a specific system, the fastest sanity check is to find your OS in that badge list. If it's there, the project has a test job for it, which is a meaningful signal.
Final Thoughts
acme.sh isn't trying to be the most feature-rich ACME client, and it isn't trying to win benchmarks. It's solving a narrower, more stubborn problem: getting certificates on systems where installing a conventional client is painful or impossible. If you're managing Linux servers with a normal package manager, you have plenty of options and this may not be the one you reach for first. But if you're dealing with a BSD, a Solaris derivative, Haiku, or some minimal environment where "just install the client" isn't a sentence that makes sense, a pure shell implementation is exactly the kind of pragmatism you want. It's the sort of project that quietly does one job across an absurd number of platforms—and that's worth knowing about.
Follow @githubprojects for more developer tools and open source projects.