I am developing a SaaS web application (https://mywebsite.example) which will be hosted in AWS and will have subdomains for individual customers like https://customer1.mywebsite.example , https://customer2.mywebsite.example.
As a second step I would like to introduce custom domain names and map it with the subdomains of mywebsite.com through cname records
https://customer1.example --> https://customer1.mywebsite.example
Here is what I have analysed till now.
Using Certificates in AWS loadbalancer for the custom domains as a SAN in the certificate. However the AWS Loadbalancer certificate limits are lesser than the number of customers I am expecting to add.
CloudFlare DNS setup for mywebsite.example and its subdomains, with ssl certificates configured in cloudflare. However Cloudflare allows thirdparty (custom domain) cname redirections only in the Enterprise Plan.
Are there any other alternative service or are there is an alternate way of achieving this use case?
it seems that this solution available in AWS EC2 marketplace should solve your problem
You can try, there is some trial available, called Kilo SSL
https://aws.amazon.com/marketplace/pp/prodview-nedlvgpke4hdk?sr=0-1&ref_=beagle&applicationId=AWSMPContessa
Also it is possible to map your customer's domains to your saas. Algorithm is:
you create EC2 instance. Allocate and associate public IP to it
create domain name which points to this instance. You will use this domain name as CNAME when pointing your own subdomains in your DNS provider (but there is limit of 50 certificates per week per one domain, so you can create only 50 domains like customer1.yourdomain.com ... customer50.yourdomain.com per week)
For customers who want to use their own domains (like app.customer1.com), you also provide them your CNAME and ask customer to set DNS record. After they will do it, you will be able to create certificate for their domain using this service.
Also this service allows to point different domains to different URLs. We started to use this in our SAAS application for URL shortening (we have several hundreds of customers who use their own domains. So we automatically able to create certificate for them, and everything is automated via API). Also we use the same machine to support SSL for all our company's domains.
available API methods: https://docs.kilossl.com/
Related
I need some help to develop this solution in my application.
I have a domain https://my-app-api.com with SSL and there is running my application API.
Every customer who using my application can enter their own Custom Domain for example customer-domain.com and points his domain CNAME to my-app-api.com.
Additional info
My API running on Kubernetes cluster and using DigitalOcean services.
Problem
There is a problem with SSL certificates. Custom Domain that points to my-app-api.com runs only under HTTP not HTTPS. Everything must be done automatically over API. If customer enters a new custom domain and points CNAME to my app domain then I need to provide connection over HTTPS.
How can I get it to run on HTTPS?
Is zerossl.com solves that problem for me?
Do I have to use Caddy or smth else?
customer domain --> CNAME --> your api
Is that correct?
your API has SSL.
Is that correct?
customer domain no SSL.
Is that correct?
If all answer is 'yes', the problem is, your customers.
Your customers need an SSL certificate for their domain, your had done all you need to do about SSL (for your API).
Your customers can use a service such as zerossl.com.
Here is my situation:
I own and control coolwebsite.com
Many websites have a CNAME entry pointing to coolwebsite.com
For example, lamewebsite.com CNAME's a.lamewebsite.com to coolwebsite.com
There are about 50 of these other websites that point to mine, none of which I can control easily
How can I get an SSL certificate that will work with these CNAME's?
There are about 50 of these other websites that point to mine, none of which I can control easily
If you have no control over these web sites or their DNS settings than you should not be able to get a certificate for these. If this would be possible than it would be a serious security issue.
This appears to be a shared hosting kind of setup where you host the websites for clients and allow them to point their own domains to your server and use SNI or host header to serve a correct website based on domain used in the request.
More information like is above correct, where you're getting your TLS certs from, do you want to use single cert to cover everything or a cert per domain would be useful, but in general you can get a certificate with multiple Subject Alternative Names for different domain names/sites.
E.g. if you're using Let's Encrypt, with Domain Validation, you don't need control over domain's DNS, only over content served from that domain. And if people point their aliases (CNAMEs) to your web server then you already have it.
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 am having a bit of trouble understanding how many ssl certificates I should get under specific conditions:
I have two pages the user is supposed to use (index and main) and all other scripts users don't access in the front end (e.g. uploadFile.php).
I have socket.io implemented in port x which I want to run over https protocol.
How many ssl certificates should I get under these conditions to assure secure data traffic? (is the data from all other php scripts still secure if index and main have ssl?)
SSL cert is issued for a specific DNS name. So if you run your PHP and Socket.io applications on the same domain, one cert is surely enough to secure both.
If you run your app on two different domains, you need to (a) use two separate regular certificates, or (b) have one SAN certificate (it secures multiple DNS names).
Also there is a wildcard certificate, it secures all direct subdomains of specified domain (*.some-site.com). It can be combined with SAN feature, so it can secure base domain some-site.com and direct subdomains as well.
IF your website is accessed via different website on https , then your website and the website through which its accessed needs to have their separate SSL certificate.
If your website does not have an ssl certificate , the connection will be dropped when your website link is accessed via other website.
We would like to setup an application on Windows Azure at abc.cloudapp.net which would have a CNAME record for www.mydomain.com pointing to it and then allow clients to do the same. Our application would then look at the requested URL and then pull out relevant data based on the requested domain (abc.theirdomain.com or www.theirotherdomain.com).
Our initial tests show that this should work, however the problem lies in that we need the site to be secure. So we'd like clients to be able to setup shared SSL certs with us that we would upload to our Azure subscription that then allowed them to create a CNAME record (abc.theirdomain.com or www.theirotherdomain.com) that points to either www.mydomain.com or abc.cloudapp.net.
Is this possible?
Edit: I'm not sure if this is the same question as Azure web role - Multiple ssl certs pointing to a single endpoint.
We've used a multi-domain certificate in this situation - see http://www.comodo.com/business-security/digital-certificates/multi-domain-ssl.php for details. This will work for up to 100 different top-level domains.
The problem with a multi-domain certificate is that it is more expensive than a "normal" certificate and that every time you add a new domain, you will have to deploy a new package with the updated certificate.
On the other hand, you could have multiple SSL certificates (one for each domain) and then the answer you seek is here Azure web role - Multiple ssl certs pointing to a single endpoint.
No, I don't think your setup would be possible with a single SSL cert. In general, SSL certs are tied to the hostname (e.g. foo.domain.com and foo.domain2.com need different certs). However, you can purchase a wildcard SSL cert that will help if you use the same root domain, but different subdomains (e.g. foo.domain.com and foo2.domain.com can share a wildcard cert).
So, in your case, since you are allowing different root domains, then you need a different SSL cert for each. If instead you choose to allow different sub-domains on same root domain, you can get away with the wildcard cert.