在多个域上的非标准端口上运行的 Web 服务的 SSL 证书

Question

我有一个旧的内部公司 Web 服务，它不在标准 HTTP\HTTPS 端口上运行。此外，它由多个子服务组成。这意味着，Web 界面通过 HTTP 调用来调用 REST 函数，这些函数位于不同的域中，有些甚至是从 IP 地址：端口调用的。

我现在遇到的问题是现代浏览器不断抱怨上述任何内容缺少经过验证的 SSL 证书。

我希望最终能以某种方式签署所有这些乱七八糟的东西，这样 Google Chrome 和 Firefox 就不会再阻止它并抱怨其安全性。但是，由于这种架构，我不确定我应该获得哪个证书。甚至可能是多个证书。

具体来说，我的问题是：

1. Web 界面未在标准 HTTPS 端口上运行这一事实对证书类型或其颁发者有何影响？

2. 由于 Web 应用程序的各个部分是从不同域调用的，我想我需要一个多域 SSL 证书，对吗？如果我用自己的证书签署每个服务会怎么样？

3. 未分配域名的 REST API 公开，这意味着它们直接从特定 IP 调用。我认为我必须为这些 API 获取域名并为该域名颁发证书，我理解正确吗？比如，没有办法从受信任的机构为 IP 地址获取适当的证书？我知道考虑这件事是一件很糟糕的事情，但这个特定部分是一个旧的、几乎无法维护的 Tomcat 服务器，我真的不想碰它。

Answer 1

如果您控制端点，则可以将证书颁发机构部署到设备。如果您想运行 PKI，这可能是您自己的。关于公共颁发的证书，唯一“正确”的事情是它们植根于普遍信任的 CA。

TLS 不关心端口。它是任何字节流中的应用程序。始终使用 443 等端口进行 https 是为了方便用户。:8443当你可以从 443 反向代理到实际后端时，为什么要让他们输入类似的东西？这也使防火墙规则和数据包捕获更容易。

您可以自行决定需要多少个证书。

• 每个服务一个证书就可以了。尽可能简化证书颁发流程。
• 主体备用名称 (SAN) 允许一个证书上有多个不同的名称。例如，一个 Web 服务器实例有多个虚拟主机。
• 通配符证书（例如）*.example.com很有用，但也很危险。如果证书泄露，任何人都可以假装拥有任何匹配名称的证书，例如evil.example.com。RFC6125不鼓励使用它，但承认它仍然存在。

每项服务确实都应该有一个名字，如今 DNS 不再是可选的，它使一切成为可能。

您可以将 IP 地址放入 SAN 中，一个众所周知的例子是https://1.1.1.1/。但是，它并不常用，而且通过典型的基于 DNS 的证书提供商不容易获得。虽然浏览器可能会接受 SAN 中的 IP 地址，但其他用户代理可能不会。只需为其命名并以该名称颁发证书即可。

---

首先让所有新应用都采用 TLS 加密。内部和外部、敏感数据和非敏感数据。在新的干净环境中更容易实践 PKI 和面向服务的设计。