我一直在研究迁移到使用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 上的连接进行了保护，因此我无法
HTTP-01在设备本身上提供该子域 (fw.example.com) 的验证文件。FTP 服务器的子域 (ftp.example.com) 也是如此。 - 我的 DNS 由当前不提供 API 的提供商托管（他们说他们正在开发 API），因此我无法
DNS-01通过将 TXT 记录写入区域文件来自动化验证过程。 - 我找到了
TLS-ALPN-01验证方法，但我不确定这是否适合我尝试实现的用例。根据Let's encrypt（强调我的）中对该方法的描述：
这个挑战并不适合大多数人。它最适合希望执行基于主机的验证（如 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？同样，我不认为是这种情况，但我想尽我所能避免在这种情况下引入更多的复杂性和/或问题。