jdk_security3_1_FAILED PKCS11Exception: CKR_USER_TYPE_INVALID/CKR_ATTRIBUTE_VALUE_INVALID & InvalidParameterException: RSA key must be at least 1023 bits #15967
Labels
Comments
|
Grinder passed, but passing machines are rhel7, ub18, ub20, ub22. |
|
Reproduced at rhel8ppc64le-fips4-1 |
|
Not sure it's valid to run on a fips machine (in non-fips mode, without the fips exclude list), these machines don't have the non-fips test label. That might explain the ".PKCS11Exception: CKR_ARGUMENTS_BAD" failure. It would be good to try Temurin as well, since this seems like a OpenJDK issue on rhel8. |
|
Internal grinder( Since RI failed similarly at |
|
The original failure wasn't on a fips machine, not sure how fips got involved. We should try the tests with Temurin on a non-fips machine, although I expect the outcome to be the same (not an OpenJ9 issue). |
|
As expected #15967 (comment), hotspot had same error at the machine So this confirms it is not an OpenJ9 issue. |
|
Internal build( |
JasonFengJ9
changed the title
JasonFengJ9
changed the title
|
Internal build( Internal build( |
|
Internal 0.35 rc1 build( |
|
Similar failure in JDK17 But it is passed by running jtreg in a Fyre machine with Redhat OS and FIPS mode enabled. Results can be found at here. Same for |
|
Another one seen in #16285 (comment). It is similar to the one reported in #15967 (comment). Exception messages: |
|
I have more failures with this
|
|
JDK11 0.36 build( |
|
Attaching a remote debugger to TestKeyFactory.java, which is the original test reported failing above, I was able to see the failing pattern while executing the test. Whenever a key was being imported using PKCS11, and the key was not 1024bit length or higher, the test would fail with Another problem in the same package could be fixed by changing this line From: To: I was then able to run all the tests in the |
|
I was able to fix all the tests in the package Increased the value from Increased the value from Increased the value from |
|
Is that going to cause any problems on older platforms we still support? |
|
We may also be seeing a system by system difference in behavior here since the allowable key length settings could potentially be configured different in the NSS library for each system. |
Key sizes of 2048 have been supported for a long period of time in various libraries and versions of Java so I wouldnt anticipate too many problems from that perspective. I am unsure the history with NSS support for various key sizes though so older systems running on older versions of NSS could potentially have different behavior. |
|
Do you think NSS would be running on the machines we use for testing, other than the FIPS machines? Our oldest system are rhel 6 jdk8 (only), but may drop that, also centos/rhel 7, sles 12. Currently Ubuntu 18 but it's going out of support so those machines will be removed soon. |
|
I do know that NSS can run on RHEL systems in fips or non fips modes. Some of the differences we are seeing with allowable key sizes could easily be associated with NSS running in FIPS or non FIPS modes. I can try to find some documentation on how to find out what key sizes are configured on RHEL. Id have to log into the other platforms to check what PKCS11 libraries are installed there. If there is a PKCS11 dll available I would think it would have to be super old to not support a 2048 key size. Id assume we would have other tests failing where we are using other key sizes like 2048..... |
|
JDK11 x86-64_linux 0.40.0 milestone 1( |
JasonFengJ9
changed the title
JasonFengJ9
changed the title
|
JDK11 s390x_linux milestone 2( |
|
JDK11 x86-64_linux rc1( |
|
JDK8 0.41 milestone 1 - ppc64le_linux( JDK8 0.41 milestone 1 s390x_linux( |
JasonFengJ9
changed the title
|
JDK11 ppc64le_linux( |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Failure link
From an internal build(
rhel8le-rt1-4):Rerun in Grinder - Change TARGET to run only the failed test targets.
Optional info
Failure output (captured from console output)
50x internal grinder - passed
The text was updated successfully, but these errors were encountered: