1567204 – OpenJDK not read jssecacerts file

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1567204 - OpenJDK not read jssecacerts file

Summary: OpenJDK not read jssecacerts file

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	java-1.8.0-openjdk
Sub Component:
Version:	7.4
Hardware:	x86_64
OS:	Linux
Priority:	high
Severity:	high
Target Milestone:	rc
Target Release:	---
Assignee:	Andrew John Hughes
QA Contact:	zzambers
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	1593736 1593737
TreeView+	depends on / blocked

Reported:	2018-04-13 14:47 UTC by Deepu K S
Modified:	2021-09-09 13:42 UTC (History)
CC List:	10 users (show)
Fixed In Version:	java-1.8.0-openjdk-1.8.0.172-5.b11.el7
Doc Type:	Bug Fix
Doc Text:	OpenJDK was recently updated to support reading the system certificate authority /etc/pki/java/cacerts database directly. As a consequence, this removed the ability to read certificates from the user-provided /usr/lib/jvm/<NVRA-of-JDK>/jre/lib/security/jssecacert file. With this update, that ability is restored by reading from that file first, if available.
Clone Of:
Clones:	1593736 1593737 (view as bug list)
Environment:
Last Closed:	2018-10-30 07:27:33 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Priority	Status	Summary	Last Updated
Icedtea Bugzilla	2888	None	None	None	2019-06-29 14:16:14 UTC
Icedtea Bugzilla	3575	None	None	None	2019-06-29 14:16:14 UTC
Red Hat Product Errata	RHBA-2018:3017	None	None	None	2018-10-30 07:29:13 UTC
openjdk bug system	JDK-8129988	None	None	None	2018-04-13 14:59:18 UTC

Description Deepu K S 2018-04-13 14:47:43 UTC

Description of problem:
After updating to OpenJDK 1.8.0.151-5.b12.el7_4 from 1.8.0.131-3.b12.el7_3; there is behavioral change that now it first read the cacerts file and ignore the jssecacerts file at all if cacerts exist.

We have to explicitly set the option '-Djavax.net.ssl.trustStore=/usr/lib/jvm/jre/lib/security/jssecacerts' to get it to find that cert file.

If cacerts file is renamed or removed, that the JRE will read the jssecacert file.
However, it is against the Oracle JRE documentation, in normal case, the jssecacerts should always be read first.

Referring to Oracle JRE document on JSSE (https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#X509TrustManager), the bug fix/behavioral change on OpenJDK is obviously deviated from Oracle JRE implementation.

If the javax.net.ssl.trustStore system property was not specified, then:
• if the file java-home/lib/security/jssecacerts exists, that file is used; <<===************
• if the file java-home/lib/security/cacerts exists, that file is used;
• if neither of these files exists, then the SSL cipher suite is anonymous, does not perform any authentication, and thus does not need a truststore.

Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux 7.4
java-1.8.0-openjdk-1.8.0.161-2.b14.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Use 'SSLContextPerform.java' from https://bugs.openjdk.java.net/browse/JDK-8129988
2. # java -Djavax.net.debug=ssl Main |& tee X | grep trustStore
3.

Actual results:
# java -Djavax.net.debug=ssl Main |& tee X | grep trustStore
trustStore is: /etc/pki/java/cacerts
trustStore type is : jks
trustStore provider is :

The problem is that we have all our Signer CA added to jssecacerts file, such change would mean that we have to modify all our codes to add the specific parameters “-Djavax.net.ssl.trustStore=/usr/lib/jvm/jre/lib/security/jssecacerts” in order to use the jssecacerts file.

Expected results:
If the file java-home/lib/security/jssecacerts exists, that file should be used.

Additional info:

Comment 4 Andrew John Hughes 2018-04-13 18:32:52 UTC

This seems to be an oversight in PR2888 which shouldn't have altered the jssecacerts logic. The intention of that patch is simply to avoid traversing the symlink:

$ ll /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/security/cacerts 
lrwxrwxrwx. 1 root root 41 Nov 21 13:16 /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/security/cacerts -> ../../../../../../../etc/pki/java/cacerts

and use /etc/pki/java/cacerts directly. The symlink still needs to exist for some third-party software (e.g. Gradle, bug 1448802, https://github.com/gradle/gradle/issues/1782) that check specifically for that path, but is unused by the JDK itself.

I'll fix this.

Comment 5 jiri vanek 2018-04-16 07:44:58 UTC

Just side note - due to parallel install feature, the config files in jdk are handled by postinstall scriplets.  This may lead to some unexpected issues like leftover old file in previous directory.
However, all glitches should be already fixed, and I have not seen issue with cacerts and/or jssecacerts being left over or other way corrupted for at least year. More likely longer. Still It may be point worthy of double checking.

Comment 17 zzambers 2018-07-02 17:24:39 UTC

Manually tested in rhel7 VM:

package: java-1.8.0-openjdk-1.8.0.161-2.b14.el7_4.x86_64

result: PASSED

Comment 18 zzambers 2018-07-02 18:08:09 UTC

I accidentally reported on rhel-7.4.z package here.

However now I have also tested 7.6 package:

package: java-1.8.0-openjdk-1.8.0.181-3.b04.el7

result: PASSED

Comment 20 errata-xmlrpc 2018-10-30 07:27:33 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-2018:3017

Note You need to log in before you can comment on or make changes to this bug.