Solution

Use OpenSSL::SSL::VERIFY_NONE for your Redis client.

Sidekiq

# config/initializers/sidekiq.rbSidekiq.configure_server do |config|  config.redis = { ssl_params: { verify_mode: OpenSSL::SSL::VERIFY_NONE } }endSidekiq.configure_client do |config|  config.redis = { ssl_params: { verify_mode: OpenSSL::SSL::VERIFY_NONE } }end

Redis

Redis.new(url: 'url', driver: :ruby, ssl_params: { verify_mode: OpenSSL::SSL::VERIFY_NONE })

Reason

Redis 6 requires TLS to connect. However, Heroku support explained that they manage requests from the router level to the application level involving Self Signed Certs. Turns out, Heroku terminates SSL at the router level and requests are forwarded from there to the application via HTTP while everything is behind Heroku's Firewall and security measures.

Sources

• https://ogirginc.github.io/en/heroku-redis-ssl-error
• https://devcenter.heroku.com/articles/securing-heroku-redis#connecting-directly-to-stunnel

If you use ActionCable, you may also need to add verify_mode to the `cable.yml config:

production:  adapter: redis  url: <%= ENV.fetch("REDIS_URL") { "redis://localhost:6379/1" } %>  channel_prefix: my_app_production  ssl_params:    verify_mode: <%= OpenSSL::SSL::VERIFY_NONE %>

Source: https://github.com/chatwoot/chatwoot/issues/2420

If you are using Rails 5 you won't be able to configure Redis's ssl_params for ActionCable via the cable.yml file. Instead you can manually set the redis_connector attribute in an initializer, like this:

# frozen_string_literal: truerequire "action_cable/subscription_adapter/redis"ActionCable::SubscriptionAdapter::Redis.redis_connector = ->(_config) do  Redis.new(...your options here...)end

And for more context on the implications of using OpenSSL::SSL::VERIFY_NONE and why it's probably OK if you're on Heroku:

Using OpenSSL::SSL::VERIFY_NONE tells the client it's OK to work with a self-signed certificate, no attempt will be made to verify that the cert was signed by a known Certificate Authority.

The risk there is the possibility of a man-in-the-middle attack. If the client attempting to talk to Heroku Redis is not verifying that the SSL certificates it encounters are known to belong to Heroku (AKA, that those certificates are signed by a certificate authority that has verified that the entity that requested the cert is in fact Heroku), then an attacker who sits betweeen your client and Heroku Redis could create their own self-signed SSL certificate and pretend to be Heroku. This means they could potentially intercept any traffic you attempt to send to Heroku Redis.

In practice that is probably not a realistic scenario for a Heroku dyno talking to Heroku Redis.

Here's a quote from Heroku support:

MITM attacks are impractical on managed hosting providers. It would bedifficult for a bad actor to get between a dyno and a Redis instancehosted on AWS. This is because EC2 instances that are in the same AZshould not route outside of the AWS infrastructure at any point. Thisbeing the case, a MITM attack could only be performed by a bad actorwithin the managed service provider's facility itself since thenetwork traffic never leaves said facility.

And here are some snippets from the AWS docs that seem to corroborate this:

https://aws.amazon.com/vpc/faqs/

Q. Does traffic go over the internet when two instances communicateusing public IP addresses, or when instances communicate with a publicAWS service endpoint?

No. When using public address space, all communication betweeninstances and services hosted in AWS use AWS's private network.Packets that originate from the AWS network with a destination on theAWS network stay on the AWS global network, except traffic to or fromAWS China Regions.

In addition, all data flowing across the AWS global network thatinterconnects our data centers and Regions is automatically encryptedat the physical layer before it leaves our secured facilities.Additional encryption layers exist as well; for example, all VPCcross-region peering traffic, and customer or service-to-serviceTransport Layer Security (TLS) connections.

And https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-vpc.html

Amazon Virtual Private Cloud (Amazon VPC) enables you to define avirtual network in your own logically isolated area within the AWScloud, known as a virtual private cloud (VPC).

When you create your AWS account, we create a default VPC for you ineach Region