Domain mapping, Domain forwarding, SSL certificate for Windows Azure

  • Article

Are you looking for an answer to any of the following questions, this article may help you.

       Q. How do I access my cloudapp.net application using my own custom domain name?

       Q. How do I access my application using custom root domain as well as sub domain?

       Q. How do I access my cloud application hosted on Azure, without www in my domain URL?  

       Q. Can we create specific subdomain, something like <prefix>.<myapp>.cloudapp.net instead of <prefix>.cloudapp.net.

       Q. We need to access our cloudapp.net application over HTTPS, but cannot buy an SSL certificate issued for a cloudapp.net domain. What is the solution?

       Q. Does Windows Azure support wildcard SSL ?  For example, can I create an SSL certificate issued for *.mydomain.com and use it in Windows Azure?

       Q. How do I configure HTTPS for multiple sites with 2 different SSL certificates on a single IP address and single port number: 443.

       Q. Unable to perform VIP Swap, due to changes in the endpoints of my staging and production deployments. How do I roll out a new deployment without downtime?

 

Configuring a CNAME (Canonical Name)

When you create an application in Windows Azure, Windows Azure provides a friendly subdomain on the cloudapp.net domain, so your users can access your application on a URL like https://<myapp>.cloudapp.net. If you want to expose your application on your own domain name, you need to configure a CNAME on your domain registrar. With a CNAME, you map a specific domain, such as www.mydomain.com, to the <myapp>.cloudapp.net domain name of your Windows Azure hosted application. Note, however, that most domain registrars only allow you to map subdomains, such as www.contoso.com and not root names, such as contoco.com or *.contoso.com.

  • Ø  Assume you have a domain name mydomain.com. This is your root domain
  • Ø  In your domain provider, register a CNAME, mapping your subdomain www.mydomain.com to <myapp>.cloudapp.net. 
  • Ø CNAME works as an alias.

(For your reference I have provided a screen shot of one of the domain provider. Please check the last row in the screen shot).

  

 The following will happen when a request comes in with your subdomain:

         www.mydomain.com              CNAME      myapp.cloudapp.net

        www.myapp.cloudapp.net       A                  VIP address

When an A record lookup for www.mydomain.com is done, the DNS resolver will see a CNAME record and restart the checking at www.myapp.cloudapp.net and will then return VIP address. VIP address is the load balancers IP address, through which requests, gets routed to one of the instances of your application. If you delete your deployment and rollout a fresh deployment, VIP address is subjected to change. So, by configuring a CNAME in your domain registrar, you will not have to worry about the DNS mapping, even if the VIP address changes.

A visitor of www.mydomain.com  will never see the true host (myapp.cloudapp.net), so the forwarding process is invisible to the end user. Note: The example above only applies to traffic at the www subdomain.

You cannot specify a root CNAME record that directs all traffic from a custom domain to your cloudapp.net address, so additional alias records must be added. If you want to direct all traffic from a root domain, such as mydomain.com, to your cloudapp.net address, you can configure a URL Redirect or domain forwarding in your DNS settings. CNAME records have one limitation: they need to map a specific subdomain. It’s not possible with a CNAME record to map the root domain itself, which is why we needed to do domain forwarding.

Domain forwarding

Use domain forwarding to map the root domain (mydomain.com) to the subdomain (www.mydomain.com).

 

SSL Certificate for Windows Azure Cloud Applications

If you get an SSL certificate issued for <myapp>.cloudapp.net, you will not be able to get this certificate verified (a mandatory validation step by Certificate Authority). This is because cloudapp.net domain is owned by Microsoft. So, you will have to get the SSL certificate issued for your domain name or wildcard name ie *.mydomain.com. You will be able to verify this certificate for the certificate authority, because you own your domain.

If you are trying to configure HTTPS for multiple sites in a single webrole with 2 different certificates on a single IP address and single port number: 443.

This is not possible because, with this design IIS is left with only host header name to distinguish between the sites. The host header name is encrypted in the SSL blob when the client sends a request. Because the host header name is part of the binding, IIS needs the host header name to lookup the right certificate. Without the right choice of certificate, IIS can't decrypt the SSL blob that contains the host name. Without the host name IIS can't look-up the right site.

Host headers were never supported on any SSL binding because that part of the packet (header) is encrypted. We must have a unique IP address for any 443 SSL binding.This explains the limitation in IIS. Alternatively, you can get a wildcard certificate or a SAN (Subject alternative name) certificate for your domain. You can use this certificate for all your subdomains and root domain.

 

Using CNAME to roll out new deployments without downtime

In order to do enable HTTPS for your application (currently running on HTTP) you will need to change the service model. Because you are changing the number of endpoint to your service, you cannot perform VIP Swap with no-downtime deployment but you can use the following workaround:

  • Create new hosted service in Windows Azure. For example mynewservice.cloudapp.net
  • Deploy and run the new code on the new hosted service.
  • Go to your domain registrar and change the CNAME mydomain.com to point to mynewservice.cloudapp.net
  • Wait at least 24 hours before deleting something.cloudapp.net

The no-downtime will be handled by the DNS servers - if you try to access your website’s URL www.mydomain.com and if your DNS server was already updated with the new CNAME, you will hit the new bits. If your DNS server wasn’t updated with the new CNAME, you will hit the old service.After some time (based on the TTL set for the CNAME which is typically 24h) all DNS servers around the world will be updated with the new CNAME, and everybody will hit the new bits.