[CI] SSLConfigurationReloaderTests testReloadingKeyStore failing #108774
Assignees
Labels
needs:risk
Requires assignment of a risk label (low, medium, blocker)
:Security/Security
Security issues without another label
Team:Security
Meta label for security team
>test-failure
Triaged test failures from CI
Comments
cbuescher
added
:Security/Security
elasticsearchmachine
added
Team:Security
|
Pinging @elastic/es-security (Team:Security) |
|
Muting this since I've also seen this fail earlier today: https://gradle-enterprise.elastic.co/s/skv7lgzrvktq6/tests/task/:x-pack:plugin:core:test/details/org.elasticsearch.xpack.core.ssl.SSLConfigurationReloaderTests/testReloadingKeyStore?top-execution=1 |
parkertimmins
pushed a commit
to parkertimmins/elasticsearch
that referenced
this issue
May 17, 2024
|
I can reliable reproduce with Java 23, but not Java 22
To avoid some misleading warnings, rule out the security manager, and provide better logging here is a better reproduction line:
fails with Java 23, but works with Java 22. Java 22 (works)Java 23 (fails)I am pretty clueless to what the root cause may be. It is either an issue with out MockWebServer which delegates down to com.sun.net.httpserver.HttpsServer or an issue with apache http client. I ran another test that uses the MockWebServer with HTTPS and it worked..so I am pretty clueless but take another look soon. |
|
I can get the test to pass in Java23 by changing: --- a/x-pack/plugin/core/src/test/java/org/elasticsearch/xpack/core/ssl/SSLConfigurationReloaderTests.java
+++ b/x-pack/plugin/core/src/test/java/org/elasticsearch/xpack/core/ssl/SSLConfigurationReloaderTests.java
@@ -130,7 +130,7 @@ public class SSLConfigurationReloaderTests extends ESTestCase {
// Load HTTPClient only once. Client uses the same store as a truststore
try (CloseableHttpClient client = getSSLClient(keystorePath, "testnode")) {
final Consumer<SSLContext> keyMaterialPreChecks = (context) -> {
- try (MockWebServer server = new MockWebServer(context, true)) {
+ try (MockWebServer server = new MockWebServer(context, false)) {
server.enqueue(new MockResponse().setResponseCode(200).setBody("body"));
server.start();
privilegedConnect(() -> client.execute(new HttpGet("https://localhost:" + server.getPort())).close());So, the problem with the test is that in Java23 we are wiring up an apache http client to a mock web server with mutual TLS and for some reason the mock web server does not trust the apache http client. It isn't clear if mTLS is intentional with this test since it really is not an important detail of what is being tested. It also not clear if it worked because the mock web server and apache http client are configured correctly for mTLS or just happened to work in the past. We tend to conflate key and trust stores, so maybe we aren't wiring up mTLS correctly and are relying on a Java bug (pre java 23) for this to work? I'll keep chipping away, but starting to gain more confidence this is not a production concern. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Seems to be related to JDK23 somehow, although I don't see any direct indication in the logs and the failure.
Build scan:
https://gradle-enterprise.elastic.co/s/ml2fwj3ywiafc/tests/:x-pack:plugin:core:test/org.elasticsearch.xpack.core.ssl.SSLConfigurationReloaderTests/testReloadingKeyStore
Reproduction line:
Applicable branches:
main
Reproduces locally?:
Yes
Failure history:
Failure dashboard for
org.elasticsearch.xpack.core.ssl.SSLConfigurationReloaderTests#testReloadingKeyStoreFailure excerpt:
The text was updated successfully, but these errors were encountered: