Hysen Labsacme.sh
A pure Unix shell script ACME client for SSL / TLS certificate automation
acme.sh manages certificates with nothing but shell
A pure Unix shell client for the ACME protocol that issues and renews SSL and TLS certificates, works with Bash, dash, and sh, and needs no Python and no root access. GPL-3.0.
A single script and nothing else
Most certificate automation tools lean on a language runtime or a pile of dependencies. acme.sh takes the opposite route. It is a pure Unix shell script that implements the ACME client protocol for SSL and TLS certificate automation, and the feature list in the README emphasizes how little it asks for: full ACME protocol support, ECDSA certificates, SAN and wildcard certificates, compatibility with Bash, dash, and sh, no Python dependency, and no requirement for root or sudo access. The project is licensed under GPL-3.0 and has grown to roughly 47,000 stars.
Which systems and CAs are covered
The README lists tested operating systems that span the usual server and desktop suspects: macOS, Windows with cygwin, FreeBSD, Ubuntu, Debian, Alpine Linux, Archlinux, Fedora, and OpenWRT. On the authority side it lists ZeroSSL as the default, along with Letsencrypt, SSL.com, Google Public CA, and any CA that is compliant with RFC 8555. That combination is meant to cover most people who run their own web servers.
The verification modes
Issuing a certificate requires proving you control the domain, and acme.sh supports several ways to do that. Webroot mode uses an existing webroot directory. Standalone mode spins up its own built in webserver on port 80, and standalone TLS ALPN mode does the same on port 443. Apache and Nginx modes hand verification to those servers, while the DNS modes use TXT records and offer alias, stateless, and persistent record options. The choice is basically about what kind of setup you already have.
Installing and issuing a first certificate
The install path is deliberately light. You create an acme.sh directory in the home folder, add an alias, and set up a daily cron job. Issuing a first certificate needs a web root folder with write access and a main domain. One warning stands out in the docs: use the install command to copy certificates into their target files rather than pulling directly from internal folder files, because the internal layout is not something you should depend on.
Renewal and DNS options
Renewal runs on a 30 day cycle by default, and the reload command matters because it flushes renewed certificates to the servers. DNS API integration makes renewal automatic for the supported DNS providers. Manual DNS mode is the tradeoff: you add TXT records by hand and give up automatic renewal. DNS persist mode sits in between, placing a single long lived TXT record that can be reused. The three modes are laid out so users can pick based on how much automation they actually want.
Community notes