Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jdk_security3_1 FAILED sun/security/ssl/X509TrustManagerImpl/distrust/Entrust.java DerInputStream.getLength(): lengthTag=109, too big #20856

Open
JasonFengJ9 opened this issue Dec 18, 2024 · 1 comment

Comments

@JasonFengJ9
Copy link
Member

JasonFengJ9 commented Dec 18, 2024

Failure link

From internal Test_openjdk17_j9_extended.openjdk_ppc64_aix_fips140_3_openjceplusfips.fips140-3_testList_0 (p10aix134)

openjdk version "17.0.14" 2025-01-21
IBM Semeru Runtime Open Edition 17.0.14.0-m2 (build 17.0.14+6)
Eclipse OpenJ9 VM 17.0.14.0-m2 (build v0.49.0-release-f4d977c71b, JRE 17 AIX ppc64-64-Bit Compressed References 20250121_867 (JIT enabled, AOT enabled)
OpenJ9   - f4d977c71b
OMR      - e49875871
JCL      - f2d3af9195a based on jdk-17.0.14+6)

Rerun in Grinder - Change TARGET to run only the failed test targets

Optional info

Failure output (captured from console output)

[2024-12-15T22:58:15.917Z] variation: Mode650
[2024-12-15T22:58:15.917Z] JVM_OPTIONS:  -XX:-UseCompressedOops -Xverbosegclog  -Dsemeru.fips=true -Dsemeru.customprofile=OpenJCEPlusFIPS.FIPS140-3

[2024-12-15T23:04:39.057Z] TEST: sun/security/ssl/X509TrustManagerImpl/distrust/Entrust.java

[2024-12-15T23:04:39.068Z] STDERR:
[2024-12-15T23:04:39.068Z] java.security.KeyStoreException: problem accessing trust store
[2024-12-15T23:04:39.068Z] 	at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:73)
[2024-12-15T23:04:39.068Z] 	at java.base/javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:282)
[2024-12-15T23:04:39.068Z] 	at Distrust.getTMF(Distrust.java:90)
[2024-12-15T23:04:39.068Z] 	at Entrust.main(Entrust.java:61)
[2024-12-15T23:04:39.068Z] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[2024-12-15T23:04:39.069Z] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
[2024-12-15T23:04:39.069Z] 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[2024-12-15T23:04:39.069Z] 	at java.base/java.lang.reflect.Method.invoke(Method.java:575)
[2024-12-15T23:04:39.069Z] 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
[2024-12-15T23:04:39.069Z] 	at java.base/java.lang.Thread.run(Thread.java:853)
[2024-12-15T23:04:39.069Z] Caused by: java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
[2024-12-15T23:04:39.069Z] 	at java.base/sun.security.util.DerInputStream.getLength(DerInputStream.java:251)
[2024-12-15T23:04:39.069Z] 	at java.base/sun.security.util.DerValue.<init>(DerValue.java:444)
[2024-12-15T23:04:39.069Z] 	at java.base/sun.security.util.DerValue.<init>(DerValue.java:487)
[2024-12-15T23:04:39.069Z] 	at java.base/sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2012)
[2024-12-15T23:04:39.069Z] 	at java.base/java.security.KeyStore.load(KeyStore.java:1473)
[2024-12-15T23:04:39.069Z] 	at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.loadKeyStore(TrustStoreManager.java:390)
[2024-12-15T23:04:39.070Z] 	at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.getTrustedCerts(TrustStoreManager.java:336)
[2024-12-15T23:04:39.070Z] 	at java.base/sun.security.ssl.TrustStoreManager.getTrustedCerts(TrustStoreManager.java:57)
[2024-12-15T23:04:39.070Z] 	at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:49)
[2024-12-15T23:04:39.070Z] 	... 9 more
[2024-12-15T23:04:39.070Z] 
[2024-12-15T23:04:39.070Z] JavaTest Message: Test threw exception: java.security.KeyStoreException: problem accessing trust store

5x internal Grinder - all failed

FYI @jasonkatonica

@jasonkatonica
Copy link
Contributor

I was able to recreate this issue on an older 17.0.3:

# java -version
openjdk version "17.0.13" 2024-10-15
IBM Semeru Runtime Open Edition 17.0.13.11 (build 17.0.13+11)
Eclipse OpenJ9 VM 17.0.13.11 (build openj9-0.48.0, JRE 17 Linux amd64-64-Bit Compressed References 20241015_886 (JIT enabled, AOT enabled)
OpenJ9   - 1d5831436e
OMR      - d10a4d553
JCL      - d17dd58f8d7 based on jdk-17.0.13+11)

I was using this simplified test:

import java.io.File;
import java.time.*;
import java.util.*;
import javax.net.ssl.*;
import java.security.KeyStore;

public class TestLoad {

    public static void main(String[] args) throws Exception {
        TrustManagerFactory tmf = TrustManagerFactory.getInstance("PKIX");
        tmf.init((KeyStore) null);
        System.out.println("Loaded default TrustManagerFactory factory keystore.");
    }
}

I could recreate the same issue with similar command line arguments using strict fips mode:

# java -Dsemeru.fips=true -Dsemeru.customprofile=OpenJCEPlusFIPS.FIPS140-3 TestLoad.java
Exception in thread "main" java.security.KeyStoreException: problem accessing trust store
	at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:73)
	at java.base/javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:282)
	at TestLoad.main(TestLoad.java:11)
Caused by: java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.
	at java.base/sun.security.util.DerInputStream.getLength(DerInputStream.java:251)
	at java.base/sun.security.util.DerValue.<init>(DerValue.java:444)
	at java.base/sun.security.util.DerValue.<init>(DerValue.java:487)
	at java.base/sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2012)
	at java.base/java.security.KeyStore.load(KeyStore.java:1473)
	at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.loadKeyStore(TrustStoreManager.java:390)
	at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.getTrustedCerts(TrustStoreManager.java:336)
	at java.base/sun.security.ssl.TrustStoreManager.getTrustedCerts(TrustStoreManager.java:57)
	at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:49)
	at java.base/javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:282)
	at TestLoad.main(TestLoad.java:11)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:575)
	at jdk.compiler/com.sun.tools.javac.launcher.Main.execute(Main.java:419)
	at jdk.compiler/com.sun.tools.javac.launcher.Main.run(Main.java:192)
	at jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:132)

I then could "fix" the issue by adding the PKCS12 keystore back into the allowable list of algorithms using this profile to extend the strict fips profile:

# cat profile.pkcs12.java.security
RestrictedSecurity.OpenJCEPlusFIPS.FIPS140-3-withPKCS12.desc.name = OpenJCEPlusFIPS Cryptographic Module FIPS 140-3 with PKCS12 Support
RestrictedSecurity.OpenJCEPlusFIPS.FIPS140-3-withPKCS12.extends = RestrictedSecurity.OpenJCEPlusFIPS.FIPS140-3
RestrictedSecurity.OpenJCEPlusFIPS.FIPS140-3-withPKCS12.jce.provider.2 = sun.security.provider.Sun [+ \
  {KeyStore, PKCS12, *}]
RestrictedSecurity.OpenJCEPlusFIPS.FIPS140-3-withPKCS12.jce.provider.4 = com.sun.crypto.provider.SunJCE [ \
  {AlgorithmParameters, PBES2, *}, \
  {AlgorithmParameters, PBEWithHmacSHA256AndAES_256, *}, \
  {SecretKeyFactory, PBEWithMD5AndDES, *}, \
  {Cipher, PBEWithHmacSHA256AndAES_256, *}, \
  {Mac, HmacPBESHA256, *}]

This fixed the test allowing it to run without error:

# java -Dsemeru.fips=true -Dsemeru.customprofile=OpenJCEPlusFIPS.FIPS140-3-withPKCS12 -Djava.security.properties=./profile.pkcs12.java.security TestLoad.java
Loaded default TrustManagerFactory factory keystore.

I don't believe that this issue is a blocker for .49 at the moment for a few reasons:

  1. We have a workaround if a user runs into this. Almost all users of TLS configure PKCS12 files which we document in our documentation for FIPS 140-3 so the workaround would involve typical configuration used anyway ( making it less likely a user would run into this in strict fips mode ).
  2. I think we should provide a better error message for this error as seen someplace since it wont make much sense to users if they encounter this. However users will still fail here anyway until they configure / allow PKCS12 files even if we provide a better error message.
  3. This behavior / failure has been present in previous releases. This new test however did expose the confusing stack trace.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants