您可以在没有正确 FQDN 的情况下生成 Let's Encrypt 证书吗？有解决方法吗

Question

我的azure VM是由其他人生成的。它已经变得很重要。我需要为数据库 SSL 创建服务器证书。我将 certbot 与 LetsEncrypt 一起使用，如下所示：

https://www.vultr.com/docs/use-ssl-encryption-with-postgresql-on-ubuntu-20-04/

我在这一步中陷入困境：

sudo certbot certonly --standalone -d zz-ubuntu1

Account registered.
Requesting a certificate for zz-ubuntu1
An unexpected error occurred:
Error creating new order :: Cannot issue for "zz-ubuntu1": Domain name needs at least one dot

所以我没有输入域名，因为好像没有域名。

hosts 文件未受影响：

127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

似乎根本没有任何关于域名的事情：

root@zz-ubuntu1:~/tmp_certbot_key# hostname -f
ZZ-UBUNTU1

为了让 certbot 按照说明生成 CA 证书，我相信我需要给它一个 FQDN，但也许我可以做一些虚拟条目或捏造...？

我无法访问天蓝色门户。我确实有root。

有人知道我可以采取什么步骤来生成证书吗？最好不要对那里的独立 Postgres 数据库造成任何损坏。

Answer 1

Let's encrypt 是获取“公开”签名证书的一种方式。 这意味着证书签名机构必须有某种方法来验证证书签名请求中的域是否可以与该请求关联。 通常，这是通过添加公共 DNS CNAME 或 TXT 记录以及“证明”您拥有该域的内容来完成的，或者通过将内容添加到域上的 Web 端点来实现，这可以获得您拥有该域的相同证据。 作为不合格的主机名，没有人拥有

ZZ-UBUNTU1

。 它只是一个字符串标识符。 您无法获得该名称的公共证书，因为在签名之前无法对其进行验证。

您可以执行以下操作：

您可以使用非公开 CA 密钥签署证书。 将 CA 密钥保存在安全的地方，将 CA 证书提供给客户端，并将签名的证书和密钥提供给 postgres 服务器。 公众不会信任该证书，但他们无论如何也不会连接到 postgres 服务器。 如果 CA 密钥是安全的，那么从加密角度来说，它与公开签名的证书一样安全。 仅当证书不需要由公众验证时，这才是合适的解决方案，公众没有理由信任您的 CA 证书。
作为类似的替代方案，您可以使用自签名证书。 这意味着与证书关联的密钥也是用于签署 CSR 的密钥，因此 CA 密钥材料和服务器密钥材料是相同的。 然后，您可以在客户端配置中将自签名证书指定为
• ca-cert

  ，以便可以验证密钥。 这也仅对私人使用的证书有效，因为公众无法验证其真实性。

您可以在您的组织控制的域下使用 FQDN。 您的组织必须允许您更新 DNS 或处理对 FQDN 的公共 http 请求，以便您可以提供所有权证明。 例如，如果您有
• example.com

  ，您可以获得

  db.internal.example.com

  的公开签名证书。 然后你可以将

  db.internal.example.com

  定义为 127.0.0.1 或 /etc/hosts 中的任何 IP。您应该注意，可以在证书透明度日志中发现任何具有公开签名证书的 FQDN。 此外，出于安全考虑，公共 DNS 可能无法可靠地解析为 127.0.0.1 或其他私有地址，但这在家庭网络上比在 Azure 中更有可能发生。

Let's Encrypt 证书的有效期为 90 天。 文章说要重新启动 postgres 以获取新证书，但这种严厉的方法会在重新启动时中断 postgresql 服务。 从不久前的 postgres 10 开始，可以重新加载

ssl 证书，而无需重新启动服务器

或中断现有客户端。 因此，如果您最终使用 let's crypt，不要每 10 天重新启动一次数据库服务器并导致中断，而是发出重新加载。