Broken Authentication in Rails with Mutual Tls

Mutual Transport Layer Security (mTLS) requires both the client and the server to present valid certificates during the TLS handshake. In Rails, developers often assume mTLS alone is sufficient to secure authentication, but it does not replace application-level identity verification. When mTLS is used without a complementary authentication mechanism (for example, session tokens, API keys, or a mapped identity), the request may be authorized based solely on the certificate while the application treats that as proof of a specific user or role.

This mismatch creates a Broken Authentication risk because Rails may treat an authenticated TLS session as an authenticated user session. If a certificate is issued broadly (e.g., to a group of microservices) but Rails does not enforce additional checks, an attacker who obtains a valid client certificate can assume any identity the server associates with that certificate. Common misconfigurations include permissive certificate verification settings, missing mapping from certificate fields (such as subject or serial) to user records, and relying on the TLS layer alone to enforce authorization.

Consider a Rails API that uses mTLS for service-to-service calls and authenticates users via client certificates without checking the certificate’s CN or SAN against a user store. An attacker with a valid certificate can call admin endpoints because Rails skips standard session or token checks. This parallels issues seen in weak Identity Provider configurations and overlaps with BOLA/IDOR when certificate-based identity is not tied to a granular access control model.

Another scenario involves certificate renewal and revocation. If Rails does not validate certificate revocation (via CRL or OCSP) and does not rotate credentials tied to the application layer, a compromised certificate can be used indefinitely. This can also expose sensitive data or enable privilege escalation when authorization logic incorrectly trusts the TLS identity alone.

These patterns show that mTLS is a transport security control, not an authentication or authorization control. In a security scan, such gaps often surface in the Authentication, Authorization, and Data Exposure checks, with findings tied to improper identity mapping and missing session validation.

To fix Broken Authentication when using mTLS in Rails, you must map the TLS identity to an application-level identity and enforce access controls. Below are concrete, syntactically correct examples that demonstrate how to implement mTLS-aware authentication in a Rails controller and initializer.

1. Configure mTLS in the web server

Your web server (e.g., NGINX, Apache, or a cloud load balancer) must request and validate client certificates. This example shows an NGINX snippet that requires client certificates signed by a trusted CA:

ssl_client_certificate /path/to/ca-bundle.crt;
ssl_verify_client on;
ssl_verify_depth 2;

The verified client certificate is then passed to the application in a request header, commonly SSL_CLIENT_CERT or via a custom header like X-SSL-CERT.

2. Extract and verify certificate identity in Rails

Create an initializer to parse the certificate and map it to a user. This example uses the openssl standard library to extract the Common Name (CN) and verify it against your database:

# config/initializers/mtls_auth.rb
require 'openssl'

class MtlsAuth
  CERT_REGEX = /CN=([^,]+)/

  def self.call(app)
    ->(env) {
      cert_pem = env['HTTP_X_SSL_CERT'] || env['SSL_CLIENT_CERT']
      if cert_pem.present?
        cert = OpenSSL::X509::Certificate.new(cert_pem)
      else
        cert = nil
      end
      env['mtls_identity'] = if cert&.subject
        subject = cert.subject.to_s
        match = subject.match(CERT_REGEX)
        match ? match[1] : nil
      end
      @app.call(env)
    }
  end
end

# Use the middleware early in the stack
Rails.application.config.middleware.insert_before 0, MtlsAuth

3. Enforce authentication in a controller

In your controller, use the extracted identity to find or authenticate a user, and ensure that the identity is tied to proper authorization rules:

class Api::V1::ProfilesController < ApplicationController
  before_action :authenticate_user_from_certificate

  def show
    # Current user is set by the certificate mapping
    render json: { user: current_user.id, role: current_user.role }
  end

  private

  def authenticate_user_from_certificate
    identity = request.env['mtls_identity']
    user = User.find_by(mtls_identity: identity)
    if user
      # Set a request-level current_user; avoid creating session state
      @current_user = user
    else
      render json: { error: 'Forbidden' }, status: :forbidden
    end
  end
end

4. Validate revocation and strict verification

For production, add certificate revocation checks and strict verification. This example shows how to enforce CRL validation in the initializer:

# config/initializers/mtls_auth.rb (extended)
require 'openssl'

CERT_STORE = begin
  store = OpenSSL::X509::Store.new
  store.add_file '/path/to/ca-bundle.crt'
  store.set_flags(OpenSSL::X509::V_FLAG_CRL_CHECK | OpenSSL::X509::V_FLAG_CRL_CHECK_ALL)
  store
rescue
  raise 'Failed to initialize certificate store with CRL support'
end

class MtlsAuth
  # ... previous call method ...

  def self.verify_certificate(cert_pem)
    return false unless cert_pem
    cert = OpenSSL::X509::Certificate.new(cert_pem)
    store = CERT_STORE
    store.verify(cert) ? cert : nil
  rescue OpenSSL::X509::CertificateError
    nil
  end
end

With these measures, mTLS becomes a strong transport layer that feeds an identity-aware authentication flow in Rails. The scanner will validate that certificate-based identity is mapped to application users and that authorization does not rely solely on TLS state.