iprog.com

TLS certificate verification error on AWS RDS

Recently, when upgrading the Docker base image for a Ruby on Rails app, the app suddenly started raising SSL error: certificate verify failed exceptions when attempting to connect to Postgres. Unfortunately, the error message doesn’t describe why verification failed.

The base image was being upgraded from Debian 9 (Stretch) to Debian 10 (Buster). The Postgres 11 instance (which started life on 9.x, so it’s older) is hosted by AWS RDS and configured to require TLS connections.

It turns out that AWS RDS only supports TLS 1.0. However, Debian 10’s openssl config defaults to requiring TLS 1.2+. The result is the certificate verification error above.

The quick fix is to modify /etc/ssl/openssl.cnf (as this is what changed between Debian 9 and 10) to allow TLS 1.0. Near the bottom of the file, change

1MinProtocol = TLSv1.2

to

1MinProtocol = TLSv1.0

Or, run this simple one liner:

1sed -i -e 's/TLSv1.2/TLSv1.0/' /etc/ssl/openssl.cnf

The better fix is to upgrade/replace the Postgres server to support TLS 1.2+ since TLS 1.0 and 1.1 are being deprecated.

0 comments

Rails 6: How to use multi-environment credentials

Rails 6.0 adds support for multi-environment credentials. Here’s a quick summary of how it works:

By default, behavior is the same as Rails 5.2. To configure credentials for another enviornment, just add --environment <env>.

Available commands

Example: rails credentials:edit --environment production

(Hint: RAILS_ENV=<env> rails credentials:show won’t work. --environment must be used instead.)

How Rails behaves

Rails continues to use the 5.2-compatible files (config/master.key & config/credentials.yml.enc) in the absence of an environment-specific file.

If an environment-specific file is available, then that is used instead (and the default file is ignored – they are not merged). This is convenient when you want multiple environments, eg: development and test, to both use the same file. In this example, use the default file for those two environments, and then provide an environment-specific file for production only.

For reference, Rails will look in the following places for the master key for decryption:

And it will look for the actual encrypted credentials at these locations:

0 comments

Replacing the Rails 5.1 asset pipeline with webpacker 3

My last post was about using webpacker v3 on Rails 5.1.

This time I want to explore how to replace the traditional sprockets-based asset pipeline completely.

Our goal will be to add Bootstrap v4 and jQuery v3 to an app, handled entirely through webpacker. We won’t even install the sprockets related gems.

We’ll also enable rails-ujs, turbolinks, and even images using webpacker.

Read more...

5 comments

Using Webpacker 3 on Rails 5.1

I recently started a new Rails 5.1 project. I wanted to try out webpacker, which is now at version 3. Turns out, the webpacker team has been working hard to simplify things and they’ve accomplished quite a bit. Most posts online talk about v1 or v2, and they include a lot more steps than are now necessary.

My goal here is to show how to use webpacker alongside the traditional asset pipeline (sprockets). The next post will show how to completely replace the asset pipeline with webpacker.

For reference, I’m working with ruby 2.4.2, rails 5.1.4, webpacker 3.0.2, node 8.7.0, and yarn 1.2.1.

Let’s dive into the now-simplified webpacker world.

Read more...

0 comments

Benchmarking GeoIP gems for Ruby

On a recent project, I had need again to use GeoIP (by the lovely people at MaxMind). I decided to take some time to benchmark a handful of various GeoIP gems, both for GeoIP v1 (legacy) and the newer GeoIP v2.

I decided to benchmark the extraction of 3 pieces of data, using the GeoIP Lite City database:

Read more...

0 comments