`Aws::CloudFront::Signer` SHA1 digest is not supported on Fedora Linux

[jdufresne]

Describe the bug

The Aws::CloudFront::Signer class always uses the digest algorithm "SHA1",

aws-sdk-ruby/gems/aws-sdk-cloudfront/lib/aws-sdk-cloudfront/signer.rb

Line 16 in 3919bcc

@cipher = OpenSSL::Digest.new('SHA1')

But this digest algorithm is unsupported since Fedora 41:

https://fedoraproject.org/wiki/Changes/OpenSSLDistrustSHA1SigVer

When using Aws::CloudFront::Signer on Fedora, it results in:

OpenSSL::PKey::PKeyError (EVP_DigestSignInit: invalid digest):

Changing the digest to SHA256 works for me, either by patching the aws-sdk-cloudfront gem or by overriding the class.

 @cipher = OpenSSL::Digest.new('SHA256')

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

Aws::CloudFront::Signer is compatible with a default Fedora installation without any monkey patching.

Current Behavior

Results in the error:

OpenSSL::PKey::PKeyError (EVP_DigestSignInit: invalid digest):

Reproduction Steps

Using Fedora Linux:

require 'aws-sdk-cloudfront'

signer = Aws::CloudFront::UrlSigner.new(key_pair_id: 'MY_KEY_PAIR_ID', private_key_path: '/home/jon/private.pem')
signed_url = signer.signed_url('https://mydistribution.cloudfront.net/myvideo.mp4', expires: Time.now.to_i + 3600)
puts signed_url

.../vendor/bundle/ruby/3.4.0/gems/aws-sdk-cloudfront-1.132.0/lib/aws-sdk-cloudfront/signer.rb:98:in 'OpenSSL::PKey::PKey#sign': EVP_DigestSignInit: invalid digest (OpenSSL::PKey::PKeyError)
	from .../vendor/bundle/ruby/3.4.0/gems/aws-sdk-cloudfront-1.132.0/lib/aws-sdk-cloudfront/signer.rb:98:in 'Aws::CloudFront::Signer#sign_policy'
	from .../vendor/bundle/ruby/3.4.0/gems/aws-sdk-cloudfront-1.132.0/lib/aws-sdk-cloudfront/signer.rb:91:in 'Aws::CloudFront::Signer#signature'
	from .../vendor/bundle/ruby/3.4.0/gems/aws-sdk-cloudfront-1.132.0/lib/aws-sdk-cloudfront/url_signer.rb:30:in 'Aws::CloudFront::UrlSigner#signed_url'
	from test.rb:4:in '<main>'

Possible Solution

require 'aws-sdk-cloudfront'

class MyUrlSigner < Aws::CloudFront::UrlSigner
  def initialize(...)
    super
    @cipher = OpenSSL::Digest.new('SHA256')
  end
end

signer = MyUrlSigner.new(key_pair_id: 'MY_KEY_PAIR_ID', private_key_path: '/home/jon/private.pem')
signed_url = signer.signed_url('https://mydistribution.cloudfront.net/myvideo.mp4', expires: Time.now.to_i + 3600)
puts signed_url

Additional Information/Context

No response

Gem name ('aws-sdk', 'aws-sdk-resources' or service gems like 'aws-sdk-s3') and its version

aws-sdk-cloudfront

Environment details (Version of Ruby, OS environment)

Fedora Linux, ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux]

[jterapin]

Hi! Thanks for submitting this issue. I found a similar ticket that was reported for AWS SDK for PHP in May 2025: aws/aws-sdk-php#3116

It's interesting that SHA256 appears to work with CloudFront despite not being documented as supported. Please continue using the monkey patch for now. I'll need to verify with the service team on this and will follow up here.

[jdufresne]

I found another workaround that may be more useful for anyone looking for a solution, first export the environment variable:

export OPENSSL_ENABLE_SHA1_SIGNATURES=1

https://fedoraproject.org/wiki/SHA1SignaturesGuidance

For package builds, you can export the OPENSSL_ENABLE_SHA1_SIGNATURES environment variable. Its value doesn't matter, the code only checks for its presence. Note that this environment variable is explicitly unsupported at runtime, and we're going to remove it without forewarning in a future version of OpenSSL on Fedora.

Don't use this environment variable to work around problems at runtime.

[jterapin]

Following up on this. Which key (RSA or ECDSA) were you using for the above?

[jdufresne]

Following up on this. Which key (RSA or ECDSA) were you using for the above?

I was using RSA, thanks.

[jterapin]

Thank you for your patience on this. CloudFront launched SHA-256 support for signed URLs in April 2026, so we're now able to address this on the SDK side. We're re-categorizing this as a feature request and tracking the implementation internally.

We don't have a timeline to share yet as we're aligning on the implementation approach, but I'll circle back here once we're aligned and have an update.