Preface

A few days ago, I suddenly received an SSL certificate expiration reminder for my domain from Tencent Cloud:

This domain is used for the DERP (Tailscale relay server) deployed on my cloud host. If you are interested in the related content, you can check out my previous article:Debian Series: A Foolproof Guide to Setting Up a Tailscale DERP Server (Relay Server)). Previously, Tencent Cloud allowed applying for a free 1-year DV certificate. I figured doing it once a year was no big deal, so I made do with it for two years. But now:

That's no longer an option. Having to do it every three months is a nightmare (and spending money is out of the question), so I had to consider the traditional free SSL certificate automatic renewal solution: acme.sh.

Note 1: Actually, I have always known about acme.sh, but I was just too lazy to set it up (once a year, which is acceptable to me), and most other situations requiring automatic SSL certificate renewal already come with built-in acme functionality, so there was no need to bother with it separately. However, now that I've been forced into this, I might as well study it carefully and take this opportunity to write a quick post.

Note 2: Besides acme.sh, there are other choices for ACME protocol clients, such as certbot. However, acme.sh is lightweight enough and doesn't require installing dependencies. My needs were simple: I just needed to automatically renew the certificates in a specific directory on the DERP server, with no other requirements and no need to integrate with Nginx or Apache. acme.sh fits my needs perfectly. The advantage of certbot lies in its high integration with Nginx and Apache (with dedicated Nginx and Apache plugins) and more comprehensive features, none of which I need right now. So, after weighing the options, I chose acme.sh.

Note 3: The acme.sh method is only suitable for scenarios where the updated certificates are stored locally. Nowadays, most websites use CDNs, in which case acme.sh won't work (since the certificates are on the CDN). If you want to automatically update free certificates on a CDN, please refer to another article:Home Data Center Series: One-Stop SSL Certificate Management Tool OHTTPS Tutorial。

Introduction to the ACME Protocol

The ”acme.sh” mentioned in this article is actually just a relatively famous ACME client tool. Most applications on the market that can automatically update SSL certificates (such as BT Panel, 1Panel, etc.) usually integrate ACME-related tools to handle certificate application, verification, and renewal. This is because the ACME protocol is currently the standard protocol for applying for and managing free SSL certificates (especially Let's Encrypt).

We encounter ACME in many situations in our daily lives:

Applications and Panels Integrating ACME

• BT Panel: BT Panel integrates Let's Encrypt's certificate application feature and provides automatic renewal. It uses tools like acme.sh or certbot in the background to handle certificate application and renewal.

• 1Panel: Similar to BT Panel, 1Panel also supports one-click application and automatic renewal of SSL certificates, and it also uses acme.sh for certificate management.

• Other Panels (such as cPanel, Plesk, etc.): These panels also have built-in support for Let's Encrypt, usually handling certificates by integrating ACME protocol clients (such as certbot or acme.sh).

Typical ACME Client Tools

• acme.sh: An ACME client implemented purely in Shell script. It supports most CAs (such as Let's Encrypt, ZeroSSL, etc.) and can easily manage various types of certificates (such as wildcard certificates, ECC/RS256 certificates, etc.). Many applications and panels integrate acme.sh because it is lightweight, highly compatible, and has few dependencies. It is also the main focus of this article.

• certbot: The official ACME client provided by the Electronic Frontier Foundation (EFF). It is powerful, especially with high integration on Apache and Nginx. certbot supports various automated operations and plugins, making it suitable for certificate management in complex scenarios.

• lego: An ACME client written in Go, providing some advanced features (such as DNS verification), suitable for developers who need custom functionality.

Note: If you are using a panel with integrated ACME features (such as BT Panel or 1Panel) for your website, you do not need to configure acme.sh separately. Those who need to use acme.sh are usually deploying Nginx or Apache from scratch (experienced users who prefer to have everything under control and won't use tools like panels to build websites); or, like me this time, have a need to use acme.sh solely to update an SSL certificate in a specific directory.

How ACME Works

ACME (Automatic Certificate Management Environment) is a protocol used to automatically manage the acquisition, installation, and renewal of SSL/TLS certificates. Its core tasks mainly include ”verifying domain ownership” and ”generating, issuing, and managing certificates.”

The workflow of the ACME protocol typically includes the following steps:

1. Register Account: The client registers an account with a server that supports the ACME protocol (such as Let’s Encrypt). Usually, contact information needs to be provided (this is not always required; Let’s Encrypt does not require it, while ZeroSSL requires a valid email address) to receive reminders when the certificate is about to expire. After registration, the client will obtain an Account Key.
2. Verify Domain Ownership: The client initiates a domain verification request, and the ACME server returns a challenge, requiring the client to prove its control over the target domain. The client must respond to the challenge through a specific verification method (such as HTTP-01, DNS-01, or TLS-ALPN-01).
3. Apply for Certificate: After verification is complete, the client can generate a Certificate Signing Request (CSR) and submit it to the ACME server. The CSR contains information such as the domain name and the applicant's public key.
4. Issue Certificate: After the ACME server verifies the information in the CSR, if there are no issues, it will generate and issue the certificate. The client retrieves the certificate and stores it locally.
5. Automatic Renewal: Before the certificate expires, the ACME client will automatically initiate the renewal process, re-verify domain ownership, and obtain a new certificate.

Install acme.sh

Preparation

Before installing acme.sh, ensure that the system has the latest root certificate list to verify certificates for HTTPS connections; otherwise, some issues may occur when generating free SSL certificates:

apt update  
apt install ca-certificates

Choosing an Installation Method

Script Installation Method

There are multiple ways to install acme using scripts:

From webhttps://get.acme.shInstallation:

curl https://get.acme.sh | sh -s [email protected]

Install from GitHub:

curl https://raw.githubusercontent.com/acmesh-official/acme.sh/master/acme.sh | sh -s -- --install-online -m  [email protected]

or

wget -O -  https://raw.githubusercontent.com/acmesh-official/acme.sh/master/acme.sh | sh -s -- --install-online -m  [email protected]

Install using ”git clone”:

git clone --depth 1 https://github.com/acmesh-official/acme.sh.git
cd acme.sh
./acme.sh --install -m [email protected]

Advanced Installation

git clone --depth 1 https://github.com/acmesh-official/acme.sh.git
cd acme.sh
./acme.sh --install  \
--home ~/myacme \
--config-home ~/myacme/data \
--cert-home  ~/mycerts \
--accountemail  "[email protected]" \
--accountkey  ~/myaccount.key \
--accountconf ~/myaccount.conf \
--useragent  "this is my client."

-p 110:110 \

• --home: Specifies acme.sh the custom directory for installation. By default,acme.sh it is installed in the ~/.acme.sh directory.
• --config-home: Specifies a writable folder,acme.sh which will write all files (including certificates, keys, and configurations) to this directory. By default, this directory is located at --home .
• --cert-home: Specifies a custom directory to save issued certificates. By default, certificates are saved in --config-home .
• --accountemail: The email address used to register the Let’s Encrypt account, where you will receive renewal notification emails.
• --accountkey: The file that saves the account private key. By default, this file is saved in --config-home .
• --useragent: Specifies the value of the user-agent request header sent to Let’s Encrypt.
• --nocron: Do not create a scheduled task (cron job) during acme.sh installation.

Note 1: As described in the ”How ACME Works” section, when acme.sh uses Let’s Encrypt or other CA authorities to apply for certificates, it needs to register an account (usually called an ACME account), which is bound to an email address. The ”[email protected]” in the above command is the email address used when registering this ACME account. This email address will be used in the following situations: receiving important notifications from the CA (such as Let’s Encrypt), such as certificate expiration reminders, security updates, etc.; serving as the account's identity information for managing certificate and account changes, revocations, etc. Although it is not a mandatory parameter, it is highly recommended to use a valid email address so that you can receive certificate expiration reminders and other related notifications in a timely manner.

Note 2: The installer will automatically perform the following operations:

Install acme.sh into the ~/.acme.sh directory, which is the .acme.sh folder under the home directory:

Automatically set up a daily cron job at 0:00 to check the status of all certificates. If a certificate is about to expire, it will automatically renew (if applicable), which can be viewed using the following command:

crontab -l

Note: If cron is not installed, this step will fail, but it doesn't matter; you can install crontab and add cron jobs yourself later.

Automatically create an alias for the acme.sh script for convenient daily use: alias acme.sh=~/.acme.sh/acme.sh, but it was not automatically created when I installed it on two devices.

Docker Method

For some environments not suitable for script installation, you can use Docker to simulate the effect of script-installing acme. The following command runs acme inside Docker as a daemon:

mkdir -p /docker/acme.sh
docker run --name=acme.sh -itd --rm \
  -v /docker/acme.sh:/acme.sh  \
  -v /var/run/docker.sock:/var/run/docker.sock \
  neilpang/acme.sh daemon

docker run --name=acme.sh -itd --rm \-v /docker/acme.sh:/acme.sh \-v /var/run/docker.sock:/var/run/docker.sock \

neilpang/acme.sh daemon

Additional Knowledge: acme.sh Domain Verification Methods

To some extent, this result achieves a similar effect to script installation, except that running acme requires using the command

1. docker exec acme.sh

, and at the same time, you need to manually configure docker acme to run on startup.
Note: Why can't we use the "--restart=always" option to make docker acme run automatically on startup? Because "--rm" and "--restart=always" are mutually exclusive, and theoretically, "--rm" is more suitable for acme running in Docker.
acme.sh mainly has three validation methods to prove the client's control over the domain name:
HTTP-01 Challenge(webroot)

• Principle: The client places a file containing a challenge string at a specified path under the target domain name (usually http://yourdomain/.well-known/acme-challenge/), and the ACME server requests this file via HTTP to verify domain ownership.

2. • Scenario: Suitable for scenarios where the Web server can directly serve content.

• Advantages: Simple and easy to use, suitable for common website environments.
• Disadvantages: Relies on an existing web server (Nginx or Apache), and the server pointed to by the target domain name must be accessible at the .well-known/acme-challenge path.
Note: This method also has a special mode called "standalone", enabled via the "--standalone" parameter. In this mode, acme.sh will start a temporary Web server on its own, listening on port 80 or 443, to handle validation requests from the specified CA (such as Let's Encrypt). However, the "standalone" mode is not very practical because it requires ports 80 and 443 to be free, whereas under normal circumstances, these two ports are basically occupied by the web server (unless there is a dedicated server used solely for managing certificates that does not directly host any website services, which can utilize the "--standalone" mode to manage certificates and then distribute them to other servers).
DNS-01 Challenge

• Principle: The client needs to add a special TXT record to the DNS records of the target domain name, containing the challenge string provided by the ACME server. The ACME server verifies domain ownership by performing a DNS lookup for this record.

3. • Scenario: Suitable for situations where the target server cannot be directly controlled or the target domain name resolves to multiple IPs.

• Advantages: No need to expose ports or server availability, only requires access to DNS records.
• Disadvantages: Requires write permission to DNS records.
Note: This method also has another implementation called "API validation", which requires the user to provide authentication information for their domain provider's API interface. This method can complete the validation automatically without user intervention.
TLS-ALPN-01 Challenge

• Principle: The client responds to the TLS handshake request on the target domain name using a specific ALPN protocol (Application-Layer Protocol Negotiation, usually acme-tls/1). The ACME server will attempt to establish a TLS connection with the client and verify whether the challenge response is correct during the handshake.

• Scenario: Suitable for scenarios where HTTP-01 or DNS-01 cannot be used, especially for services that can only communicate using specific TLS protocols.

acme.sh in Practice

Preparation

Use alias to Create an Alias for the acme.sh Script (Optional)

Use• Advantages: No need to expose HTTP ports, only requires opening the TLS (usually 443) port.• Disadvantages: Requires precise control over the server's TLS configuration, the client needs to support the ALPN protocol, and it also needs to occupy port 443, so it has similar issues to ”standalone”.

alias acme.sh=~/.acme.sh/acme.sh

Ultimately, the most commonly used domain validation methods are "HTTP-01 Challenge (webroot)" and "DNS-01 Challenge".

Change the Default CA

Note: In addition to the ACME server verifying domain control during the initial SSL certificate application, the ACME server will check domain ownership again using the same method (HTTP, DNS) as the application during each subsequent certificate renewal. Therefore, please ensure that after the initial application, the validation-related content (access to the .well-known path or DNS records) remains unchanged.

acme.sh --set-default-ca  --server  letsencrypt

The command displays existing aliases. If there are none, for convenience, you need to use the alias command to create an alias "acme.sh" for the acms.sh script:

Register an Account on the ACME Server (Optional)

Note: Theoretically, this step should be performed automatically when installing via script. However, for some reason, I found it didn't take effect after installing with the script, so I added this step myself. If you find this alias already exists after script installation, you don't need to add it manually.

acme.sh was acquired by ZeroSSL's parent company (Apilayer) in 2021, and after the acquisition, the default Certificate Authority (CA) of acme.sh was changed to ZeroSSL. Using ZeroSSL as the default CA is actually fine, but one thing is that you need to register when using ZeroSSL for the first time, and during registration, you will be forced to provide a valid email address, meaning there is an email verification step, which is a bit annoying. Therefore, to save trouble, it is generally recommended to switch back to Let's Encrypt using the following command:

acme.sh --register-account --accountemail [email protected]

acme also supports other CAs, which you can choose as needed:

This step is also not mandatory. Some CAs will automatically generate an account based on the domain name even without a registration action (such as Let's Encrypt), while some CAs will strictly verify the validity of the email address (such as ZeroSSL). However, even for Let's Encrypt, which does not have strict requirements, I still recommend providing a valid email address to make it easier to receive notifications from Let's Encrypt (such as certificate expiration notices).

acme.sh --update-account --accountemail [email protected]

acme.sh --register-account --accountemail [email protected]

Use acme.sh to Apply for a Certificate

Additional Knowledge: What Exactly Does acme.sh Do?

This allows you to register an account on the ACME server (CA) being used while associating it with your email address.If you already have an account but have not associated an email address, you can use the following command to update the email address separately:acme.sh --update-account --accountemail [email protected]

1. Note: If the email address provided during script installation is real, an account will be automatically created on the corresponding ACME server using that email address (of course, it depends on whether the ACME server needs to verify the validity of the email, which is still unavoidable), so there is no need to recreate it separately. That's why I said this step is optional.
2. yourdomain.cer: Certificate file. It contains the public key certificate issued by the ACME server.
3. yourdomain.fullchain.cer: Full certificate chain file. It contains a combination of the domain certificate and intermediate certificates, used for most Web server configurations.
4. ca.cer: CA certificate file. It contains the root certificate and intermediate certificates that issued the certificate.

Then, during each automatic renewal, except for the private key file which remains unchanged (unless manually specified), the certificate file and the full certificate chain file will be automatically updated. The CA certificate file generally does not change, but it might (for example, if the CA is changed, such as switching from Let's Encrypt to ZeroSSL, or if the certificate chain changes even with the same CA, such as Let's Encrypt switching its default intermediate certificate from R3 to E1 at the end of 2021).

Therefore, to summarize in one sentence, acme.sh actually is in the specified path (default is~/.acme.sh/) under the corresponding domain name folder, generating 4 files (private key file, certificate file, full certificate chain file, CA certificate file) and continuously updating the certificate file and full certificate chain file therein, while updating the CA certificate file as needed.

Note 1: If you do not want to use the default~/.acme.sh/path, you can use the--config-homeparameter to change it; if you only want to change the storage path of the certificate file, you can use the--cert-homeparameter to change it, so that except for the certificate file, other configuration files will still remain in the~/.acme.sh/path.

Note 2:~/.acme.sh/account.confis the global configuration file of acme.sh, containing the user's ACME account information (such as the account key and API URL).

Two Ways to Apply for Certificates with acme.sh

Apply Using the Script Method

HTTP Verification Method (webroot)

If acme.sh is used to apply for a certificate for an existing website's domain name, assuming the domain name that needs a certificate is ”www.tangwudi.com“, then the command to perform domain name verification based on the script and using the webroot method is as follows:

acme.sh --issue -d www.tangwudi.com --webroot /home/wwwroot/www.tangwudi.com/

• --issue indicates requesting to generate a certificate
• -d specifies the domain name for which the certificate needs to be generated; if generating multiple domain names at once, there can be multiple-d
• --webroot /home/wwwroot/www.tangwudi.com/ specifies the actual location of the website root directory corresponding to the domain name

Note 1: In addition to using the--webrootmethod to directly specify the root directory of the corresponding website, there are also--nginx和--apachethese two methods, which correspond to cases where the web server uses nginx and apache respectively. However, these two methods depend on the default installation path and configuration of the Web server. If the Web server is not installed in the default path, or there is no permission to reload the service, it may cause trouble. Therefore, if only one domain name needs SSL, it is best to use the--webrootmethod.

Note 2: When using the HTTP verification method, you must ensure that the website itself can be accessed normally and that thehttp://yourdomain/.well-known/acme-challenge/path is accessible, otherwise it will definitely fail.

Note 3: The HTTP verification method can only verify a single domain name. If you want to apply for a wildcard domain certificate, you must use the dns verification method.

DNS Verification Method

Manual Method

Generate a txt record locally using acme.sh
The command is as follows (please replace tangwudi.com with your own domain name when using it):

acme.sh  --issue  --dns -d tangwudi.com  --yes-I-know-dns-manual-mode-enough-go-ahead-please

Then record the generated txt record content:

Add the txt record in the domain name provider's console:

Use the--renewparameter to regenerate the host certificate for tangwudi.com:

acme.sh  --renew -d tangwudi.com  --yes-I-know-dns-manual-mode-enough-go-ahead-please

API Method

This method no longer requires manually creating a txt record, but instead verifies through the domain name provider's API. Therefore, you need the authentication information for the API interface corresponding to your domain name provider's account (usually API ID and API key, though names vary for different DNS providers). Below are the API and API parameter verification details for some DNS providers:

Taking a domain name hosted on Alibaba Cloud as an example, first obtain Aliyun's Ali_Key and Ali_Secret:

Create a new AccessKey:

You can also use the RAM access control method currently recommended by Alibaba Cloud to create it, with the link below:Alibaba Cloud RAM User

After obtaining Ali_Key and Ali_Secret, use the export command to export them as environment variables:

export Ali_Key="xxxxxxxx"
export Ali_Secret="xxxxxxxxxxxxx"

Finally, use the following command to generate the wildcard domain certificate for tangwudi.com:

acme.sh --issue --dns dns_ali -d '*.tangwudi.com'

Note 1: The ”dns_ali” following the ”–dns” parameter in the above command is generally ”dns_provider abbreviation”, for example, ”dns_ali” here. If using Tencent DNSPod, it would be ”dns_dp”, and if using Cloudflare, it would be ”dns_cf”. However, there are exceptions, so it is best to confirm before deployment. For details, you can refer to ”Domain Name Provider APIs Supported by ACME“.

Note 2: The ”-d tangwudi.com” I used in the manual method and the ”-d" used in the API method *.tangwudi.com“, the former is to generate the host certificate corresponding to the domain name ”tangwudi.com”, while the latter is to generate the wildcard certificate corresponding to ”tangwudi.com”. The two are completely different. The latter can match any host certificate under the second-level domain ”tangwudi.com”. Everyone must pay attention to this. Generally speaking, directly generating a wildcard certificate is enough, and there is no need to apply for a host certificate separately.

Note 3: The DNS verification method does not require HTTP environment support and is more adaptable (for example, this time I did it to automatically renew the SSL certificate of the derp application). The only disadvantage is that it requires control over the domain name. It is not suitable for some friends who only have control over the website but not the domain name (such as building a website using virtual hosting). In this case, the HTTP verification method is more suitable, so everyone can choose the appropriate method according to their actual environment.

Note 4: acme.sh support for Cloudflare is divided into two types:
Only when using the Global API Key, CF_Key + CF_Email is used; 2. For non-global Keys, but zone-scoped API Tokens (the method recommended by CF official), CF_Token should be used instead of CF_Key. Everyone must pay attention to this, as I also fell into this trap.

Apply Using the Docker Method

This method is an alternative in environments where it is inconvenient to use the script method to apply. Essentially, it uses the docker exec command to run acme running in docker as a script. In the earlier part of the article, I explained how to run acme inside docker as a daemon. Under this premise, you only need to run the following command:

docker  exec \
    -e Ali_Key="xxxxxxxx" \
    -e Ali_Secret="xxxxxxxxxxxxx"  \
    acme.sh --issue -d tangwudi.com  --dns dns_ali

-e Ali_Key="xxxxxxxx" \

---

-e Ali_Secret="xxxxxxxxxxxxx" \
acme.sh --issue -d tangwudi.com --dns dns_ali

docker run --rm -it \
  -v /docker/acme.sh:/acme.sh \
  neilpang/acme.sh --issue -d tangwudi.com --webroot /acme.sh/webroot

Actually, when applying using the docker method, the pre-deployment step is not mandatory, and a one-time command is also fine, for example:

docker run --rm -it \
  -v /docker/acme.sh:/acme.sh \
  neilpang/acme.sh --issue -d tangwudi.com --dns dns_cf

docker run --rm -it \

---

Certificate Deployment

Certificate Deployment in Regular Environments

-v /docker/acme.sh:/acme.sh \If you already have an account but have not associated an email address, you can use the following command to update the email address separately:neilpang/acme.sh --issue -d tangwudi.com --webroot /acme.sh/webroot

(2) --dns mode

acme.sh --install-cert -d '*.tangwudi.com' \
--key-file       /path/to/keyfile/in/nginx/key.pem  \
--fullchain-file /path/to/fullchain/nginx/cert.pem \
--reloadcmd     "service nginx force-reload"

-v /docker/acme.sh:/acme.sh \

acme.sh --install-cert -d '*.tangwudi.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"

---

It just depends on what you prefer.

• NginxBy default, acme will only update
• Apachethe certificates under the path. The certificates under this path are only for internal use by acme (the folder structure may change as needed), and it is not recommended to use them directly. Therefore, do not directly use the cp command to copy the certificate files under the path to other locations.

---

If you need to deploy the certificate to other locations, the formal way is to use the official ”install” parameter to specify in detail the target location where the certificate file needs to be copied. Taking the deployment of the ”tangwudi.com” certificate to Nginx as an example (please replace the actual path yourself):acme.sh --install-cert -d '*.tangwudi.com' \--key-file /path/to/keyfile/in/nginx/key.pem \

--fullchain-file /path/to/fullchain/nginx/cert.pem \

server {
  listen       443 ssl;
  ssl_certificate      /path/to/fullchain/nginx/cert.pem;
  ssl_certificate_key  /path/to/keyfile/in/nginx/key.pem;
}

Certificate Deployment Involving Docker Environments

Deploying to Apache is the same:acme.sh --install-cert -d "*.tangwudi.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"

acme.sh --install-cert -d '*.tangwudi.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 \

: Usually only 2 files are needed (certificate file + private key), and the intermediate certificate can be merged into the certificate file.

: Usually 3 files are needed (certificate file + private key + intermediate certificate), and the intermediate certificate needs to be configured separately.

Based on various complex deployment environments, acme has to go to great lengths to deliver certificates (the --install-cert method has limitations). For example, to deliver certificates into Nginx deployed via docker, you need to ”label” Nginx, then use the export command to set environment variables, and finally use acme.sh's--deploy和--deploy-hook dockerparameters:

docker run --rm -it -d  --label=sh.acme.autoload.domain=tangwudi.com   nginx:latest

# The label value to find the container
export DEPLOY_DOCKER_CONTAINER_LABEL=sh.acme.autoload.domain=tangwudi.com

# The target file path in the container.
# The files will be copied to the position in the container.
export DEPLOY_DOCKER_CONTAINER_KEY_FILE="/etc/nginx/ssl/example.com/key.pem"
export DEPLOY_DOCKER_CONTAINER_CERT_FILE="/etc/nginx/ssl/example.com/cert.pem"
export DEPLOY_DOCKER_CONTAINER_CA_FILE="/etc/nginx/ssl/example.com/ca.pem"
export DEPLOY_DOCKER_CONTAINER_FULLCHAIN_FILE="/etc/nginx/ssl/example.com/full.pem"

# The command to reload the service in the container.
export DEPLOY_DOCKER_CONTAINER_RELOAD_CMD="service nginx force-reload"

acme.sh --deploy --deploy-hook docker -d example.com

# The label value to find the containerexport DEPLOY_DOCKER_CONTAINER_LABEL=sh.acme.autoload.domain=tangwudi.com。

acme.sh Operations and Maintenance

Upgrading acme.sh

# The target file path in the container.

acme.sh --upgrade

export DEPLOY_DOCKER_CONTAINER_KEY_FILE="/etc/nginx/ssl/example.com/key.pem"

acme.sh --upgrade --auto-upgrade

export DEPLOY_DOCKER_CONTAINER_CA_FILE="/etc/nginx/ssl/example.com/ca.pem"

acme.sh --upgrade --auto-upgrade 0

For the Docker-based acme upgrade, just follow the regular Docker upgrade process, which won't be detailed here.

acme.sh Debug Mode

If an error occurs during acme execution, in addition to checking the logs, you can also use the ”–debug 2" parameter to enable debug mode:

acme.sh --issue -d www.tangwudi.com --webroot /home/wwwroot/www.tangwudi.com/ --debug 2

View Certificate Information with acme.sh

If you need to view the certificate information of a domain name, use the following command:

acme.sh --info -d tangwudi.com

Summary

Actually, the general use of acme.sh is very simple, and there is no need to explain it in such a lengthy way. Moreover, I originally only wanted to solve the update problem of the derp server certificate on the cloud server. Honestly, a few commands could have settled it.

However, out of habit, I still visited the acme.sh homepage on GitHub and found that there is actually quite a lot of content. Most online tutorials only cover configurations for the most basic scenarios, leaving out many details (since they are usually not needed) and rarely touching upon the underlying principles. So, after some thought, I felt it would be best to write a dedicated, detailed tutorial. This way, if anyone encounters less basic scenarios in the future, they can still use it as a reference manual.

Even so, there is still a lot of content I haven't covered (because I really felt it wasn't needed~). Interested friends can check out the official documentation at the following address:acme.sh official GitHub address。

Note: Actually, combining acme.sh with Syncthing or other synchronization solutions can also achieve a ”unified issuance center + multi-node certificate distribution”. If you have such a need, you can research it on your own.