LetsEncrypt 证书已为example.com和创建www.example.com。这是 IP 上的 Linux 服务器123.123.123.1。
我想添加foo.example.comand bar.example.com，但这些子域设置为123.123.123.2（MS2012 服务器，DNS 记录中设置的 IP）。
我需要 SSL 证书才能在不引发浏览器错误的情况下传输数据。显然，在服务器上创建的证书123.123.123.1只需要复制到123.123.123.2.
问题是使用
sudo certbot --apache --cert-name example.com -d example.com,www.example.com,foo.example.com,bar.example.com
要添加子域，我收到未经授权的错误和 404。
如果子域位于另一台服务器（我有权访问）上，如何将子域添加到证书中？
假设您对托管 foo.example.com 和 bar.example.com 的服务器具有 ssh 访问权限，只需运行certbot上述两个域的命令，它应该可以正常工作而不会出现任何错误和浏览器警告。为了certbot能够生成证书，它需要在托管域的同一服务器上运行。
我最终使用
certbot certonly --manual --cert-name example.com --preferred-challenge dns -d example.com,www.example.com,x.example.com,y.example.com,z.example.com --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory
同样重要的是等待 DNS 记录在网络中传播，或者在我的情况下（在同一个网络中），等待 5 分钟直到 DNS 设置生效。
一年多来，我一直在使用从一个 Linux 机器到另一个机器的一些脚本来做这件事。让我概述一下我在做什么，因为我将无法共享脚本。此外，您在一端使用 Windows，因此某些 shell 脚本将毫无用处。
certbot客户端使用一个众所周知的 URI/.well-known来放置用于通过 HTTP 进行自动域验证的令牌文件（使用webroot身份验证器/插件）。
现在，我对位于您的案例 123.123.123.2 上的少数域所做的就是在 123.123.123.1 上启用 HTTP（即端口 80）foo.example.com并bar.example.com分别为 和 配置虚拟主机。
然后将该虚拟主机配置为（在 Nginx 中）指向 URI 的物理位置，/.well-known以便certbot能够将令牌文件放入该路径：
location /.well-known/ {
alias /your/path/.well-known/;
autoindex on;
try_files $uri $uri/ =404;
limit_except GET {
deny all;
}
}
通过这种方式，我可以使用webroot验证器certbot并指向所述“假域”的 Web 根目录（它是假的，因为它是 123.123.123.1 上的虚拟主机，而该域的 DNS 条目指向 123.123.123.2）。
现在这不是结束，而是第一步。
在 DNS实际指向的另一台机器上，我安装rinetd了指向端口 80 上的 123.123.123.1（运行 certbot 的机器）。/etc/rinetd.conf这看起来像：
127.0.0.1 8080 123.123.123.1 80
同时，/.well-known对站点foo.example.com和bar.example.com123.123.123.2 的任何请求都被静默代理到 127.0.0.1 端口 80，同时保留 HTTP 参数（主机名和 URI 不变）。
例如，通过使用这种方法certbot（在 .1 上运行）将创建一个令牌文件/your/path/.well-known/foobar，Letsencrypt 将尝试访问http://foo.example.com/.well-known/foobar. 该请求将 - 像往常一样 - 最终出现在 DNS 记录指向的机器上。所以它最终在 .2 上结束，其中 HTTP 服务器配置为将 URI 下的项目请求静默转发/.well-known到 127.0.0.1 端口 8080，该端口rinetd用于将数据包转发到 123.123.123.1 端口 80。因此我们关闭了圆圈，certbot 将能够执行其域验证例程。
唉，我在 Linux 上运行它，所以你的设置似乎是一个 Windows 服务器，你必须找到（或创建）类似rinetdWindows 的东西。尽管这可能没有直接帮助，但也许它可以帮助其他人在两个 Linux 机器上遇到类似问题。
整个rinetd例程旨在使 123.123.123.1 的 HTTP 标头完好无损，以便该域的虚拟主机在 123.123.123.1 上生效。
使用这个例程，我的一台服务器可以更新一系列实际托管各个子域的其他机器。
哦，另一个注意事项。您的场景只是一个非常明确的场景。如果您想运行 XMPP 或 MTA，并且服务的查找不仅仅与 A/AAAA 或 CNAME 记录的 DNS 查找严格相关，那么您最终会遇到在技术上与您的情况相同的情况.
如果有人对如何解决这个问题有更聪明的想法，请在对此答案的评论中给我留言。