Generate test keystore in jsptest and multipleApps so HTTPS tests pass standalone#26032
Merged
Conversation
…s standalone Since 6b062d0 ("Removed nonexisting keystore.jks and cacerts.jks", Jun 2025) the embedded GlassFish artifacts no longer ship the s1as keystore. The maven-plugin embedded HTTPS tests therefore have no usable server keypair: SecuritySupport falls back to an empty in-memory KeyStore, JSSE cannot present a certificate for the s1as alias, and the TLS 1.3 handshake aborts with HANDSHAKE_FAILURE. The client (jsptest, multipleApps) sees "Remote host terminated the handshake". CI masked this for ~10 months because secureWebApp runs first in the shared Maven JVM and its src/test/resources/system.properties sets javax.net.ssl.keyStore to a pre-generated testkeystore.p12 via the embedded plugin's <systemPropertiesFile>. The system property leaks into the same JVM and rescues every later embedded HTTPS test - but only when they run together. Running jsptest or multipleApps standalone fails. Fix: give each affected module its own keystore the same way secureWebApp already does it. - src/test/resources/system.properties points javax.net.ssl.keyStore and trustStore at target/testkeystore.p12, with property filtering so ${project.build.directory} expands. - pom.xml wires the file into the embedded plugin via <systemPropertiesFile> and pulls in glassfish-jdk-extensions and test-utils as test deps for KeyTool / JUnitSystem. - JspTest.createKeyStore() generates a fresh PKCS12 s1as keypair under @BeforeAll, mirroring SecureWebAppTest.createKeyStore. Supersedes PR eclipse-ee4j#26031, which attempted to fix the same handshake failure by generating an s1as keypair inside EmbeddedGlassFishRuntime at every embedded JVM start. Reviewers pushed back on auto-generating certificates in the runtime: embedded GlassFish should not ship or synthesize a private key, production users are expected to supply their own keystore, and a CN=localhost self-signed cert is worthless anyway. Confining the fix to the test modules that actually need it leaves the runtime untouched and matches the existing convention in secureWebApp. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
OndroMih
approved these changes
May 14, 2026
arjantijms
approved these changes
May 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Since 6b062d0 ("Removed nonexisting keystore.jks and cacerts.jks", Jun 2025) the embedded GlassFish artifacts no longer ship the s1as keystore. The maven-plugin embedded HTTPS tests therefore have no usable server keypair: SecuritySupport falls back to an empty in-memory KeyStore, JSSE cannot present a certificate for the s1as alias, and the TLS 1.3 handshake aborts with HANDSHAKE_FAILURE. The client (jsptest, multipleApps) sees "Remote host terminated the handshake".
CI masked this for ~10 months because secureWebApp runs first in the shared Maven JVM and its src/test/resources/system.properties sets javax.net.ssl.keyStore to a pre-generated testkeystore.p12 via the embedded plugin's . The system property leaks into the same JVM and rescues every later embedded HTTPS test - but only when they run together. Running jsptest or multipleApps standalone fails.
Fix: give each affected module its own keystore the same way secureWebApp already does it.
Supersedes PR #26031, which attempted to fix the same handshake failure by generating an s1as keypair inside EmbeddedGlassFishRuntime at every embedded JVM start. Reviewers pushed back on auto-generating certificates in the runtime: embedded GlassFish should not ship or synthesize a private key, production users are expected to supply their own keystore, and a CN=localhost self-signed cert is worthless anyway. Confining the fix to the test modules that actually need it leaves the runtime untouched and matches the existing convention in secureWebApp.