我正在实现一个多租户应用程序，其中我的应用程序托管并提供租户产品的技术文档。
现在，我正在考虑的方法是 - 我托管文档docs.<tenant>.mycompany.com并要求我的租户设置一个 CNAME DNS 记录来docs.tenantcompany.com指向docs.<tenant>.mycompany.com。
我希望使用租户证书为网站启用 SSL。我想知道如果我的租户公司有通配符 SSL 证书，它是否适用于此设置，还是必须购买新的 SSL 证书docs.tenantcompany.com？
答案1
证书名称必须与用户在浏览器中输入的内容相匹配，而不是“最终”DNS 记录。如果用户输入，docs.tenantcompany.com则您的 SSL 证书必须涵盖该内容。
如果docs.tenantcompany.com是 CNAME foo.example.com，则证书不是需要 覆盖foo.example.com, 只是docs.tenantcompany.com.
答案2
Jason 的回答是正确的。但在此需要澄清一些术语，“DNS 重定向”这个名称有点用词不当。DNS 有 CNAME 记录（又称别名），即指向另一个名称的名称。但这不是重定向。从名称到名称再到 IP 的转换都在后台进行，您的浏览器只关心初始名称。
唯一会重定向的是 Web 服务器，服务器明确地告诉您的浏览器转到其他地方。如果您的 Web 服务器曾是实际上重定向到另一个名称，你会实际上需要这两个名称的证书，因为您的浏览器最终将分别连接到它们两个。
答案3
我想了解如果我的租户公司有通配符 SSL 证书，它是否可以适用于此设置，还是必须购买新的 SSL 证书
docs.tenantcompany.com？
简短回答：不。如果您的租户公司名称中有通配符*.tenantcompany.com，则在您的服务器上安装即可覆盖通过该名称进行的访问。您是否想这样做又是另一回事。
如果始终通过名称进行访问，则名称中的证书docs.<tenant>.mycompany.com（例如直接证书或通配符）是无用的。*.<tenant>.mycompany.comdocs.tenantcompany.com
较长的答案
假设您使用一个合理的浏览器进行浏览https://docs.tenantcompany.com。浏览器通过 HTTP 协议运行 TLS。它特别关注两件事：
浏览器和操作系统的 DNS 子系统会返回合适主机的 IP 地址，该主机在本地网络或互联网上其他合适的端口上运行 Web 服务器。对于 HTTPS（安全）流量，
443除非在 URL 中另行覆盖，否则默认端口为。当。。。的时候TLS 握手发生在浏览器和远程服务器之间，服务器提供受信任的证书，允许其在请求的地址提供 TLS 服务（
docs.tenantcompany.com）。
DNS
浏览器将 DNS 视为一个黑匣子。它会调用合适的 DNS 库，请求将友好的完全限定域名 (FQDN) 映射到合适的 IP 地址 (v4 或 v6)。它并不关心如何获取该 IP 地址。CNAME如果DNS 中的原始记录和A或记录之间有 20个别名AAAA，则 DNS 解析器将跟踪这些别名，直到获得 IP 地址。
TLS
当浏览器执行TLS 握手，它需要验证与其通信的服务器是否被授权在请求的 FQDN 上提供安全的网站服务：docs.tenantcompany.com。
请记住：浏览器并不关心docs.<tenant>.mycompany.com- DNS 解析器已经通过CNAME记录抽象出了所有有关间接的知识。
我们授权服务器提供安全会话的方法docs.tenantcompany.com是通过 SSL 证书，该证书由在浏览器根证书存储中已建立信任的机构签署。这并不总是服务器到客户端最强大的身份验证形式 - 在集中式 CA 模型中可能会出现很多问题 - 但这是我们目前拥有的最佳方式。
这里还有两个注意事项：
密钥共享
许多商业 SSL 证书供应商只会签署一份签名请求，这实际上将通配符证书绑定到单个私钥。租户公司可能不愿意在其组织之外共享此信息，因为任何拥有私钥的人显然都会危及与租户公司其他安全系统的通信。
一些供应商会在同一证书下签署多个证书签名请求，这允许在多个服务器和系统上安装单个通配符证书，而无需在它们之间共享私钥。
伪装
如果租户公司向您提供了其通配符证书的副本（通过共享私钥或签署您自己的 CSR），您可以伪装成<anydomain>.tenantcompany.com，从而破坏确保 DNS 命名空间中标识的服务器完整性的重要保护tenantcompany.com。从法律/责任的角度来看，这对您和租户公司来说都可能是一个不利的处境。