Java 26 EA Test Failures.

[prbprbprb]

See, e.g. https://github.com/google/conscrypt/actions/runs/22361936139/job/64721730265?pr=1484 where 226 tests fail.

These fall into two categories:

1. Java 26 newly adds a bunch of certificate checks in the paths of SunX509KeyManagerImpl.chooseServerAlias() (and all the other alias choosing functions) and the test certificates and keys which are generated on the fly for TestKeyStore using Bouncy Castle fail these checks. The correct fix is to figure out which check(s) are failing and fix the test certificate generation, but as these checks are likely not failing for any real, production certs then it makes sense to temporarily disable these checks during testing only by setting the java property jdk.tls.SunX509KeyManager.certChecking to false in the OpenJDK test suite. This would make 224 of the 226 failures pass.

2. The same alias chooser methods now return null when asked for a key of type EC_EC, which breaks the other two failing tests. This feels like an upstream regression introduced in the change which caused (1) because this style of naming (<key type>_<signature type>) is still very much listed in the Java 25 JCA Standard Names document and the change makes no reference to deprecating them. It might make sense to disable testing for this key type until it is determined if this is a regression or not, otherwise landing Add more JDK versions to CI #1484 will break CI for everyone.

[prbprbprb]

FWIW the root cause to (1) is somewhat hilarious: The extra checks in Java 26 ensure that any certificate returned by a KeyManager uses a signature algorithm that the peer supports. But Conscrypt's ExtendedSSLSession.getPeerSupportedSignatureAlgorithms() returns a hard coded list. Of SHA1withRSA and SHA1withECDSA.........

(2) does indeed look like an upstream bug, but only affects EC_EC (not other compound signature types) and only affects self signed certificates and probably only affects tests as nothing in the SSLEngine implementation ever uses EC_EC.

[miguelaranda0]

Thanks Pete! I spoke with Liam and we're filing an upstream bug, I'm working through the other issues and will hopefully get a fix out soon

[prbprbprb]

For (1), a short term, "doesn't make anything worse" fix is just to update the hard coded lists to something modern.

I was going to take a crack at reading the list from BoringSSL but probably not for a few days, so I won't if you have another plan.

[cushon]

Thanks Pete!

+1!

we're filing an upstream bug

I filed https://bugs.openjdk.org/browse/JDK-8379191 for (2), let me know if I mischaracterized anything and I can update the report.

[miguelaranda0]

I was going to take a crack at reading the list from BoringSSL but probably not for a few days, so I won't if you have another plan.

Yeah I'm trying to work on the plumbing for that (but I've had a few stops and starts this week)

[prbprbprb]

I filed https://bugs.openjdk.org/browse/JDK-8379191

❤️

FWIW I have a standalone repro (well Claude did it) that doesn't depend on Conscrypt's TestKeyStore, happy to share.

Basically when J26 is checking, it splits on the underscore and expects the second part to match the "With" part of the signature algorithm, so when you have SHA256WithECDSA it'll end up matching EC against ECDSA and fail.

It's kind of a throwback to early EC days, because nowadays if the private key is EC then the signature algorithm is pretty much always going to be SomethingWithECDSA, so people just use EC.

And for clarity my comment about only affecting tests because not used in SSLEngine was scoped to Conscrypt only I have no idea about upstream SSLEngine, i.e. it wouldn't be a big deal if Conscrypt skipped testing for EC_EC key types until this is resolved.

[cushon]

Thanks! If you want to share the repro that might be helpful upstream, I started looking at including equivalent logic from TestKeyStore for the test to avoid depending on conscrypt and gave up :)

[prbprbprb]

Turns out Claude's code was a bit rubbish so I rewrote it...

https://gist.github.com/prbprbprb/659e551d41812069f8e305fd1aee7c56

[cushon]

There's a pending fix for (2) in openjdk/jdk#30064

[prbprbprb]

Nice quick response, but I did leave a nitty comment on it :)