多SSL的站点一个Azure的云服务网站 [英] Multiple SSL domains to one Azure Cloud Service Site
问题描述
我们对Windows Azure云服务运行在一个Web应用程序的的 ourapp.cloudapp.net 的。
我们创建从CNAME记录 my.ourapp.com 的以指向这个云服务。该域采用SSL安全。
We have a web application running on Windows Azure Cloud Service at ourapp.cloudapp.net. We created a CName record from my.ourapp.com to point to this cloud service. This domain is secured with SSL.
我们现在有一个要求，让不同的域（ my.secondapp.com 的）的访问到底是什么看到的 my.ourapp.com 。
We now have a requirement to allow a different domain (my.secondapp.com) access exactly what is seen on my.ourapp.com.
我们可以创建一个新的云部署，但我们不希望额外费用托管和维护一个单独的部署。我们也想过将另一HTTPS终结比443，但其它的端口上我已阅读，这意味着我们的用户将不得不浏览我们的网站与444。后缀
We could create a new cloud deployment but we don't want the extra cost to host and maintain a seperate deployment. We also thought about adding another https EndPoint on a port other than 443 but from what I have read, this meant our users would have to navigate our site with the ":444" suffix.
在互联网上做一些挖后 - 我们遇到了这篇文章：<一href=\"http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/\">http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/ 。它指出，使用IIS8和SNI我们可以有一个云服务多个证书。
After doing some digging on the internet - we came across this article: http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/ . It states that using IIS8 and SNI we can have multiple certificates for one cloud service.
但是，我们不能得到这个工作 - 导航到 my.secondapp.com 的给出了一个证书警告说提供的证书实际上是对于 my.ourapp.com 的
However, we can't get this to work - navigating to my.secondapp.com gives a certificate warning saying the cert provided is actually for my.ourapp.com.
下面是一些指针：
-
为 my.ourapp.com 的和 my.secondapp.com 的显示的证书正确安装（通过文章中的SNI code一个过孔通常Azure的方法和一个以上）。当我远程登录到我们的网络角色和进入国际空间站 - 他们在服务器Cerificates部分既present
The cert for both my.ourapp.com and my.secondapp.com appear to be installed correctly (one via the usual Azure method and one via the SNI code in the article above). When I remote into our web roles and go to ISS - they are both present in the 'Server Cerificates' section.
不知道这是否有差别，但我读了一些文章前面：有在MMC的虚拟主机一节中没有证书。我手动添加一个管理单元的证书和进口 my.secondapp.com 的证书，但无济于事。
Not sure if this makes a difference, but I read it on some article earlier: there are no certificates in the "Web Hosting" section in the MMC. I manually added a Snap-In for Certificates and imported the my.secondapp.com cert but to no avail.
在IIS我们平时Azure的Web角色网站我们的服务器下 - 有点像'RD0001683008。当我看网站绑定选项我看到：
In IIS we have the usual Azure web role site under our server - something like 'RD0001683008'. When I look at the Site Binding options I see:
键入 | 主机名 | 端口 | IP
HTTP | （空白）的 | 80 | 10.26.130.10
http | (blank) | 80 | 10.26.130.10
HTTPS的 | （空白）的 | 443 | 10.26.130.10
https | (blank) | 443 | 10.26.130.10
HTTPS的 | my.secondapp.com | 443 | 10.26.130.10
https | my.secondapp.com | 443 | 10.26.130.10
-
我试图进入 my.ourapp.com 的成的前两行希望它只会拿起该主机名，而不是主机名部分< STRONG>的 my.secondapp.com 的，但没有运气。我试图改变IP的combinationg地址为全部未分配，但再次，没有运气。我需要重新启动该站点或应用程序池？
I tried to enter my.ourapp.com into the hostname part in the first two lines hoping that it would only pick up that hostname and not my.secondapp.com, but no luck. I tried changing a combinationg of IP addresses to 'All Unassigned' but again, no luck. Would I need to restart the site or application pool?
我删除了绑定的的 my.secondapp.com 的并添加IIS中的新网站使用相同的细节 我的。 ourapp.com 的（同一应用程序池和网络空间）。这也给我一个503服务不可用这是不同的东西，但我不知道我是否应该继续探索这个选项。
I removed the binding for my.secondapp.com and added a new Site in IIS with the same details as my.ourapp.com (same Application Pool and web space). This did give me a 503 Service Unavailable which was something different, but I'm not sure if I should continue exploring this option.
另外需要注意的是SSL证书本身。它是由第三方产生，是有所不同的 my.ourapp.com 的证书我们有。通常情况下，我们得到一个.crt文件并导出这.PFX。当我尝试导出证书新的.PFX选项是灰色的，我只能选择.CER。我做了一些魔术和管理的导入和导出某种程度上它PFX，提供沿途的密码。也许第三方应创建与早期的过程中密码证书？此外，第三方提供了三个证书（AddTrustExternalCARoot.crt，my_secondapp_com.crt，PositiveSSLCA2.crt）。我只用my_secondapp_com.crt - 我应该使用他人或把它们连
Another thing to note is the SSL cert itself. It was generated by a third party and is somewhat different to the my.ourapp.com cert we have. Usually, we get one .crt file and export this to .pfx. When I try to export the new cert, the .pfx options are greyed out and I can only choose .cer. I did some magic and managed to import and somehow export it to pfx, providing a password along the way. Maybe the third party should of created the cert with a password earlier in the process? Also, the third party provided three certs (AddTrustExternalCARoot.crt, my_secondapp_com.crt, PositiveSSLCA2.crt). I only used my_secondapp_com.crt - should I use the others or chain them?
开放本身指出，这个证书被用于以下用途：该证书并具有通常的确保远程计算机的身份，证明你的身份到远程计算机。但也有另外两条线1.3.6.1.4.1.6449.1.2.2.7和2.23.140.1.2.1，这是不是我们有什么其他证书。
Opening the cert itself states that "This cert is intended for the following purposes:" and has the usual "Ensures the identity of a remote computer", "Proves your identity to a remote computer". But also has two other lines "1.3.6.1.4.1.6449.1.2.2.7" and "2.23.140.1.2.1" which aren't on any other cert we have.
最后，在蔚蓝的门户证书部分证书看时。新证书的主题有CN = my.secondapp.com，OU = PositiveSSL，OU =通过举办爱尔兰，OU =域控制验证托管，而我们正常的证书有更多的选择：CN = my.ourapp.com ，OU =域控制验证 - 的RapidSSL（R），OU =见www.rapidssl.com/resources/cps（三）11，OU = GT1234567，O = my.ourapp.com，C = IE浏览器，SERIALNUMBER = sOmESerIalNumBEr。可这有什么关系呢？
Finally, when looking at the cert in the Certificates section in the azure portal. The subject for the new cert has "CN=my.secondapp.com, OU=PositiveSSL, OU=Hosted by Hosting Ireland, OU=Domain Control Validated" while our normal cert has many more options: "CN=my.ourapp.com, OU=Domain Control Validated - RapidSSL(R), OU=See www.rapidssl.com/resources/cps (c)11, OU=GT1234567, O=my.ourapp.com, C=IE, SERIALNUMBER=sOmESerIalNumBEr". Could this have something to do with it?
对不起，长的问题 - 我想给尽可能多的细节可能会帮助
Sorry for the long question - I thought giving as much detail as possible might help.
我真的AP preciate任何帮助。
I'd really appreciate any help.
推荐答案
万一有人需要这样的服务，有两个问题：
Just in case someone else needs help on this, there were two problems:
- 我用的是SSL证书没有被正确链接。如果你从你的提供商3的证书，你需要正确地安装它们使用IIS和MMC。请参见这里更多信息。
- 的SNI文章做的工作。对我们来说，问题是绑定顺序。我们结束了下面的命令：
正如你所看到的，我们不得不玩得到这个工作，但以下绑定意味着两个域将指向同一个Web应用程序。
As you can see we had to play around to get this to work but the following bindings meant that both domains would point to the same web application.
您会注意到我们在 my.ourapp.com 的两次增加了 - 一个符合SNI启用，IP地址和其他没有。 SNI不与IE浏览器在Windows XP上运行 - 我们添加的最后一个选项为默认的，非SNI约束力所以我们的主要领域总是工作，即使在IE浏览器和放大器; XP。
You will notice that we have added in my.ourapp.com twice - one with SNI enabled and an IP address and the other without. SNI does not work with IE on Windows XP - we added the last option as a default, non-SNI binding so our main domain would always work, even on IE & XP.
希望有所帮助别人。
这篇关于多SSL的站点一个Azure的云服务网站的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
