I have created an iOS app, and rails server, that communicate with each other back and forth. I am using login capabilities, so I want SSL.
It appears an SSL endpoint on heroku is $20/mo. Adding that seems simple. heroku addons:create ssl:endpoint.
Now, I need to purchase an SSL certificate.
1) Where's the cheapest place I can get an SSL certificate for my needs? There seems to be varying degrees of options. Do I just require the most basic?
2) What exactly do I receive with my purchase? A private key, and the certificate? I'm not too sure exactly what happens though. Is it like this... When the iOS client hits my server, and hits any https link, my server will return the certificate. The iOS app receives the certificate, and send it to a Certificate Authority(CA). The CA will return the certificate along with the public key to the iOS app. The iOS app will then encrypt the data with the public key, and send it back to the server. The server will then use the private key to decrypt the data.
3) Where exactly do I store the private key on my rails server? In my db? In a .secrets file? In the heroku config?
#1: The SSL certificate you need depends on how many domains you want to secure. If it's jus www.yourdomain.com and yourdomain.com most certs (i.e. a Comodo PositiveSSL) will do the trick.
In addition:
DNSimple, who won't be the absolute cheapest, can do a lot of the work for you (key generation, CSR generation, and generating the certificate)
I (currently) use Namecheap for single-domain PositiveSSL and/or multi-domain PositiveSSL certs. Relatively cheap, two-factor authentication on their login, their UI is "usable" if not great.
#2: Heroku has an article on how to set up the endpoint once you have a cert: https://devcenter.heroku.com/articles/ssl-endpoint - which shows how to add the signed certificate and private key via heroku certs:add yourcert.crt yourkey.key
#3: Your iOS app should use the NSURLSession method to make calls to your Heroku application remotely. This handles the TLS (SSL) handshake and you don't have to worry about the particulars.
As an additional tip, you can also pin the certificate of your Heroku application in your iOS app. Your iOS app effectively matches its' hardcoded signature against the signature in the certificate of your Heroku app so that it knows it's not just talking to some other HTTPS server.
Hopefully that's clear.
Added IRT comment
Note that when you add the SSL addon, you will get an SSL endpoint - e.g. sushi-bento-2141.herokussl.com - which already has SSL through Heroku's wildcard certificate. Your app can listen to requests on the non-SSL endpoint morning-evergreen-9385.herokuapp.com and re-direct them (301 permanent). You don't need to buy your own cert for this.
However, it's typically much nicer to have your own domain name (more recognisable for users!), for which you do have to buy a certificate for (as per my answers above).
Related
TL;DR version: Is there any way to pass a Server certificate to an iOS client that doesn't involve also passing along the Server's private key?
I have written an iOS client app that communicates with my macOS server app (so I have control over both ends). I have implemented certificate pinning using a self-signed certificate to make things more secure. To accomplish this during development, I hardcoded the Server cert into the iOS client app and told the client to only connect to a server that gives you that exact cert during the TLS handshake. Everything is working great.
However in the real world I am selling this system as a set (1 Server, multiple clients to each customer), so I cannot hardcode a Server cert into the iOS client. My plan is to instead deliver the Server cert out of band (via email) to the iOS client like mentioned here: Making Certificates and Keys Available To Your App:
Apps can only access keychain items in their own keychain access groups.
To use digital identities in your own apps, you will need to write code to import them. This typically means reading in a PKCS#12-formatted blob and then importing the contents of the blob into the app's keychain using the function SecPKCS12Import
One way to provision an identity is via email. When you provision a device, send the associated user an email with their client identity attached as a PKCS#12 file.
My problem is that a .p12 file contains the certificate and the private key of the server - this seems very wrong to pass the private key along as well.
Is there any other way to pass the Server certificate to the iOS client that doesn't involve also passing along the Server's private key?
Thanks!!!
I was overthinking things here, the solution is actually pretty simple.
I just needed to email the Server's public certificate out of band to the client device with a custom extension like cert.myCustomExt1234. This is because the .crt extension is already claimed by iOS so you have to register your app to handle custom extensions (see apple docs here). Then in my app I can do all the logic of cert pinning using that out of band delivered Server public cert.
The key was changing the file extension to something not already claimed by iOS.
I have a cert signed by a CA (Geotrust) on my server. I have the same cert installed in my app. I compare the two certs in URLSession:didReceiveChallenge:completionHandler:. But I was notified by my hosting service that I need to 'renew' the cert each year. That creates a new and different cert for me to handle in the app. Since the certs are not self-signed, do I need to embed the cert in the app for comparison with the cert as it comes from the server or does iOS's SSL handling take care of the challenge for me. Maybe I can just use server trust without looking at the cert?
I have the same cert installed in my app.
Why?
I compare the two certs in URLSession:didReceiveChallenge:completionHandler.
Why?
What you should be doing is comparing the subjectDN. That's what the signer is verifying. It's all you need.
Maybe I can just use server trust without looking at the cert?
It sounds like you're trying to do the correct thing and add an authorization step. Relying on 'server trust' just gives you authentication, i.e. the subject DN is who he says he is. Authorization checks whether that DN is authorised to use this part of the application. But you don't need to check the entire certificate for that.
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'm building a Rails-based website builder as an experiment and am wondering if there's an API for purchasing and provisioning an SSL certificate automatically for a new website via an API. I believe I have a way to set up the domain and unique IP (although still working through that), but not seeing a great way to set up the SSL certificate.
I found some sort of SSL API -- anyone used it? http://doc.rpc.gandi.net/cert/usage.html
I have a JRuby on Rails application deployed to Tomcat which is setup for two-way/mutal authentication using SSL. When a request comes in to my Rails application, it then makes a request to an external server. That external server requires the certificate of the person originating the request. I need to grab the certificate from my Rails app and forward it when making a request to the external server (another Rails app).
I can get the X509Certificate (java) object in a controller in the Rails app where the initial goes. I can then get the DER string (X509CertificateImpl#getEncoded, something like that) and I can build a PEM string if necessary...but how I can forward that on when making a request to the external Rails app?
I tried sticking the urlsafe base64 encoded PEM version into a header, but when I pull out that header on the external rails app it only appears to get a chunk of it (60 characters as opposed to the 2095 that were sent).
Any ideas/thoughts on how to do this?
If the external server requires client-side SSL authentication and not just a certificate, then you are out of luck. The reason is that SSL autentication is performed using private keys, not certificates themselves. And private keys are not transferred to the server. So grabbing the certificate will give you nothing.