CloudFrontUtilities: Support SHA256 for signed URLs/signed Cookies

[FlorianSW]

Describe the feature

Now that CloudFront supports SHA256 (on top of SHA1) for signed URLs and signed cookies, the CloudFrontUtilities helper class should support that as well.

Use Case

The use of SHA256 over allows to meet security and compliance requirements, especially when using signed URLs/cookies to control access to restricted resources through CloudFront.

Proposed Solution

Using SHA256 should therefore be as seamless as using SHA1. Hence it should be supported in CloudFrontUtilities. It should either be an opt-in configuration for the signer, or (maybe?) be the default and an opt-in to use SHA1 should be used. The usage of SHA256 should be supported on virtually every supported platform for the SDK, hence switching to it shouldn't be a big concern for users of the SDK.

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS Java SDK version used

2.42.28

JDK version used

25.0.2

Operating System and version

MacOS 26.4

[bhoradc]

Thank you for filing this feature request, @FlorianSW. This appears to be a reasonable ask now that CloudFront supports SHA-256 for signed URLs and signed cookies.

Regarding making SHA-256 the default, CloudFront itself still defaults to SHA-1 when the Hash-Algorithm parameter is not specified, so changing the SDK default to SHA-256 would be a behavior change for existing customers who don't expect a different algorithm. We'll likely go with SHA-256 as an opt-in, but I will bring this up with the team for discussion.

We'll update this issue as we make progress.

Community Note: If this feature is important to you, please give a 👍 on the original issue description, it helps us prioritize.

[FlorianSW]

Regarding making SHA-256 the default, CloudFront itself still defaults to SHA-1 when the Hash-Algorithm parameter is not specified, so changing the SDK default to SHA-256 would be a behavior change for existing customers who don't expect a different algorithm. We'll likely go with SHA-256 as an opt-in, but I will bring this up with the team for discussion.

Totally agree. I just wanted to point out that I wouldn't be against either way (opt-in or opt-out). Your explanation makes a lot of sense, though :)