DEV Community: Madhusudhanan

🧩 How We Solved “Unable to Get Certificate CRL” in Rails: A Debugging Story

Madhusudhanan — Fri, 14 Nov 2025 07:30:00 +0000

If you’ve been around Rails long enough, you’ve probably battled your fair share of SSL demons. But this one? This one had personality.

It was a Seahorse::Client::NetworkingError that failed only on macOS — yet worked perfectly inside Docker. The kind of “it works on my container” bug that makes you question every life choice leading up to this point.

So here’s the story of how we chased down a ghostly SSL error, only to discover that the real culprit was… OpenSSL itself.

⚠️ The Error

Seahorse::Client::NetworkingError
SSL_connect returned=1 errno=0 peeraddr=[...]
state=error: certificate verify failed (unable to get certificate CRL)

This popped up whenever our Rails app tried connecting to AWS S3 using the aws-sdk-ruby gem.

🔍 The Contradiction That Made No Sense

From the get-go, the bug refused to play by any rules of logic.

❌ It failed locally but
✅ Worked flawlessly in Docker

That told us one thing: the problem wasn’t our code. It was the environment. macOS and Docker’s Linux setup were behaving differently.

🧪 The “Wait, What?” Moment

We decided to test the SSL connection manually, expecting it to fail the same way:

openssl s_client -connect 52.219.66.109:443 -servername s3.ap-south-1.amazonaws.com < /dev/null

Result?

Verify return code: 0 (ok)

So, macOS’s OpenSSL tool had no problem verifying the certificate. But Rails (and the AWS SDK) still choked on it.

At this point, confusion levels were high. Coffee consumption was higher.

🧠 The Real Test — Inside the Rails Console

To rule out any system-level differences, we went straight into rails c:

require 'aws-sdk-s3'
s3 = Aws::S3::Client.new(region: 'ap-south-1')
s3.list_buckets

Result:

certificate verify failed (unable to get certificate CRL)

Boom. So the system OpenSSL was fine, but Ruby’s built-in OpenSSL (via Net::HTTP) was throwing a tantrum.

🧩 The Root Cause — A Policy Change in OpenSSL

That cryptic message — “unable to get certificate CRL” — turned out to be the key.

A CRL (Certificate Revocation List) is basically a “blacklist” for certificates that have been revoked. The problem? The AWS certificate didn’t actually have a CRL defined.

We checked with:

openssl s_client ... | openssl x509 -noout -text | grep "CRL Distribution Points"

Result:

X509v3 CRL Distribution Points:
# (empty)

Comparing environments made things click:

Environment	OpenSSL Version	Result
macOS (failing)	3.4.0 (new)	❌ Fails
Docker (working)	3.0.11 (stable)	✅ Works

Turns out, OpenSSL 3.4.0 introduced stricter validation rules. It now treats missing CRL entries as fatal errors — whereas the 3.0.x series simply shrugged and moved on.

So no, your Mac isn’t broken — it’s just being too helpful.

🛠 The Fixes — Two Paths to Sanity

After a lot of trial (and some error), we landed on two solid fixes.

🧩 Fix 1: The Local-Only (Insecure but Practical) Workaround

Since this issue only showed up in development, one quick way to move on is to tell AWS SDK to skip SSL verification locally.

Create: config/initializers/aws_ssl_workaround.rb

# WARNING: LOCAL DEVELOPMENT ONLY
# OpenSSL 3.4.0 enforces stricter CRL policies, so skip verification here.
if Rails.env.development?
  Aws.config.update(ssl_verify_peer: false)
end

✅ Pros:

Works instantly
Doesn’t affect production

⚠️ Cons:

Insecure (but fine for local development)

🧠 Fix 2: Match Environments (I tried this one!)

The better long-term solution is to make your local OpenSSL match Docker’s version.

Install an older OpenSSL (3.0.x):
```
brew install openssl@3.0
```

Reinstall Ruby:

rbenv uninstall 3.2.2
RUBY_CONFIGURE_OPTS="--with-openssl-dir=$(brew --prefix openssl@3.0)" rbenv install 3.2.2

Reinstall gems:
```
gem install bundler
bundle install
```

Now your local Ruby is linked against OpenSSL 3.0 — just like Docker and peace is restored.

🧾 Confirmation & References

Turns out, we weren’t the only ones haunted by this ghost:

openssl/openssl#28758 — CRL verification failures in OpenSSL 3.6.0
ruby/openssl#949 — Net::HTTP failing due to stricter CRL rules

💡 Takeaway

SSL errors can feel like black magic, but more often than not, they’re version mismatches in disguise.

So next time something works in Docker but not on your laptop, remember: sometimes it’s not your code, it’s just your OpenSSL being extra.

Thanks for reading! If you found this helpful, share it with a fellow developer who’s currently staring at an SSL error and losing their mind.

💡 Rails Tip: Use bundle exec rails c or bin/rails c to ensure the console runs with your app’s gem versions. rails c alone can load mismatched gems 🚫

Madhusudhanan — Tue, 28 Oct 2025 11:48:22 +0000

The One-Letter Rails Bug That Slipped Past Rubocop, CI, and Code Reviews

Madhusudhanan — Wed, 03 Sep 2025 08:33:55 +0000

We often think production bugs happen because of big oversights or complex logic failures. But sometimes, it’s the smallest things a single typo that sneak past every safeguard and cause trouble in live environments.

Recently, I had one such experience in a Rails project. It wasn’t a major crash, but it did break a piece of business logic under specific conditions. More importantly, it taught me valuable lessons about code reviews, rubocop, and testing discipline lessons I’d like to share here.

The Safeguards We Already Had

Like most teams, we don’t push code directly to production. Instead, we follow a layered safety net:

✅ Pre-commit checks to catch obvious mistakes
✅ RSpec test cases to validate logic
✅ CI pipelines to enforce standards and run checks
✅ Code reviews to ensure human oversight
✅ QA testing before deployment

You’d think with all this in place, no typo could possibly slip through. So how did it happen?

Where Things Went Wrong: Rubocop and a “Helpful” Auto Fix

In this Rails project, we rely on Rubocop for code style enforcement. Normally, we fix issues in one of two ways:

Manually correcting the code
Running rubocop -A for automatic fixes

But this time, I chose a third option: letting my AI powered IDE auto suggest fixes. And that’s where the trouble began.

The IDE suggested changing this:

.order("start_date DESC") # Existing

#to this:

.order(start_date: :des) # Auto suggested

Notice the problem? :des is a typo it should have been :desc.

Rubocop didn’t catch it. Tests didn’t cover that exact line. Reviewers missed it. And before we knew it, the code went live.

The Aftermath

A few hours after deployment, we noticed the issue in a read replica query. By then, the rake task had already run. Thankfully, the impact was limited, and we quickly reverted the change.

After proper testing, we fixed the issue and redeployed safely. But the lesson was loud and clear: automation is powerful, but not infallible.

Key Takeaways for Rails Developers

Here are the practical lessons I walked away with:

Don’t skip QA when unrelated code changes occur. Even if you’re only fixing style or small tweaks, ensure major areas affected by the change get tested.
Review staged changes before committing. Don’t blindly trust auto fixes. Double-check what’s being committed in your name.
Re-review your PR on GitHub or GitLab. Even after staging, a second look often catches mistakes that slip through the first pass.
Stay aware of “helpful” AI and IDE suggestions. They’re great tools—but you own the final responsibility for what’s shipped.

Final Thoughts

This experience reinforced something every Rails developer should remember: typos are small, but their impact isn’t. Between Rubocop, CI pipelines, and human reviews, we have strong safety nets but no safeguard replaces mindful coding and thorough reviews.

So the next time your IDE “helpfully” suggests a change, pause for a second. That quick check might save you from the kind of bug that inspired this post.

👉 What about you? Have you ever had a tiny mistake sneak into production despite all your safeguards? I’d love to hear your stories in the comments.

Python VEnv Setup: A Rails Developer's Survival Guide 🐍

Madhusudhanan — Thu, 05 Jun 2025 09:00:00 +0000

Hey everyone!

Ever been in a situation where you solve a tricky technical problem, celebrate your victory, only to face the exact same problem months later with no memory of your brilliant solution? 😅 That's exactly what happened to me, and it taught me a valuable lesson about documenting those "one-off" solutions.

The Genesis of a Python Problem 💡

In our project, we had a unique requirement: efficiently manage feature flags. Our solution involved moving one of our API endpoints to an AWS Lambda Function. My task? Replicate the existing API response using Python and, of course, use the same environment variables. Sounds straightforward, right?

Initially, it felt like smooth sailing. I got hold of the existing Python code used for authorization, analyzed how to handle requests and responses, and started writing my own. But then came the pain point: setting up a Python virtual environment (venv). As a Rails developer, Python venvs were a foreign concept to me. I was completely lost! 😵‍💫

I scoured the web, consulted AI, and eventually, with some help from my Python-savvy teammates, I managed to set up the venv and get my code working locally. Phew!

The Deployment Gauntlet 🚀

But the challenges didn't stop there. When deploying the code to Lambda, I ran into package issues. No idea why! 🤔 Thankfully, sharing the local packages from my venv (a quick fix suggested by a teammate) resolved the deployment woes. After a bit more testing, it was finally in production and working perfectly! 🎉

Deja Vu... Six Months Later! 🤦‍♂️

Fast forward six months. We needed to migrate another API using the same approach. And guess what? I'd completely forgotten the venv setup steps! It felt like a joke, but it wasn't. While the DevOps and code changes were fresh in my mind, the local Python setup was a blank slate. I had to start from scratch.

However, this time, with the help of AI and some residual knowledge tucked away in my brain, I managed to get it done much faster.

The Power of Documentation ✍️

This recurring struggle highlighted a crucial point: the immense importance of documenting solutions that aren't covered at the project or framework level. These are the "hidden gems" of knowledge that can save you (and your colleagues) countless hours in the future.

For example, a simple note like this could have saved me a lot of hassle:

How to set up a Python virtual environment (venv) for this project:

# 1. Navigate to your project directory
cd your_project_name

# 2. Create the virtual environment
python3 -m venv venv

# 3. Activate the virtual environment
source venv/bin/activate

# 4. Install dependencies (assuming you have a requirements.txt)
pip install -r requirements.txt

# To deactivate:
deactivate

This experience solidified my belief that documenting these small, specific solutions is just as important as documenting the core project. It's a collaborative effort that benefits everyone!

That's it for this one! I hope my experience encourages you to document those tricky solutions. Until next time, keep coding and keep learning! 💻📚

How to Add V2 on Swagger: Adding Version 2 (V2) with Swagger!

Madhusudhanan — Fri, 18 Apr 2025 12:40:49 +0000

Hey everyone!

So, recently I tackled a really interesting challenge: implementing API versioning for one of our projects and making sure the documentation stayed crystal clear. We decided to go with Swagger (now OpenAPI Specification) for the docs, and I wanted to share the steps we took to bring V2 of our API to life alongside its shiny new documentation.

Step 1: Laying the Foundation for V2 Controllers

First things first, we needed a dedicated space for our V2 controllers. It felt nice and organized to create a new directory structure. Here's a peek at how we set it up in our Ruby on Rails app:


# app/controllers/api/v2/users/users_controller.rb
module Api
  module V2
    module Users
      class UsersController < ApplicationController
        # Our awesome V2 controller methods will live here!
      end
    end
  end
end

This keeps things nice and tidy, separating the concerns of different API versions.

Step 2: Telling Swagger About V2

Next up, we needed to tell Swagger about our new V2. This involved tweaking our swagger_helper.rb file. We essentially added a whole new section to define the documentation specifically for V2:


# spec/swagger_helper.rb
RSpec.configure do |config|
  config.swagger_docs = {
    'v1/swagger.json' => {
      # Our existing V1 configuration stayed here
    },
    'v2/swagger.json' => {
      openapi: '3.0.1',
      info: {
        title: 'API V2',
        version: 'v2',
        description: 'User service V2 APIs'
      },
      paths: {},
      servers: [
        {
          url: '{defaultHost}',
          variables: {
            defaultHost: {
              default: 'http://localhost:3000'
            }
          }
        }
      ],
      components: {
        securitySchemes: {
          # Our security setup...
        },
        schemas: {
          # Defining our data structures...
        }
      }
    }
  }
end

Notice how we defined a separate entry for 'v2/swagger.json' with its own info section, clearly marking it as V2.

Step 3: Writing Specs That Know Their Version

To make sure our V2 endpoints were properly documented, we created new request spec files specifically for them. The key here was linking these specs to the V2 Swagger documentation:


# spec/requests/api/v2/users_spec.rb
require 'swagger_helper'

RSpec.describe 'api/v2/users', swagger_doc: 'v2/swagger.json', type: :request do
  path '/api/v2/users/send_otp' do
    patch('send otp') do
      # All the details about this V2 endpoint go here!
    end
  end
end

That swagger_doc: 'v2/swagger.json' line is the magic that tells RSwag to include this documentation in our V2 Swagger file.

Step 4: Giving Users a Choice on the Docs Page

Okay, so we had the V2 documentation all set up behind the scenes. But what good is it if you can't actually see it alongside the original? We needed to give users a way to easily switch between API versions right there on the documentation page. My initial thought was to configure the RSwag UI to list both V1 and V2 endpoints. Here's what I added to our config/initializers/rswag_ui.rb:

Done the below thing in your Rails app


# config/initializers/rswag_ui.rb
Rswag::Ui.configure do |c|
  c.openapi_endpoint "/api-docs/v1/swagger.json", "API V1 Docs"
  c.openapi_endpoint "/api-docs/v2/swagger.json", "API V2 Docs"

  # Add Basic Auth in case your API is private
  # c.basic_auth_enabled = true
  # c.basic_auth_credentials 'username', 'password'
end

In theory, this should have presented a nice little dropdown or list in the UI, allowing seamless navigation between API V1 and V2. But... spoiler alert... it didn't work right away! Cue the head-scratching and mild frustration. I knew I must have missed something obvious, and I made a mental note to revisit this mystery at the end of the post.

This should have given a clear and intuitive way to navigate between the different API versions in the UI.

Step 5: Unleashing the Swagger Rake Task!

With all the configurations in place, it was time to generate the actual Swagger documentation files. This was as simple as running this Rake task:

bundle exec rake rswag:specs:swaggerize

rails rswag

This command did its thing and, lo and behold, we had both swagger/v1/swagger.json and swagger/v2/swagger.json ready to go!

Step 6: The Importance of Testing Across Versions

Of course, no development process is perfect, and we did hit a few snags along the way:

Ensuring V1 Still Plays Nice: We had to double-check that any underlying V1 methods we reused in V2 were still working as expected and didn't have any unintended side effects.
Key Takeaways from the Journey
Here are a few things that really stood out during this process:

Keep Schemas Separate: Maintaining distinct schemas for each API version in swagger_helper.rb is key for clarity and avoids confusion. Be Explicit with swagger_doc: Using the swagger_doc parameter in your request specs is essential for linking the documentation to the correct version.
Embrace Component Reuse (Where Sensible): If there are common data structures or security schemes, reusing them across versions can save time and effort, but be mindful of potential version-specific changes.
Test, Test, Test Across Versions: I can't stress this enough! Thorough testing of both old and new API versions is vital for a smooth transition and to prevent breaking existing functionality.

The thing I missed is very funny. Since we change the initializers file, we need to restart the server. I totally missed that and spent some additional time scratching my head! Later found my own silly mistake and fixed it 😂. Always the simple things, right?

Overall, implementing API versioning and documenting it with Swagger was a worthwhile effort. It provides a much cleaner and more organized way to evolve our API while keeping our developers (and anyone integrating with us) well-informed.

What are your experiences with API versioning and documentation? I'd love to hear your thoughts and any tips you might have! 😊

Sharing Your Local Rails App for Development and Testing with Ngrok

Madhusudhanan — Thu, 10 Oct 2024 08:27:00 +0000

Developing an application often involves testing on your own system or with dedicated tools. But what if you need to share your progress or test features with devices not on your network?

Enter Ngrok, a powerful tool for developers! Ngrok allows you to expose your local web server to the internet securely, creating temporary URLs accessible from any device.

This guide will show you how to set up Ngrok and use it with your Rails app, streamlining your development and testing workflow.

Step 1: Sign Up for Ngrok

Head over to the Ngrok platform and create an account. On the welcome page, you'll see options for different agent types (software used to interact with Ngrok).

Step 2: Install Ngrok (Docker Method)

For this guide, we'll use the Docker agent. However, Ngrok offers various agent types. Choose the one that best suits your environment, and follow the installation instructions provided on the Ngrok dashboard.

Here's the Docker command to run Ngrok and expose your Rails app on port 80:

docker run --net=host -it -e NGROK_AUTHTOKEN=**** ngrok/ngrok:latest http 80

Important Note: Replace "****" with your actual Ngrok auth token, which you can find in your Ngrok account dashboard.

Step 3: Ensure Firewall Permissions

Verify that your firewall allows incoming connections to the port your application is running on (usually port 80). Refer to the screenshot below for an example of firewall settings on macOS.

Step 4: Start Your Rails App & Configure Local Development

Launch your local Rails development server with the port mentioned in the Ngrok command output (usually port 80 in this case).

If you're using a local development environment, add the following line to your config.hosts file in config/environments/development.rb:

Ruby

config.hosts << '.ngrok-free.app'

Sharing Your App

Voila! Now you have a temporary public URL provided by Ngrok. Share this URL with your collaborators or test it on any device with an internet connection.

Advanced Ngrok Features

Ngrok offers a variety of features beyond basic tunnelling. In a future post, we'll delve deeper into exploring the full potential of Ngrok!

Thanks for reading!

Additional Tips:

Ngrok offers a free plan with limitations. Upgrading to a paid plan unlocks additional features and extended tunnel durations.
For enhanced security, consider using Ngrok with authentication methods offered in their paid plans.
This guide should get you started with Ngrok and streamline the development and testing process for your Rails app. Feel free to share your experiences and ask any questions in the comments below!

Is Using an Integer Column as an Array a Good Practice in Rails with PostgreSQL?

Madhusudhanan — Sat, 08 Jul 2023 08:52:28 +0000

Hi everyone! I'm back with another blog post. Today, I want to share with you a recent experience I had while working on a project that involved storing an array of integer values in a database. I initially used an integer column with an array type and an empty array as the default value. Let me show you the code:

add_column :user, :selected, :integer, array: true, default: []

SELECTED = { "0" => "Blue", "1" => "Green", "2" => "Red" }

However, when my senior reviewed my code, he pointed out that integer data type columns should only be used for storing integer values, not other data types. He suggested that the selected column's data type should be a string. Additionally, he asked me to investigate whether using an array in an integer column was a good practice.

To address his concerns, I turned to the official PostgreSQL documentation. According to the documentation,

PostgreSQL allows columns of a table to be defined as variable-length multidimensional arrays. Arrays of any built-in or user-defined base type, enum type, composite type, range type, or domain can be created.

Armed with this information, I explained my findings to my senior. In response, he shared another reference link that outlined the permitted params when using the array type in a database column. Here's what he shared:

params.require(:user).permit(:selected, selected: [])

He warned me that if we submit an array as nil or containing nil values, it would raise an error. The error message stated:

Value for params[:selected] was set to nil, because it was one of [], [null] or [null, null, ...]. Go to http://guides.rubyonrails.org/security.html#unsafe-query-generation for more information.

To understand this error better, I consulted the Rails guides on security.

The guide explained that

Due to the way Active Record interprets parameters in combination with the way that Rack parses query parameters it was possible to issue unexpected database queries with IS NULL where clauses. As a response to that security issue (CVE-2012-2660, CVE-2012-2694 and CVE-2013-0155) deep_munge method was introduced as a solution to keep Rails secure by default.

The deep_munge method replaces some values with nil to prevent unsafe query generation. Here's how the parameters are transformed based on the JSON sent in the request:

JSON	Parameters
{ "person": null }	{ :person => nil }
{ "person": [] }	{ :person => [] }
{ "person": [null] }	{ :person => [] }
{ "person": [null, null, ...] }	{ :person => [] }
{ "person": ["foo", null] }	{ :person => ["foo"] }

It is possible to return to old behavior and disable deep_munge configuring your application if you are aware of the risk and know how to handle it:

config.action_dispatch.perform_deep_munge = false

After considering all of this information, my senior agreed that using an array in an integer column was a suitable approach. So, we celebrated our decision to use arrays in integer columns! 🥳

This was a positive experience for me. If something happens that makes me interested or teaches me something new, I will let you friends know.

How to pass boolean values in Rspec

Madhusudhanan — Sat, 24 Jun 2023 04:54:21 +0000

Hey there, fellow programmer! 🤓 Let's dive into the world of Rails API testing and explore how to handle boolean parameters correctly. It's time to put on our detective hats and solve the mystery of unexpected test failures!

So, picture this: you're working on an API endpoint in your Rails application, and you want to test if it correctly handles a boolean parameter called active. You decide to use RSpec for your testing needs because, well, it's awesome! Here's how you might write the test case:

describe 'API Endpoint' do
  it 'handles boolean parameter correctly' do
    get '/api/endpoint', params: { active: true }
    expect(response.status).to eq(200)
    expect(response.body).to include('Success')
  end
end

Looks good, right? But hold your horses, my friend! There's a sneaky bug lurking in the shadows. When you run this test, you might encounter a failure, even though your API endpoint is implemented correctly. What sorcery is this? 🧙‍♂️

Well, here's the deal: boolean values passed in the params can sometimes be converted into strings. And that's exactly what's happening here. The innocent-looking true is being transformed into the mischievous string "true". No wonder our test is failing!

To get to the bottom of this, let's add a little detective work to our test case. We'll use a puts statement to print the params in the console:

describe 'API Endpoint' do
  it 'handles boolean parameter correctly' do
    get '/api/endpoint', params: { active: true }
    puts params.inspect
    expect(response.status).to eq(200)
    expect(response.body).to include('Success')
  end
end

Now, when we run the test, we can inspect the params and see what's really going on. And voila! We discover that our innocent true has indeed been transformed into the string "true". No wonder our if condition might pass when it shouldn't. This is a classic case of mistaken identity!

But fear not, my friend! We have the power to fix this issue and restore justice to our code. We just need to ensure that the parameters are passed in the correct format. And one way to do that is by setting the format as JSON. 🦸‍♀️

By setting the format as JSON, Rails will handle boolean values correctly and prevent them from being converted into strings. To achieve this, we can modify our test case like so:

describe 'API Endpoint' do
  it 'handles boolean parameter correctly' do
    get '/api/endpoint', params: { active: true }, as: :json
    expect(response.status).to eq(200)
    expect(response.body).to include('Success')
  end
end

See what we did there? We added the as: :json option to our test case. This little gem explicitly tells Rails to treat the params as JSON. And guess what? It works like magic! 🎩✨

Now, when we run our test, the boolean value true will be preserved as an actual boolean, and not transformed into a string. Our if condition will behave as expected, and our test will pass with flying colors!

So there you have it, my fellow programmer. You now know how to handle boolean parameters correctly in Rails API testing with RSpec. Remember to set the format as JSON in your test cases, and those pesky string conversions will be a thing of the past. Happy testing! 🚀🎉

Here is the reference Link: Github