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 1918144 - Null pointer exception on ssl connection
Summary: Null pointer exception on ssl connection
Keywords:
Status: CLOSED DUPLICATE of bug 1915071
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: java-11-openjdk
Version: 8.3
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Martin Balao
QA Contact: OpenJDK QA
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-01-20 07:51 UTC by Pavel
Modified: 2021-01-21 17:16 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-01-21 17:16:41 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Pavel 2021-01-20 07:51:55 UTC 
Description of problem:
Opening ssl connection on red hat java on cent os results in null pointer exception.

Version-Release number of selected component (if applicable):
java-11-openjdk-11.0.9.11-3.el8_3.x86_64

How reproducible:
Just run ssl request
This looks like happens only on linux and only with redhat open jdk (no problems on corretto or zulu)

Steps to Reproduce:
import java.io.IOException;
import java.net.URL;

public class TestClass {
    public static void main(String[] args) throws IOException {
        new URL("https://google.com").openConnection();
    }
}

Actual results:
Exception in thread "main" java.lang.NullPointerException
    at java.base/sun.security.ssl.SunJSSE.doRegister(SunJSSE.java:201)
    at java.base/sun.security.ssl.SunJSSE$1.run(SunJSSE.java:159)
    at java.base/java.security.AccessController.doPrivileged(Native Method)
    at java.base/sun.security.ssl.SunJSSE.registerAlgorithms(SunJSSE.java:156)
    at java.base/sun.security.ssl.SunJSSE.<init>(SunJSSE.java:118)
    at java.base/com.sun.net.ssl.internal.ssl.Provider.<init>(Provider.java:42)
    at java.base/sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:185)
    at java.base/sun.security.jca.ProviderList.getProvider(ProviderList.java:266)
    at java.base/sun.security.jca.ProviderList.getService(ProviderList.java:379)
    at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:157)
    at java.base/javax.net.ssl.SSLContext.getInstance(SSLContext.java:168)
    at java.base/javax.net.ssl.SSLContext.getDefault(SSLContext.java:99)
    at java.base/javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:123)
    at java.base/javax.net.ssl.HttpsURLConnection.getDefaultSSLSocketFactory(HttpsURLConnection.java:335)
    at java.base/javax.net.ssl.HttpsURLConnection.<init>(HttpsURLConnection.java:292)
    at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.<init>(HttpsURLConnectionImpl.java:100)
    at java.base/sun.net.www.protocol.https.Handler.openConnection(Handler.java:62)
    at java.base/sun.net.www.protocol.https.Handler.openConnection(Handler.java:57)
    at java.base/java.net.URL.openConnection(URL.java:1074)
    at TestClass.main(TestClass.java:7)


Expected results:
no NPE

Additional info:
I know this, that this product is speciffically  named "on windows" but I did not find anything about where to report problems on linux, so I am putting this error here anyway. Please make more clear where to report linux problems with redhat open jdk.

Here is corresponding question on stack overflow
https://stackoverflow.com/questions/65798369/opening-secure-socket-using-redhat-java-produces-nullpointerexception
Comment 1 Martin Balao 2021-01-20 17:57:58 UTC 
@Pavel: does the described issue happen on FIPS-alignment mode only? Looks to me like a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1915071 (which is believed to be a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1906862).
Comment 3 Andrew John Hughes 2021-01-20 18:47:45 UTC 
"This looks like happens only on linux and only with redhat open jdk (no problems on corretto or zulu)"

Then why is this bug filed under "OpenJDK on Windows"?
Comment 4 Andrew John Hughes 2021-01-20 18:54:30 UTC 
What crypto policy are you using? This looks like a known FIPS mode issue.
Comment 5 Deepak Bhole 2021-01-20 19:30:32 UTC 
(In reply to Andrew John Hughes from comment #3)
> "This looks like happens only on linux and only with redhat open jdk (no
> problems on corretto or zulu)"
> 
> Then why is this bug filed under "OpenJDK on Windows"?

Original report says it happens on CentOS. I assume reporter was unaware that OpenJDK is under the RHEL product -- thanks for fixing the product/component!
Comment 6 Andrew John Hughes 2021-01-20 20:10:41 UTC 
Yes, perhaps it should have been filed with https://bugs.centos.org/my_view_page.php but never mind.

It would help if the reporter could supply their java.security file from their JDK installation and perhaps more details on their setup. This doesn't happen with a default installation. It requires system properties to have been disabled:

$ /usr/lib/jvm/java-11-openjdk/bin/java -version
openjdk version "11.0.9" 2020-10-20 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.9+11-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.9+11-LTS, mixed mode, sharing)

$ /usr/lib/jvm/java-11-openjdk/bin/keytool -J-Djava.security.disableSystemPropertiesFile -genkeypair -v -alias myproject -keyalg RSA -keysize 4096 -storetype jks -dname "cn=myproject, ou=Devices, ou=Random Company, ou=Random Company, o=Random Company, c=US" -keypass 123456 -storepass 123456 -keystore my.keystore
keytool error: java.lang.NullPointerException
java.lang.NullPointerException
        at java.base/sun.security.ssl.SunJSSE.doRegister(SunJSSE.java:201)
        etc.

See bug 1915071.
Comment 7 Martin Balao 2021-01-20 20:22:50 UTC 
(In reply to Andrew John Hughes from comment #6)
> Yes, perhaps it should have been filed with
> https://bugs.centos.org/my_view_page.php but never mind.
> 
> It would help if the reporter could supply their java.security file from
> their JDK installation and perhaps more details on their setup. This doesn't
> happen with a default installation.

Agree. I suggest to list every step and configuration that deviates from a default / out-of-the-box installation as part of the bug report.

Thanks,
Martin.-
Comment 8 Pavel 2021-01-21 10:21:40 UTC 
Hallo thanks for your answers. It solved our issue.

First of all sorry for adding this under "on windows" as i already stated in additional info I did not find any "jdk for linux" and did not know that I should report it under RHEL or centos section.

Thanks for pointing to bug https://bugzilla.redhat.com/show_bug.cgi?id=1915071 where there are steps to reproduce, but all of them were not needed for us.
1. Enable RHEL 8 FIPS and reboot.
2. Set security.useSystemPropertiesFile=false in <java.home>/jre/lib/security/java.security
3. Use PKCS12 or JKS 

as for theese steps:
as for 1) we use cent os, not rhel but fips is disabled
cat /proc/sys/crypto/fips_enabled returns 0
as for 2) this was it! We trully had this settings turned to false. Changing this to true solved the issue.

BUT ...

/etc/java/java-11-openjdk/java-11-openjdk-11.0.9.11-3.el8_3.x86_64/conf/security/java.security
contains this:

#
# Determines whether this properties file will be appended to
# using the system properties file stored at
# /etc/crypto-policies/back-ends/java.config
#
security.useSystemPropertiesFile=false

But the weird thing is if we delete everything in this file (java.config). And set use system properties file to true. It still works fine. We dont understand why. Why referencing empty file to merge works but seting this boolean to false does not? Can someone please explain this? And is this a bug or just misconfiguration of jdk?

Thanks again for solving this issue and responding so quickly :-)
Comment 10 Andrew John Hughes 2021-01-21 17:15:30 UTC 
(In reply to Pavel from comment #8)

> as for 1) we use cent os, not rhel but fips is disabled

Sorry, the FIPS side of this is a bit of a misnomer. The bug is caused by FIPS changes, but FIPS does not need to be enabled to encounter the bug. The problem was that the new FIPS code wrongly assumed security.useSystemPropertiesFile is set to true, and relied on something that was only initialised in that mode.

This is fixed in the new RHEL RPMs that shipped today. They should find their way to CentOS soon (java-11-openjdk-11.0.10.0.9-4.el8_3).

> cat /proc/sys/crypto/fips_enabled returns 0
> as for 2) this was it! We trully had this settings turned to false. Changing
> this to true solved the issue.
> 
> BUT ...
> 
> /etc/java/java-11-openjdk/java-11-openjdk-11.0.9.11-3.el8_3.x86_64/conf/
> security/java.security
> contains this:
> 
> #
> # Determines whether this properties file will be appended to
> # using the system properties file stored at
> # /etc/crypto-policies/back-ends/java.config
> #
> security.useSystemPropertiesFile=false

Did you change this or did it ship like this?

In Fedora and RHEL, this is set to true:

https://src.fedoraproject.org/rpms/java-11-openjdk/blob/master/f/pr3694-rh1340845-support_fedora_rhel_system_crypto_policy.patch

> 
> But the weird thing is if we delete everything in this file (java.config).
> And set use system properties file to true. It still works fine. We dont
> understand why. Why referencing empty file to merge works but seting this
> boolean to false does not? Can someone please explain this? And is this a
> bug or just misconfiguration of jdk?

Which file are you deleting?

Currently if security.useSystemPropertiesFile is true, the system properties are enabled. If set to anything else (or not set at all), you will encounter the bug.

That is fixed in the new release.

> 
> Thanks again for solving this issue and responding so quickly :-)

No problem. We'd already encountered it so little debugging required :-)
Comment 11 Andrew John Hughes 2021-01-21 17:16:41 UTC 

*** This bug has been marked as a duplicate of bug 1915071 ***
Note You need to log in before you can comment on or make changes to this bug.