Bug 1760437

Summary: SunPKCS11 in FIPS-enabled OpenJDK can't understand SQL-only NSS DBs
Product: Red Hat Enterprise Linux 8 Reporter: Alex Scheel <ascheel>
Component: java-1.8.0-openjdkAssignee: Martin Balao <mbalao>
Status: CLOSED ERRATA QA Contact: OpenJDK QA <java-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.1CC: ahughes, cheimes, dbhole, jvanek, zzambers
Target Milestone: rc   
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: java-1.8.0-openjdk-1.8.0.242.b08-3.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-28 15:46:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1655466, 1760850    

Description Alex Scheel 2019-10-10 14:32:36 UTC
Description of problem:

NSS in RHEL 8.0.0 switched to using SQL by default [0]. DBM has is legacy code that has been deprecated in RHEL 8. Certutil, when creating a new NSS DB will create a SQL-only one by default:

$ mkdir /tmp/nssdb
$ certutil -N -d /tmp/nssdb
$ ls /tmp/nssdb
cert9.db  key4.db  pkcs11.txt

If you set a certutil-created NSS DB in lib/security/nss.fips.cfg, the JDK will choke with an error such as:


Oct 10 09:30:44 pki.example.com server[7100]: Caused by: java.security.ProviderException: Could not initialize NSS
Oct 10 09:30:44 pki.example.com server[7100]:         at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:223)
Oct 10 09:30:44 pki.example.com server[7100]:         at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:103)
Oct 10 09:30:44 pki.example.com server[7100]:         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
Oct 10 09:30:44 pki.example.com server[7100]:         at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
Oct 10 09:30:44 pki.example.com server[7100]:         at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
Oct 10 09:30:44 pki.example.com server[7100]:         at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
Oct 10 09:30:44 pki.example.com server[7100]:         at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:224)
Oct 10 09:30:44 pki.example.com server[7100]:         at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206)
Oct 10 09:30:44 pki.example.com server[7100]:         at java.security.AccessController.doPrivileged(Native Method)
Oct 10 09:30:44 pki.example.com server[7100]:         at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206)
Oct 10 09:30:44 pki.example.com server[7100]:         at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187)
Oct 10 09:30:44 pki.example.com server[7100]:         at sun.security.jca.ProviderList.getProvider(ProviderList.java:233)
Oct 10 09:30:44 pki.example.com server[7100]:         at sun.security.jca.ProviderList.getService(ProviderList.java:331)
Oct 10 09:30:44 pki.example.com server[7100]:         at sun.security.jca.GetInstance.getInstance(GetInstance.java:157)
Oct 10 09:30:44 pki.example.com server[7100]:         at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
Oct 10 09:30:44 pki.example.com server[7100]:         at org.apache.tomcat.util.net.jsse.JSSESSLContext.<init>(JSSESSLContext.java:45)
Oct 10 09:30:44 pki.example.com server[7100]:         at org.apache.tomcat.util.net.jsse.JSSEUtil.<clinit>(JSSEUtil.java:89)
Oct 10 09:30:44 pki.example.com server[7100]:         ... 21 more
Oct 10 09:30:44 pki.example.com server[7100]: Caused by: java.io.FileNotFoundException: /tmp/nssdb/secmod.db
Oct 10 09:30:44 pki.example.com server[7100]:         at sun.security.pkcs11.Secmod.initialize(Secmod.java:205)
Oct 10 09:30:44 pki.example.com server[7100]:         at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:218)


The workaround is to create an empty file named secmod.db in your NSS DB.


Version-Release number of selected component (if applicable):

[root@pki java]# rpm -qa | grep -i openjdk
java-1.8.0-openjdk-1.8.0.222.b10-3.el8.x86_64
java-1.8.0-openjdk-devel-1.8.0.222.b10-3.el8.x86_64
java-1.8.0-openjdk-headless-1.8.0.222.b10-3.el8.x86_64



How reproducible:

Very


Steps to Reproduce:

1. See steps above. 

Actual results:

OpenJDK chokes.

Expected results:

OpenJDK should correctly handle the modern SQL-only NSS DB format. This is the default on RHEL 8.


Additional info:

[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1489094

Comment 1 Alex Scheel 2019-10-11 13:49:50 UTC
On my checkout of jdk8u upstream, this is caused by this incorrect snippet of code, lines 198 - 207 in jdk/src/share/classes/sun/security/pkcs11/Secmod.java (changeset:   13685:69c4f673b33e): 


>        if (configDir != null) {
>            File configBase = new File(configDir);
>            if (configBase.isDirectory() == false ) {
>                throw new IOException("configDir must be a directory: " + configDir);
>            }
>            File secmodFile = new File(configBase, "secmod.db");
>            if (secmodFile.isFile() == false) {
>                throw new FileNotFoundException(secmodFile.getPath());
>            }
>        }


secmod.db isn't a valid heuristic for "is this directory a NSS DB".

Comment 2 Christian Heimes 2019-10-11 14:23:55 UTC
Corect heuristic is ((cert8.db && key3.db && secmod.db) || (cert9.db && key4.db && pkcs11.txt))

Comment 3 Martin Balao 2019-11-05 20:21:00 UTC
The 8u backport of 8165996 [1][2] and 8195607 [3][4] would be needed to support SQLite DBs.

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8165996
[2] - http://hg.openjdk.java.net/jdk/jdk/rev/55b9b1e184c6
[3] - https://bugs.openjdk.java.net/browse/JDK-8195607
[4] - http://hg.openjdk.java.net/jdk/jdk/rev/4bf4c7918063

Comment 5 Martin Balao 2020-01-20 18:41:35 UTC
Status update:

 * 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite
  * 8u backport proposed but blocked by the requirement of a dependency (8133318) [1]

 * 8133318: Exclude intermittent failing PKCS11 tests on Solaris SPARC 11.1 and earlier
  * 8u backport proposed [2]. Waiting for review.

 * 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with "NSS initialization failed" on NSS 3.34.1
  * 8u backport will come after 8165996 is pushed.

--
[1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010572.html
[2] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-January/010989.html

Comment 6 Andrew John Hughes 2020-01-21 01:34:56 UTC
This bug does not need to be dependent on the upstreaming process, and its long trail of testing dependencies. We can get this fixed in the RPM and then pick up the upstream version in April. That avoids rushing the upstream process for the sake of getting this bug into RHEL 8.2.

Comment 12 errata-xmlrpc 2020-04-28 15:46:27 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1646