|
Some checks failed
DNS / CheckToken (push) Has been cancelled
Build DockerHub / CheckToken (push) Has been cancelled
Shellcheck / ShellCheck (push) Has been cancelled
Shellcheck / shfmt (push) Has been cancelled
DNS / Fail (push) Has been cancelled
DNS / Docker (push) Has been cancelled
DNS / MacOS (push) Has been cancelled
DNS / Windows (push) Has been cancelled
DNS / FreeBSD (push) Has been cancelled
DNS / GhostBSD (push) Has been cancelled
DNS / OpenBSD (push) Has been cancelled
DNS / NetBSD (push) Has been cancelled
DNS / DragonFlyBSD (push) Has been cancelled
DNS / MidnightBSD (push) Has been cancelled
DNS / Solaris (push) Has been cancelled
DNS / Omnios (push) Has been cancelled
DNS / OpenIndiana (push) Has been cancelled
DNS / Tribblix (push) Has been cancelled
DNS / Haiku (push) Has been cancelled
DNS / Hurd (push) Has been cancelled
DNS / OpenEuler (push) Has been cancelled
Build DockerHub / build (push) Has been cancelled
* dns_yc: restore YC_SA_Key_File in dns_yc_rm before signing the JWT dns_yc_rm() never rebuilt YC_SA_Key_File from YC_SA_Key_File_PEM_b64 / YC_SA_Key_File_Path like dns_yc_add() does. Per the DNS API dev guide, add()/rm() run in separate subshells, so rm() must repeat add()'s setup steps rather than rely on variables set during add(). Without it, when _yc_login() needs a fresh JWT during removal (the IAM token from the add phase isn't available), it signs with an empty/unset key path, and openssl fails with "Unknown key file format". The resulting auth failure then surfaces misleadingly as "invalid domain" in _get_root, and the TXT record is never deleted. Verified against a real Yandex Cloud account/zone with --staging: before the fix, removal failed with the same errors reported in the issue; after adding the missing key-restoration block, add + remove both succeed and the TXT record is actually deleted. * dns_yc: preserve other TXT values when removing one at the same name dns_yc_rm previously sent the full current data array (all existing TXT values at the name) to the deletions API, wiping out the whole rrset instead of only the value being removed. This breaks wildcard + base domain issuance, where both share the same _acme-challenge name with two different values: removing the first one deleted both, leaving nothing for the second removal to find. * dns_yc: read persisted config from domain conf before account conf YC_Zone_ID, YC_Folder_ID, YC_SA_ID, YC_SA_Key_ID (zone-ID mode) and YC_SA_Key_File_PEM_b64/Path were always saved via _savedomainconf (domain.conf), but only ever read back via _readaccountconf_mutable (account.conf). Once the env vars were unset, none of these could be recovered from the saved config, so dns_yc_add/dns_yc_rm failed with "You didn't specify a YC_SA_ID or YC_SA_Key_ID or YC_SA_Key_File." even though the values had been persisted correctly on the prior run. * dns_yc: replace grep -Fxv/sed with a portable loop in dns_yc_rm Solaris's /usr/bin/grep supports neither -F nor -x, so _remaining_txtvalue was always empty there and the preserve-other- values logic silently fell back to deleting the whole rrset (with a grep usage error on stderr on every rm). The sed trailing-comma strip had a matching issue on Solaris, whose sed drops an unterminated last line. CI didn't catch this because the fallback path also returns "done: true". Use a plain for-loop with word splitting instead. * dns_yc: use upsertRecordSets.deletions to remove a single TXT value updateRecordSets has no "merges" field (only deletions/additions), so the previous preserve-other-values logic silently did nothing -- the TXT record was never actually removed, a regression from before that change (which at least deleted the whole rrset). CI didn't catch it because _clearupdns runs dns_yc_rm in a subshell and ignores its exit code. upsertRecordSets.deletions removes only the specified value from the rrset directly, so the getRecordSet read and the remaining-value recomputation are no longer needed at all. Verified against a real zone (base + wildcard domain sharing one _acme-challenge name): adding both values then removing one leaves the other in place, and removing the second cleans up fully. * dns_yc: don't delete the user's own key file in YC_SA_Key_File_Path mode _yc_login unconditionally rm'd $YC_SA_Key_File after signing. That's fine for the PEM_b64 path, where it's a decoded temp file, but in YC_SA_Key_File_Path mode it's the user's own persistent key file -- the first successful login permanently deleted it, so every subsequent dns_yc_rm/renewal hit "Unknown key file format" (the exact symptom this PR is about, just from a different cause). Track whether the key file is our own temp copy and only delete it in that case. Verified with a stubbed _yc_login: a temp-mode key gets removed after login, a path-mode key survives. * dns_yc: clear both domain and account conf on invalid config The failure branch in dns_yc_add only ever called _clearaccountconf, but YC_Zone_ID/YC_Folder_ID/YC_SA_Key_File_PEM_b64/Path are persisted via _savedomainconf, and YC_SA_ID/YC_SA_Key_ID may have been saved via _saveaccountconf_mutable (Folder_ID mode, which stores under a SAVED_ prefix read back by _readaccountconf_mutable). Clearing only one store left stale values behind in whichever one wasn't touched. Verified by seeding both domain.conf and account.conf with leftover values, then triggering this branch and confirming both config files end up empty. |
||
|---|---|---|
| .github | ||
| deploy | ||
| dnsapi | ||
| notify | ||
| acme.sh | ||
| acme.sh.completion | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| LICENSE.md | ||
| README.md | ||
🔐 acme.sh
An ACME Protocol Client Written Purely in Shell
✨ Features
- 🐚 An ACME protocol client written purely in Shell (Unix shell) language
- 📜 Full ACME protocol implementation
- 🔑 Support ECDSA certificates
- 🌐 Support SAN and wildcard certificates
- ⚡ Simple, powerful and very easy to use — only 3 minutes to learn!
- 🔧 Compatible with Bash, dash and sh
- 🚫 No dependencies on Python
- 🔄 One script to issue, renew and install your certificates automatically
- 👤 DOES NOT require
root/sudoeraccess - 🐳 Docker ready
- 🌍 IPv6 ready
- 📧 Cron job notifications for renewal or error
💡 It's probably the easiest & smartest shell script to automatically issue & renew free certificates.
📚 Wiki • 🐳 Docker Guide • 🐦 Twitter
🌏 中文说明
🏆 Who Uses acme.sh?
- FreeBSD.org
- ruby-china.org
- Proxmox
- pfsense
- Loadbalancer.org
- discourse.org
- Centminmod
- splynx
- opnsense.org
- CentOS Web Panel
- lnmp.org
- more...
🖥️ Tested OS
| NO | Status | Platform |
|---|---|---|
| 1 | Mac OSX | |
| 2 | Windows (cygwin with curl, openssl and crontab included) | |
| 3 | FreeBSD | |
| 4 | Solaris | |
| 5 | Ubuntu | |
| 6 | NA | pfsense |
| 7 | OpenBSD | |
| 8 | NetBSD | |
| 9 | DragonFlyBSD | |
| 10 | MidnightBSD | |
| 11 | Omnios | |
| 12 | OpenIndiana | |
| 13 | Debian | |
| 14 | openSUSE | |
| 15 | Alpine Linux (with curl) | |
| 16 | Archlinux | |
| 17 | fedora | |
| 18 | Kali Linux | |
| 19 | Oracle Linux | |
| 20 | Mageia | |
| 21 | Gentoo Linux | |
| 22 | ----- | Cloud Linux https://github.com/acmesh-official/acme.sh/issues/111 |
| 23 | ----- | OpenWRT: Tested and working. See wiki page |
| 24 | Proxmox: See Proxmox VE Wiki. Version 4.x, 5.0, 5.1, version 5.2 and up | |
| 25 | Haiku OS | |
| 26 | Tribblix | |
| 27 | GhostBSD | |
| 28 | GNU Hurd | |
| 29 | openEuler |
🧪 Check our testing project
🖥️ The testing VMs are supported by vmactions.org
🏛️ Supported CA
| CA | Status |
|---|---|
| ZeroSSL.com CA | ⭐ Default |
| Letsencrypt.org CA | ✅ Supported |
| SSL.com CA | ✅ Supported |
| Google.com Public CA | ✅ Supported |
| Actalis.com CA | ✅ Supported |
| Pebble strict Mode | ✅ Supported |
| Any RFC8555-compliant CA | ✅ Supported |
⚙️ Supported Modes
| Mode | Description |
|---|---|
| 📁 Webroot mode | Use existing webroot directory |
| 🖥️ Standalone mode | Built-in webserver on port 80 |
| 🔐 Standalone tls-alpn mode | Built-in webserver on port 443 |
| 🪶 Apache mode | Use Apache for verification |
| ⚡ Nginx mode | Use Nginx for verification |
| 🌐 DNS mode | Use DNS TXT records |
| 🔗 DNS alias mode | Use DNS alias for verification |
| 📡 Stateless mode | Stateless verification |
| 📌 DNS persist mode | Persistent DNS TXT record (draft-ietf-acme-dns-persist-01) |
📖 Usage Guide
1️⃣ How to Install
📥 Install Online
Check this project: https://github.com/acmesh-official/get.acme.sh
curl https://get.acme.sh | sh -s email=my@example.com
Or:
wget -O - https://get.acme.sh | sh -s email=my@example.com
📦 Install from Git
Clone this project and launch installation:
git clone https://github.com/acmesh-official/acme.sh.git
cd ./acme.sh
./acme.sh --install -m my@example.com
💡 You
don't have to be rootthen, althoughit is recommended.
📚 Advanced Installation: https://github.com/acmesh-official/acme.sh/wiki/How-to-install
The installer will perform 3 actions:
- Create and copy
acme.shto your home dir ($HOME):~/.acme.sh/. All certs will be placed in this folder too. - Create alias for:
acme.sh=~/.acme.sh/acme.sh. - Create daily cron job to check and renew the certs if needed.
Cron entry example:
0 0 * * * "/home/user/.acme.sh"/acme.sh --cron --home "/home/user/.acme.sh" > /dev/null
⚠️ After the installation, you must close the current terminal and reopen it to make the alias take effect.
✅ You are ready to issue certs now!
Show help message:
acme.sh -h
2️⃣ Issue a Certificate
Example 1: Single domain.
acme.sh --issue -d example.com -w /home/wwwroot/example.com
or:
acme.sh --issue -d example.com -w /home/username/public_html
or:
acme.sh --issue -d example.com -w /var/www/html
Example 2: Multiple domains in the same cert.
acme.sh --issue -d example.com -d www.example.com -d cp.example.com -w /home/wwwroot/example.com
The parameter /home/wwwroot/example.com or /home/username/public_html or /var/www/html is the web root folder where you host your website files. You MUST have write access to this folder.
Second argument "example.com" is the main domain you want to issue the cert for. You must have at least one domain there.
You must point and bind all the domains to the same webroot dir: /home/wwwroot/example.com.
The certs will be placed in ~/.acme.sh/example.com/
🔄 The certs will be renewed automatically every 30 days.
🔐 The certs will default to ECC certificates.
📚 More examples: https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert
3️⃣ Install the Certificate to Apache/Nginx
After the cert is generated, you probably want to install/copy the cert to your Apache/Nginx or other servers.
⚠️ IMPORTANT: You MUST use this command to copy the certs to the target files. DO NOT use the certs files in
~/.acme.sh/folder — they are for internal use only, the folder structure may change in the future.
🪶 Apache Example:
acme.sh --install-cert -d example.com \
--cert-file /path/to/certfile/in/apache/cert.pem \
--key-file /path/to/keyfile/in/apache/key.pem \
--fullchain-file /path/to/fullchain/certfile/apache/fullchain.pem \
--reloadcmd "service apache2 force-reload"
⚡ Nginx Example:
acme.sh --install-cert -d example.com \
--key-file /path/to/keyfile/in/nginx/key.pem \
--fullchain-file /path/to/fullchain/nginx/cert.pem \
--reloadcmd "service nginx force-reload"
Only the domain is required, all the other parameters are optional.
The ownership and permission info of existing files are preserved. You can pre-create the files to define the ownership and permission.
Install/copy the cert/key to the production Apache or Nginx path.
🔄 The cert will be renewed every 30 days by default (configurable). Once renewed, the Apache/Nginx service will be reloaded automatically.
⚠️ IMPORTANT: The
reloadcmdis very important. The cert can be automatically renewed, but without a correctreloadcmd, the cert may not be flushed to your server (like nginx or apache), then your website will not be able to show the renewed cert.
4️⃣ Use Standalone Server to Issue Certificate
🔐 Requires root/sudoer or permission to listen on port 80 (TCP)
⚠️ Port
80(TCP) MUST be free to listen on, otherwise you will be prompted to free it and try again.
acme.sh --issue --standalone -d example.com -d www.example.com -d cp.example.com
📚 More examples: https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert
5️⃣ Use Standalone TLS Server to Issue Certificate
🔐 Requires root/sudoer or permission to listen on port 443 (TCP)
⚠️ Port
443(TCP) MUST be free to listen on, otherwise you will be prompted to free it and try again.
acme.sh --issue --alpn -d example.com -d www.example.com -d cp.example.com
📚 More examples: https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert
6️⃣ Use Apache Mode
🔐 Requires root/sudoer to interact with Apache server
If you are running a web server, it is recommended to use the Webroot mode.
Particularly, if you are running an Apache server, you can use Apache mode instead. This mode doesn't write any files to your web root folder.
acme.sh --issue --apache -d example.com -d www.example.com -d cp.example.com
💡 Note: This Apache mode is only to issue the cert, it will not change your Apache config files. You will need to configure your website config files to use the cert by yourself. We don't want to mess with your Apache server, don't worry!
📚 More examples: https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert
7️⃣ Use Nginx Mode
🔐 Requires root/sudoer to interact with Nginx server
If you are running a web server, it is recommended to use the Webroot mode.
Particularly, if you are running an Nginx server, you can use Nginx mode instead. This mode doesn't write any files to your web root folder.
It will configure Nginx server automatically to verify the domain and then restore the Nginx config to the original version. So, the config is not changed.
acme.sh --issue --nginx -d example.com -d www.example.com -d cp.example.com
💡 Note: This Nginx mode is only to issue the cert, it will not change your Nginx config files. You will need to configure your website config files to use the cert by yourself. We don't want to mess with your Nginx server, don't worry!
📚 More examples: https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert
8️⃣ Automatic DNS API Integration
If your DNS provider supports API access, we can use that API to automatically issue the certs.
✨ You don't have to do anything manually!
📚 Currently acme.sh supports most DNS providers: https://github.com/acmesh-official/acme.sh/wiki/dnsapi
9️⃣ Use DNS Manual Mode
See: https://github.com/acmesh-official/acme.sh/wiki/dns-manual-mode first.
If your dns provider doesn't support any api access, you can add the txt record by hand.
acme.sh --issue --dns -d example.com -d www.example.com -d cp.example.com
You should get an output like below:
Add the following txt record:
Domain:_acme-challenge.example.com
Txt value:9ihDbjYfTExAYeDs4DBUeuTo18KBzwvTEjUnSwd32-c
Add the following txt record:
Domain:_acme-challenge.www.example.com
Txt value:9ihDbjxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Please add those txt records to the domains. Waiting for the dns to take effect.
Then just rerun with renew argument:
acme.sh --renew -d example.com
✅ Done!
⚠️ WARNING: This is DNS manual mode — it cannot be renewed automatically. You will have to add a new TXT record to your domain manually when you renew your cert. Please use DNS API mode instead.
🔟 Use DNS Persist Mode
📖 Wiki: https://github.com/acmesh-official/acme.sh/wiki/DNS-persist-mode
📚 Spec: draft-ietf-acme-dns-persist-01
DNS persist mode lets you place a single, long‑lived _validation-persist TXT record in your zone and reuse it for every subsequent issuance and renewal. There is no per-issuance challenge token, so renewals require no DNS edits — useful when DNS API access is not available but you still want unattended renewals.
🪄 Step 1: Print the TXT record value
acme.sh --make-dns-persist-value -d example.com [--server letsencrypt] [--dns-persist-wildcard] [--dns-persist-ca-name "sectigo.com"] [--dns-persist-days 365]
Options:
| Flag | Description |
|---|---|
--server <ca> |
Pick the CA (default is your configured default). The account is registered automatically if you have not used this CA before. |
--dns-persist-wildcard |
Adds policy=wildcard to the record so it also authorizes wildcard / subdomain certs. |
--dns-persist-ca-name <name> |
Use a specific CA identity domain (e.g. sectigo.com). If omitted, identities are read from the ACME directory's caaIdentities field and one record per identity is printed — you only need to add any one of them. |
--dns-persist-days <N> |
Adds persistUntil=<unix-timestamp> to the record, set to N days from now. The CA will refuse new validations against the record after that time. Omit for a record with no expiry. |
You should get an output like:
TXT persist domain:_validation-persist.example.com
TXT persist value :"letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789"
✍️ Step 2: Add the TXT record to your DNS
Add the printed TXT persist domain / TXT persist value pair as a TXT record at your DNS provider, then wait for it to propagate.
📜 Step 3: Issue the certificate
acme.sh --issue -d example.com --dns-persist
✅ Done! No challenge token is provisioned during issuance — the CA reads the persistent TXT record directly.
🔄 Renewals just work:
acme.sh --renew -d example.com(or the cron job) reuses the same TXT record automatically — no further DNS edits needed.
1️⃣1️⃣ Issue Certificates of Different Key Types (ECC or RSA)
Just set the keylength to a valid, supported value.
Valid values for the keylength parameter:
| Key Length | Description |
|---|---|
ec-256 |
prime256v1, "ECDSA P-256" ⭐ Default |
ec-384 |
secp384r1, "ECDSA P-384" |
ec-521 |
secp521r1, "ECDSA P-521" ⚠️ Not supported by Let's Encrypt yet |
2048 |
RSA 2048-bit |
3072 |
RSA 3072-bit |
4096 |
RSA 4096-bit |
Examples:
Single domain with ECDSA P-384 certificate
acme.sh --issue -w /home/wwwroot/example.com -d example.com --keylength ec-384
SAN multi domain with RSA4096 certificate
acme.sh --issue -w /home/wwwroot/example.com -d example.com -d www.example.com --keylength 4096
1️⃣2️⃣ Issue Wildcard Certificates
It's simple! Just give a wildcard domain as the -d parameter:
acme.sh --issue -d example.com -d '*.example.com' --dns dns_cf
1️⃣3️⃣ How to Renew Certificates
🔄 No need to renew manually! All certs will be renewed automatically every 30 days, or earlier when the CA's ARI says so (see below).
However, you can force a renewal:
acme.sh --renew -d example.com --force
For ECC cert:
acme.sh --renew -d example.com --force --ecc
📡 ACME Renewal Information (ARI) — RFC 9773
📖 Wiki: https://github.com/acmesh-official/acme.sh/wiki/ARI
If the CA exposes a renewalInfo endpoint in its ACME directory (Let's Encrypt, ZeroSSL, etc.), acme.sh follows RFC 9773 automatically — no flag needed, no opt-in:
| What | When | Why |
|---|---|---|
🔍 Polls suggestedWindow |
Every cron run, before deciding to skip | Lets the CA shift the renewal time forward in case of an incident (key compromise, mass revocation, etc.) |
| 🎯 Picks a random renewal time inside the window | Right after a successful issuance/renewal | Disperses renewals across the network so all clients don't hit the CA at the same instant |
🔗 Sends replaces=<certID> in newOrder |
On renewal | Lets the CA correlate the new order with the certificate it supersedes (RFC 9773 §5) |
↩️ Retries without replaces |
If the CA rejects with alreadyReplaced or an ARI validation error |
Robust against edge cases (e.g. switching CAs, retired issuers) |
Renewal trigger logic: the cert is renewed if any one of the following becomes true:
--forceis given- The CA's ARI
suggestedWindowhas started - The cached
Le_NextRenewTimehas passed (default fallback for CAs without ARI)
You can see the resulting next renewal time (already ARI-picked when applicable) in:
acme.sh --info -d example.com
# Look for: Le_NextRenewTimeStr=...
For the live ARI window the CA is currently advertising, run with --debug 2:
acme.sh --renew -d example.com --debug 2 2>&1 | grep -i 'ARI suggestedWindow'
💡 If your CA does not advertise
renewalInfo,acme.shfalls back to the classic 30-day rule — no behavior change.
1️⃣4️⃣ How to Stop Certificate Renewal
To stop renewal of a cert, you can execute the following to remove the cert from the renewal list:
acme.sh --remove -d example.com [--ecc]
The cert/key file is not removed from the disk.
💡 You can remove the respective directory (e.g.
~/.acme.sh/example.com) manually.
1️⃣5️⃣ How to Upgrade acme.sh
🚀 acme.sh is in constant development — it's strongly recommended to use the latest code.
Update to latest:
acme.sh --upgrade
Enable auto upgrade:
acme.sh --upgrade --auto-upgrade
Disable auto upgrade:
acme.sh --upgrade --auto-upgrade 0
1️⃣6️⃣ Issue a Certificate from an Existing CSR
📚 https://github.com/acmesh-official/acme.sh/wiki/Issue-a-cert-from-existing-CSR
1️⃣7️⃣ Send Notifications in Cronjob
📚 https://github.com/acmesh-official/acme.sh/wiki/notify
1️⃣8️⃣ Under the Hood
🔧 Speak ACME language using shell, directly to "Let's Encrypt".
1️⃣9️⃣ Acknowledgments
| Project | Link |
|---|---|
| 🙏 Acme-tiny | https://github.com/diafygi/acme-tiny |
| 📜 ACME protocol | https://github.com/ietf-wg-acme/acme |
👥 Contributors
💻 Code Contributors
This project exists thanks to all the people who contribute.
If you want to become a contributor make sure to read CONTRIBUTING.md.
💰 Financial Contributors
Become a financial contributor and help us sustain our community. [Contribute]
👤 Individuals
🏢 Organizations
Support this project with your organization. Your logo will show up here with a link to your website. [Contribute]
2️⃣0️⃣ License & Others
📄 License: GPLv3
⭐ Please Star and Fork this project!
🐛 Issues and 🔀 Pull Requests are welcome.
2️⃣1️⃣ Donate
💝 Your donation makes acme.sh better!
| Method | Link |
|---|---|
| PayPal / Alipay(支付宝) / Wechat(微信) | https://donate.acme.sh/ |
2️⃣2️⃣ About This Repository
Note
This repository is officially maintained by ZeroSSL as part of our commitment to providing secure and reliable SSL/TLS solutions. We welcome contributions and feedback from the community!
For more information about our services, including free and paid SSL/TLS certificates, visit https://zerossl.com.All donations made through this repository go directly to the original independent maintainer (Neil Pang), not to ZeroSSL.