Issues after 8u282 -> 8u292 update: "unrecognized algorithm name: PBEWithSHA1AndDESede"

[pnsantos]

I'm not entirely sure if this is a BC issue or something with 8u292 but here goes:

After bumping the Java version to 8u292 our services (vert.x based) failed to start with the following message:

java.security.KeyStoreException: Key protection  algorithm not found: 
  java.security.UnrecoverableKeyException: Encrypt Private Key failed: 
    unrecognized algorithm name: PBEWithSHA1AndDESede

From what I could tell this happened while setting up the pem cert files for the HTTPS server.

Services are using bcprov-jdk15on:168 and we were doing Security.addProvider to add BC.

I was able to confirm that:

• Even not adding BC as a provider, just by it being in the classpath the above error occurs
• If BC is inserted above JSSE provider then the problem goes away
• I went back on BC versions and once I reached 1.56 the issue no longer happened (from 1.57 up to 1.68 has the same issue)
• I am using Zulu JDK distribution, problem happens in both the glibc (Zulu 8.54.0.21-CA-linux64) and musl (Zulu 8.54.0.21-CA-linux-musl-x64) variant. As mentioned all version leading up to 8u282 had no such issue.

Another (might be unrelated) issue happened when BC was added before the SUN provider (pos 1). While using postgresql jdbc driver to connect to postgres using TLS, the driver would "hang" while switching to an SSL socket taking as much as 45s to connect (it would eventually succeed). When BC is added after the SUN provider then the switch happens in under 1s.

Like I mentioned in the beginning it's a bit hard tell whether this is a BC issue or one (or more) issues with vertx/postgresql or even some issue with the Java update... so I though I'd posted here first.

[hofmandl1]

Hi, we have just hit the same problem.

OpenJdk is from here https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u292-b10/OpenJDK8U-jre_x64_linux_8u292b10.tar.gz
Also reproduced with the correpsonding Windows build.

We have a reproducer that seems to indicate, that the problem is caused by a race condition because it sometimes works and sometimes it doesn't.

Exception in thread "main" java.security.KeyStoreException: Key protection  algorithm not found: java.security.UnrecoverableKeyException: Encrypt Private Key failed: unrecognized algorithm name: PBEWithSHA1AndDESede
	at sun.security.pkcs12.PKCS12KeyStore.setKeyEntry(PKCS12KeyStore.java:677)
	at sun.security.pkcs12.PKCS12KeyStore.engineSetKeyEntry(PKCS12KeyStore.java:577)
	at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
	at TestJavaMain.main(TestJavaMain.java:65)
Caused by: java.security.UnrecoverableKeyException: Encrypt Private Key failed: unrecognized algorithm name: PBEWithSHA1AndDESede
	at sun.security.pkcs12.PKCS12KeyStore.encryptPrivateKey(PKCS12KeyStore.java:921)
	at sun.security.pkcs12.PKCS12KeyStore.setKeyEntry(PKCS12KeyStore.java:614)
	... 3 more
Caused by: java.security.NoSuchAlgorithmException: unrecognized algorithm name: PBEWithSHA1AndDESede
	at sun.security.x509.AlgorithmId.get(AlgorithmId.java:448)
	at sun.security.pkcs12.PKCS12KeyStore.mapPBEAlgorithmToOID(PKCS12KeyStore.java:938)
	at sun.security.pkcs12.PKCS12KeyStore.encryptPrivateKey(PKCS12KeyStore.java:895)
	... 4 more

We are pretty sure it is caused by a problem that was fixed for Java9 and is still unfixed for Java8:
Java9-issue: https://bugs.openjdk.java.net/browse/JDK-8156584
Linked Backport-Issue: https://bugs.openjdk.java.net/browse/JDK-8157190

[hofmandl1]

We were able to reproduce our issue without bouncycastle being involved at all (not even lying unused in the classpath).
Executing this regularly in eclipse (with the affected Java-Version) works.
Executing this in debug-mode in eclipse (with the affected Java-Version) produces the stacktrace from above.

TestJavaMain.txt

[hofmandl1]

We have filed a new bug here https://bugreport.java.com/bugreport/ which oracle is currently reviewing :-/ Their internal review ID is 9070059.

[anorimaki]

I am having the same problem.

It seems that sun.security.x509.AlgorithmId.oidTable is being initialized when verifying the BC jar signature. Jar signature verification algorithm changes the registered Providers for the thread during its execution by a limited list ("sun.security.provider.Sun", "sun.security.rsa.SunRsaSign", "sun.security.ec.SunEC", "sun.security.provider.VerificationProvider"). Therefore, the AlgorithmId.oidTable is initialized based on a limited subset of the available Providers.

As a workarround, I call AlgorithmId.get("PBEWithSHA1AndDESede") before using any class that depends on BC to initialze AlgorithmId.oidTable before the BC jar signature verification occurs.

[hofmandl1]

Hi, looks like we got an official bug-id from oracle for this one: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8266261

@anorimaki your workaround does not work in our case (where no bouncycastle is involved at all) also sun.security.x509.AlgorithmId is not an official stable API I suppose?

[anorimaki]

@hofmandl1 true, it is not an official API. new EncryptedPrivateKeyInfo("PBEWithSHA1AndDESede", new byte[] { 0 }); should work also where the workaround can be applied (from https://bugs.openjdk.java.net/browse/JDK-8266279).

[lauredogit]

@hofmandl1 you can fix your issue by editing your java.security file and configuring a stronger algorithm for PKCS#12 and the SUN Provider.
For example:
keystore.pkcs12.keyProtectionAlgorithm=PBEWithSHA512AndAES_256

This is happening in sun.security.pkcs12.PKCS12KeyStore

[jy-git]

.

[splix]

I've a workaround like @lauredogit suggested, but PBEWithSHA512AndAES_256 didn't work for me too, so I've used PBEWithHmacSHA256AndAES_256.

In general it supposed to be java -Dkeystore.pkcs12.keyProtectionAlgorithm=PBEWithHmacSHA256AndAES_256 ...

But in my case it was a Gradle unit test, so I've used following to pass java system properties:

test {
    systemProperty "keystore.pkcs12.keyProtectionAlgorithm", "PBEWithHmacSHA256AndAES_256"
}

[gatman]

setting
keystore.pkcs12.keyProtectionAlgorithm=PBEWithHmacSHA256AndAES_256
in the java security worked for me on RHEL 7

Many thanks guys!

[swxEmily]

I think this related to https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8266290
Because SignerInfo.java is changed in 8u292:

It call AIgorithmId.get() function, which will initial oidTable.
During jar verify, Providers.getThreadProviderList() is not null, it only has 4 jar verified providers.
It cause oidTable in AlgorithmId is lack.
http://cr.openjdk.java.net/~martin/webrevs/jdk8/AlgorithmId-get-race/AlgorithmId-get-race.patch can not fix this problem.