Preface

A few days ago, I suddenly received a reminder from Tencent Cloud that my domain name SSL certificate had expired:

This domain name is what I use to deploy derp (tailscale relay server on the cloud host. If you are interested in related content, you can read the previous article:Debian series build tailscale DERP server (relay server) for dummies), Tencent Cloud could apply for a one-year free DV certificate before, and I thought it didn't matter if I got a certificate once a year, so I used it for two years, but now:

It’s hopeless. If I have to do it once every three months, I’d rather die (spending money is out of the question), so I have to consider the traditional free SSL certificate automatic renewal solution: acme.sh.

Note 1: I have known about acme.sh before, but I was too lazy to use it (once a year, I am fine with it), and most other occasions that require automatic renewal of SSL certificates have built-in acme functions, so there is no need to mess around with it separately. But now that I am forced to do this, I might as well study it carefully and write an article.

Note 2: In addition to acme.sh, there are other options for ACME protocol clients, such as certbot. However, acme.sh is lightweight enough and does not require any dependencies. My original needs were simple: I just needed to automatically renew the certificates in a directory on the derp server, without any other requirements, and did not need to integrate with Nginx and Apache. acme.sh just met my needs. The advantage of certbot is its high integration with Nginx and Apache (with special Nginx and Apache plug-ins) and more comprehensive functions, which I do not use at present, so I chose acme.sh after weighing the pros and cons.

Note 3: The acme.sh method is only suitable for updating certificates stored locally. However, most websites now use CDN, so acme.sh cannot be used (the certificate is on the CDN). If you want to automatically update the free certificate on the CDN, please refer to another article:Home Data Center Series SSL Certificate One-Stop Management Tool OHTTPS Usage Tutorial.

ACME Protocol Introduction

The "acme.sh" mentioned in this article is actually just a well-known ACME client tool. Most applications on the market that can automatically renew SSL certificates (such as Baota Panel and 1Panel) typically integrate ACME-related tools to handle certificate application, verification, and renewal. This is because the ACME protocol is the current standard for applying for and managing free SSL certificates (especially Let's Encrypt).

We can encounter ACME in many occasions in our daily life:

1. Integrate ACME applications and panels

• Pagoda Panel：The Baota panel integrates the certificate application function of Let's Encrypt and provides automatic renewal function. It uses tools such as acme.sh or certbot in the background to handle certificate application and renewal.

• 1Panel: Similar to Baota, 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 by integrating an acme protocol client (such as certbot or acme.sh) to handle certificates.

2. Typical ACME client tools

• acme.sh: A pure shell script ACME client that 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 protagonist 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 plug-ins, and can be used for certificate management in complex scenarios.

• lego: An ACME client written in Go that provides some advanced features (such as DNS validation) and is suitable for developers to use when they need custom functions.

Note: If you use a panel with integrated ACME function (such as Baota Panel, 1Panel Panel) to build your website, you do not need to configure acme.sh separately. You need to use acme.sh if you want to deploy Nginx or Apache purely (experienced workers prefer to have everything under control and will not use tools such as panels to build websites); or if you want to update the SSL certificate in a specific directory like I did this time, you will need to use acme.sh.

How ACME works

ACME (Automatic Certificate Management Environment) is a protocol for automating the acquisition, installation, and renewal of SSL/TLS certificates. Its core functions include verifying domain ownership and generating, issuing, and managing certificates.

The ACME protocol workflow generally includes the following steps:

1. Register for an account：The client registers an account with a server that supports the ACME protocol (such as Let's Encrypt). Usually, it needs to provide contact information (this is not necessarily the case. Let's Encrypt does not require it, while ZeroSSL requires a valid email address) so that it can remind you 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 name verification request, and the ACME server returns a challenge, requiring the client to prove its control over the target domain name. 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 a certificate：After verification, 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. Issuance of certificate：After the ACME server verifies the information in the CSR, if there is no problem, it will generate and issue a certificate. The client obtains 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 name ownership and obtain a new certificate.

Install acme.sh

Preparation

Before installing acme.sh, make sure you have the latest list of root certificates in your system to verify the certificates for HTTPS connections, otherwise there may be some problems when generating free SSL certificates:

apt update apt install ca-certificates

Installation method selection

Script installation method

There are several ways to install acme using scripts:

1. From the webhttps://get.acme.shInstall:

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

2. 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]

3. 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]

4. 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."

Parameter Description:

• --home: Specify acme.sh A custom directory for installation. By default,acme.sh Installed on ~/.acme.sh directory.
• --config-home: Specify a writable folder.acme.sh All files (including certificates, keys, configuration) will be written to this directory. By default, this directory is located at --home middle.
• --cert-home: Specify a custom directory for storing issued certificates. By default, certificates are stored in --config-home middle.
• --accountemail: The email address used to register your Let's Encrypt account. You will receive renewal notification emails to this email address.
• --accountkey: The file that stores the account private key. By default, this file is saved in --config-home middle.
• --useragent: Specifies the URL sent to Let's Encrypt User-agent The value of the request header.
• --nocron: During installation acme.sh Do not create a cron job.

Note 1: As described in the "How ACME Works" section, when acme.sh uses Let's Encrypt or other CAs to apply for a certificate, you need to register an account (usually called an ACME account), which is bound to an email address.[email protected]" is the email address used when registering this ACME account. This email address is used in the following situations: to receive important notifications from CAs (such as Let's Encrypt), such as certificate expiration reminders and security updates; and as the account's identity information, used to manage certificate and account changes, revocations, and other operations. Although it is not a required parameter, it is strongly 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 installation program will automatically perform the following operations:

1. Install acme.sh to the ~/.acme.sh directory, that is, the .acme.sh folder under the home directory:

2. Automatically set a cronjob at 0:00 every day to check the status of all certificates. If the certificate is about to expire, it will be automatically updated (available), which can be viewed with 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 scheduled tasks later.

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

Docker way

For some environments that are not suitable for script installation, you can use docker to simulate the effect of script installation of acme. The following command allows acme in docker to run 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

This result is similar to the script installation to some extent, except that running acme requires the use of the commanddocker exec acme.shAt the same time, you need to manually start and run docker acme.

Note: Why can't you use the "--restart=always" option to make docker acme run automatically at startup? Because "--rm" and "--restart=always" are mutually exclusive. In theory, "--rm" is more suitable for running acme in docker mode.

Additional knowledge: acme.sh domain name authentication method

There are three main authentication methods for acme.sh to prove the client's control over the domain name:

1. HTTP-01 Challenge (webroot)

• Principle: The client places a file containing a challenge string in the specified path under the target domain name (usually http://yourdomain/.well-known/acme-challenge/), and the ACME server requests this file through HTTP to verify domain name ownership.
• Scenario: Applicable to scenarios where a web server can directly provide content.
• Advantages: Simple and easy to use, suitable for common website environments.
• Disadvantages: It needs to rely on an existing web server (Nginx or Apache), and the server pointed to by the target domain name can be accessed to the .well-known/acme-challenge path.

Note: This method also has a special mode, "standalone," enabled with the "--standalone" flag. In this mode, acme.sh will automatically start a temporary web server listening on port 80 or 443 to handle verification requests from a designated CA (such as Let's Encrypt). However, "standalone" mode is not practical because it requires ports 80 and 443 to be free, which are usually occupied by web servers. (Unless you have a dedicated server dedicated to certificate management that doesn't directly host any websites, in which case you can use "--standalone" mode to manage certificates and then distribute them to other servers.)

2. DNS-01 Challenge

• Principle: The client needs to add a special TXT record in the DNS record of the target domain name, which contains the challenge string provided by the ACME server. The ACME server looks up the record through DNS to verify the domain name ownership.
• Scenario: Applicable to situations where the target server cannot be directly controlled or the target domain name is resolved to multiple IP addresses.
• Advantages: No need to expose ports or server availability, just access to DNS records.
• Disadvantage: Requires write access to DNS records.

Note: There is another implementation method for this method, "API Verification", which requires users to provide their own domain name provider API interface authentication information. This method can complete the verification automatically without user intervention.

3. TLS-ALPN-01 Challenge

• Principle: The client responds to the TLS handshake request using a specific ALPN protocol (Application Layer Protocol Negotiation, usually acme-tls/1) on the target domain name. The ACME server attempts to establish a TLS connection with the client and verifies whether the challenge response is correct in the handshake.
• Scenario: Applicable to scenarios where HTTP-01 or DNS-01 cannot be used, especially services that can only communicate using specific TLS protocols.
• Advantages: No need to expose HTTP port, only TLS (usually 443) port needs to be opened.
• Disadvantages: Precise control over the server's TLS configuration is required, and the client needs to support the ALPN protocol and also needs to occupy port 443, so it has similar problems to "standalone".

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

Note: In addition to the ACME server verifying the control of the domain name when you first apply for an SSL certificate, the ACME server will check the ownership of the domain name again in the same way (HTTP, DNS) as when you applied for each certificate renewal. Therefore, please ensure that after the initial application, the verification related content (access to the .well-known path or DNS records) can remain unchanged.

acme.sh in action

Preparation

Use alias to create an alias for the acme.sh script (optional)

usealiasThe command displays the existing alias. If not, for ease of use, you need to use the alias command to create an alias "acme.sh" for the acms.sh script:

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

Note: In theory, this step should be performed automatically when installing using a script, but for some reason I found that it did not work after installing it using the script, so I added a step myself. If you find that there is this alias after the script is installed, you do not need to add it manually.

Changing the Default CA

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. It is not impossible to use ZeroSSL as the default CA, but one thing is that you need to register when you use ZeroSSL for the first time, and you will be forced to provide a valid email address when registering, which means you have to verify your email address. This is a bit annoying, so it is generally recommended to switch back to letsencrypt for the sake of convenience, using the following command:

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

Acme also supports other CAs, you can choose as needed:

Register an account on the ACME server (optional)

This step is not necessary. Some CAs will automatically generate an account based on the domain name even if you have not registered (such as Let's Encrypt), while some CAs will strictly check the validity of the email address (such as ZeroSSL). However, even if Let's Encrypt does not have strict requirements, I still recommend providing a valid email address so that you can easily receive notifications from Let's Encrypt (such as notifications about the certificate expiring).

If you don't have a corresponding ACME server account, you can register a new account using the following command

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

This way you can register an account on the ACME server (CA) and associate it with your own email address.

If you already have an account but no associated email address, you can update the email address separately using the following command:

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

Note: If the email address provided when installing using the script is real, an account will be automatically created on the corresponding ACME server using the email address (of course, it depends on whether the ACME server needs to verify the validity of the email address, so this step cannot be avoided). There is no need to recreate it separately, so I said this step is optional.

Apply for a certificate using acme.sh

Additional knowledge: What does acme.sh do?

When you apply for an SSL certificate for the first time using acme.sh, after passing the domain name verification on the ACME server, the local acme.sh script will be placed in the path~/.acme.sh/yourdomainThe following main certificate files are generated in (one folder for each domain name):

1. yourdomain.key: Private key file. This file contains the private key used to decrypt SSL traffic.
2. yourdomain.cer: Certificate file. It contains the public key certificate issued by the ACME server.
3. yourdomain.fullchain.cer: The complete certificate chain file. It contains the combination of the domain name certificate and the intermediate certificates, which is used in most web server configurations.
4. ca.cer: CA certificate file. It contains the root certificate and intermediate certificates used to issue the certificate.

Then, each time the certificate is automatically renewed, except for the private key file, which will not change (unless manually specified), the certificate file and the complete certificate chain file will be automatically updated. The CA certificate file generally does not change, but it may change (for example, the CA is changed from Let's Encrypt to ZeroSSL, or although it is the same CA, the certificate chain has changed, such as Let's Encrypt will switch the default intermediate certificate from R3 to E1 at the end of 2021).

So, to sum up, acme.sh is actually specifying the path (the default is~/.acme.sh/) generates 4 files (private key file, certificate file, complete certificate chain file, CA certificate file) in the corresponding domain name folder under the root directory, and continuously updates the certificate file and complete certificate chain file, and updates the CA certificate file as needed.

Note 1: If you do not want to use the default~/.acme.sh/Path, you can use--config-homeIf you only want to change the storage path of the certificate file, you can use--cert-homeParameters are changed so that except for the certificate file, other configuration files will remain in~/.acme.sh/in the path.

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

Two ways to apply for a certificate with acme.sh

Apply using script

HTTP authentication method (webroot)

If acme.sh is applying for a certificate for an existing website domain name, assuming the domain name for which the certificate is required is "www.tangwudi.com", then the command for 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 request to generate a certificate
• -d Specify the domain name for which the certificate needs to be generated. If you generate multiple domain names at one time, you can have multiple-d
• --webroot /home/wwwroot/www.tangwudi.com/ Specify the actual location of the root directory of the website corresponding to the domain name

Note 1: In addition to using--webrootIn addition to this method of directly specifying the root directory of the corresponding website, there are other--nginxand--apacheThese two methods correspond to the cases where the web server is nginx and apache. However, these two methods depend on the default installation path and configuration of the web server. If the web server is not installed according to the default path or does not have permission to reload the service, it may cause trouble. Therefore, if only one domain needs SSL, it is best to use--webrootWay.

Note 2: When using HTTP authentication, make sure that the website itself can be accessed normally andhttp://yourdomain/.well-known/acme-challenge/The path must be 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 name certificate, you must use the DNS verification method.

DNS verification method

Manual method

1. 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:

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

3. Use--renewParameters to regenerate the host certificate of 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 you to manually create txt records. Instead, you need to verify through the domain name provider's API. Therefore, you need the authentication information of the API interface corresponding to your domain name provider's account (usually API ID and API key, which vary from DNS provider to DNS provider). The following is the API and API parameter verification information of some DNS providers:

Taking the 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. The link is as follows:Alibaba Cloud RAM Users

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 name certificate for tangwudi.com:

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

Note 1: In the above command, the "dns_ali" following the "--dns" parameter is generally "dns_service provider abbreviation". For example, here it is "dns_ali". If Tencent dnspod is used, it is "dns_dp". If Cloudflare is used, it is "dns_cf". However, there are exceptions, so it is best to confirm before deployment. For details, please refer to "ACME-powered domain provider API".

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

Note 3: The dns verification method does not require the support of the http environment and is more adaptable (for example, this time I want to automatically renew the SSL certificate of the derp application). The only disadvantage is that it requires control over the domain name. Some friends who only have control over the website but not the domain name (for example, using a virtual host to build a website) are not suitable. At this time, the http verification method is more suitable, so everyone can choose the appropriate method according to their actual environment.

Note 4: acme.sh supports Cloudflare in two ways:
1. CF_Key + CF_Email are only used when using the Global API Key; 2. When using a regional API Token (officially recommended by CF) instead of a global key, CF_Token should be used instead of CF_Key. Everyone must pay attention to this, as I also fell into the trap.

Apply using docker

This method is an alternative solution in an environment where it is inconvenient to apply using a script. In essence, it uses the docker exec command to run acme running in docker as a script. In the previous part of the article, I talked about how to run acme in docker as a daemon process. 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

I feel that it is most convenient to apply for certificates using Docker and choose API verification, so don't bother with other methods. However, the principles are actually the same. Choosing other methods will be more troublesome. It depends on you.

---

In fact, if you apply using Docker, it is not necessary to deploy this step in advance. A one-time command is also possible, for example:
(1) –webroot mode

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

(2) –dns mode

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

It depends on what everyone likes.

---

Certificate deployment

Certificate deployment for general environments

By default, acme will only update~/.acme.sh/yourdomainThe certificates in the path are only used internally by ACME (the folder structure may be changed as needed). It is not recommended to use them directly, so do not use the cp command directly to copy the certificate files in the path to other locations.

If you need to deploy the certificate to another location, the official way is to use the "install" parameter and specify the target location where the certificate file needs to be copied. Take 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 \ --reloadcmd "service nginx force-reload"

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"

---

The number of SSL certificates required for Nginx is different from that for Apache.

• Nginx: Usually only 2 files are required (certificate file + private key), and the intermediate certificate can be merged into the certificate file.
• Apache: Usually 3 files are required (certificate file + private key + intermediate certificate), and the intermediate certificate needs to be configured separately.

---

In fact, the "install" parameter is essentially a copy, but using the "install" parameter is equivalent to telling acme where the certificate of the domain name "tangwudi.com" is copied. In the future, when acme updates~/.acme.sh/tangwudi.comWhen updating the certificates under the path, the certificates with specific copy destinations will also be associated and updated.

Of course, don't forget to use the certificate in the Nginx or Apache configuration. Take Nginx as an example:

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 environment

You should have discovered that the key to the above command is actually not related to whether it is deployed to Nginx or Apache. The only thing that is relevant to Nginx and Apache is the last parameter.--reloadcmd "service nginx force-reload"and"--reloadcmd "service apache2 force-reload"That's it.

In other words, the real key is just the following command (remember which certificate files will be updated when the certificate is updated?):

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 \

To further sublimate, in essence, Acme only cares about the validity of the certificate file corresponding to the domain name and the directory where the certificate file that needs to be updated is located. As for where the certificate is used (Nginx, Apache deployed in source code mode, Nginx, Apache deployed in Docker mode, or simply a certificate in a certain directory), Acme does not care at all.

However, since it is not recommended to move the certificate by directly copying it, and you can only use the "install" parameter, then the problem arises: the direct path specification method is only suitable for environments where acme, Nginx, or Apache are all deployed directly. It is not suitable for some other unconventional environments, such as: acme is deployed on the host machine as a script, while Nginx or Apache is deployed using Docker (the certificate folder inside the container is not mounted); or acme itself is also running in Docker, etc.

Due to various complex deployment environments, acme has to worry about passing certificates (the --install-cert method has limitations). For example, in order to pass the certificate to Nginx deployed in docker mode, you need to give Nginx a "label", then use the export command to set the environment variables, and finally use acme.sh--deployand--deploy-hook dockerparameter:

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

I will just mention this part, and I won't say much. Generally, you won't encounter it. If you really need it, you can directly refer to the link on the official github:deploy-to-docker-containers.

acme.sh operation and maintenance

acme.sh upgrade

If you need to upgrade acme (script installation), just use the following command:

acme.sh --upgrade

To enable automatic updates:

acme.sh --upgrade --auto-upgrade

To turn off automatic updates:

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

To upgrade acme in docker mode, just follow the normal process of docker upgrade, and I won’t go into details here.

acme.sh debug mode

If errors occur during acme execution, in addition to viewing 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

acme.sh view certificate information

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

acme.sh --info -d tangwudi.com

Summarize

In fact, the general use of acme.sh is very simple, and there is no need for such a long explanation. Moreover, I just wanted to solve the problem of updating the derp server certificate on the cloud server. In theory, it can be done with a few commands.

However, out of habit, I still went to the homepage of acme.sh on GitHub and found that there are quite a lot of things. Most of the tutorials on the Internet are about the configuration of the most basic scenarios. A lot of content is not mentioned (because it is generally not used), and the principles are also rarely involved. So I thought about it and thought it would be better to write a more detailed tutorial so that if you encounter less basic scenarios in the future, you can still use it as a manual.

Even so, there is still a lot of content that I haven't talked about (because I really don't feel it is useful~). Friends who are interested can take a look at the official documentation, the address is as follows:acme.sh github official address.

In addition: In fact, acme.sh combined with syncthing or other synchronization solutions can also achieve "unified issuance center + multi-node certificate distribution". If you have needs, you can study it yourself.