[test-failed]: X-Pack API Integration Tests1.x-pack/test/api_integration/apis/fleet/unenroll_agent·ts - apis Fleet Endpoints fleet_unenroll_agent "before each" hook for "allow to unenroll using a list of ids"

[liza-mae]

Version: 7.9.0
Class: X-Pack API Integration Tests1.x-pack/test/api_integration/apis/fleet/unenroll_agent·ts
Stack Trace:
{ ConnectionError: self signed certificate in certificate chain
at ClientRequest.request.on.err (/var/lib/jenkins/workspace/elastic+estf-cloud-kibana-tests/JOB/xpackExt/TASK/saas_run_kibana_tests/node/linux-immutable/ci/cloud/common/build/kibana/node_modules/@elastic/elasticsearch/lib/Connection.js:107:18)
at TLSSocket.socketErrorListener (_http_client.js:401:9)
at emitErrorNT (internal/streams/destroy.js:91:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
at process._tickCallback (internal/process/next_tick.js:63:19)
name: 'ConnectionError',
meta:
{ body: null,
statusCode: null,
headers: null,
warnings: null,
meta:
{ context: null,
request: [Object],
name: 'elasticsearch-js',
connection: [Object],
attempts: 3,
aborted: false } } }
Test Report: https://internal-ci.elastic.co/view/Stack%20Tests/job/elastic+estf-cloud-kibana-tests/495/testReport/

[elasticmachine]

Pinging @elastic/kibana-test-triage (failed-test)

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[delvedor]

Hello! It looks like you are using a self-signed certificate in the test environment, and this is causing the Elasticsearch Node.js client to fail. You should either add rejectUnauthorized: false in the ssl configuration or put process.env.NODE_TLS_REJECT_UNAUTHORIZED = 0 at the top of your test file.

This is valid also for #72180 #72181 #72194 #72195 #72196

[liza-mae]

Thanks @delvedor I tested it with that option set and it worked, why do these specific tests need this setting? Looks like the other API tests are working without it.

[spalger]

@delvedor I think it's misleading to imply that the only "solution" is to disable TLS authorization. Turning off authorization is a work around, not a solution.

[liza-mae]

Thanks @spalger for clarifying - I am going to revert my change so we don't mask this failure.

cc: @legrego @jportner

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[liza-mae]

@legrego if this test is catching a TLS misconfiguration on cloud we need to investigate it.

[liza-mae]

Checking first with fleet team to see if there isn't something incorrect on their side first.

[liza-mae]

cc: @nchaulet to look at the tests.

[nchaulet]

I am able to have a repro locally and looks like I am able to fix the test by commenting this line https://github.com/elastic/kibana/blob/master/test/common/services/elasticsearch.ts#L32

I do not think it's a ingest manager specific problem

[liza-mae]

I am not familiar with this setup.

@spalger why would commenting out this line fix the problem?

kibana/test/common/services/elasticsearch.ts

Line 32 in 1f155de

ca: fs.readFileSync(CA_CERT_PATH, 'utf-8'),

[spalger]

Looks like this line was added in #65598 with the assumption that the only time the elasticsearch client is used with https urls will be when using our local certificates.

[elasticmachine]

Pinging @elastic/kibana-operations (Team:Operations)