What were you trying to do that didn't work?

Java pads the EC signatures (r, s, nLen) }}to the {{{}max(r,s). This can result in signatures shorter than 2*nLen. This caused problem that was recently fixed (RHEL-31891) because nss expected signatures of length 2*nLen. Even though what java does is in fact compliant with the standard, the same standard notes the following recommendation:

Note: For applications, it is recommended to encode the signature as an octet string of length two times nLen if possible. This ensures that the application works with PKCS#11 modules which have been implemented based on an older version of this document. Older versions required all signatures to have length two times nLen.

Therefore I suggest to follow the recommendation.

Please provide the package NVR for which bug is seen:

java-11-openjdk-11.0.23.0.9-3.el9 

How reproducible:

100% in FIPS mode

Steps to reproduce

This can be reproduced with nss-3.90.0-6.el9_3 by running this test in FIPS mode (otherwise java won't use nss-softokn). It does the validation of EC signatures using NIST256p, NIST384p and NIST521p curves, it uses signatures generated such that they are shorter than {{2*nLen }}when padded by java. 

Expected results

Once this is fixed in java, test passes even with this specific version of nss,

Actual results

With reported version of java and this specific version of nss, test fails.

Additional information

This also applies to RHEL-8 java (and possibly to RHEL-10 too). Notice that even though NSS was fixed to accept EC signatures shorted than their maximum length, other application might still expect maximum length and will fail to validate valid signatures.