介绍
简而言之，问题就是这个。我使用“Virtualmin”已经有一段时间了，主要是因为它比 VestaCP、Ajenti、Direct Admin (Evolution)、CPanel、Sentora 和大多数“ISP”系列效果更好（在我看来和我的目的） .
在这样做时，我已经可以通过 CLI / FTP 完成几乎所有事情，这只是一个更一致的选择，让每个人都可以一起工作，并且其他人可以解决他们自己的问题。习惯 Virtualmin / Webmin 并没有花很长时间，但我遇到了一个问题，就是因为没有更好的词，令人费解。
我通过“Let's Encrypt”和有时 Cloudflare 的组合在我的所有站点上运行 SSL 证书，因为无论如何我都使用它来管理 DNS 和缓解 DDOS 攻击（必要时打开它）。此外，我限制了 TLS 版本，通过全局指令设置了我自己的密码，并启用了 HSTS。
但是，现在我有一个软件，如果站点位于 SSL 层和/或代理下，由于某种原因，它无法连接到它的 REST API。因此，我尝试禁用 SSL 证书强制以暂时纠正问题。但是，在删除它之后，我意识到启用 HSTS 后，我无法再访问该站点的正常“HTTP”版本。我删除了指令中的 HSTS 行，但它仍然存在。
由于 Virtualmin 发生证书不匹配，我也收到了安全警告。出于某种原因，其他域上的 SSL 证书正在应用于当前证书。我检查了每个站点的 .conf 文件以及每个站点的指令（和 SSL 指令），因为我们正在寻找可以在全局指令中执行此操作的任何内容。情况看起来有点像这样。
域和层
- Example.com（域一）
- --Analytics.Example.com（上述子域下的一个）
- ExampleTwo.com（不同的域，“域二”）
- --App.ExampleTwo.com（上面'Two'下的子域）
本质上，除了 App 自己的 SSL 证书之外，来自 Analytics 的 SSL 证书正在被推送到 App 子域（位于不同域下）。当我关闭 Analytics 的 SSL 证书和 App 的 SSL 证书时，顶层的 (Example.com) SSL 证书随后被强制进入“App”子域。我原以为这必须体现在站点指令、它们的 SSL 指令或全局指令中的 SSL.Conf 中，但那里什么都没有。我还没有找到解决这个问题的方法。