I want users of my service to be able to add their own custom domains. For example, www.[their domain].com should be able to access their application's index and show pages. My service is implemented in Rails 3.
I've seen apps like Tumblr offer this functionality for their front facing blogs. Although I have seen apps for Rails that implement sub domains in the way that Basecamp does, I have not found a resource for fully custom domains.
They'll need to create an A record in their DNS to point to your app servers IP. You'll need to know what domain they have pointed to your server and log it against their account, and also set your web servers config in such a way as to channel the requests from other domains to your app. You can then use the request object to look up their account in your application_controller.
I just answered a similar question so I decided to chime in here too.
#Codebeef gave a good answer but this won't work anymore in the world where HTTPS is a must in most modern browsers.
This is the full picture of how to handle custom domains for your app.
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
Related
I have configured mutual authentication on an Azure Application Gateway. Currently all client certificates issued by the intermediate CA (as configured on SSL profile) are accepted, but I only want a specific certificate to be granted access, ideally based on the subject of the client certificate. Making changes to the CA that issues the client certificate is not feasible in my case.
Options explored:
Use leaf certificate when configuring SSL profile: app gateway seems to ignore the leaf certificate; all client certificates issued by the intermediate CA are accepted.
Configure a rewrite rule action to pass a server variable (e.g. client_certificate_subject) to backend in a custom request header. This would require changing the backend to interpret the request header, which I’m trying to avoid.
Configure a rewrite rule condition to check server variable (e.g. client_certificate_subject) and conditionally take some action. Ideally the action should set the HTTP response code (without forwarding the request to backend) or rewrite to an error page generated by the app gateway (e.g. HTTP 401 unauthorized / 403 forbidden). Can this be done somehow?
WAF rules don’t seem like a viable option as they don’t have access to server variables
Hoping to find a way of configuring this requirement on the app gateway. Thanks.
I understand that you want to be able to allow specific certificates only based on their subject names etc., to be granted access by the Application Gateway.
You can't use a rewrite rule because in order to "get to" a rule in the first place you have to get through the listener and you can't get through the listener if you can't authenticate with mutual authentication.
At this point, the best way to avoid people from accessing App GW would be to not give the Leaf certificate so they cannot access the same.
Also please note that Application Gateway Mutual Authentication is in preview right now and therefore, it is intended for "Evaluation" and testing, and not production currently. Once it is GA, there will be options to have revocation lists and checks.
Hope this helps. Please do let us know if you have further questions. Thank you!
I'm a relatively new programmer to backend security so very much in the dark about how to set up HTTPS. I'm currently writing an IOS app that is sending http requests to my public EC2 backend domain, however I'm trying to transition this to HTTPS. Right now the backend is running on the developmental Flask server using HTTPS with a self signed certificate. However the problem is that on the IOS app side, it rejects this as invalid so I'm unable to test HTTPS dependant features. I tried to use the domain exception with the infoplist and ip.xip.io but it still complains that someone could be pretending to be this address. Could someone list in a very systematic way how I should approach building this out,i.e are there any free CA's, do I need a cert from a CA, and how to go about properly connecting the app and backend with HTTPS using my ec2 public ip.
Perhaps the iOS app will authenticate properly using a free community certificate. Investigate free certificate authorities, like letsencrypt. There are several. These work like the commercial CAs such as GoDaddy.
Actually the easiest solution was to just use Ngrok
I pushed a Spree Rails app to Heroku and I see it's using ssl withhttps:// and has a yellow padlock in the browser. Clicking on this shows "Identity verified" and the Certificate Information says Issued To: *.herokuapp.com
This is great. With no configuration or expense at the Heroku end, my app is using SSL with a valid looking certificate. Ok it's a yellow rather than green padlock but hey, not bad for free.
I'm sure this is a stupid question..but how can I run another Rails app on Heroku with a verified certificate without paying for the SSL add-on and purchasing my own certificate?
The TLS/SSL connection your browser is establishing is due to the fact the you are connecting to your app via appname.herokuapp.com. This is standard and will automatically work for any app you create out of the box. Heroku provides SSL encryption as you may be sending sensitive information to the server and it is better practice to encrypt data that you may not necessarily deem sensitive, but your client may. All reputable providers (SAS, Web Hosts, Email Providers) will have a wildcard SSL certificate installed to the base domain (*.herokuapp.com) as it is a single certificate that is relatively inexpensive and will secure all the sub-domains automatically.
That being said Apps are SSL-enabled already and can be accessed simply by using https, e.g., https://appname.herokuapp.com, but you would want to go with the SSL endpoint option when you want to establish the trusted relationship with your clients. Both ways are as secure as the other, but with the wildcard SSL (also referred to as a shared SSL certificate) the trust is established between the client via their browser and Heroku not your App/Site. With the SSL signed to your domain.com the clients can connect to your domain and not the Heroku sub-domain and see your site's information in the connection information on the browser. If your site is needing disambiguation from Heroku then is when you will want to proceed with an SSL setup outside the default.
As for what SSL type and issuer to use I would not recommend https://www.startssl.com/ as they do not offer SSLs with high browser ubiquity as they are not fully signed by an external root authority. Comodo and the consumer standard Rapid/GeoTrust are the best choices as far as assurance, recognition, and easy of use and concerned. You only need a DV (domain validated) SSL and they can be had for a few domains a month.
More on this and the Heroku SSL configuration can be found here
I recently spent some time setting this up. It can be done using CloudFront and a proxy to Heroku. This is probably best used for small projects but seems to be working great so far! See my post here:
http://ksylvest.com/posts/2014-05-06/setup-free-ish-ssl-tls-on-heroku-for-ruby-on-rails-or-any-other-framework
A few things have changed since this question was first answered, notably the advent of Let's Encrypt and new Heroku SSL endpoints, which together make it possible to add SSL for free. I've created a gem to generate and add certificates automatically: https://github.com/KMarshland/heroku-ssl. Once you've added heroku_ssl to your gemfile, you can simply run:
rake heroku_ssl:update_certs
Alternatively, if you don't want to use the gem, you can do these tasks manually:
1. Generate the SSL Certificate
Follow the instructions in https://github.com/unixcharles/acme-client to generate your certificates. You'll need to register your email, authorize the domain, and then finally get your certificates. When authorizing the domain, if you only have one server running, you can simply stick the authorization file in your public folder; if not, you'll either have to set up a dedicated controller and route or add a text record to your DNS zone file.
2. Add the certificate to Heroku
After downloading your certificates, you can either use Heroku's web interface or just run
heroku certs:update fullchain.pem privkey.pem
3. Configure your DNS
You need to set a CNAME record in your DNS zone file that points to [yourdomain].herokudns.com. The DNS zone file specifies what urls get mapped to what servers on the domain name you own. If your site is already pointed to your Heroku app, there will already be a CNAME record; you just need to change where it points to. If not, you'll need to add a new line:
[subdomain] [TTL] IN CNAME [yourdomain].herokudns.com.
I have an iOS client app which connects to a server using HTTPS.
I've added code in the client to verify the identify of the server.
How can a tester testing this feature test that it is now secure, how can they for example create a MITM situation and check that the client rejects connects etc.?
I've tried googling for how to do this but haven't had much luck.
Can it be done using tools like Charles and proxies etc. or is messing around with a wireless router and having detailed knowledge necessary?
This might be over simplification for your solution, but concepts might help.
A web browsers extracts the name of hosts from embedded certificate and do a comparison of host name that we're trying to connect with. If validation fails, we usually see a security warning. For ex: we can connect with facebook by either typing https://www.facebook.com or by typing https://173.252.100.16/. When we choose second option, we get a security warning.
Your program must be using SSL client socket to connect with HTTPS server. The socket must be having capability to extract the hostname from the embedded certificate. Once you get that, compare that with valid HOST NAME that your program is trying to connect with. If it matches, let request proceed, If not, abandon that session.
To re-create MITM, your web server can use a self signed certificate that can be issue to whatever host name you want, but the IP of server could be 127.0.0.1 (for example). Since there is a mismatch between the host name and actual IP, we can probably simulate the MITM situation.
I'm assuming that digital certificate can't be forged in this case.
Say I have a Web service, called JokeService, which is a Rack/Rails3 app deployed on Heroku. And lets say I have an application, called ComedyApp. Now, I want JokeService to only entertain requests from ComedyApp. To do so, I would like ComedyApp to use a client certificate, which it uses to authenticate itself with JokeService.
My question is, how the heck can I configure the JokeService (again, a Rack/Rails3 app on Heroku) to check the validity of the client certificate?
This is related, but unanswered: How to access SSL client certificate from rack app
In short, you can't, since we don't have control of the http layer (thin or the routing mesh) in the stack.
An alternative is to authenticate one's requests simply using a custom request header.