知名 PaaS 提供商Heroku为 SSL 问题提供了多种解决方案。其中一种是名为基于主机名的 SSL
这不是 SNI。他们声称它可以在任何配置下在所有浏览器上运行,但有其他缺点,主要是(引用文档):
基于主机名的 SSL 不适用于根域,因为它依赖于自定义域名的 CNAME 别名。
主机名 SSL 仅适用于一个域名。例如,www.domain.com 可以工作,但如果将 secure.domain.com 的第二个证书添加到应用程序,它将无法工作。
我们基于主机名的 SSL 产品当前删除了一些 HTTP 标头;例如,当您的应用需要查看客户端的 IP 时,这可能会出现问题。
使用此自定义构建解决方案,Heorku 可以在单个 IP 地址上为多个 SSL 站点提供服务,并且正如他们声称的那样,它可以在任何平台上运行。
有人能解释一下这个解决方案的技术方面以及该产品背后的技术吗?
答案1
事实并非如此。Heroku 不会在单个 IP 地址上提供多个 SSL 证书。例如,如果您针对不同的 Hostname SSL 部署执行 nslookup,您会发现它们各自指向不同的亚马逊 ELB. 秘诀就在于此。
当客户请求基于主机名的 SSL 时,系统会为他们配置一个 ELB,并要求客户将该 ELB 的主机名 CNAME 化。这些 ELB 会根据需要重新连接到 Heroku 路由网格。
希望以上内容能让您有所了解。欢迎随时提问。
答案2
我不知道,所以我只能猜测。这可能是 Heroku 自己的 DNS 服务器和 HTTP 服务器之间交互的结果。流程可能如下:
- 客户请求https://www.yourdomain.com
- 客户端的 DNS 解析器将 www.yourdomain.com 作为 CNAME 解析为 heroku 名称服务器上的 RR(例如 app1234.apps.heroku.com)
- 客户端的 DNS 解析器从 apps.heroku.com 的名称服务器查询 app1234.apps.heroku.com 的 A RR
- apps.heroku.com 的名称服务器发出一个地址,并通知相应的 Web 服务器,IP 地址为 1.2.3.4 的客户端正在请求主机 www.yourdomain.com
- 客户端发起与 app1234.apps.heroku.com 的 SSL 连接握手
- HTTPS 服务器知道 1.2.3.4 处的客户端将请求 www.yourdomain.com 作为站点,因此为 www.yourdomain.com 选择正确的证书,并继续进行 SSL 握手
在某些情况下,流程可能会中断,特别是当许多针对不同站点的请求源自单个 IP 地址时(代理或 NAT 网关后面的客户端就是这种情况),但这可以通过将来自单个源 IP 的不同目标主机的请求分散到许多 HTTPS 服务器之间来“平衡”,因此单个 HTTPS 服务器在决定为给定客户端选择哪个证书时不会有任何歧义。