Use 'sha256' instead of 'sha' when validating RSA signing supportability #142
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In Openssl 3.0.1 in default configuration,
jose_server.erl
will determine that noRS*
algorithms are supported for signing. The reason for this is usage ofsha
for DigestType when determining RSA signing supportability.This breaks various flows even though 2 workarounds exist (both of which are not satisfactory enough in our case):
crypto_fallback
env var totrue
I propose we change the DigestType to
sha256
, sincesha1
signature creation will probably be disabled in the future on both RHEL 9 and RHEL 10, based on info from [1].Currently, SHA1+RSA signature creation is not allowed in OpenSSL configuration on public cloud Alma Linux images. Where the config is hardened to disallow certain signature algorithms. On those machines, example output of
JOSE.JWA.supports()
is as follows:If we use
sha256
to create and validate RSA signing algorithms, the supported list becomes correct:Setup:
Alma Linux 9.1
OpenSSL 3.0.1
Elixir 1.14.0-otp-25
Erlang 25.0.4
jose 1.11.2
[1] openssl/openssl#17662