I have a web app, and when users sign up, we give them their own subdomain, e,g, user1.website.example
We do this with a wildcard ssl for *.website.example
However, users are requesting custom domains.
So we plan on letting them point a CNAME to our system.
So when the user creates a CNAME "register.user1website.example" points to "user1.website.example", we pull that CNAME from the db and server the correct content - all works hunky dory...
BUT How do we allow the users domain to have a SSL?
Our system auto redirects from http to https, so they would get an insecure warning. Obviously, for the moment we have stopped the redirect, but we want everyone to have a SSL.
We're also talking about 10k+ users, so I don't want to have to have the domain added into Plesk and Lets Encrypt, as it changes all the time, and it would be a nightmare for management.
Related
GH-pages tells me the domain is not eligible for HTTPS at this time. I am wondering how do I enable this with a Godaddy purchased domain? My site is connected and running properly, but I cannot get HTTPS to work. I have also checked that there are no mixed-asset types in my index.html
I figured out that in the DNS records that are automatically configured with the GoDaddy domain, you must remove that A Record that has the value of park.
I have recently had an active website that was protected by an SSL certificate. The site is no longer active and the certificate has expired. I have tried to put up a simple HTML holding page but Google will not show it because there is an expired certificate associated with the domain. Is there a solution to allow me to display the page without needing a certificate.
You don't mention what web server or hosting platform you are using. In general yes you can remove an SSL certificate (and stop listening on port 443). But bear in mind if the user has saved a bookmark starting HTTPS, or the links to the site are HTTPS, or if you used the HSTS header to indicate the site should always be viewed over HTTPS then visitors will have trouble viewing the page only accessible over HTTP.
Given you can get a certificate from LetsEncrypt at no cost the most straightforward, and visitor friendly, option would be to renew the certificate.
There are two domain names:
1.one long (example: MaryJaneFamily.com)
2.one short (MaryJane.com).
The 301 redirect works correctly from EXISTING links from various web sites (from when the site had no ssl).
The redirect domain name appears but gives a "insecure site" warning and it appears as https://MaryJane.com.
The primary domain name does not show up in google listings at all.
I have validated the full domain name with google and provided a new sitemap to google.
The sitemap submission is not showing any errors. DNS for primary domain name shows it is fully propagated.
The link that appears in google is not the primary domain but the forwarded domain name with an "s" added to the http - selecting that link brings to you a "insecure site" warning screen.
What am I doing wrong?
It appear that your SSL certificat is maybe not valid or generated and auto-signed by your server. You have to use a SSL certificate certified by high autority trusted domain. A lot of hosting services can sell you a validated and trusted SSL certificate, or some companies like CloudFlare can give you for free (with some other protections and services like CDN, DDoS protect, firewall...etc).
If you want to do it yourself, you can use Let's encrypt to make your own trusted certificate (remember that you will have to renew this all 3 months but you can easily automate it).
Well, you can read this guide to know more about SSL certificates and which you sould use.
I hope it will help.
Is there a "return 301" for forced SSL in your sites config? If you don't force SSL then you will receive both secure and insecure ports.
I have build a saas product with angular 4 integrated with golang rest api and uploaded the build on aws ec2 instance. My project is a multi-tenant based app which loads customers dashboard on merchant-name.mystore.com subdomain but some of the customers asking for custom domain feature like they should be able to load the app on mydomain.com .
I have done the the subdomain part with following code in apache2.conf file so all subdomain loads from apps folder where the angular app files located
<VirtualHost *:80>
ServerAlias *.mystore.com
DocumentRoot /var/www/html/apps
<Directory "/var/www/html/apps">
AllowOverride All
Require all Granted
</Directory>
</VirtualHost>
For custom domain feature I have a section in admin to save custom domain but not sure how should I implement it.
possible method I thought about are
Create virtual host file and update it on each merchant signup with his custom domain
Do it somehow with htaccess file and mod_rewrite
Shopify do it but not sure how they load merchant specific store. Another point kept me busy thinking about is what values should I ask to update
IP address on domain registrar
Name servers ( not sure what it will be for my on aws )
Ask to create CNAME or A record as some of the article suggest
I have a similar setup on a number of SaaS platforms I develop and manage. This type of setup is certainly desirable, as your clients suggest. You should plan to serve each customer site on its own domain, probably also with *SSL, from the begining. In my opinion, this is best practice for a well architected Saas service today.
In reading your question, I think you are over engineering it a little.
For a custom domain Saas app on the same server, you simply open port 80 to all traffic, regardless of domain name. Point all customer domains to app.mystore.com, which is a CNAME to your app endpoint.
The app then reads the HTTP request header, and in that way determines the host name that was requested.
Finally the app looks up the host name in its client database, and locates the client record for the give customer domain.
For example, in Nginx all you need is:
server {
listen 80 default_server;
server_name _;
root /var/www/myservice/htdocs;
}
This server configuration provides a catch all for any domain that points to this endpoint.
That is all the web server should need to allow it to answer to any customer domain. The app must do the rest.
* When you serve a custom domain on an app on this domain, you should plan to serve the SSL endpoint for the domain, eg https://www.mycustomdomain.com. Consider this in your architecture design. Consider also the DNS issues also if your app fails over to a new IP.
The accepted answer is satisfactory but it only skims over the most important part, and that is enabling HTTPS by issuing certificates for third-party domains.
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 Caddy, greenlock.js, OpenResty (Nginx).
tl;dr on what happens here;
Caddy server listens on 443 and 80, receives requests, issues, and renews certificates automatically, and proxies traffic to your backend.
How to handle it on the 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
I have a webapp hosted on firebase hosting at example.com. Firebase provisions a SSL for the root domain. I now connected a ghost blog hosted on heroku at subdomain blog.example.com. I do process credit card payments through my webapp (root domain). Now I am unclear if i should purchase a SSL certificate from third party and provision it with my subdomain(blog.example.com). Is it required for my blog? can it affect my root domain security? WOuld a free SSL from something like Let's encrypt me enough for the blog subdomain .
The short answer is that: No, your blog being unsecured won't affect your webapp's HTTPS security on the root domain (actually called the "apex domain", although usually www.example.com is also made to work the same as the apex domain in web browsers).
When someone visits your secure webapp via the domain example.com, the webapp will present to the client a certificate that is only valid for example.com (and maybe some/all subdomains) that was signed by a certificate authority that most clients keep in their root trust store. This verifies to a decent degree of certainty that the page they are loading is actually from the person/organization that owns the example.com domain. The client/server then do a key exchange and then start enciphering the acutal payload of the HTTP session. This ensures data between the client/server hasn't been modified, and the connection cannot be eavesdropped upon.
You can run other services at blog.example.com or somethingelse.example.com and that wouldn't affect security for users going to example.com.
The plausible reason that you might want to use HTTPS on your blog is if your blog contains links to point users towards your secure site, and you want to make sure users always get directed from those links appropriately. Since your blog is unsecured, anyone with a privileged network position can modify how your blog looks to someone that loads it. State or ISP actors could modify how your blog looks almost anywhere, but even a simpler example of a malicious user at a coffee shop can affect how other browsers at the coffee shop load unsecured sites virtually undetectably. Imagine if your blog contains a link "click here to go to my main site and give me money" but the link was modified to go to a phishing site to allow the attacker to steal users' passwords and/or money.
Only you can decide if this means your blog should have security. While setting up HTTPS can be more work, encrypting everything by default certainly can only help, and many people have undertaken this mantra in the past few years. Certainly Let's Encrypt would be good enough for this.