Lua-resty-auto-ssl: 通配符证书

我不是回购维护者，但我不得不说这不是一件容易添加的事情。 LE 通配符证书需要 DNS 验证，现在 lua-resty-auto-ssl 使用 http 验证。

拥有 DNS 验证会很好，即使不考虑通配符。 一些想法：

• 我们需要先等待 dehydrad 获得 ACMEv2 支持：dehydrad #420
• dehydrad 已经支持 (ACMEv1) dns-01 挑战。 当前 ACMEv2 草案中的 dns-01 挑战看起来与我相同或几乎相同。
• dehydrated 的deploy_challenge钩子提供了要写入 TXT 记录的域和令牌。
• 因为我们不知道用户如何管理他们的 DNS 记录，所以这部分需要通用。
  
  
  
  1. 支持流行的 DNS API。 我们至少应该添加基础设施来支持“标准”API，例如 PowerDNS、CloudFlare 甚至 nsupdate 提供的 API。 在这种情况下，我们的设置中只需要某种身份验证令牌。
  
  
  2. 用户必须需要自定义解决方案来设置这些记录，例如与专有 API 对话，甚至调用脏 shell 脚本。 我们应该为这些情况提供一个通用的钩子：
     
     -- Define a function to store the validation tokens for DNS verification -- by let's encrypt in your DNS setup. auto_ssl:set("deploy_dns_challenge", function(domain, token) -- talk to your DNS-API to create a new TXT record _acme-challenge.$domain with value $token end)
  
  
• 存储层目前假设它可以使用全域作为密钥来获取证书。 这将不再适用。 我的第一个想法是将通配符存储为parentdomain.com:wildcard:latest并在未找到具体证书时让存储层检查该密钥。

问题：

1. 我们如何知道是生成普通证书还是通配符证书？ 一个新的用户定义函数is_wildcard_domain ？ 现有allow_domain的新返回值？
2. 我们是同时支持 DNS（用于通配符）和 HTTP（用于普通证书）验证，还是两者都支持 DNS？ 请注意，HTTP 可能要快得多，因为我们控制了所有移动部分。

仅供参考：现在有一个 ACMEv2 登台端点可用。 :)

当前 ACMEv2 草案中的 dns-01 挑战看起来与我相同或几乎相同。

你是对的 :-) V1 和 V2 API 之间的 DNS-01 挑战没有任何改变。

仅供参考：至少脱水的开发版本现在支持 ACMEv2 以及通配符证书。 如果有人想开始研究这个，现在是你的机会；）

我认为进行 DNS 验证的 resty-auto-ssl 完全超出了范围。
但是，我们应该可以让 resty-auto-ssl 回退到“带外”配置的通配符证书。
例如，我将使用 bind9 和 certbot 设置我的服务来为域做通配符证书。 现在我不认为我可以告诉 resty-auto-ssl 使用该通配符证书而不是尝试生成一个。

编辑：嗯，这不是超出范围。 我不知道可以使用手动脚本配置脱水以连接到自定义 DNS api...

有没有办法将手动生成的通配符 LE 证书存储到 Redis 以便 resty-auto-ssl 可以使用它？

根据我从代码中了解到的情况，这是不可能的。 我们可以很容易地在存储界面中为每个sub.domain.tld添加以下检查：

• sub.domain.tld:latest — 当前
• *.domain.tld:latest
• *.sub.domain.tld:latest

这样，我们可以向通配符迈出第一步，目前仅支持以前生成的证书。 这样做之后，如果我们决定要这样做，我们可以继续并决定支持生成通配符证书的好方法。

编辑：我很乐意草拟上述的实现。

@akalipetis您是否尝试查看是否设置

ssl_options.fullchain_der
ssl_options.privkey_der

可以在 allow_domain 中工作吗？
如果可能，那么您可以在 allow_domain 中执行 redis 请求并进行设置。

为了记录我刚刚遇到这个问题，我使用lua-resty-auto-ssl为我的监控服务上的自定义域状态页面生成证书，大多数人会使用我自己的域，例如xxxx.status.updown.io ，这样更有效使用通配符证书。

我通过使用allow_domain lambda 跳过*status.updown.io的证书生成来实现这一点：

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

然后提供通配符作为默认后备证书：

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

我使用 DNS 质询手动生成了证书：

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

我不确定是否值得花时间将其自动化，因为 DNS 挑战看起来很复杂。 它的技术含量很低，但可以按预期工作:)

这是一个很好的解决方法，并且适用于许多用例。
但是请注意，使用https://github.com/AnalogJ/lexicon可以轻松应对 DNS 挑战！
它运行良好并支持许多提供商。 我什至添加了其中一个，这个过程非常简单。

@kapouer感谢有关lexicon的提示，如果我想自动化，请记住它；）

为了记录我刚刚遇到这个问题，我使用lua-resty-auto-ssl为我的监控服务上的自定义域状态页面生成证书，大多数人会使用我自己的域，例如xxxx.status.updown.io ，这样更有效使用通配符证书。

我通过使用allow_domain lambda 跳过*status.updown.io的证书生成来实现这一点：

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

然后提供通配符作为默认后备证书：

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

我使用 DNS 质询手动生成了证书：

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

我不确定是否值得花时间将其自动化，因为 DNS 挑战看起来很复杂。 它的技术含量很低，但可以按预期工作:)

我也在为我们的应用程序进行相同类型的域检查。 如果用户的门户主机包含我们“自己的”域之一，那么我们只需恢复使用来自静态 CA 的通配符证书。 但我喜欢你仍然使用 LE 并手动生成通配符的想法。

我要测试一下。

更新
好的，这是真正满足我需求的解决方案。 cloudflare 插件。 文档非常好。 我让它在一两个小时内工作。

https://certbot-dns-cloudflare.readthedocs.io/en/stable/

@jarthod任何其他解决方法可以自动执行此操作？ 记住每 3 个月更新一次通配符实际上是痛苦的。

@jarthod任何其他解决方法可以自动执行此操作？ 记住每 3 个月更新一次通配符实际上是痛苦的。

不在我这边，我仍在使用它并每 3 个月进行一次手动更新。 记住对我来说不是问题，因为我正在使用我的服务 (updown.io) 来监控端点，并且它会在证书即将到期时提醒我。

我也是您服务的用户。 无论如何，我继续使用传统的 1 年通配符 SSL。

现在你的服务有工作在明年提醒我😄

在 2020 年 10 月 3 日晚上 10:30，Adrien Rey-Jarthon [email protected]写道：

@jarthod任何其他解决方法可以自动执行此操作？ 记住每 3 个月更新一次通配符实际上是痛苦的。

不在我这边，我仍在使用它并每 3 个月进行一次手动更新。 记住对我来说不是问题，因为我正在使用我的服务 (updown.io) 来监控端点，并且它会在证书即将到期时提醒我。

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看，或退订。