多个SSL域到一个Azure云服务站点

Question

我们在ourapp.cloudapp.net上的Windows Azure云服务上运行了一个Web应用程序.我们从my.ourapp.com创建了一个CName记录,指向这个云服务.此域使用SSL加以保护.

我们现在要求允许不同的域(my.secondapp.com)访问my.ourapp.com上看到的内容.

我们可以创建一个新的云部署,但我们不希望额外的成本来托管和维护单独的部署.我们还考虑在443以外的端口上添加另一个https EndPoint,但从我读过的内容来看,这意味着我们的用户必须使用":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的证书似乎安装正确(一个通过常用的Azure方法,一个通过上面文章中的SNI代码).当我远程访问我们的Web角色并转到ISS时 - 它们都出现在"服务器证书"部分中.

• 不确定这是否有所不同,但我之前在一些文章中读过它:MMC中的"虚拟主机"部分没有证书.我手动为证书添加了Snap-In并导入了my.secondapp.com证书,但无济于事.

• 在IIS中,我们在服务器下拥有通常的Azure Web角色站点 - 类似于"RD0001683008".当我查看Site Binding选项时,我看到:

输入 | 主机名 | 港口 | 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,但没有运气.我尝试将IP地址的组合更改为"所有未分配",但再次,没有运气.我是否需要重新启动站点或应用程序池？

• 我删除了my.secondapp.com的绑定,并在IIS中添加了一个新站点,其中包含与my.ourapp.com相同的详细信息(相同的应用程序池和Web空间).这确实给了我503服务不可用,这是不同的,但我不确定我是否应该继续探索这个选项.

• 另外需要注意的是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 =托管爱尔兰托管,OU =域名控制验证",而我们的普通证书有更多选项:"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".这可能与它有关吗？

很抱歉这个问题很长 - 我想尽可能多地提供细节可能有所帮助.

我真的很感激任何帮助.

Answer 1

为了防止别人需要帮助,有两个问题:

1. 我使用的SSL证书没有正确链接.如果您从提供商处获得3个证书,则需要使用IIS和MMC正确安装它们.有关详细信息,请参见此处
2. SNI文章确实奏效了.对我们来说问题是绑定顺序.我们最终得到以下顺序:

正如您所看到的,我们必须四处寻找才能使其工作,但以下绑定意味着两个域都指向同一个Web应用程序.

你会注意到我们已经在my.ourapp.com中添加了两次 - 一个启用了SNI,一个是IP地址而另一个没有.SNI在Windows XP上无法与IE一起使用 - 我们将最后一个选项添加为默认的非SNI绑定,因此我们的主域将始终有效,即使在IE和XP上也是如此.

希望能帮助别人.