Multiple SSL domains to one Azure Cloud Service Site

Question

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.

We now have a requirement to allow a different domain (my.secondapp.com) access exactly what is seen on my.ourapp.com.

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.

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.

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.

Here are some more pointers:

• 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.

• 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.

• 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:

Type | Hostname | Port | IP

http | (blank) | 80 | 10.26.130.10

https | (blank) | 443 | 10.26.130.10

https | my.secondapp.com | 443 | 10.26.130.10

• 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?

• 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.

• 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?

• 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.

• 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.

I'd really appreciate any help.

Answer 1

Just in case someone else needs help on this, there were two problems:

1. The SSL cert I was using wasn't chained correctly. If you get 3 certs from your provider, you need to install them correctly using the IIS and MMC. See here for more info.
2. The SNI article did work. The problem for us was the binding order. We ended up the following order:

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.

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.

Hope that helps someone.