【发布时间】：2021-10-10 17:53:45
【问题描述】：
我一直在研究迁移到使用 Let's Encrypt 的可能性，以维护我们为我们用于运营的各种资源所拥有的 SSL 证书。我们有以下使用 SSL 证书的资源：
- 主网站 (
www.example.com/example.com) - 由同样维护 SSL 证书的第三方托管和维护 - 客户端门户网站 (
client.example.com) - 由我们在位于远程数据中心的服务器上托管和维护的 IIS 站点 - FTP 服务器 (
ftp.example.com) - 由我们在位于远程数据中心的服务器上托管和维护的 WS_FTP 服务器 - 硬件防火墙 (
firewall.example.com) - 我们内部网络的本地安全设备 - 远程桌面网关 (
rd.example.com) - 由我们在本地服务器上托管和维护的 RDP 服务器
如上所述，主网站 (www) 的 SSL 证书由第 3 方主机维护，所以我一般不会弄乱那个。但是，正如您所知，每个端点的 DNS 记录都指向各种不同的 IP 地址。这就是我对颁发和部署 SSL 证书的整个过程缺乏经验让我有点困惑的地方。
首先，由于我不管理或维护主网站，因此我目前正在从提供端点的服务器/服务中手动为每个端点生成 CSR——一个来自 IIS 服务器，另一个一个来自 RDP 服务器，另一个来自 WS_FTP 服务器，一个来自硬件防火墙。手动过程虽然不是很耗时，但仍然需要我通过几个步骤来处理需要不同过程的不同服务器系统。
我考虑过使用 Let's Encrypt 的免费通配符 SSL 证书之一来覆盖所有四个端点 (*.example.com)，但我不想“干涉”我们的主要网站主机在这方面所做的事情.我意识到实际的证书本身是由客户端连接的服务器提供的，所以它不应该重要（对吗？），但我可能仍然对单独的 SSL 证书更满意每个子域端点。
因此，我一直致力于使用Certes ACME 客户端库构建应用程序，以尝试自动处理从 CSR 到部署的整个 SSL 流程。但是，我遇到了一些障碍：
- 防火墙针对端口 80 上的连接进行了保护，因此我无法在设备本身上为该子域 (fw.example.com) 提供
HTTP-01验证文件。 FTP 服务器的子域 (ftp.example.com) 也是如此。 - 我的 DNS 由当前不提供 API 的提供商托管（他们说他们正在开发 API），因此我无法通过将 TXT 记录写入区域来自动执行
DNS-01验证过程文件。 - 我找到了
TLS-ALPN-01验证方法，但我不确定这是否适合我尝试实现的用例。根据 Let's encrypt (emphasis mine) 中对该方法的描述：
此挑战不适合大多数人。它最适合希望执行基于主机的验证（如 HTTP-01）的 TLS 终止反向代理的作者，但希望完全在 TLS 层完成以分离关注点。目前，这主要意味着大型托管服务提供商，但 Apache 和 Nginx 等主流 Web 服务器有一天可能会实现这一点（Caddy 已经这样做了）。
优点：
- 如果您无法使用端口 80，它会起作用。
- 可以纯粹在 TLS 层执行。
缺点：
- Apache、Nginx 或 Certbot 不支持它，并且可能不会很快支持。
- 与 HTTP-01 一样，如果您有多个服务器它们都需要使用相同的内容来回答。
- 此方法不能用于验证通配符域。
所以，根据我目前的研究和我的环境，我最大的三个问题是：
-
TLS-ALPN-01验证方法对于为每个子域生成单独的 SSL 证书是否是一种有效的（甚至是可用的）选项？由于防火墙和 FTP 服务器目前无法在端口 80 上提供适当的文件，因此我看不到任何方法可以对这些子域使用HTTP-01验证。无法使用 API 自动执行DNS-01验证会使该方法通常比其价值更麻烦。虽然我可能可以对客户端门户进行HTTP-01验证 - 也可能是 RDP 服务器（我的研究还没有做到这一点） - 我仍然需要手动处理其他两个子域。李> - 尝试为子域创建通配符证书会更好吗？除了通过减少需要颁发的 SSL 证书的数量来“简化”流程之外，与为每个子域使用单独的证书相比，走这条路线是否有任何内在的好处？由于主站点由第 3 方托管/管理，并且（再次）我目前无法使用 API 来自动执行
DNS-01验证，我想我需要使用HTTP-01验证。根据我的理解，这意味着我需要获得访问/权限才能创建响应文件，以及该服务器上的相应目录。 - 可以肯定的是，如果我要生成/部署通配符证书到子域，而主网站仍然使用自己的 SSL 证书作为
www，是否有可能导致某种“冲突”？同样，我认为不会是这种情况，但我想尽我所能避免给这种情况带来更多的复杂性和/或问题。
【问题讨论】：
-
我想我的一个“替代方案”是将我的整个 DNS 区域迁移到一个确实有可用 API 的主机。虽然不一定是我的最喜欢的解决方案——只是因为我很懒，不想在新主机上重新创建所有记录——这可能是我自动化证书的最佳选择使用
DNS-01验证方法的请求、验证和颁发过程。
标签： ssl subdomain lets-encrypt wildcard-subdomain acme