JDK-8232153 : sun/security/pkcs11/Secmod/AddTrustedCert.java failed with Linux built-in NSS libs
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto:pkcs11
  • Affected Version: 11,14,17,21
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • OS: linux
  • Submitted: 2019-10-11
  • Updated: 2024-01-04
  • Resolved: 2024-01-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8231338 - sun/security/pkcs11/Secmod/AddTrustedCert.java failed on Ubuntu 18.04.2 LTS
Relates :  
JDK-8296631 - NSS tests failing on OL9 linux-aarch64 hosts
Relates :  
JDK-8180837 - SunPKCS11-NSS tests failing with CKR_ATTRIBUTE_READ_ONLY and CKR_MECHANISM_PARAM_INVALID
Description
$ cat /etc/oracle-release 
Oracle Linux Server release 7.6

java version "14-ea" 2020-03-17
Java(TM) SE Runtime Environment (build 14-ea+18-773)

After JDK-8180837, test sun/security/pkcs11/Secmod/AddTrustedCert.java is skipped for defined NSS version:
-->  "Skip test due to improper NSS version in [3.28, 3.35). "

But this test failed with the default NSS version 3.36, which is not in the skipped version list, on Oracle Linux 7.6

----------System.out:(86/3621)*----------
Cannot resolve artifact, please check if JIB jar is present in classpath.
nssLibDir: /usr/lib64/
Cannot resolve artifact, please check if JIB jar is present in classpath.
libnss3 version = 3.36.  ECC None.
SunPKCS11-NSSKeyStore version 14

...
----------System.err:(21/1603)----------
java.security.KeyStoreException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ATTRIBUTE_READ_ONLY
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11KeyStore.engineSetEntry(P11KeyStore.java:1049)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11KeyStore.engineSetCertificateEntry(P11KeyStore.java:515)
	at java.base/java.security.KeyStore.setCertificateEntry(KeyStore.java:1228)
	at AddTrustedCert.main(AddTrustedCert.java:106)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:830)
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ATTRIBUTE_READ_ONLY
	at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_CreateObject(Native Method)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11KeyStore.storeCert(P11KeyStore.java:1567)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11KeyStore.engineSetEntry(P11KeyStore.java:1045)
	... 9 more
Comments
This bug was addressed in https://bugs.openjdk.org/browse/JDK-8296631
04-01-2024
Setting the jtreg option -e:NSS_DEFAULT_DB_TYPE=sql makes the test pass on our RHEL 7.9 machine (tested with jdk11 and jdk21). So it looks like the NSS on the system needs some help to determine the "default Database type" (=sql) used in OpenJDK, is that correct ?
06-06-2023
The test sun/security/pkcs11/Secmod/AddTrustedCert.java fails as well with OpenJDK 21 on RHEL 7.9, error message looks similar : java.security.KeyStoreException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ATTRIBUTE_READ_ONLY at jdk.crypto.cryptoki/sun.security.pkcs11.P11KeyStore.engineSetEntry(P11KeyStore.java:1059) at jdk.crypto.cryptoki/sun.security.pkcs11.P11KeyStore.engineSetCertificateEntry(P11KeyStore.java:528) at java.base/java.security.KeyStore.setCertificateEntry(KeyStore.java:1253) at AddTrustedCert.main(AddTrustedCert.java:106) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125) at java.base/java.lang.Thread.run(Thread.java:1623) Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ATTRIBUTE_READ_ONLY at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_CreateObject(Native Method) at jdk.crypto.cryptoki/sun.security.pkcs11.P11KeyStore.storeCert(P11KeyStore.java:1576) at jdk.crypto.cryptoki/sun.security.pkcs11.P11KeyStore.engineSetEntry(P11KeyStore.java:1055) ... 7 more JavaTest Message: Test threw exception: java.security.KeyStoreException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ATTRIBUTE_READ_ONLY JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.security.KeyStoreException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ATTRIBUTE_READ_ONLY I think Oracle Linux mentioned in the description is very similar to RHEL 7, so probably it is not surprising the test fails there as well .
29-12-2022
the test fails when attempting to add the same trustedcert to the same store a 2nd time. Some behavioural difference within the NSS libs means this isn't always possible with a CKR_ATTRIBUTE_READ_ONLY error returned. Running the test with the NSS_DEFAULT_DB_TYPE=sql environment variable set (-e:NSS_DEFAULT_DB_TYPE=sql in jtreg) seems to let the test pass. Unclear as to whether the JDK should be setting this variable by default now.
30-08-2022
I see this test fail with NSS 3.35 - wasn't the intention of JDK-8180837 to exclude this test for NSS version <= 3.35 ( && nssVersion >= 3.28) ? - if so, this logic is incorrect if (p.getName().equalsIgnoreCase("SunPKCS11-NSSKeyStore") && nssVersion >= 3.28 && nssVersion < 3.35) { == in any case, it looks like the test needs updating to deal with the new default NSS file format.
30-08-2022
I managed to reproduce the failure using https://github.com/nss-dev/nss/releases/tag/NSS_3_53_1_RTM. I reverted the patch https://bugzilla.mozilla.org/show_bug.cgi?id=1377940 and build nss libraries with enable-legacy-db. When the libraries are built with the patch and with enable-legacy-db, the test passes. I found that since version 3.35 NSS moved to use the SQL format. NSS also changes how it handles data when a prefix to the storage parameter is not provided. Without the prefix data is migrated to the SQL format on first access. Details can be found: - https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql - https://wiki.mozilla.org/NSS_Shared_DB I saw this NSS behaviour when I ran sun/security/pkcs11/Secmod/AddTrustedCert.java. The DBM files were converted to the SQL files. I think two sets of files, the storage parameter without a prefix and the DBM format assumed by default cause the failure.
26-05-2021
The test fails on Amazon Linux 2 because of changes in nss-util. It is built with a reverted patch: https://bugzilla.mozilla.org/show_bug.cgi?id=1377940. The patch changes NSS default storage file format (currently DBM), when no prefix is given, to SQL. In nss-util built for Amazon Linux 2, the old behavior is kept: if no prefix is used, the DBM format is assumed. As I understand the DBM format is now the legacy format and the SQL format is recommended. The test has files in both format: DBM and SQL. The DBM files are used by default. Without the patch something wrong happens with processing of the DBM files. The test passes when the SQL files are used or nss-util having the patch is built. I checked libnss3 version 3.35 from Ubuntu 18.04.5 has nss-util with the patch reverted.
25-05-2021
The test passes on Amazon Linux 2, AArch64 because it skips testing. It cannot find NSS libraries. After fixing this the test fails the same as on x86_64.
25-05-2021
Amazon Linux 2, libnss 3.53.1, JDK 11u x86_64: test failure aarch64: test pass
15-04-2021
At Microsoft, we are seeing this same failure on Ubuntu 18.04.5 LTS with libnss3 version 3.35 and JDK 11u.
10-02-2021
I am observing this on both RHEL7.8 and CentOS8.
21-08-2020
BTW, It'd be helpful to print out more OS and NSS info for unexpected test failures for easier troubleshoot in the future.
27-11-2019
The part of code has not changed much and based on the test results, it seems to be due to Linux distro-specific NSS library. Re-assign back to John to handle this in the test.
27-11-2019
The test passed with my new built NSS 3.36 and 3.44 libs on Ubuntu 18.04.
13-10-2019
If this issue is caused by the NSS libs in some Linux distributions, it would have to swallow this exception as an known problem. But this way may cover up a possible real JDK bug in the feature.
12-10-2019
This test failed with NSS 3.44 on OL 7.1. See the attached AddTrustedCert-NSS_3.44.jtr for more details.
12-10-2019
I tested this case on Ubuntu19.04 (seems to be nss-3.36?), and it passed with the built-in nss.
12-10-2019
I reproduced this failure with the built-in NSS 3.35 libs from libnss3-dev on Ubuntu 18.04. But the test passed with the libs in my own NSS 3.35 build. I suppose this issue may NOT be related to the some specific NSS versions, including 3.35, 3,36 and 3.44. Instead, it may be related to the NSS libs distributed by some Linux releases.
12-10-2019