前言
前几天忽然收到腾讯云发来的域名SSL证书过期提醒:
这个域名是我用来给云主机上部署的derp(tailscale中继服务器,相关内容大家有兴趣的话可以看看之前的文章:debian系列 搭建tailscale DERP server(中继服务器)之傻瓜书)用的,之前腾讯云还可以申请1年期的免费DV证书,我琢磨着一年弄一次证书也无所谓,就将就着用了2年,不过现在嘛:
已经没戏了,3个月让我弄一次不如杀了我算了(花钱更不可能),所以我不得不考虑传统的免费SSL证书自动续期解决方案:acme.sh。
注1:我之前其实一直是知道acme.sh的,只是一直懒得搞(一年一次嘛,我可以接受),而其他需要自动续期SSL证书的场合大都自带了acme功能,也用不着单独折腾。不过现在既然被逼上梁山,那就干脆仔细研究研究,也好趁机水一篇文章。
注2:ACME协议的客户端除了acme.sh也还有其他选择,比如certbot,只不过,acme.sh足够轻量化,不用安装什么依赖,我本来需求就简单:只是需要对derp服务器上一个目录里的证书实现自动续期即可,没有其他什么要求,也不需要和Nginx和Apache集成,acme.sh刚好可以满足我。而certbot的优势在于和Nginx和Apache的高度集成(有专门的Nginx和Apache插件)和更全面的功能,这些我目前都用不上,所以权衡之后选择了acme.sh。
注3:acme.sh的方式只适合更新证书存放在本地的场景,而现在大多数网站都使用了CDN,这时候acme.sh就发挥不了作用了(证书在CDN上)。如果要实现自动更新CDN上的免费证书,请参考另一篇文章:家庭数据中心系列 SSL证书一站式管理工具OHTTPS使用教程。
ACME协议介绍
本文讲的”acme.sh”,其实只是一个比较出名的ACME客户端工具而已。市面上大多数能够自动更新 SSL 证书的应用(如宝塔面板、1Panel面板等)通常都集成了ACME相关工具来处理证书的申请、验证和更新,这是因为ACME协议是目前申请和管理免费的 SSL 证书(尤其是 Let’s Encrypt)的标准协议。
我们日常生活中很多场合都能接触到ACME:
1. 集成ACME的应用和面板
• 宝塔面板:宝塔面板集成了Let’s Encrypt的证书申请功能,并且提供了自动更新的功能。它在后台使用acme.sh或 certbot 之类的工具来处理证书申请和更新。
• 1Panel:类似于宝塔,1Panel 也支持一键申请和自动更新SSL证书,其也是使用acme.sh来进行证书管理。
• 其他面板(如 CPanel、Plesk 等):这些面板也都内置了对 Let’s Encrypt 的支持,通常通过集成 acme 协议的客户端(如 certbot 或acme.sh)来处理证书。
2. 典型的ACME客户端工具
• acme.sh:一个纯 Shell 脚本实现的ACME客户端,支持大部分 CA(如 Let’s Encrypt、ZeroSSL 等),可以轻松管理各种类型的证书(如泛域名证书、ECC/RS256 证书等)。很多应用和面板都集成了acme.sh,因为它轻量、兼容性强、依赖少,它也是本文的主角。
• certbot:由 Electronic Frontier Foundation (EFF) 提供的官方ACME客户端,功能强大,特别是在 Apache 和 Nginx 上的集成度高。certbot 支持各种自动化操作和插件,可用于复杂场景下的证书管理。
• lego:一个用 Go 语言编写的ACME客户端,提供了一些高级功能(如 DNS 验证),适合开发者在需要自定义功能时使用。
注:如果本身建站使用了集成ACME功能的面板(比如宝塔面板、1Panel面板),是不需要单独来配置acme.sh的。需要使用acme.sh的是纯净部署Nginx或者Apache(熟练工更喜欢一切尽在掌握的感觉,不会用面板之类的工具来建站);或者像我这次一样就为了单独更新一个特定目录里的SSL证书,才会有使用acme.sh的需求。
ACME工作原理
ACME(Automatic Certificate Management Environment)是一种协议,用于自动管理 SSL/TLS 证书的获取、安装和更新。它的核心工作主要包括”验证域名所有权”和”生成、签发和管理证书”。
ACME 协议的工作流程通常包括以下步骤:
- 注册帐户:客户端向支持ACME协议的服务器(例如Let’s Encrypt)注册帐户,通常需要提供联系信息(这个其实不一定,Let’s Encrypt就不需要,而ZeroSSL就需要提供有效邮箱),以便在证书即将到期时进行提醒。注册后,客户端会获得一个账户密钥(Account Key)。
- 验证域名所有权:客户端发起一个域名验证请求,ACME 服务器会返回一个挑战(Challenge),要求客户端证明其对目标域名的控制权。客户端必须通过特定的验证方式(例如 HTTP-01、DNS-01 或 TLS-ALPN-01)来响应挑战。
- 申请证书:验证完成后,客户端可以生成一个证书签名请求(Certificate Signing Request, CSR),并将其提交给 ACME 服务器。CSR 包含了域名、申请者公钥等信息。
- 签发证书:ACME 服务器验证 CSR 中的信息后,如果没有问题,就会生成并签发证书。客户端获取证书并存储到本地。
- 自动续期:在证书到期前,ACME 客户端会自动发起续期流程,重新验证域名所有权并获取新证书。
安装acme.sh
准备工作
安装acme.sh之前,确保系统中有最新的根证书列表,用来验证 HTTPS 连接的证书,否则在生成免费 SSL 证书时可能会出现一些问题:
apt update
apt install ca-certificates
安装方式选择
脚本安装方式
使用脚本方式安装acme有多种方式可选:
1、从webhttps://get.acme.sh
安装:
curl https://get.acme.sh | sh -s [email protected]
2、从GitHub安装:
curl https://raw.githubusercontent.com/acmesh-official/acme.sh/master/acme.sh | sh -s -- --install-online -m [email protected]
或者
wget -O - https://raw.githubusercontent.com/acmesh-official/acme.sh/master/acme.sh | sh -s -- --install-online -m [email protected]
3、使用”git clone”方式安装:
git clone --depth 1 https://github.com/acmesh-official/acme.sh.git
cd acme.sh
./acme.sh --install -m [email protected]
4、高级安装
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."
参数说明:
--home
:指定acme.sh
安装的自定义目录。默认情况下,acme.sh
安装在~/.acme.sh
目录下。--config-home
:指定一个可写的文件夹,acme.sh
会将所有文件(包括证书、密钥、配置)写入此目录。默认情况下,这个目录位于--home
中。--cert-home
:指定一个自定义目录用于保存已签发的证书。默认情况下,证书会保存在--config-home
中。--accountemail
:用于注册 Let’s Encrypt 账户的邮箱地址,你将会在此邮箱接收到续期通知邮件。--accountkey
:保存账户私钥的文件。默认情况下,这个文件保存在--config-home
中。--useragent
:指定发送到 Let’s Encrypt 的user-agent
请求头的值。--nocron
:在安装acme.sh
时不创建定时任务(cron job)。
注1:如”ACME工作原理”部分的描述,acme.sh在使用 Let’s Encrypt 或其他 CA 颁发机构申请证书时,需要注册一个账户(通常称为 ACME 账户),这个账户与一个邮箱地址绑定。上述命令中的”[email protected]
” 就是注册这个 ACME 账户时使用的邮箱地址。该邮箱地址会在以下情况下使用:接收来自 CA(如 Let’s Encrypt)的重要通知,例如证书到期提醒、安全更新等;作为账户的身份信息,用于管理证书和账户的变更、撤销等操作。虽然不是必须的参数,但强烈推荐使用有效的邮箱地址,以便你能够及时接收到证书到期提醒和其他相关通知。
注2:安装程序会自动执行以下操作:
1.将acme.sh安装到 ~/.acme.sh 目录中,即 home 目录下的 .acme.sh 文件夹:
2.自动设置一个每日 0:00 的定时任务(cronjob),用来检查所有证书的状态。如果证书即将到期,它会自动更新(可用),可用以下命令查看:
crontab -l
注:如果没有安装cron,这步操作会失败,不过也无妨,后续自己安装crontab并添加定时任务即可。
3.自动为acme.sh脚本创建一条alias方便平时使用: alias acme.sh=~/.acme.sh/acme.sh
,不过我在两台设备上安装都没有自动创建。
docker方式
对于一些不适合脚本方式安装的环境,可以使用docker方式来模拟脚本安装acme的效果,以下命令让docker内的acme以守护进程方式运行:
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
这种结果某种程度上也算实现了和脚本安装类似的效果,只是运行acme需要使用命令docker exec acme.sh
的方式,同时,需要手动实现docker acme开机运行的效果。
注:为什么不能使用”–restart=always”选项让docker acme开机自动运行呢?因为”–rm”和”–restart=always”是互斥的,理论上来说”–rm”更合适docker方式运行的acme。
附加知识:acme.sh域名认证方式
acme.sh主要有三种验证方式,用于证明客户端对域名的控制权:
- HTTP-01 Challenge(webroot)
• 原理:客户端在目标域名下的指定路径(通常是http://yourdomain/.well-known/acme-challenge/)放置一个包含挑战字符串的文件,ACME服务器通过 HTTP 请求这个文件来验证域名所有权。
• 场景:适用于 Web 服务器可以直接提供内容的场景。
• 优点:简单易用,适合常见的网站环境。
• 缺点:需要依赖于已有的web服务器(Nginx或者Apache),且目标域名指向的服务器能够被访问到 .well-known/acme-challenge 路径。
注:该方式还有一种特殊模式”standalone”,通过”–standalone”参数开启,此时,acme.sh会自己启动一个临时的 Web 服务器,监听 80 或 443 端口,用于处理来自指定CA(比如Let’s Encrypt) 的验证请求。不过,”standalone”模式并不实用,因为要求80、443端口空闲,而正常情况下这2个端口基本都被web服务器占用了(除非是有一台专门用来管理证书的服务器,并不直接承载任何网站服务,可以利用”–standalone”模式来管理证书,然后将证书分发到其他服务器上)。
- DNS-01 Challenge
• 原理:客户端需要在目标域名的 DNS 记录中添加一个特殊的 TXT 记录,包含 ACME 服务器提供的挑战字符串。ACME 服务器通过 DNS 查找该记录以验证域名所有权。
• 场景:适用于不能直接控制目标服务器或目标域名解析到多个 IP 的情况。
• 优点:不需要暴露端口或服务器可用性,只需访问 DNS 记录即可。
• 缺点:需要对 DNS 记录的写入权限。
注:该方式还有另一种实现方式”API验证”,需要使用者提供自己域名供应商API接口的身份验证信息,这种方式可以不需要使用者干预而自行完成验证。
- TLS-ALPN-01 Challenge
• 原理:客户端在目标域名上使用特定的 ALPN 协议(应用层协议协商,通常是 acme-tls/1)响应 TLS 握手请求。ACME 服务器会尝试与客户端建立 TLS 连接,并在握手中验证挑战响应是否正确。
• 场景:适用于无法使用 HTTP-01 或 DNS-01 的场景,特别是只能用特定的 TLS 协议进行通信的服务。
• 优点:不需要暴露 HTTP 端口,只需要开放 TLS(通常是 443)端口。
• 缺点:需要对服务器的 TLS 配置有精确的控制,且客户端需要支持 ALPN 协议,并且也需要占用443端口,所以和”standalone”有类似的问题。
最终,域名方式最常用的就是”HTTP-01 Challenge(webroot)”和”DNS-01 Challenge”这两种方式。
注:除了在初次申请SSL证书时ACME服务器会验证域名的控制权之外,之后每次证书更新(续期)时,ACME服务器都会再次按照申请时的方式(HTTP、DNS)检查域名的所有权,所以请保证在初次申请之后,验证相关的内容(.well-known 路径的访问或者DNS的记录)能够保持不变。
acme.sh实战
准备工作
更改默认CA
acme.sh在 2021 年被 ZeroSSL 的母公司(Apilayer)收购,并且在收购后,acme.sh默认的证书颁发机构(CA)被更改为 ZeroSSL。使用ZeroSSL作为默认CA其实也不是不行,但是有一点是,首次使用ZeroSSL时需要注册,且注册的时候会强制要求你提供一个有效邮箱,也就是说有验证邮箱的动作,这个有点烦,所以一般图省事还是建议改回letsencrypt,使用如下命令:
acme.sh --set-default-ca --server letsencrypt
acme还支持其他CA,大家可以按需选择:
使用alias为acme.sh脚本创建别名(可选)
使用alias
命令显示已有的alias,如果没有,为了方便使用,需要使用alias命令为acms.sh脚本创建一个别名”acme.sh”:
alias acme.sh=~/.acme.sh/acme.sh
注:理论上这步工作应该是使用脚本方式安装时自动进行的,不过不知道为什么我用脚本安装后发现没生效,所以自己加一步,如果大家发现脚本安装后有这条alias就不需要手动再添加了。
在ACME服务器注册一个账号(可选)
这一步也不是必须的,有些CA即便没有注册的动作,也会自动根据域名生成一个账号(比如Let’s Encrypt),而有些CA会严格检验邮箱的有效性(比如ZeroSSL)。不过,即便是没有严格要求的Let’s Encrypt,我仍旧建议提供有效的邮箱地址,这样方便接收Let’s Encrypt发来的通知(比如证书即将到期的通知)。
如果之前没有对应的ACME服务器账号,可以使用如下命令注册一个新账号
acme.sh --register-account --accountemail [email protected]
这样可以在使用的ACME服务器(CA)上注册一个账号的同时关联上自己的邮箱地址。
如果本来已经有账号,但是没有关联邮箱地址,可以使用如下命令单独更新邮箱地址:
acme.sh --update-account --accountemail [email protected]
注:如果在使用脚本方式安装时提供的邮箱地址是真实的,会自动在对应的ACME服务器上使用该邮箱地址创建账号(当然要看ACME服务器是否需要校验邮箱有效性,这步还是逃不了的),就不需要单独重新创建了,所以我才说这一步是可选步骤。
使用acme.sh申请证书
附加知识:acme.sh都做了些什么?
使用acme.sh初次申请SSL证书时,在通过ACME服务器的域名验证之后,本地的acme.sh脚本会在路径~/.acme.sh/yourdomain
(每个域名一个文件夹)中生成以下几个主要的证书文件:
- yourdomain.key:私钥文件。这个文件包含了用于解密 SSL 流量的私钥。
- yourdomain.cer:证书文件。它包含了由 ACME 服务器签发的公钥证书。
- yourdomain.fullchain.cer:完整证书链文件。它包含了域名证书以及中间证书的组合,用于大多数 Web 服务器配置。
- ca.cer:CA证书文件。它包含了签发证书的根证书和中间证书。
而后每次自动续期时,除了私钥文件不会变(除非手动指定),证书文件和完整证书链文件都会被自动更新,而CA证书文件一般不会变,但是也可能会变(比如更换了CA,从 Let’s Encrypt更换到ZeroSSL,或者虽然同一个CA,但是证书链发生了变化,比如Let’s Encrypt 在 2021 年底将默认中间证书从 R3 切换到 E1)。
所以,一句话总结的话,acme.sh其实就是在指定路径(默认是~/.acme.sh/
)下对应的域名文件夹里生成4个文件(私钥文件、证书文件、完整证书链文件、CA证书文件)并持续更新其中的证书文件、完整证书链文件,同时视需要更新CA证书文件。
注1:如果不想使用默认的~/.acme.sh/
路径,可以使用--config-home
参数进行更改;如果只想改证书文件的存储路径,可以使用--cert-home
参数进行更改,这样除了证书文件,其他的配置文件仍旧会留在~/.acme.sh/
路径中。
注2:~/.acme.sh/account.conf
是acme.sh的全局配置文件,包含用户的 ACME 账户信息(例如账户的密钥和 API URL)。
acme.sh申请证书的2种方式
使用脚本方式申请
HTTP验证方式(webroot)
如果acme.sh是为已有网站的域名申请的证书,假设需要申请证书的域名为”www.tangwudi.com
“,那么基于脚本并使用webroot方式进行域名验证的命令如下:
acme.sh --issue -d www.tangwudi.com --webroot /home/wwwroot/www.tangwudi.com/
--issue
表示请求生成证书-d
指定需要生成证书的域名,如果一次性生成多个域名可以有多个-d
--webroot /home/wwwroot/www.tangwudi.com/
指定域名所对应网站根目录的实际位置
注1:除了使用--webroot
方式直接指定对应网站的根目录这种方式以外,其他还有--nginx
和--apache
这两种方式,分别对应web服务器是用的nginx和apache这两者情况,不过,这两种方式依赖于Web 服务器的默认安装路径和配置,如果Web 服务器没有按默认路径安装,或者没有权限重载服务,都可能带来麻烦,所以如果只有一个域名需要SSL的话,最好使用--webroot
方式。
注2:使用HTTP验证方式,一定要确保网站本身能正常访问以及http://yourdomain/.well-known/acme-challenge/
路径下是可以访问的,否则肯定会失败。
注3:HTTP验证方式只能验证单个的域名,如果要申请泛域名证书,必须使用dns验证方式。
dns验证方式
手动方式
1、在本地用acme.sh生成一条txt记录
命令如下(使用时请大家自行把tangwudi.com替换为自己的域名):
acme.sh --issue --dns -d tangwudi.com --yes-I-know-dns-manual-mode-enough-go-ahead-please
然后记录生成的txt记录内容:
2、在域名供应商的控制台添加txt记录:
3、使用
--renew
参数重新生成tangwudi.com的主机证书:
acme.sh --renew -d tangwudi.com --yes-I-know-dns-manual-mode-enough-go-ahead-please
API方式
这种方式不再需要自己手动创建txt记录,而是改为通过域名供应商的API来验证,所以需要自己在域名供应商的账号对应的API接口的身份验证信息(一般是API ID和API key,不同DNS供应商对应的名称有所不同),以下是部分DNS供应商的API及API参数验证信息:
以域名托管在阿里云上为例,首先获取aliyun的Ali_Key和Ali_Secret:
创建一个新的AccessKey:
也可以使用阿里云现在推荐的RAM访问控制的方式来创建,链接如下:阿里云RAM用户
获取到Ali_Key和Ali_Secret之后,使用export命令导出为环境变量:
export Ali_Key="xxxxxxxx"
export Ali_Secret="xxxxxxxxxxxxx"
最后使用如下命令即可生成tangwudi.com的泛域名证书:
acme.sh --issue --dns dns_ali -d *.tangwudi.com
注1:上面命令中”–dns”参数后面跟着的”dns_ali”,一般来说是”dns_服务商简称”,比如这里就是”dns_ali”,而如果采用腾讯dnspod,就是”dns_dp”,如果采用cloudflare,就是”dns_cf”,不过也有例外,所以大家最好还是在部署之前确认一下,具体可以参考”ACME支持的域名供应商API“。
注2:我在手动方式中使用的”-d tangwudi.com”和API方式中使用的”-d *.tangwudi.com
“,前一个是生成”tangwudi.com”这个域名对应的主机证书,而后一个是生成”tangwudi.com”对应的泛域名证书,两者完全不一样,后者可以匹配二级域名”tangwudi.com”下的任意主机证书,这点大家一定要注意,一般来说,直接生成泛域名证书就够了,不用单独申请主机证书。
注3:dns验证方式不需要http环境的支持,可适应性更强(比如我这次是为了自动续期derp应用的SSL证书),唯一的劣势是需要对域名的控制权,一些只对网站有控制权而对域名没有控制权的朋友(比如采用虚拟主机方式建站)就不合适了,这时http验证方式更适合,所以大家按照自己的实际环境选择适合的方式即可。
使用docker方式申请
这种方式是在不方便使用脚本方式申请的环境下的一个替代方案,本质上就是使用docker exec命令把docker中运行的acme当做脚本来运行。在文章前面部分我讲过如何让docker内的acme以守护进程方式运行,在这个前提下,只需要运行如下命令:
docker exec \
-e Ali_Key="xxxxxxxx" \
-e Ali_Secret="xxxxxxxxxxxxx" \
acme.sh --issue -d tangwudi.com --dns dns_ali
感觉使用docker方式申请证书选择API验证的方式最方便,就不要折腾其他的了,不过原理其实都一样,选其他方式就更折腾一点,看大家了。
其实采用docker方式申请,提前部署这个步骤并不是必须的,一次性命令也是可以的,比如:
(1) –webroot 模式
docker run --rm -it \
-v /docker/acme.sh:/acme.sh \
neilpang/acme.sh --issue -d tangwudi.com --webroot /acme.sh/webroot
(2) –dns 模式
docker run --rm -it \
-v /docker/acme.sh:/acme.sh \
neilpang/acme.sh --issue -d tangwudi.com --dns dns_cf
就看大家喜欢了。
证书部署
常规环境的证书部署
默认情况下,acme只会更新~/.acme.sh/yourdomain
路径下的证书,该路径下的证书只是acme内部使用(可能会因为需要而更改文件夹结构),并不推荐直接拿来用,所以不要直接使用cp命令将路径下的证书文件拷贝到其他位置。
如果需要将证书部署到其他位置,正规的方式是使用官方的”install”参数,详细指定证书文件需要拷贝到的目标位置,以将”tangwudi.com”的证书部署到Nginx中为例(实际路径请自行替换):
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"
部署到Apache中是一样的:
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"
Nginx所需SSL证书数量和Apache不同。
• Nginx:通常只需要 2 个文件(证书文件 + 私钥),中间证书可以合并在证书文件中。
• Apache:通常需要 3 个文件(证书文件 + 私钥 + 中间证书),中间证书需要单独配置。
其实”install”参数本质上也是拷贝,只不过使用”install”参数相当于告诉acme,域名”tangwudi.com”的证书具体拷贝到哪里去了,以后acme在更新~/.acme.sh/tangwudi.com
路径下证书的同时,会顺带把有具体拷贝去向的证书进行关联更新。
当然,最后不要忘记在Nginx或者Apache的配置中使用证书,以Nginx为例:
server {
listen 443 ssl;
ssl_certificate /path/to/fullchain/nginx/cert.pem;
ssl_certificate_key /path/to/keyfile/in/nginx/key.pem;
}
涉及docker环境的证书部署
大家应该已经发现了,上述命令的关键其实和部署到Nginx还是部署到Apache都没关系,和Nginx和Apache有关的只是最后一条参数--reloadcmd "service nginx force-reload"
和”--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 \
再升华一下,本质上来说,acme自始自终关心的只有设置域名对应的证书文件的有效性以及需要更新的证书文件所在的目录,至于证书用在什么地方(源码方式部署的Nginx、Apache,docker方式部署的Nginx、Apache,或者单纯只是某个目录中的证书),acme根本一点都不关心。
但是嘛,由于不推荐直接使用拷贝的方式来移动证书,只能使用”install”参数,那么问题就来了:直接指定路径的方式只适合acme、Nginx或者Apache均直接部署的环境,而一些其他非常规的环境,比如:acme以脚本方式部署在宿主机上,Nginx或者Apache却采用docker方式部署(容器内部的证书文件夹没有挂载出来);或者acme本身也是docker方式运行等等。
基于各种复杂的部署环境,acme不得不为了传递证书操碎了心(–install-cert方式有局限性),简单举例,为了传递证书进docker方式部署的Nginx,需要给Nginx打”label”,然后使用export命令设置环境变量,最后使用acme.sh的--deploy
和--deploy-hook docker
参数:
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
这部分内容我就提一下,不多说,一般大家也遇不上,如果确实有需求的朋友,可以直接参考官方github上的链接:deploy-to-docker-containers。
acme.sh运维
acme.sh升级
如果需要升级acme(脚本方式安装),只需要使用如下命令:
acme.sh --upgrade
如果要开启自动升级:
acme.sh --upgrade --auto-upgrade
如果要关闭自动升级:
acme.sh --upgrade --auto-upgrade 0
docker方式的acme升级,就按照docker升级的常规流程吧,这里不多说。
acme.sh调试模式
如果acme执行出现错误,除了查看日志以外,也可以使用”–debug 2″参数起开debug模式:
acme.sh --issue -d www.tangwudi.com --webroot /home/wwwroot/www.tangwudi.com/ --debug 2
acme.sh查看证书信息
如果需要查看域名的证书信息,使用如下命令:
acme.sh --info -d tangwudi.com
总结
其实acme.sh一般的使用非常简单,用不着如此长篇大论般的讲,而且我本来也只是为了解决云服务器上derp服务器证书的更新问题,讲道理几个命令就可以搞定了。
不过,因为习惯问题,我还是上github上acme.sh的主页看了看,结果发现东西还蛮多的,网上的教程大多都是讲最基本场景的配置,好多内容都没有谈到(因为一般也用不上),原理涉及得也较少,所以我想了想,觉得最好还是专门写一篇较为详细的教程,这样大家以后万一遇到不那么基本的场景时,还能够当手册查查。
但是,我仍旧还是有很多内容没有讲到(因为的确是感觉用不上~),感有兴趣的朋友可以看看官方的文档,地址如下:acme.sh github官方地址。
三个月一次确实太烦人了, 我现在直接域名丢给Cloudflare托管了。
即便我早就使用ohttps自动更新证书,也还是在年初放弃备案域名全面转移到cloudflare了,整体解决方案方面国内的供应商和cloudflare的Free计划比起来,真的一个能打的都没有~。
很全面,但是如果有cdn还得手动-.-
CDN的更新方式我已经在另一篇文章里写过了(家庭数据中心系列 SSL证书一站式管理工具OHTTPS使用教程),这种更新方式反而不太适合本文中的这种场景,所以我纠结了半天还是选择使用acme.sh的方式。不过你倒是提醒我了,我在文章中补充一句~。