使用 certbot 代替 acme.sh 免费申请 wildcard 通配符证书和自动更新实践小结

[wsgzao]

前言

因为 Google Chrome 和运营商劫持干扰访问者体验的努力推动了大型网站加速应用全站 HTTPS，而Let's Encrypt这个项目通过自动化把配置和维护 HTTPS 变得更加简单，Let's Encrypt 设计了一个 ACME 协议目前版本是 v2，并在 2018 年支持通配符证书Wildcard Certificate Support is Live。官网主推的客户端是Certbot，任何人都可以基于 ACME 协议实现一个客户端，比如大名鼎鼎的acme.sh。本文主要使用certbot-dns-route53插件为例，由于 certbot 官方 DNS Plugins 插件支持有限，如果你需要支持 aliyun/tencentyun/godaddy dns 可以参考certbot-letencrypt-wildcardcertificates-alydns-au，随着 Docker 容器化和 K8S(Kubernetes)的进击，相信会促进 certbot 多样化玩法。

使用 certbot 代替 acme.sh 免费申请 wildcard 通配符证书和自动更新实践小结

更新历史

2020 年 02 月 19 日 - 初稿

阅读原文 - https://wsgzao.github.io/post/certbot/

---

基础知识

关于 HTTPS

引维基百科的说法

超文本传输安全协议（英语：Hypertext Transfer Protocol Secure，缩写：HTTPS ）是一种网络安全传输协议。在计算机网络上，HTTPS 经由超文本传输协议进行通信，但利用 SSL/TLS 来对数据包进行加密。HTTPS 开发的主要目的，是提供对网络服务器的身份认证，保护交换数据的隐私与完整性

HTTPS 的主要思想是在不安全的网络上创建一安全信道，并可在使用适当的加密包和服务器证书可被验证且可被信任时，对窃听和中间人攻击提供合理防护。

HTTPS 的信任继承基于预先安装在浏览器中的证书颁发机构（如 Symantec、Comodo、GoDaddy 和 GlobalSign 等）（意即“我信任证书颁发机构告诉我应该信任的”）。因此，一个到某网站的 HTTPS 连接可被信任，当且且当：

• 用户相信他们的浏览器正确实现了 HTTPS 且安装了正确的证书颁发机构；
• 用户相信证书颁发机构仅信任合法的网站；
• 被访问的网站提供了一个有效的证书，意即，它是由一个被信任的证书颁发机构签发的（大部分浏览器会对无效的证书发出警告）；
• 该证书正确地验证了被访问的网站（如，访问 https://example.com 时收到了给 example.com 而不是其他组织的证书）；
• 或者互联网上相关节点是值得信任的，或者用户相信本协议的加密层（ TLS 或 SSL ）不能被窃听者破坏。

HTTP 和 HTTPS 区别

HTTP 协议传输的数据都是未加密的，也就是明文的，因此使用 HTTP 协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了 SSL （ Secure Sockets Layer ）协议用于对 HTTP 协议传输的数据进行加密，从而就诞生了 HTTPS。简单来说，HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 HTTP 协议安全。

HTTPS 和 HTTP 的区别主要如下：

• HTTPS 协议需要到 CA 申请证书，一般免费证书较少，因而需要一定费用。
• HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。
• HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
• HTTP 的连接很简单，是无状态的； HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。

Types of SSL Certificates for a Secure Business Website

关于 TLS/SSL

传输层安全协议（英语：Transport Layer Security，缩写：TLS ），及其前身安全套接层（ Secure Sockets Layer，缩写：SSL ）是一种安全协议，目的是为互联网通信，提供安全及数据完整性保障

为什么要部署 HTTPS

说到底，就是 HTTPS 更安全。甚至为了安全，一个专业可靠的网站，HTTPS 是必须的。Firefox 和 Chrome 都计划将没有配置 SSL 加密的 HTTP 网站标记为不安全（貌似 Firefox 50 已经这么干了），目前它们也正在联合其他相关的基金会与公司推动整个互联网 HTTPS 化，现在大家访问的一些主要的网站。如 Google 多年前就已经全部启用 HTTPS，国内的淘宝、搜狗、知乎、百度等等也全面 HTTPS 了。甚至 Google 的搜索结果也正在给予 HTTPS 的网站更高的排名和优先收录权。

怎么部署 HTTPS

你只需要有一张被信任的 CA （ Certificate Authority ）也就是证书授权中心颁发的 SSL 安全证书，并且将它部署到你的网站服务器上。一旦部署成功后，当用户访问你的网站时，浏览器会在显示的网址前加一把小绿锁，表明这个网站是安全的，当然同时你也会看到网址前的前缀变成了 HTTPS，不再是 HTTP 了。

怎么获得 SSL 安全证书

理论上，我们自己也可以签发 SSL 安全证书，但是我们自己签发的安全证书不会被主流的浏览器信任，所以我们需要被信任的证书授权中心（ CA ）签发的安全证书。而一般的 SSL 安全证书签发服务都比较贵，比如 Godaddy、GlobalSign 等机构签发的证书一般都需要 20 美金一年甚至更贵，不过为了加快推广 HTTPS 的普及，EEF 电子前哨基金会、Mozilla 基金会和美国密歇根大学成立了一个公益组织叫 ISRG （ Internet Security Research Group ），这个组织从 2015 年开始推出了 Let’s Encrypt 免费证书。这个免费证书不仅免费，而且还相当好用，所以我们就可以利用 Let’s Encrypt 提供的免费证书部署 HTTPS 了

Let’s Encrypt 简介

Let’s Encrypt 是 一个叫 ISRG （ Internet Security Research Group，互联网安全研究小组）的组织推出的免费安全证书计划。参与这个计划的组织和公司可以说是互联网顶顶重要的先驱，除了前文提到的三个牛气哄哄的发起单位外，后来又有思科（全球网络设备制造商执牛耳者）、Akamai 加入，甚至连 Linux 基金会也加入了合作，这些大牌组织的加入保证了这个项目的可信度和可持续性。

部署 HTTPS 网站的时候需要证书，证书由 CA 机构签发，大部分传统 CA 机构签发证书是需要收费的，这不利于推动 HTTPS 协议的使用。

Let’s Encrypt 也是一个 CA 机构，但这个 CA 机构是免费的！！！也就是说签发证书不需要任何费用。

Let’s Encrypt 由于是非盈利性的组织，需要控制开支，他们搞了一个非常有创意的事情，设计了一个 ACME 协议，目前该协议的版本是 v1。

那为什么要创建 ACME 协议呢，传统的 CA 机构是人工受理证书申请、证书更新、证书撤销，完全是手动处理的。而 ACME 协议规范化了证书申请、更新、撤销等流程，只要一个客户端实现了该协议的功能，通过客户端就可以向 Let’s Encrypt 申请证书，也就是说 Let’s Encrypt CA 完全是自动化操作的。

任何人都可以基于 ACME 协议实现一个客户端，官方推荐的客户端是 Certbot。

Let’s Encrypt 通配符证书

在没有出现通配符证书之前，Let’s Encrypt 支持两种证书。

1 ）单域名证书：证书仅仅包含一个主机。

2 ） SAN 证书：一张证书可以包括多个主机（ Let’s Encrypt 限制是 20 ），也就是证书可以包含下列的主机：www.example.com 、www.example.cn 、blog.example.com 等等。

证书包含的主机可以不是同一个注册域，不要问我注册域是什么？注册域就是向域名注册商购买的域名。

对于个人用户来说，由于主机并不是太多，所以使用 SAN 证书完全没有问题，但是对于大公司来说有一些问题：

• 子域名非常多，而且过一段时间可能就要使用一个新的主机。
• 注册域也非常多。

读者可以思考下，对于大企业来说，SAN 证书可能并不能满足需求，类似于 sina 这样的网站，所有的主机全部包含在一张证书中，而使用 Let’s Encrypt 证书是无法满足的。

通配符证书就是证书中可以包含一个通配符，比如 .example.com 、.example.cn ，读者很快明白，大型企业也可以使用通配符证书了，一张证书可以防止更多的主机了。

这个功能可以说非常重要，从功能上看 Let’s Encrypt 和传统 CA 机构没有什么区别了，会不会触动传统 CA 机构的利益呢？

如何申请 Let’s Encrypt 通配符证书

为了实现通配符证书，Let’s Encrypt 对 ACME 协议的实现进行了升级，只有 v2 协议才能支持通配符证书。

也就是说任何客户端只要支持 ACME v2 版本，就可以申请通配符证书了，是不是很激动。

在了解该协议之前有几个注意点：

客户在申请 Let’s Encrypt 证书的时候，需要校验域名的所有权，证明操作者有权利为该域名申请证书，目前支持三种验证方式：

• dns-01：给域名添加一个 DNS TXT 记录。
• http-01：在域名对应的 Web 服务器下放置一个 HTTP well-known URL 资源文件。
• tls-sni-01：在域名对应的 Web 服务器下放置一个 HTTPS well-known URL 资源文件。

而申请通配符证书，只能使用 dns-01 的方式

Certbot 简介

What’s Certbot?

Certbot is a free, open source software tool for automatically using Let’s Encrypt certificates on manually-administrated websites to enable HTTPS.

Certbot is made by the Electronic Frontier Foundation (EFF), a 501(c)3 nonprofit based in San Francisco, CA, that defends digital privacy, free speech, and innovation.

Certbot 的官方网站是 https://certbot.eff.org/ ，打开这个链接选择自己使用的 web server 和操作系统，EFF 官方会给出详细的使用方法，如果 DNS 在官方的支持插件列表中可以按官方文档操作，但如果是国内的 DNS 可以参考certbot-letencrypt-wildcardcertificates-alydns-au

DNS plugin's name on the Documentation list

certbot docs

certbot 插件介绍

Certbot 现在需要运行在安装了 Python （ 2.7 or 3.4 ）的类 unix 系统上，内存大于 512MB （如果小于的话，官方解决方案），默认是需要 root 权限的，比如写证书操作需要 root 权限。

Certbot 客户机支持获取和安装证书的两种插件:auth和install，当使用 certonly 参数的时候，只会获取证书，并不会安装证，获取的证书位于 /etc/letsencrypt 目录下

主要插件的介绍：

Getting certificates (and choosing plugins)

| Plugin | Auth | Install | Notes | Challenge types (and port) | | --- | --- | --- | --- | --- | | apache | Y | Y | 自动化获取并安装证书 | tls-sni-01 (443) | | webroot | Y | N | 已经有运行的服务，通过验证 webroot 目录来获取证书 | http-01 (80) | | nginx | Y | Y | 使用 nginx 自动获取和安装证书 | tls-sni-01 (443) | | standalone | Y | N | 建立一个 standalone WEB 服务，需要 80 或者 443 端口可用，如果你没有类似 nginx 和 apache 等服务，这很有用 | http-01 (80) or tls-sni-01 (443) | | DNS plugins | Y | N | 通过修改 dns 服务器的 text 记录，来获取证书，野卡证书只能通过此方式获取 | dns-01 (53) | | manual | Y | N | 通过自己给指令获取证书，支持添加定制脚本来完成任务 | http-01 (80), dns-01 (53) or tls-sni-01 (443) |

解析：

• 如果你使用 standalone 插件，那么需要使用 80 和 443 端口，因为要建一个监听这些端口的服务，如果你有别的服务使用了该端口，那么就会出问题了。
• webroot 方式，如果你使用了 nginx，那么你需要更改一些 nginx 配置，确保能验证你对该域名的所有权限

插件的具体使用可以参考letsencrypt 证书-管理工具 certbot

我个人推荐选择DNS plugins 或者 manual方式来管理

certbot-dns-route53 实践

因为域名在 Amazon Route 53，所以选择使用 certbot-dns-route53 插件会比较方便，敏感信息都用 xxx 打码了但不影响阅读理解

https://github.com/certbot/certbot/tree/master/certbot-dns-route53

# Create a virtual environment
pip install virtualenv
cd /root
virtualenv certbot
source certbot/bin/activate

# Update its pip and setuptools (VENV/bin/pip install -U setuptools pip) to avoid problems with cryptography's dependency on setuptools>=11.3.

certbot/bin/pip install -U setuptools pip

pip list

Package    Version
---------- -------
pip        20.0.2
setuptools 44.0.0
wheel      0.34.2

# Make sure you have libssl-dev and libffi (or your regional equivalents) installed. You might have to set compiler flags to pick things up (I have to use CPPFLAGS=-I/usr/local/opt/openssl/include LDFLAGS=-L/usr/local/opt/openssl/lib on my macOS to pick up brew's openssl, for example).

pip install certbot-dns-route53

# create aws credentials
mkdir ~/.aws/
vim ~/.aws/credentials
[default]
aws_access_key_id=xxx
aws_secret_access_key=xxx

# generate certificate
certbot certonly \
  -n --agree-tos --email xxx \
  --dns-route53 \
  -d "*.xxx" 

(certbot) [root@xxx ~]# certbot certonly \
>   -n --agree-tos --email xxx  \
>   --dns-route53 \
>   -d "*.xxx"
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Found credentials in shared credentials file: ~/.aws/credentials
Plugins selected: Authenticator dns-route53, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for xxx
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/xxx/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/xxx/privkey.pem
   Your cert will expire on 2020-05-19. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

certbot 证书默认存放路径结构

Where are my certificates

All generated keys and issued certificates can be found in /etc/letsencrypt/live/$domain. In the case of creating a SAN certificate with multiple alternative names, $domainis the first domain passed in via -d parameter. Rather than copying, please point your (web) server configuration directly to those files (or create symlinks). During the renewal, /etc/letsencrypt/liveis updated with the latest necessary files.

# check letsencrypt directory
[root@xxx ~]# tree /etc/letsencrypt/
/etc/letsencrypt/
├── accounts
│   └── acme-v02.api.letsencrypt.org
│       └── directory
│           └── xxx
│               ├── meta.json
│               ├── private_key.json
│               └── regr.json
├── archive
│   └── xxx
│       ├── cert1.pem
│       ├── chain1.pem
│       ├── fullchain1.pem
│       └── privkey1.pem
├── csr
│   ├── 0000_csr-certbot.pem
│   └── 0001_csr-certbot.pem
├── keys
│   ├── 0000_key-certbot.pem
│   └── 0001_key-certbot.pem
├── live
│   ├── xxx
│   │   ├── cert.pem -> ../../archive/xxx/cert1.pem
│   │   ├── chain.pem -> ../../archive/xxx/chain1.pem
│   │   ├── fullchain.pem -> ../../archive/xxx/fullchain1.pem
│   │   ├── privkey.pem -> ../../archive/xxx/privkey1.pem
│   │   └── README
│   └── README
├── renewal
│   └── xxx.conf
└── renewal-hooks
    ├── deploy
    ├── post
    └── pre

15 directories, 18 files

• live 目录下存放的将会链接到最新的证书和私钥
• csr keys 用来存放当前代理的授权密钥对
• account 用来存放证书的管理信息, 这里涉及 ACME
• renewal 存放当前代理所管理的域的信息

如果是配置 Nginx SSL 证书，通常只需要按照下面这样修改即可

	ssl_certificate /etc/letsencrypt/live/xxx/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/xxx/privkey.pem;

Certbot command-line options

Certbot supports a lot of command line options. Here’s the full list, from certbot --help all:

(certbot) [root@xxx ~]# certbot -h

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...

Certbot can obtain and install HTTPS/TLS/SSL certificates.  By default,
it will attempt to use a webserver both for obtaining and installing the
certificate. The most common SUBCOMMANDS and flags are:

obtain, install, and renew certificates:
    (default) run   Obtain & install a certificate in your current webserver
    certonly        Obtain or renew a certificate, but do not install it
    renew           Renew all previously obtained certificates that are near
expiry
    enhance         Add security enhancements to your existing configuration
   -d DOMAINS       Comma-separated list of domains to obtain a certificate for

  (the certbot apache plugin is not installed)
  --standalone      Run a standalone webserver for authentication
  (the certbot nginx plugin is not installed)
  --webroot         Place files in a server's webroot folder for authentication
  --manual          Obtain certificates interactively, or using shell script
hooks

   -n               Run non-interactively
  --test-cert       Obtain a test certificate from a staging server
  --dry-run         Test "renew" or "certonly" without saving any certificates
to disk

manage certificates:
    certificates    Display information about certificates you have from Certbot
    revoke          Revoke a certificate (supply --cert-name or --cert-path)
    delete          Delete a certificate (supply --cert-name)

manage your account:
    register        Create an ACME account
    unregister      Deactivate an ACME account
    update_account  Update an ACME account
  --agree-tos       Agree to the ACME server's Subscriber Agreement
   -m EMAIL         Email address for important account notifications

More detailed help:

  -h, --help [TOPIC]    print this message, or detailed help on a topic;
                        the available TOPICS are:

   all, automation, commands, paths, security, testing, or any of the
   subcommands or plugins (certonly, renew, install, register, nginx,
   apache, standalone, webroot, etc.)
  -h all                print a detailed help page including all topics
  --version             print the version number
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

certbot 自动更新证书

简单介绍 2 种常见的需求，其他情况如使用容器 renew 的朋友相信应该都不用参考本文了

# 最简单的手动 renew 命令，看到 success 表示成功
certbot renew --force-renewal

(certbot) [root@xxx ~]# certbot renew --force-renewal
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/xxx.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found credentials in shared credentials file: ~/.aws/credentials
Plugins selected: Authenticator dns-route53, Installer None
Renewing an existing certificate

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/xxx/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/xxx/fullchain.pem (success)

使用 crontab 定期执行

# 编辑 certbot_renew.sh ，强制更新并重新 reload nginx 加载新证书
vim /root/certbot_renew.sh

#!/bin/bash
certbot renew --force-renew
nginx -s reload

# 如果是 virtualenv 虚拟环境可以这样写

#!/bin/bash
export PATH=$PATH:/usr/local/bin
source /root/source certbot/bin/activate
certbot renew --force-renew
nginx -s reload


# 添加执行权限
chmod a+x /root/certbot_renew.sh

# 设置定时任务自动更新证书，“At 01:01 on day-of-month 1.”
vim /etc/crontab
1 1 1 * * /root/certbot_renew.sh >/root/crontab.log 2>&1

# 如果需要记录日志可以这样写
1 1 1 * * echo `date -R` >> /var/log/certbot.crontab.log; certbot renew --force-renewal >> /var/log/certbot.crontab.log 2>&1; nginx -s reload

# certbot 官方使用 python 产生了一个分钟的随机数，让更新时间随机一些
echo "0 0,12 * * * root python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew" | sudo tee -a /etc/crontab > /dev/null

参考文章

Let’s Encrypt Documentation

acme.sh

Certbot

certbot docs

How To Secure Apache with Let's Encrypt on CentOS 7

How To Secure Nginx with Let's Encrypt on Ubuntu 18.04

How To Secure Apache with Let's Encrypt on Ubuntu 18.04

LET'S ENCRYPT 给网站加 HTTPS 完全指南

申请 Let's Encrypt 通配符 HTTPS 证书

Let's Encrypt 终于支持通配符证书了

Certobot 管理 Let's Encrypt 证书的几个经验

letsencrypt 证书-管理工具 certbot

[flynaj]

acme.sh 简单高效。

[gearfox]

谢谢分享

[SingeeKing]

好奇的问一下，为啥要用 Certbot 代替 acme.sh ，全文看下来没找到什么特别的优点

[GTim]

我去，你这是退化啊

[crystone]

@GTim 同问啊，acme 方便多啊

[KENNHI]

我说个最简单的，caddy 服务器。
可以代替 Nginx 的大部分功能，语法简单，支持 quic （ http3 ），还支持自动申请证书和自动维护更新证书，自动 https 跳转支持。
举个反代的栗子：
example.com {
proxy / http://127.0.0.1:8080 {
transparent
}
}
已经完成。你的证书将会被自动部署和维护，通过 http 访问网站的用户会被自动跳转到 HTTPS。

[ysc3839]

用 acme.sh 主要是不想配置 Python 吧，而且也不依赖 bash，ash 等 shell 也能运行，能在嵌入式设备上跑。能配置 Python 的环境下用 certbot 没什么问题。

[LokiSharp]

Certbot 包管理就能装

[uptime]

caddy 了解一下

[qile1]

Windows 系统好像执行不了这些，最简单方法就是去代理网站上面申请，dns 设置为点鼠标就生成了

[qile1]

@ysc3839 Windows 系统能运行，无法生成，Windows 系统下 nginx 更没法配置

[KENNHI]

@uptime 我也提过还有发帖推荐过 caddy，就是好像没多少人感兴趣。宁愿打补丁重新编译 Nginx 也不愿意试一下原生支持 quic 的 caddy ；宁愿顶着 Nginx 复杂难懂的语法复制粘贴删删改改也不愿意尝试一下说人话简单易用的 caddy ；宁愿研究完 acme.sh 再研究 certbot，搞出这么长一篇教程，也不愿尝试一下能够全自动获取维护更新证书的 caddy。(生产环境另算不做讨论）人还是更喜欢自己熟悉的东西，呆在舒适区不想动就会找出 1 万个借口来，例如为自己没什么访问量的博客找一个性能理由 2333

[LokiSharp]

@KENNHI CentOS 8 上 Nginx 和 certbot 官方源就能装了，caddy acme.sh 还要自己折腾，没必要吧。Nginx 的配置文件我觉得很简单易懂啊，有什么问题？

[009694]

@LokiSharp acme.sh 一个 curl 就装了。。折腾啥

[KENNHI]

@LokiSharp 我回想了一下 Nginx 的配置反代要多少行，还有给 Nginx 打 quic 补丁编译安装的过程，caddy 简单很多了。

[KENNHI]

@LokiSharp 还有如果使用 caddy，可以直接不用管证书这件事了，从申请到更新都和你无关，也不需要 acmesh （就我而言 acmesh 明显比 certbot 香啊，简单到想写都写不出这么长的教程）

[LokiSharp]

@009694 你装上就完事了？不更新了？

[LokiSharp]

@KENNHI 他这个教程是没事找事，实际上 apt dnf 装好 certbot 之后就一条命令的事情

[LokiSharp]

@009694 还有就是 curl 装的东西 SELinux 的上下文还得自己来配

[uptime]

@LokiSharp #13 你需要打开看一眼 caddy 官网，连官网都不看一眼就不要说话。caddy 就是全自动，就是自动续签，不用命令，不用你操心。

[LokiSharp]

@uptime #20 所以说除了自动签发证书 Caddy 还有什么杀手级的特性能让人从 Nginx 迁移过去用一个目前还在 beta 的软件？

[uptime]

@LokiSharp #21 哈哈，beta ？ https://github.com/caddyserver/caddy/releases/tag/v1.0.4

你喜欢用什么是你选择，但要是你什么都不了解就别说话，我不是来给你科普的，我更不是免费教你的。

[LokiSharp]

@uptime #22 大人时代变了。你难道没看一眼官网和官方文档吗？ Caddy 2 了
官方文档里源的包给的也是 2.0.0~beta13-1.fc32
https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/packages/

[LokiSharp]

@uptime #22
digitalocean 的一键部署镜像也是 v2.0.0-beta12
https://marketplace.digitalocean.com/apps/caddy
官方的 docker 也是 v2.0.0-beta.13
https://hub.docker.com/r/caddy/caddy/dockerfile

自己什么都不了解就不要乱说别人怎么样，谢谢。

[uptime]

@LokiSharp 你开心就好。 按你这逻辑，全世界的软件都是 beta 版、开发版

[LokiSharp]

@uptime #25 问题是我现在从官方文档上给的方法部署，确实都是 beta 版啊。
想要用 caddy 1 的话，手动从 github 上下载 binaries 部署和维护，多麻烦？？？

当然，我只是想反驳一下你说的我什么都不了解而已。

[Nekonico]

@SingeeKing +1
楼主说了一大堆 完全没有找到 Certbot 代替 acme.sh 的理由

[uptime]

@LokiSharp #26 为什么到现在你还不承认你什么都不了解？明明就是完全不了解，偏偏要一会儿说 caddy acme.sh 要自己折腾，一会儿又说 Beta 版，一会儿又说部署麻烦，你这么浮躁就不要勉强自己，行吗？

官网看过吗？
https://caddyserver.com/v1/download

官网就给了一键部署看到吗？？
curl https://getcaddy.com | bash -s personal

[LokiSharp]

@uptime #28 搞笑了，你到底懂不懂 Linux ？有包管理我什么要用 curl， 后续更新怎么办？？？ SELinux 怎么配？？？
这个又不是你内部的小工具，是对外开放端口的 http 服务，爆出漏洞手动更新？？？抱歉，为了不折腾，我使用 Linux 的原则是，能用包管理能提供的软件我就尽量用包管理的。

Certbot + Nginx 新一点的发行版都在官方源里自带了，我安装只需要 apt/dnf install certbot nginx，更新只需要随着日常维护的时候 apt/dnf upgrade 就行。

你的 Caddy 1 能吗？ 至少从旧版的官方文档来看他没说。而新的 Caddy 2 在源里的是 beta 版，很抱歉，我不敢用。

还有就是，既然官方文档包管理提供的是 Beta 版本，我认为他是 Beta 有什么问题？

[superrichman]

nginx 经过了很多年的考验，目前很稳定性能也很好，大型项目都 hold 的住。从自动申请证书这功能来看，caddy 应该更多是给个人项目用的吧。

[neilp]

用步行代替开车上下班.

[ungrown]

@KENNHI #12
为什么你就认定别人是为了固守舒适区呢？
看你说的 caddy 的“优点”难道不是都从“舒服”这个角度出发的吗？
那为什么不能说用 caddy 才是在逃避到舒适区呢？
为什么别人用 nginx 就不能是为了某些功能呢？

[uptime]

@LokiSharp #29 哈哈哈哈……无语死了！ 你连 Go 语言的程序都没用过也不了解，就敢指手画脚乱说一通的！ caddy 老早就商业化，只有个人版才免费 --- 脚本“bash -s personal” 看到吗？，商业用一直都是付费，人家一直都在公司化运营卖商业卖钱的。

Go 应用本身就不存在环境依赖，python 应用可以说因为 Linux 系统本身自带 py2.7 或 3.x，也算是无需环境依赖，而 Go 是 100%不需要环境依赖。简单说，你可以理解为 Windows 上的一个绿色软件。
什么？版本升级？简单到死，再一次运行 curl 脚本就可以了，自动下载新版本替换老版本。无它，Go 应用就是如此，纯“绿色”软件。你没用过、不了解、不清楚的，真不明白你为何说那么废话？！非要暴露自己？谦虚点不可以的？多一点谦虚，少一点浮躁。

Beta ？ Beta 还要说？有好多人追求新功能，跳过 Stable 直接用 Nginx 最新开发版，难道有人会这样说 Nginx 只是个 Beta 软件？！ 我很好奇，会有这种人吗？

[LokiSharp]

@uptime #33
1. 开源软件的商业版不代表靠谱，只是代表出问题你能找他们的技术支持
2. Go 不存在环境依赖不代表你的服务不需要后续维护
3. 我用发行版自带的包管理，各种运维工具都完美支持。如果没有什么不可替代的需求，为什么要用这种蠢的办法下载脚本来维护软件？我难道还要天天盯着 Caddy 的版本日志手动更新？
4. 绿色软件？？？ Linux 也有这个说法了？？？我一直觉得包管理装的东西是最绿色的
5. Nginx 可没有把 beta 的软件包放在官网最醒目的位置的官方文档部署教程上面

[chotow]

看到楼上说 QUIC，我想到…… 现在支持 QUIC 的网站有哪些？之前 Google 官网支持，后来好像就不支持了。不过已经很久就研究这个，不支持现在是什么情况。

[LokiSharp]

@uptime #33
对了，我在 EPEL 源找到 caddy 了，https://rpms.remirepo.net/rpmphp/zoom.php?rpm=caddy
不过我不是很懂他们为什么不把 EPEL 源列到文档里，要用 curl 下载脚本这种笨办法

[uptime]

@LokiSharp #34 我的天，这是什么样的人？！ 大家快来看个无脑杠精。明明啥也不了解，非要怼天怼地。

人家官网主页页头大写的提示：This page is about Caddy 2, which is currently in beta. Click here for the old Caddy 1 site. Thank you for your patience as we transition!

当然杠精只会嘴硬，眼睛嘛，不存在的。 你真的不是啄木鸟，光嘴硬是没用的。你不知道，不了解，真的没关系，没人在意你的，但一个人要学会谦虚，少点浮躁，不要不懂装懂还要怼天怼地

[LokiSharp]

@uptime #37

我不想在服务器上跑来历不明我也没读过的脚本，也懒得去读他的安装脚本。
我就想找个软件源或者用 Docker 装一下，谢谢。
这些 Caddy 1 的文档没有提供，Caddy 1 的文档都是不知道多少年之前的了，没有什么意义。

你说了半天就说了点废话，唯一给我的信息只有你知道 Caddy 能用 curl 安装，这种是个人都知道的东西。

嘛，看了看你的注册日期，估计还是个学生吧，呵呵。

[kennylam777]

生產環境表示才不會用 Caddy 做 acme, 直接在 k8s 跑 cert-manager 管好自動更新、部署及儲存密鑰的問題......

不過 certbot 是很基本的工具, 學清楚也是有用的

[Buges]

@LokiSharp #38
这确实是个黑点，不知道他们怎么 caddy2 的 beta 还没结束就把官方 docker 镜像的 caddy1 下了。我之前用的时候默认 tag 是 caddy1 稳定版，文档就在 docker hub 页面上。没有上各大发行版软件源仓库倒是奇怪，几个月前或 caddy2 稳定后你说的这些问题并不存在。
可能是 beta 到最后“公测”阶段了，这强迫开源用户当小白鼠的做法确实不好，和 Qt 一个货色。
抛开这些 caddy 安装部署简单（单可执行文件），配置文件简洁易懂远胜 nginx，更不用说 auto HTTPS 这样开箱即用的功能。不过性能和功能上还不如 nginx，对个人用户 /中小企业来说如果没有非常复杂的配置需求的话用 caddy 还是省时省力的多。

[LokiSharp]

@Buges #40
我觉得单可执行文件部署简单是个伪命题。成熟的软件基本都进各大发行版的软件源了，用包管理装单文件和多文件没有什么区别。部署都是半自动的，手动把配置文件放到 etc 里就行了。如果用 Docker 的话那就更加没区别了。

而单个可执行文件不用包管理安装，直接放到一个目录有些东西免不了自己写点脚本处理的。比如 Caddy 你把可执行文件放进去了，用户、权限、路径和 SELinux 上下文还有 systemd 的服务都得自己来设置。生产环境，总不至于真的随便下到里面直接拿 root 跑吧= =

配置文件，我没用过 Caddy 不敢怎么评价。Nginx 其实也不复杂，只是默认配置文件列出的可改的参数比较多，但是有个模板改改就行了。这些东西 Caddy 实际使用应该也需要调的，用默认的值一般都不靠谱。

[Buges]

@LokiSharp #41 你感觉没有什么区别是因为脏活打包者已经帮你干了。软件包的话还可能有依赖冲突、版本过旧等问题，docker 的一大重要作用不就是打包整个环境让任何应用都可以像单可执行文件一样无依赖直接运行么。官方提供的脚本把包管理的工作做了，但再怎么也该把稳定版上到常用发行版软件源上，这个为什么没有我不明白。
不是所有环境都是生产环境部署，个人弄小网站、开发调试的时候，文件下下来然后 root 一把梭比安装一堆依赖，还要分别配置更合适。
配置文件语法简洁自然上是真的吊打 ngnix，caddy 不只是默认配置尽量开箱即用，改起来也比 nginx 方便的多。随便拿个配置：
```
www.domain.com {
gzip
log /var/log/caddy/www.log
root /var/www/
header /api {
Access-Control-Allow-Origin *
Access-Control-Allow-Methods "GET, POST, OPTIONS"
}
fastcgi / 127.0.0.1:9000 php {
index index.php
}
rewrite {
to {path} {path}/ /index.php?{query}
}
}
domian.com{
log /var/log/caddy/domain.log
redir / https://www.domin.com/{uri} 301
}
```
文档都不用看就能理解差不多，用 nginx 做到同样效果得写一大坨而且可读性远远不如。

当然有些很复杂的功能 caddy 实现不了（比如 lua 扩展），性能也不如 nginx。caddy 可能不是功能最强的，但一定是最用户友好的。

[blogfeng]

@Buges 简单意味着别人帮你封装好了。nginx 配置里面很多特性，需要自己手动配，caddy 无法做到。所以生产环境死都不会用 caddy。而且也不推荐新人用，因为多接触细节才能学会更多。你啥也不想做，不如用用别人做的 nginx 一键脚本吧，我估计比 caddy 体验差不了哪里去，大家都是用现成轮子不想事。

[cydian]

传统 CA 和 Let’s Encrypt
都支持一张证书多个通配符域名啊

[LokiSharp]

@Buges
对啊，我尽量用包管理装，就是因为软件包打包的时候都按各个发行版的最佳实践配置好了。

依赖冲突问题，我用的 Fedora 和 CentOS 上用包管理装的环境并没有发生过，只有工作前已经折腾安装脚本的时候碰到过。

本地调试并不需要自动部署 https 证书，负载均衡和 QUIC 这样的特性，用内置的 Web Server 足够了。

用 Nginx 也不用调太多参数，很多参数都是涉及性能调优，安全性和浏览器兼容性的，不涉及这部分测试的情况保持默认也能跑起来。

Nginx 配置 php 服务也并不比 Caddy 复杂

server {
listen 80 default_server;
listen [::]:80 default_server;

root /var/www/html;
index index.php index.html index.htm index.nginx-debian.html;

server_name server_domain_or_IP;

location / {
try_files $uri $uri/ =404;
}

location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}

location ~ /\.ht {
deny all;
}
}

[uptime]

@LokiSharp #38 你真逗，根本就不想回复你，一个根本没用的软件，甚至没接触过的东西，就你敢秒天秒地，真是活久见。我学生？哈哈，我的年龄能做你爸！ 年轻人，别浮躁，谦虚点。最后居然还能重新定义商业化。
Nginx 不是免费软件，没事先上上 nginx.com 看看，好好看看 nginx 官网到底是啥样子的，别以为看过 nginx.org 就以为 nginx 就长这样的。nginx.com 你给我找个版本号看看。

不要回复了，你根本就不是来讨论问题，没用过没关系，不了解没问题，但人要有起码的尊重，啥也不了解
#13 楼就怼 caddy 需要自己折腾 acme.sh ；---- caddy 自带自动更新证书
#21 楼怼 caddy 只有 beta 版本；----- caddy 从 1.0 就是正式版
#23 楼怼官网只有 beta 版 ----- caddy 官网网头就是大写的提示，并有跳转
#26 楼又怼部署麻烦 ----- 官方 curl 一键命令安装更新一条龙
#29 楼怼这 curl 脚本 ------ 根本没用过更不了解 Go 应用的特点，单文件绿色软件化
#34 楼更厉害了，怼商业版不靠谱，怼后续维护，连 nginx 官网都不了解怼 caddy 的官网，真是怼天怼地------ 要不要环境依赖与后续维护有个卵关系？包管理绿色？后面一大堆依赖包你眼瞎的，包管理只是方便解决依赖，哪来绿色。我都不想说，既然喜欢用包管理，为何不用更好更新 debian/ubuntu，却偏要用万年不更、软件老掉牙的 centos 系，还非要执着版本号，真是搞笑。还 nginx 官网？ nginx.com 了解一下
#38 楼也是厉害，居然怼官网提供的官方脚本来路不明；怼官方文档不知多少年 ------- 我去，真是说话都不打草稿，caddy 1.0~1.04 正式版是去年 2019 年才发布的，至今都没半年，并且 caddy 本身就非常年轻的 web server 也就近两年才开始活跃流行起来，你居然说官网文档不知多少年，要脸不？
#38 楼，更无语的居然拿我注册时间评价，我这 ID 2018 年注册就成了学生？那是不是我拿个 2014 年 9 月的老号回应你，你就不嘴硬了叫我一声爸了？？ 注册时间有什么用，能吃？

活久见，居然有这样的人，对 caddy 完全不了解，偏要装偏要怼，怼天怼地，关键还是怼啥都有错，无知上的错。死不认有错，还喜欢跳跃，看上面，跳跃得多厉害。

[uptime]

@blogfeng #43 开源，你完全可以自己封装，官方提供各种组合插件，可以自由添加插件来增加功能，插件还可以你自己写，提交给官方。
人家的思路、模式就是这样，也是其特点。这世界上有好多个 web server，apache、Lighttpd、IIS、LiteSpeed、nginx 等，每一个都有它特点和优缺点，和它的应用场景，不然 apache 哪来那么高的市占率

[LokiSharp]

@uptime 自己学学 Linux 运维吧，自己编译安装没问题，我们一般是编译了部署到一个自建软件源，安装部署都是用包管理。

CentOS 系老掉牙？奇了怪了，你还真是不懂 Linux 啊，我现在只找到 Caddy 官方建立了 Fedora Copr 源，( https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/packages/)这是和 rpm 源哦，说明 Caddy 团队自己用的就是 CentOS/Fedora 开发

[LokiSharp]

@uptime 除了官方文档的这个之外，我只找到了 Fedora 的软件源和 EPEL 上有 Caddy，然而这都是 rpm 源 都是给 RH 系用的。

还有就是自己好好学点东西，什么叫老掉牙？你知道 Long-term support 是什么意思吗？知道发行版版本冻结的意思吗？知道为什么稳定版要冻结版本号吗？你觉得老只是因为 LTS 发行策略不同，RH 系 3 年一冻结 Ubuntu 2 年一冻结。

RHEL 和 CentOS 是 RH 系的 LTS 发行版，软件包版本三年一冻结。如果想用新技术可以用半年冻结一次的 Fedora。Fedora 的更新速度只比 Arch 这样的滚动更新慢一步。而且自己看看版本差异，现在 RH 系的最新 LTS 版的 RHEL/CentOS 8.1 不比 Debian/Ubuntu LTS 的老，这是去年 CentOS 8 和弦 Ubuntu 18.04 的对比，https://developpaper.com/version-comparison-of-some-software-between-centos-8-and-ubuntu-18-04/。

[LokiSharp]

@uptime 拜托了，自己学点东西吧，学学 Linux, 学学包管理怎么用吧。你的发言让我觉得你是个只用过一 Ubuntu，啥都不会的人。我说你是学生是因为我觉得你没在正经企业里工作过，什么都不懂。

给你科普一下，企业里部署的时候是不可能让你用未经审核的脚本和二进制安装的。除了软件源里的东西之外，通常都是需要代码审查后，自己编译源码搭建私有源，最终才能部署。而软件源里的软件都是经过测试和无数个公司审查的可信度极高。尤其是 SUSE 和 RHEL 这样的 Enterprise Linux 软件源的可靠性有公司的担保，拿来直接能用。

至于为什么我不愿意用你说的 curl 一键脚本安装，我是真的外来的被脚本坑过。比如说脚本里删除东西多打了一个空格，比如 rm -rf / tmp/foo/bar/* 这些事情不是没有发生过。此后我跑外来脚本都得自己读一遍才敢跑。
当然，你可以说你相信 Caddy 团队不会出这种问题，可从我的角度看他家的文档都写不清楚，版本管理混乱。文档里给的 Docker, Digitalocean, Fedora COPR 源里都是 beta 版，稳定版只有 curl 脚本安装。Fedora 和 EPEL 源有 Caddy 1 也没更新到文档的安装指南。从我的角度来看，作为初次使用者，不觉得他可靠度有多高。

而 Caddy 的特性与 nginx 相比较，它追加的特性也都是一些鸡肋和实验性功能。
鸡肋是指你吹捧的证书自动部署，企业级 http 服务器安全策略一般不会允许 httpd 主动向外发来请求。企业也不会用 LE 的证书，LE 没有担保，只是个证书而已。
实验性功能是指 QUIC, 在 http3 标准确立之前，QUIC 都不会被大规模使用，甚至 Google 自己都不用。

还有就是，不要再吹 Go 的单可执行文件部署了。并不是只有 Go 能做到单可执行文件。而且部署一个服务不是你随便一丢无脑 root 运行就万事大吉的。

[LokiSharp]

@uptime 我确实不了解 Caddy。
可从你的发言来看，我觉得你
1. 只用过 Ubuntu 这种默认不开安全策略的发行版，或者起手禁用 SELinux
2. 不知道发行版发行策略的差异
3. 不知道 LTS 代表什么意思
4. 没了解过也不知道什么是 SELinux
5. 没有维护过个人服务器以外的服务器
6. 不会自建软件源
7. 没读过最新的 Caddy 文档
8. 不知道 Caddy 有除 curl 一键脚本以外的安装方式
9. 安装软件喜欢用一键安装脚本
10. 没有在正经企业了解过 Linux 运维和安全策略

如果你是在正经企业工作过的，请分清生产环境和个人环境。

[LokiSharp]

@uptime 最后补充一句，个人环境怎么玩都可以，然而不是每个人用 Linux 都是像学生一样拿来玩的

[uptime]

@LokiSharp #51 24K 逗逼一个，老老实实承认自己完全不了解 caddy 不就得了！ 非要啰啰嗦嗦东扯西扯一大堆，各种跳跃，完全不知情居然也要跑出来云评测，还秒天秒地的。到现在还是各种跳跃，各种扯，东扯西扯，各种嘴硬。真是极品。

你用什么，你喜欢什么，你会什么，你专业什么，没人关心你，更没人会说你。但是做人一定要有最最起码谦虚，懂还是不懂，了解还是不了解，自己没点数？非常简单的说，你人品有问题，大大的问题。

你继续说太多，扯太多，跳跃下去，不会掩饰你的人品问题，只会让你更显得逗逼而已。就像人一旦说出第一句谎话，必将会千千万万谎话下去。

[LokiSharp]

@uptime #53
你看懂我说的东西了么？我和你讨论的东西和 Caddy 本身没有关系，而是 Linux 部署和安全策略的问题，不过看了看你的发帖历史，估计是对牛弹琴，你可能真的是不会用 Linux 的（笑

你现在过了 500 多天知道 sudo 是干啥用了么？要不要我教教你？
ref: https://www.v2ex.com/t/484337
https://wiki.archlinux.org/index.php/sudo

还有 400 天前的 caddy systemd 服务怎么写怎么配懂了么？不会还是用网上找的一键脚本吧？
ref: https://www.v2ex.com/t/522738
https://wiki.archlinux.org/index.php/Systemd

当然，对 Linux 我也不敢说太懂，只能算能折腾起来。对 Linux 的了解可能也只停留在 RH 的文档上。
我从 2010 年学校里学 Linux 的时候用 RHEL 5.5 开始算到现在也只有 10 年，用的时间也不算太长。

不浪费时间了，再发不友善的言论我只能 B 了你了

[wensonsmith]

纳闷这个帖子怎么这么多回复，原来是交(si)流(bi)导致啊

[uptime]

什么都可解，唯一人品是无解的。

互联网是有记忆的，v2ex 是不能删帖，不注意自己的言行，以后某一天是会死得很惨的。前些天就有个活生生的例子，一个逗逼跟风缅怀李医生，结果被人挖出在更早之前，骂八君子造谣的也还是他。结果微博马上被暴击……

说出一个谎言，必将无数个谎言接着。同理，为了掩饰自己的无知，必定胡扯一大堆毫不相关的东西，南辕北辙，恰得其反知道不？呵呵，我都不好意思说 Ubuntu 20.04 LTS 下下个月就要发行了，敢情 Ubuntu LTS 版又被狗吃了？

人嘛，在这浮躁的社会的确是需要包装，但是有经验的知道，只在自己专业领域吹牛 50%，不要在自己不了解的情况下乱吹牛。云评测可厉害了，完全不了解也敢瞎吹牛，上面说过了，互联网是有记忆的，这无疑是自己给自己做最蠢的 SEO ！

这些天墙比较厉害，就很少用 TG，结果发现，呵呵，果然人品是终生的，就如狗改不了吃屎：没错，在好几天前，在# 22 ~ 29 楼就暴露人品。

[LokiSharp]

@uptime #56

俺寻思，你说的这些不友善的言论都是在自言自语？！

1. 请证明一下你会用 Linux，不然我请恕我拒绝和你讨论任何技术性话题。原因是讨论任何你看不懂的技术性话题，都会被认为是不相关的胡扯。我的感受是，和你讨论任何技术话题都是毫无意义而且浪费时间，谢谢。
2. 胡扯不相干的东西的人是你，是你举出 Ubuntu 更好更新，谢谢。“为何不用更好更新 debian/ubuntu，却偏要用万年不更、软件老掉牙的 centos 系”
3. 你的言行让我觉得你是个对 Linux 什么都不懂的人，谢谢。
4. 对你上述所有不友善言论全数原话奉还，谢谢。

最后补充一下，我 TG 名是 LokiSharp。截图里这个小苹果我不认识，也与我无关。而且我的发言里也没有任何脏字，谢谢。