Lua-resty-auto-ssl: 颁发证书时忽略 IP 地址

我刚刚为此写了一张支票，却发现它很早就已经失败了，在：

ssl_certificate(): auto-ssl: 无法确定请求的域（不支持 SNI？） - 使用后备 -

当浏览器向 IP 地址发出请求时，它不会发送 SNI 标头，因此甚至不会设置“域”。

我不确定为什么我的发送请求让我们加密，然后发送有关使用 IP 注册 SSL 证书的错误：S

@discobean ：当您看到这个时，您是否有特定的错误消息？

@GUI我有时会遇到同样的错误。 我猜这是因为客户端（可能是扫描程序机器人）正在发送与目标 IP 地址相等的 Host 标头，例如：

2018/02/20 02:10:44 [warn] 490#490: *2723 [lua] init_by_lua:11: allow_domain(): auto-ssl: debug allow_domain domain XXX.XXX.XX.XX, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443
2018/02/20 02:10:49 [error] 490#490: *2723 [lua] lets_encrypt.lua:41: issue_cert(): auto-ssl: dehydrated failed: env HOOK_SECRET=XXXXX HOOK_SERVER_PORT=8999 /usr/local/bin/resty-auto-ssl/dehydrated --cron --accept-terms --no-lock --domain XXX.XXX.XX.XX --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config --hook /usr/local/bin/resty-auto-ssl/letsencrypt_hooks status: 256 out: # INFO: Using main config file /etc/resty-auto-ssl/letsencrypt/config
Processing XXX.XXX.XX.XX
 + Signing domains...
 + Creating new directory /etc/resty-auto-ssl/letsencrypt/certs/XXX.XXX.XX.XX ...
 + Generating private key...
 + Generating signing request...
 + Requesting authorization for XXX.XXX.XX.XX...
 err:   + ERROR: An error occurred while sending post-request to https://acme-v01.api.letsencrypt.org/acme/new-authz (Status 400)

Details:
{
  "type": "urn:acme:error:malformed",
  "detail": "Error creating new authz :: Issuance for IP addresses not supported",
  "status": 400
}

, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443
2018/02/20 02:10:49 [error] 490#490: *2723 [lua] ssl_certificate.lua:97: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443
2018/02/20 02:10:49 [error] 490#490: *2723 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for XXX.XXX.XX.XX - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: 107.170.236.113, server: 0.0.0.0:8443

其中XXX.XXX.XX.XX是我们的实际服务器 IP 地址

我完全赞成在代码中阻止这一点，但是，嗯：您的 allow_domain() 应该_only_允许您希望为（白名单方法）生成证书的 FQDN，而不是“不为这些”（黑名单方法）。

你不应该只是简单地在 allow_domain() 中“返回 true”。 它会给您的系统带来压力，并将故障累积到 LE。

不过，我们要更进一步。 我们将所有虚拟主机客户的列表导出到磁盘上的 Lua 表文件中，读取该文件并将其存储在 nginx 内的 SHM 键/值存储中，以便我们可以轻松检查我们应该为哪些主机生成证书。

我们的管理主机名有多个通配符证书，因此我们提前退出，并使用其中包含相应 SSL 证书的替换 SSL 链。 我们提前退出 IP 地址和 localhost。 最后，我们检查 DNS 以及该名称是否实际上在我们系统上配置的域列表中。

大多数这些检查只是及时获胜，但它们并不是真正必要的。 要点是：使用白名单而不是黑名单。 这也是常见的代码实践。 安全总比后悔好。

有时最好不要过度设计和跳过可能是另一个故障点的各种检查:) 特别是如果你有一个高度动态的环境。

我并不是说这应该在 lua-resty-auto-ssl 中被阻止，只是分享我在测试其他人是否偶然发现这个问题时发现的内容。

快速破解allow_domain ：

          local ip_chunks = {domain:match("(%d+)%.(%d+)%.(%d+)%.(%d+)")}
          if (#ip_chunks == 4) then
            return false
          end

白名单不是过度设计，它做得对。 世界上有这么多安全事件，因为开发人员使用的是黑名单而不是白名单，这甚至一点都不有趣。

您的检查还跳过了 IPv6 地址，实际上是过度设计的：

if string.match(domain, "(%d+).(%d+).(%d+).(%d+)") or string.find(domain, ":", 1, true) then
    return false
end

你不知道我们的情况，但你很快就判断了。 取点。

您可能可以创建一个 PR 并将 README.md 中的allow_domain更改为比返回true更明智的内容，以使每个人都更安全