I'm building an ASP.NET MVC website to be hosted as a shared Azure website with custom domain name.
For the backend portion of the site (for specific users only) I need a login form and from that point on all traffic should be SSL encrypted. However I don't have a custom certificate and would like to avoid that extra cost.
I noticed that free websites already serve over HTTPS with a wildcard certificate for *.azurewbesites.net. Is that "free" azurewebsites.net-address also available for shared websites with custom domain(s) so I can simply redirect all "pages" that require authentication via the https://xyz.azurewebsites.net address? I'm aware that would be a cross-domain redirect which is visible to the end-user but that is not an issue since it's only a select group of users...
Yes, using the *.azurewebsites.net domain is your only option to have HTTPS without extra cost. The domain is always available, even if you use a custom domain, because it's used for a few additional services (like your repo, remote console, ...).
Related
We do have multitenant app hosted on azure and we considered using wild card domains as there is restriction of number of subdomains an app service can contain(as of now it is 500) and I was able to add wildcard domains and attach to out App service.
Now Our concern is , it allows any domains which ends with say '.oursize.com', at least the landing page of website.
Suppose, we asked customer A to use as.oursite.com, if they misspell and use ap.oursite.com, still they will be able to access this and try to login and end up having error.
So, Is there any way, we can add restriction for subdomain? at App service level to allow only some domains or at Traffic manager level or load balancer level?
If you have enabled TLS/SSL with your Azure Web App then maybe by using a certificate with Subject Alternate Name you can restrict a customer from entering a wrong domain name. You can go through this documentation for additional details.
I'm developing a multitenant web app hosted in azure. Tenants point their domain to my app and this is how I distinguish between them. So client1.com and client2.com both point to myapp.azurewebsites.net but depending on which url a user came from I serve different pages.
How can I add SSL certificate(s) to that website so nobody gets an invalid domain name error?
Thanks
When you put the website in the correct pricing tier you can add custom domains and ssl certificates yourself.
After you add your domains (client1.com, etc) and after you add your certificats (for client.com,etx) you can set an ssl binding.
That way it should work.
Here are some useful links: https://azure.microsoft.com/en-us/documentation/articles/web-sites-custom-domain-name/ (to add a custom domain to the website)
And here how to add the ssl binding (check step 3) https://azure.microsoft.com/en-us/documentation/articles/web-sites-purchase-ssl-web-site/
If I create an azure website let's assume: myname.azurewebsites.net, I can access this by using http (http://myname.azurewebsites.net) or https (https://myname.azurewebsites.net).
What does this mean? Did I understood it right that basically I don't need an SSL certificate as it has one by default?
I need to build a web service that needs to use SSL. Therefore do I need to buy an ssl certificate and custom domain (not important)? I don't need a custom domain and the default one works fine for me. So can I use my service over SSL provided by Azure: https://myname.azurewebsites.net (is a wildcard certificate)?
If you need to build a web service that needs to use SSL I highly suggest that you use your own domain and your own SSL certificate (buy one) if you are going in production with it. If you just test/play around - than you can safely use the default provided one.
And you are correct about default provided one - you get a (free) SSL for your azure web site as long as it is only bound to the default XXX.azurewebsites.net domain. However the certificate you get there is a wildcard certificate issued to *.azurewebsites.net. I would not use it if I have to go for a production service!
If you are to use SSL features of Azure Web Sites with your own domain and certificate, check out the Pricing and requirement pages. There are important things to note!
I've looked at all related posts in MSDN and stack overflow but still having difficulty finding a solution.
I am looking to map a domain and all sub-domains to my windows azure website. It is a reserved website instance. I am using Amazon Route 53 DNS manager and have mapped a wildcard CNAME to my azure sub domain, and created a redirect on the naked domain to the www. subdomain.
When I navigate to the naked root, the redirect kicks in and I'm brought to www..com, where I receive a 404 error from azure.
I know the wildcard CNAME is working. I've verified using MXToolbox. If I go to "Manage Domains" in the Azure web UI admin system, I can manually add "www..com" or any other subdomain (e.g. "helloworld..com"). Azure verifies it fine and after saving, I can pull up the website fine by navigating to that subdomain and my azure website loads.
Is there any way to add wild card subdomains without having to verify each one manually through the azure ui interface? My application is a SaaS that relies on custom user sub-domains to serve up their branded website and gain access to their account so I need any and all subdomains to map to my application.
Currently, wildcard domains are not supported as far as I know. At least on Windows Azure Web Sites. They are on the roadmap, but currently you'll have to rely on adding every domain manually.
See wildcard comment on "Configuring a custom domain name for a Windows Azure web site".
Another feature not yet available on Azure Web Sites is SSL using a vanity (your own) domain name. If you want full control of your site(s) you can use Azure Cloud Services instead of Web Sites. With Cloud Services you can provision certificates, domain names, and run multiple sites on the same instances using host header routing.
Anything you can do with IIS Management you can do with a cloud service.
You're a little closer to the metal compared to Azure Web Sites (but not as close as with a VM) and you get load balancing, scaling, caching, and other goodness. Visual Studio 2010/2012 has excellent deployment tooling. You will need to study up on Azure deployment projects from VS, bit it's not bad.
I'm using IIS in Windows 2003 Server for a SharePoint intranet. External incoming requests will be using the host header portal.mycompany.com and be forced to use SSL.
I was wondering if there's a way to set up an alternate host header such as http://internalportal/ which only accepts requests from the internal network, but doesn't force the users to use SSL.
Any recommendations for how to set this up?
Daniel, keep in mind that just because something is possbile in IIS, and via any number of off box solutions (like hardware load balancers and SSL) doesn't mean that it is supported by SharePoint, or that it is implemented in the same way.
You can do what you are asking for, however you should do it via SharePoint Central Administration, and "Create or Extend a Web Application" and then "Extend and Existing Application".
In this way you can create a new web site (in IIS) for accessing your existing SharePoint Web Application, one that can be accessed via a different hostheader, port, using SSL, Authentication mechanism, etc.
As a general rule, if you can do something in IIS AND in SharePoint, you should do it only in SharePoint.
Assuming that http://internalportal/ wasn't accessible from outside the company, you could set up two websites in IIS. The first site, configured to use a host header value of 'portal.mycompany.com', would require SSL. The second site, configured to use a host header value of 'internalportal', would not require SSL. The host header value is configured under 'Web Site' -> 'Advanced'.
Having a hardware load balancer makes things much easier. The site on the load balancer is set up to require SSL, and your websites in IIS are setup not to require SSL.
You could just add a second host header and internal IP address to the site for internal non-ssl access
172.16.3.1:443:portal.mycompany.com
172.16.3.2:80:internalportal