This might be a stupid question, and for that I'm sorry, I'm not well-versed in DNS configurations (so perhaps I shouldn't be meddling in this, lol), but anyhow..
I have a web app running in Azure that is currently undergoing a bit of a name change. Therefore, I want to redirect users trying to access my domain to another domain, let's say https://example.com to https://subdomain.anotherexample.com. I own both domains and have certificates for both of them, but I cannot for the life of me understand how (or if its even possible) to redirect users in this way?
I have both URLs configured as A records for the underlying IPv4 adress, and have tried to configure a re-direct in my cPanel to redirect the domain example.com to https://subdomain.anotherexample.com, but if I try to access https://example.com it just complains that the certificate is from another provider (not my Azure certificate, but instead my web hosting certificate used for other sites). Both URLs are set up as custom domains for the same app service in Azure with SNI SSL certificate bindings where example.com is bound to a standard certificate for that specific domain, while subdomain.anotherexample.com is bound to a wildcard certificate for *.anotherexample.com.
I assume there must be something that's not allowed in trying to redirect between two different domains where https is involved because trying to access http://example.com works (i.e. it re-directs to https://subdomain.anotherexample.com). Do I have to write some kind of script server-side that re-directs users manually?
I have created few subdomains for my domain like api.example.com, dev.example.com and www.example.com. For every subdomain I created an virtualhost in Nginx.
But now the problem is when I visit a domain which does not exist it should be redirected to www.example.com. But this is not the exist instead I am getting an error page that the sub domain does not have an secure connection. Since I am using Let's Encrypt, I get this message all the time for sub domains which is incorrect. I contacted my DNS provider and they told me your settings are correct you have to correct your web server configuration. They added a CNAME.
Now I do not know how to add this in my nginx configuration.
So... you type the https ://incorrect.example.com in your browser?
If so, I think the problem cannot be solved.
In the article (https://community.letsencrypt.org/t/can-i-use-letsencrypt-in-more-than-one-subdomain/16588/8) they said
Let's Encrypt does not currently offer "wildcard" certificates. So you will need to be able to list all the domains you want a certificate for, you can't (as you can with some of the pricier paid certificates) get just one that works for every possible name in your domain. With Let's Encrypt you'd need to issue new certificates for any new names you needed.
That showed you can't set all the certificate of incorrect subdomains...
But if you just type "http ://incorrect.example.com", It can be success redirect without error page.
If error page continue occurring, please post your conf of nginx.
I see two separate questions -
security warning can be removed using a wildcard certificate from letsencrypt. Please see detailed instructions here
Redirect non-existent domains to www.domainname.com
You need multiple server sections in place -
Have server {} sections for each existent domain to port 443 (HTTPS port)
Have one server {} section for *.domainname.com to redirect to port 443 or www.domainname.com
If you are running an app that dynamically uses subdomains (for each customer) the app should also implement the redirection to www.domainname.com for non-existent subdomains.
I own a domain in godaddy (rainychat.com), and i have a node/socket.io chat app hosted in openshift on a domain provided by them (rainychat-jgal.rhcloud.com)
I'm using "forwarding with masking" configuration on godaddy to make it so when a user enters rainychat.com, godaddy forwards the user to rainychat-jgal.rhcloud.com, but with the user seeing rainychat.com in the browser (You can try that now if you want).
My question is: As this is a chat app, is the user constantly going through godaddy first to reach my app because of the masking? I don't want my app to be slower because of this configuration. Is this the correct way to permanently direct a user to the site while still showing rainychat.com in the browser, or should i mess with DNS registery? Can i use .htaccess maybe?
I have 2 websites in my hosting account at bluehost. The main domain (maindomain.com) has an SSL and there is one registration page where I need to use https//www.maindomain.com.
I also have an add-on domain (addondomain.com) and am hosting the website for that in the same account. There is no necessity for a secure connection.
However, I want to make sure that if https://addonsite.com is used, it redirects to http://addonsite.com. The reason is that now if you go to https://addonsite.com, it shows that in the URL address window, but the maindomain.com website loads.
I have tried adding redirects to both .htaccess files (for maindomain.com and addondomain.com), but cannot seem to get it to work. Is it possible to do this with a main domain and add on domain if there is an SSL on the main domain?
I want to create an example SaaS app, whereby users are able to signup, create web pages, use templates and/or customize them with custom css, serve their web pages off custom domains.
I was considering saving the templates on S3/other CDNs, along with media/stylesheets/js files. While all are technically possible (practical? that could be debatable). Anyways, I was having a hard time figuring out how websites would be served off custom domains in this case? For instance, when they sign up, they could get a subdomain.domain.com address. However, how do they point customerdomain.com so that when customerdomain.com is entered, it serves same content as customerdomain.domain.com, and URL remains customerdomain.com
Additionally, if I want to have a "feature" whereby, custom domains could be a paid feature. How would I restrict it to paid users only?
Normally when, we setup websites, we specify it in virtual host config file (apache), and give it aliases, so it looks for and serves those aliases. In this case, I do not want to have a separate vhost file for each person who signs up. Is there an alternative? How can I program this? Are there any gotchas to be aware of?
One solution that I have seen is to have the server serve a wildcard domain i.e *.domain.com, and a separate vhost for each custom domain, however I would prefer to avoid if I can.
Thanks.
The custom domain is usually done through a CNAME DNS record (sort of a symlink for DNS records). You tell your customer (who is usually in control of customerdomain.com) to create a CNAME record saying that customerdomain.com is an alias for customerdomain.domain.com. Then you need to set up your own server to interpret requests to customerdomain.com the same as it would treat requests to customerdomain.domain.com.
Depending on how you serve your subdomains, this can be done in a few different ways.
If you have a vhost file for every single customer, you need to add a "ServerAlias" directive for the custom domain your client has provided.
If you are coding the entry point through your own application server (say, reading the "Host" HTTP header from PHP and then setting the customer name from that) then you need to adjust that code accordingly to interpret requests for external domains according to your own database of custom domains. You can even use straight DNS for this!
Something on the lines of:
if http "host" header does not end in domain.com:
cname = get_cname_record(http "host" header value)
if cname does not end in domain.com:
return error 404
else:
site = first part of cname
else:
site = first part of http "host" header
Then you can use DNS as your "custom domain database". Make sure you are using a DNS cache though, as those queries will be performed on every single request.
The accepted answer is good but it doesn't show the full picture.
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.
Alternatively, there have been a few services like this recently that allow you to add custom domains to your app without running the infrastructure yourself.
If you need more detail you can DM me on Twitter #dragocrnjac