I have an Azure web app up and running, using a custom domain purchased outside of Azure... and that all runs fine. So I have https://myappname.azurewebsites.net/ loading fine with my domain name URL https://www.myappname.com
I'm trying to upgrade the web app, though using Azure Traffic Manager. I've cloned the app a few times, each on its own app service plan, and I have the traffic manager all up and running fine. I can successfully hit different versions of my cloned website based on the traffic manager configuration profile... so no issues there.
The only issue is that I can only access the "traffic managed" version of my website via the standard azure URL -> myappname.trafficmanager.net.
All examples I've seen say all I really need to do now, is go into my DNS Management screen, and add domain forwarding, however, my online DNS management tool does not offer this option.
I can't really change my A record in the DNS management screen, because I don't know the IP address of myappname.trafficmanager.net
Every place I've tried to change the name of the current/working Azure URL (like in awverify text files, www cnames, etc.) does nothing. The DNS still points to the single instance which remains in the IP address od the DNS managers A record.
Also, since my live/single instance is linked to the domain name (along with the SSL binding), I can't add those properties to the clones, which makes sense....only one version can be live. However I could unbind that when I make the switch from the single instance web app to the traffic managed set of clones, but I fear I can only bind that to one of the clones. I can't seem to bind it to the myappname.trafficmanager.net version, which might cascade down to all of its endpoints. Is there a way to bind my domain name and SSL cert to more than one version of my web app?
Thanks!
Is there a way to bind my domain name and SSL cert to more than one
version of my web app?
I don't think you can do that unless you have two different domains or subdomains with each own SSL cert. Each web app hostname is unique globally and each SSL binding is attached with the web app domain name.
If you have a purchased domain and just keep the default xxx.azurewebsites.net as each hostname. Then you could configure the two Azure app serves as the endpoint of TM.
By default, Azure provided a wildcard cert for this domain *azurewebsites.net, so you can automatically access this hostname with HTTPS without any extra cert. Then use a CNAME record www in the domain domain.com in your DNS provider to point to the traffic manager hostname myappname.trafficmanager.net. Since Traffic Manager works as DNS level, it does not validate the server and client SSL, you could safely ignore the SSL warning when accessing with traffic manager hostname.
Feel free to let me know if you have any question.
Related
Please help on the below use-case.
We have an AWS EC2 instance with public IP or load balancer DNS --> public.ip or application.lb.amazonaws.com (where we have a custom web apps running as target)
We have another VM instance (e.g.: private.ip) within our Data Center (DC) (where the same web apps is running as source).
We need to have a web based communication between these 2 instances but currently its happening through HTTP. We have already handled all connectivity issues and we are able to now communicate between 2 instances.
We're accessing the source & target URL's as http://public.ip:31415 or application.lb.amazonaws.com:31416
Now we need to convert HTTP URL's in (4) to HTTPS along with a custom domain name. This domain name will not be PUBLIC & it will be resolved only within our office network. E.g Domain name: test.source.apps & test.target.apps
We would be making an entry in our local machine /etc/hosts (similar to below) to have this name resolution in (5) works for now in test & for other environments we planned to make an entry in our internal office DNS servers for this name resolution.
Example /etc/hosts:
Target:
test.target.app public.ip.ec2.server
(or) test.target.app application.lb.amazonaws.com
Source:
test.source.app data.center.ip
We don’t want any paid mode of SSL (like CA or public domain) due to the fact that this URL will be used only by 2 -3 developers and within the office network only. But as part of the security compliance we need to definitely make this a HTTPS URL.
Web apps are running in Jetty web server. We've planned to do it using LetsEncrypt + Custom domain.
Can anyone suggest if this possible in AWS & any steps on how to make this change (i.e. creating subdomain that is internal to our host/network &
using LetsEncrypt SSL)?
I'm running my parse app on a naked domain. Parse is not making my life easy though.
At first I struggled to set it up because most DNS hosting services don't allow CNAMEs on the the root domain and Parse requires a CNAME.
Decided to try it out with CloudFlare's CNAME flattening and it ended up working by setting up the CNAME under [hostname key].example.com.
Parse wouldn't allow me to set it up without the hostname key because example.com was not a real CNAME (it's being translated to an A record under the wood by CloudFlare).
But I want to run my website under HTTPS so I registered a certificate that is valid for both "https:// example.com" and "https:// www.example.com".
Again Parse doesn't make it easy. First it didn't accept my certificate because the hostname wouldn't match. I thought that maybe it was trying to compare it with the subdomain of the cert (www.example.com) and that wouldn't match with my app domain (example.com).
I created another CNAME at [hostname key].www.example.com poiting to my parseapp.com url (didn't want to change www.domain.com because it's already poiting to another service that redirects to domain.com), changed my app hostname to www.example.com and it finally accepted my certificate! Yeahhh!
Changed the app hostname back to example.com and tried to access it in the browser, but it takes forever to load and ends failing.
If I change my app to run on "https:// www.example.com" (secure site with with the www subdomain) then it works fine.
So I'm able to run my app in http://example.com (not secure, without www) or "https:// www.example.com" (secure with www).
Why is it that Parse makes it so difficult to run an app on the root domain?
Is there something that I need to do to be able to run a secure app in the root domain?
Most of web services nowadays are designed around the idea of CNAMEs: they provide you a CNAME and you should alias your hostname to that name.
However, as you noted, the CNAME has certain limitations imposed by the DNS protocol RFC and it can't be used to map an apex domain.
Some DNS companies, such as DNSimple or DNS Made Easy, provides a CNAME-like record type that can be used to map the root domain to an hostname provided by a cloud service. Using these services will also make it easier to configure an SSL certificate.
Speaking of SSL certificates, beware that when you purchase a single-name certificate for example.com or www.example.com, it is only valid for that specific hostname. Most certificate authorities will also include the corresponding apex domain if you purchase www.example.com, but you need to check with your SSL certificate provider.
Last but not least, the ability to redirect HTTP to HTTPS traffic really depends on your service provider, in this case parse.com. Unfortunately, it's not uncommon for these services to not force HTTPS. Heroku is currently doing the same, they don't force HTTP to HTTPS when you enable HTTPS.
You should check with them if there is a way to apply such redirect, as the only way is to apply it either at server level or app level. You can't apply the redirect, for example, at DNS level.
I am developing an app (RoR + Heroku) which allows users create their own websites either using my subdomain (pagename.myapp.com) or using their own domain (pagename.com).
An important point of this is that this option is the key of my business: subdomains are the free plans and custom domains are the paid ones. So I have a table where I store the custom domains of each user and check if this page is active (exists and has paid the quota).
For that I need to give users the capability of point their domain to my servers. All we know that Heroku don't recommend the use of DNS A-Records.
Also I would like to abstract as much as possible this feature to being able to switch my infrastructure (Heroku to AWS) in the future without having to ask all my users to change their DNS Zone. Taking this into account, I think that the best option would be run something like an EC2 proxy (using AWS Elastic IP) which give me the ownership of this IP. This proxy I think that should redirect to proxy.myapp.com, and I would resolve the request in the app level.
Due to I didn't find clear information about that, I am not sure if this hypotesis is the best solution and how to setup the proxy (which type of proxy use? Nginx maybe?).
Said that, I would like to ask recommendations/best practices to solve this "common" feature.
Thanks
What you are wanting to do is fairly straight forward to implement. Your assumptions are correct about setting up the proxy. Nginx or haproxy will both work great for this (I personally would use haproxy). Here are some of the gotchas that you will run into though:
Changing the host header at a proxy server can cause the end web application to generate incorrect links. You can use relative paths to fix this, but it requires that the web application developer to be aware of the environment that they are running in.
user connects to www.example.com (proxy server)
proxy server connects to www.realdomain.com (web app)
the web app has a link for a shopping cart. www.realdomain.com/shoppingcart
the end user clicks on the link but the link is www.realdomain.com/shoppingcart instead of www.example.com/shoppingcart
The cost of the host acting as the proxy server. This can spiral out of control really quickly. For example, do you want redundancy, if so how are you planning on implementing that? Do you plan on having ssl termination? If so you will have to increase the CPU count to accommodate the additional load. Do you want to have a secure connection to heroku from your proxy? If you do then you will need to increase the CPU count for that as well. You may have to add additional ram as well depending on the number of concurrent connections.
Heroku also changes their load balancers regularly. This is important because your proxy service will need to reload the config / update the ip addresses of the heroku instances every 60 seconds. In my experience they may change once or twice a day, but the DNS entry that they use has a 60 second TTL. That means that you should make sure that you are capable of updating your config up to every 60 seconds.
My company has been doing something very similar to this for almost a year now. We use haproxy and simply have it reload the config regularly. We have never had an outage or an interruption to our end users. Nginx is also a very good product. It has built in DNS caching so if you go that route you will need to make sure that you configure it correctly so that the DNS cache TTL is 60 seconds.
Will many of your clients want to use your app on their domain apex? E.g. example.com rather than theapp.example.cpm? If not, I would recommend having them CNAME to proxy.myapp.com which CNAMEs to myapp.herokuapp.com. Then, you can update proxy.myapp.com without customer interruption.
If you do need apex or A record support, you would want to set up Nginx as a reverse proxy for your Heroku app. Keep in mind that if you need HTTPS support for client domains, you will need to do some sort of certificate management on your proxy.
I like the answer dtorgo gave and that he mentioned the TLS termination, which many online tutorials on custom domains don't touch at all.
I'll go into more detail on how to implement the custom domains feature for your SaaS while also handling the TLS/HTTPS.
If your customers just CNAME to your domain or create the A record to your IP and you don't handle TLS termination for these custom domains, your app will not support HTTPS, and without it, your app won't work in modern browsers on these custom domains.
You need to set up a TLS termination reverse proxy in front of your webserver. This proxy can be run on a separate machine but you can run it on the same machine as the webserver.
CNAME vs A record
If your customers want to have your app on their subdomain, e.g. app.customer.com they can create a CNAME app.customer.com pointing to your proxy.
If they want to have your app on their root domain, e.g. customer.com then they'll have to create an A record on customer.com pointing to your proxy's IP. Make sure this IP doesn't change, ever!
How to handle TLS termination?
To make TLS termination work, you'll have to issue TLS certificates for these custom domains. You can use Let's Encrypt for that. Your proxy will see the Host header of the incoming request, e.g. app.customer1.com or customer2.com etc., and then it will decide which TLS certificate to use by checking the SNI.
The proxy can be set up to automatically issue and renew certificates for these custom domains. On the first request from a new custom domain, the proxy will see it doesn't have the appropriate certificate. It will ask Let's Encrypt for a new certificate. Let's Encrypt will first issue a challenge to see if you manage the domain, and since the customer already created a CNAME or A record pointing to your proxy, that tells Let's Encrypt you indeed manage the domain, and it will let you issue a certificate for it.
To issue and renew certificates automatically, I'd recommend using Caddyserver, greenlock.js, OpenResty (Nginx).
tl;dr on what happens here;
Caddyserver listens on 443 and 80, it receives requests, issues, and renews certificates automatically, proxies traffic to your backend.
How to handle it on my backend
Your proxy is terminating TLS and proxying requests to your backend. However, your backend doesn't know who is the original customer behind the request. This is why you need to tell your proxy to include additional headers in proxied requests to identify the customer. Just add X-Serve-For: app.customer.com or X-Serve-For: customer2.com or whatever the Host header is of the original request.
Now when you receive the proxied request on the backend, you can read this custom header and you know who is the customer behind the request. You can implement your logic based on that, show data belonging to this customer, etc.
More
Put a load balancer in front of your fleet of proxies for higher availability. You'll also have to use distributed storage for certificates and Let's Encrypt challenges. Use AWS ECS or EBS for automated recovery if something fails, otherwise, you may be waking up in the middle of the night restarting machines, or your proxy manually.
If you need more detail you can DM me on Twitter #dragocrnjac
our hosting account is set up with the domain www.nashman.ca, and our application is at www.nashman.ca/hub. We have another domain that forwards to www.nashman.ca/hub and that's hub.mhn.co. The problem i'm having with this is that the forwarded domain adds on the /hub whenever you navigate to another page from hub.mhn.co, so the domain shows as hub.mhn.co/hub/admin when you're in the admin area, for example. I need the domain to stay consistent, and never show that folder name, because its breaking some of the javascript I use. What is the best way to set this up?
edit
I've been doing some reading about URL Rewriting, and looking into it - my hosting provider supports the IIS7 URL Rewrite module. All the tutorials I've found so far detail how to set up rules using the IIS config tools, but I don't have access to them. Is there a way to do it by editing my web.config in my apps root directory? And will this solve my issue?
Is the default page for hub.mhn.co using a redirect to www.nashman.ca? If so, what is happening is that the forwarding software basically returns a new URI that the browser requests, and the new URI will replace the old one in the browser window and thus in all future requests. You're probably redirecting to ~/hub/ (the hub subdirectory of the site root) which will result in the browser requesting a new URI that keeps the domain name but tacks on the subdirectory.
If you have direct control over the DNS and your webservers, you can use the DNS configuration to direct a request for the hub.mhn.co domain directly to the /hub subdirectory of your webserver. That way, the browser never knows that hub.mhn.co is actually www.nashman.ca/hub/. You might have to direct to an alternate port on the webserver and map that port to the subdirectory, depending on your DNS software (IIRC, most can deal with ipaddress/subdir routes, but some can only handle routing to ipaddress:port).
If your IT department does not have direct control/ownership over your DNS routing, or your exact hosting environment, you are more or less at the mercy of your hosting provider. They may be able to set up their environment to do the same thing, or not; all you can do is ask.
EDIT: Basically you have two options left if you're hosting remotely and can't use their DNS to reroute silently.
First option: clone (copy all files from) the web layer of nashman.ca/hub as hub.mhn.co under a different root space in your hosting environment (try to keep any hooks to service-layer code over at nashman so you don't have to copy the whole vertical slice). If you must also keep the UI under the /hub/ subdirectory, you're repeating code, but you may be able to mitigate this with deploy scripts that will allow you to deploy one local copy of your codebase to various locations. This may also cost more as your hosting environment is now hosting two non-trivial sites.
Second option: host the site and/or resolve the calls on your own hardware. As long as you have a public, static IP address through your ISP, you can provide a DNS server that will be the "authoritative" server for nashman.ca and hub.mhn.co domains. Your ISP or a third party domain name registry can provide a "pass-down" route to get requests from the TLD servers down to you. Then, you can route requests to whatever IP address, port and/or subfolder you like; that can be a remote webhosting provider (as long as they don't mind JUST hosting your site) or your own webservers. This will require the hardware, and a static IP from your ISP. If you lose power to this server, your site will be unreachable until power's restored. If the IP address of your DNS server changes, your site will be unaccessible by DNS until the server that routes requests to you updates its routing table with the new IP (which can be up to 24 hours).
I have a Default Web Site and another web application (let's call it Application2) inside the Default Web Site in IIS7.
I have 2 registered domain names, let's say www.example.com and www.example.net.
I would like to configure things that when I open www.example.com I get Default Web Site, when I open www.example.net I get Default Web Site/Application2.
www.example.com -> Default Web Site
www.example.net -> Default Web Site/Application2
How can I do that?
First you need to decide if your going to use Name Based or IP Based hosting.
IP-Based uses unique ip's to determine which virtual host it will serve and Name Based will actually use the host header which is sent by your client browser.
So let's see two scenarios:
Scenario # 1 (ONE IP TO SHARE)
You have a server with only one IP, could be either private or public as long as the domains you are serving are properly configured in the dns serving you internally or your client externally (NAT).
I suggest that for the sake of this tutorial you stop the default website. Ok.
You will set up one site in II7 and name it accordingly. Go to the right hand side of the manager and look for "Bindings" under actions menu; making sure you have the new site selected on your left pane. Now under "Site Bindings" select the ip address you will be sharing between the sites (name based hosting). Under "Hostname" enter domain # 1 "www.example.com", hit ok.
Follow the same procedure above with the other domain or domains, making sure they have diferent hostnames and same ip's.
That's it. You will now be able to start those sites and run them at the same time.
The same principle above applies if your using the "Default Site". "Default Site" is just a name MS gave the default created one.
Scenario # 2 (MULTIPLE IP TO SHARE)
If you have either some private or public ip to spare, or at least until you do the exercise the only diference here is that sites you will set up and don't have to specify the "Hostname" per each site, as this is basically done in the DNS zones itself. The sites will respond for any request made to those ip's on port 80 regardless.
When will you need to use multiple Ip's to serve websites. Well it all depends.
Some reasons are: Network Isolation (Security), Applications which don't work well under name based hosting, SSL Certificates Bindings 443(PRE II7), and mostly complete control over site. There are of course more reasons, but I'll let others write a bit also.
Have fun.
Edit... upon further investigation I found that if you can set up multiple sites and run them simultaneously. Just need to stop and start the sites after setting the host values to get them to both run at the same time.
Original post:
The straight-forward way to do this would be to add another application by opening IIS and right-clicking Sites then select Add Web Site. In there you can specify the physical path of Application2 and also set the "host" to "www.example.net" which will filter all those requests to your second site. Any requests that don't match "www.example.net" will still go to the default web site.
That approach will work fine on Windows Server using IIS, but on Vista's IIS7 it won't work since you can only have one site running at a time. To start the second site, you'd first have to stop Default Web Site.