我们在 ourapp.cloudapp.net 上有一个在 Windows Azure 云服务上运行的 Web 应用程序。
我们从 my.ourapp.com 创建了一个 CName 记录来指向这个云服务。此域使用 SSL 进行保护。
我们现在需要允许不同的域( my.secondapp.com )访问 my.ourapp.com 上看到的内容。
我们可以创建一个新的云部署，但我们不希望额外的成本来托管和维护单独的部署。我们还考虑在 443 以外的端口上添加另一个 https 端点，但根据我的阅读，这意味着我们的用户必须使用“:444”后缀浏览我们的网站。
在互联网上进行了一些挖掘之后 - 我们发现了这篇文章: http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/ 。它指出，使用 IIS8 和 SNI，我们可以为一项云服务拥有多个证书。
但是，我们不能让它工作 - 导航到 my.secondapp.com 给出一个证书警告说提供的证书实际上是 my.ourapp.com 。
这里还有一些提示:
my.ourapp.com 和 my.secondapp.com 的证书似乎已正确安装(通过上面的常用 SNI 代码和文章之一)。当我远程访问我们的 Web 角色并转到 ISS 时 - 它们都出现在“服务器证书”部分中。 不确定这是否有所不同，但我在之前的一些文章中读到过:MMC 的“Web 托管”部分中没有证书。我手动添加了证书管理单元并导入了 my.secondapp.com 证书但无济于事。 在 IIS 中，我们的服务器下有通常的 Azure Web 角色站点 - 类似于“RD0001683008”。当我查看站点绑定(bind)选项时，我看到: 类型 | 主机名 | 端口 | IP http
| (空白)
| 80
| 10.26.130.10
https
| (空白)
| 443
| 10.26.130.10
https
| my.secondapp.com
| 443
| 10.26.130.10
我试图将 my.ourapp.com 输入到前两行的主机名部分，希望它只能获取该主机名而不是 my.secondapp.com _67，但没有运气。我尝试将 IP 地址的组合更改为“全部未分配”，但同样没有运气。我需要重新启动站点或应用程序池吗？ 我删除了 my.secondapp.com 的绑定(bind)，并在 IIS 中添加了一个新站点，其详细信息与 my.ourapp.com 和 websame 应用程序相同。这确实给了我一个不同的 503 Service Unavailable，但我不确定我是否应该继续探索这个选项。 另一个需要注意的是 SSL 证书本身。它是由第三方生成的，与我们拥有的 my.ourapp.com 证书有些不同。通常，我们会得到一个 .crt 文件并将其导出为 .pfx。当我尝试导出新证书时，.pfx 选项变灰，我只能选择 .cer。我做了一些魔术并设法将其导入并以某种方式导出到 pfx，并在此过程中提供了密码。也许第三方应该在此过程的早期使用密码创建证书？此外，第三方提供了三个证书(AddTrustExternalCARoot.crt、my_secondapp_com.crt、PositiveSSLCA2.crt)。我只使用了 my_secondapp_com.crt - 我应该使用其他的还是链接它们？ 打开证书本身声明“此证书用于以下目的:”并具有通常的“确保远程计算机的身份”、“向远程计算机证明您的身份”。但还有另外两行“1.3.6.1.4.1.6449.1.2.2.7”和“2.23.140.1.2.1”，它们不在我们拥有的任何其他证书上。 最后，在查看 azure 门户中证书部分中的证书时。新证书的主题有“CN=my.secondapp.com, OU=PositiveSSL, OU=Hosted by Hosting Ireland, OU=Domain Control Validated”，而我们的普通证书有更多选项:“CN=my.ourapp.com , OU=域控制验证 - RapidSSL(R), OU=参见 www.rapidssl.com/resources/cps (c)11, OU=GT1234567, O=my.ourapp.com, C=IE, SERIALNUMBER=sOmESerIalNumBEr"。这可能与它有关吗？ 抱歉问了这么长的问题 - 我认为提供尽可能多的细节可能会有所帮助。
我真的很感激任何帮助。
以防万一其他人需要帮助，有两个问题:
我使用的 SSL 证书没有正确链接。如果您从提供商处获得 3 个证书，则需要使用 IIS 和 MMC 正确安装它们。见 here了解更多信息。 SNI 文章确实有效。我们的问题是绑定(bind)顺序。我们最终得到了以下订单: 
正如您所看到的，我们不得不尝试使其工作，但以下绑定(bind)意味着两个域都将指向同一个 Web 应用程序。
您会注意到我们添加了
my.ourapp.com 两次 - 一个启用了 SNI 和一个 IP 地址，另一个没有。 SNI 不适用于 Windows XP 上的 IE - 我们添加了最后一个选项作为默认的非 SNI 绑定(bind)，因此我们的主域将始终有效，即使在 IE 和 XP 上也是如此。
希望能帮助某人。