Securing Padrino apps with https and ssl on Heroku

5 minute read

Let’s Encrypt has done an amazing job of making https the new normal for web sites and helping create a more secure and private internet by giving away free, automatic ssl certificates to domain owners.

You should be encrypting your web traffic (and need to, to take advantage of new protocols like http/2. Some implementations have stated they will only support http/2 over an encrypted connection. And currently, no browser supports http/2 unencrypted afaik.). Add to this the fact Google will start penalizing non-secured sites in search results, and https is fast becoming the de facto standard.

What does this mean if you’re running a Padrino application?

Heroku has integrated Let’s Encrypt and provides a great, fire-and-forget Automatic Certificate Management system for any paid (even Hobby) dyno on their system.

It turns what used to be a difficult, complex process of certificate management, configuration, and Rack middleware chains (which were quite old), and that could not use padrino’s native Sinatra-based sessions management, into dead-easy ssl and https provision. Since I hadn’t seen a post detailing this, and most posts dealing with getting padrino and ssl going together were quite old, I wanted to write something google-able to save other people the effort of puzzling this out.

You can do everything I’ve described below from Heroku’s well-designed web interface. However, I tend to favour and drive most things off the excellent Heroku CLI. If you haven’t got it installed, and are on OSX, use homebrew and simply brew install heroku. With the heroku cli you can do everything from the command line (as well as script), which is handy if you’re big on the terminal. If you’re on linux or windows, alternative installation instructions are here. Both homebrew and the heroku cli are going to make your dev life easier if you’re not already using them.

Setting up Padrino

At time of writing, I was using Padrino v.

In general, in your app(s), you just need to set

# app.rb
enable :sessions

You probably already have this set if you’ve used the padrino g admin generator for creating an admin panel, or are using any sort of functionality which requires logging in or somehow managing session state. This turns on Padrino’s native sessions management, which uses Sinatra’s sessions and is handy since you can use the session hash between routes and views. It stores all the data in the cookie. Also, make sure to check that your app has a random session secret set in config/apps.rb, which should be a random 64 character hexadecimal string already created by Padrino for you in the Padrino.configure_apps block (nb: you can also enable: sessions there for all apps in the Padrino application if you prefer rather than setting it in app.rb).

There are other ways to get sessions in Padrino, including using Rack::Session::Cookie and Rack::Session::Pool. The former is useful if you need to add extra parameters to the cookies (for example, expiry) and the latter is faster than pure cookie-based sessions as it only stores an ID in cookie but maintains the rest of the session hash in an instance variable called @pool that’s available to you (but the session data does not persist across app restarts). My use case meant Padrino’s native sessions simplified a lot. YMMV.

Setting up DNS

To have https working, you need to have a qualified domain name for your application. This is fairly simple on Heroku, and just a matter of making sure you have a CNAME record in your DNS provider records (I personally use the excellent DNSimple) pointing at your app on heroku and making sure you’ve let your Heroku app know it’s the endpoint for that CNAME by having set the qualified domain in the app’s Settings | Domains and certificates section in the web interface and explicitly hitting the Add domain button and adding it in.

You can also perform this from the cli with

🚀  ~ heroku domains:add --app your_app_name

One gotcha on this: You need to make sure you have your DNS pointing at the correct domain in your application (an issue may be older apps that may be pointing at or similar) If this is you, it might make sense to create and redeploy the app on the newer heroku stack to support this rather than workarounds, and repoint your DNS. If you do not have your DNS configured and ready when you upgrade the dyno and trigger ACM, certificate verification will fail.

You can verify that you’re actually pointed at by running

🚀  ~ heroku domains --app your_app_name

If it comes up looking something like this with the,

=== your_app_name Custom Domains
Domain Name                DNS Target
─────────────────────────  ─────────────────────────────────────── 

you’re good to go.

Setting up the SSL Certificate and https

This is usually the most painful part of getting ssl going on any system. I have to say Heroku has done an amazing job of making this utterly painless through their Automatic Certificate Management. Big fan.

Just upgrade your dyno from Free to Hobby (or more). At time of writing, a Hobby dyno costs $7 USD/month/dyno.

🚀  ~ heroku ps:resize hobby --app your_app_name

When you upgrade your Heroku dyno(s) from the Free tier to Hobby, the ACM will automatically start generating you a cert. It does take about 45-60 minutes, but you can obsessively check on its progress with:

🚀  ~ heroku certs:auto --app your_app_name

As near as I can tell it’s fairly automatic and foolproof as long as you have your DNS configured and pointing correctly. Heroku did a great job with this.

When the response to the above command comes through with the Domain and an OK in the status,

=== Automatic Certificate Management is enabled on your_app_name

Certificate details:
Common Name(s):
Expires At:     2017-07-19 15:03 UTC
Issuer:         /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Starts At:      2017-04-20 15:03 UTC
Subject:        /
SSL certificate is verified by a root authority.

Domain                     Status
─────────────────────────  ──────           OK

you’re ready to move on to restricting the app to just https traffic.

Setting up the app for https only

Now, what if you want to ensure that all traffic that gets sent to your app, even if someone is using http goes through https to the app?

You could use some of the aforementioned middlewares: the Rack::SSL and the Rack SSL Enforcer gems seem popular. However, they break cookies if you don’t disable native padrino/sinatra sessions, meaning you can’t use padrino’s native enabled: sessions . Since I didn’t want to mess with the existing sessions functionality I already had built, tested, and working (and, as some of those middlewares had not been updated in years), I went a simpler route.

An easier solution is to simply use a before filter on the app(s):

# app.rb
  unless RACK_ENV == 'development'
    before do
      redirect request.url.sub('http', 'https') unless

This seemed simple, explicit, code-transparent, and meant I didn’t have to worry about the extra complexities of a Rack middleware chain breaking padrino’s Sinatra-based session management. All this does is test to see if the request is secure, and if it isn’t, redirects it to the https URL before processing. It ignores the directive in your development environment (I should note here I have ssl set up in both my production and staging environments. If you only need https in production, change the first line to if RACK_ENV == 'production'.).

Wrap up

Really, the overall process is quite logical. It’s a matter of making sure your DNS is set up properly so the cert request can be verified, paying for a dyno, triggering the ACM request, it generating a cert for you, and then providing a redirect to https for all http requests.

In any case, that’s all there is to it. Once your cert verifies, you should be able to push your app to heroku via git push heroku master and see it working in secure https glory at the domain you’ve configured.

Happy https-ing.

dev ruby padrino devops security