[zvonand]

Changelog category (leave one):

• Not for changelog (changelog entry is not required)

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

...

Documentation entry for user-facing changes

...

CI/CD Options

Exclude tests:

• Fast test
• Integration Tests
• Stateless tests
• Stateful tests
• Unit tests
• Performance tests
• Aarch64 tests
• All with ASAN
• All with TSAN
• All with MSAN
• All with UBSAN
• All with Coverage
• All Regression
• Disable CI Cache

Regression jobs to run:

• Fast suites (mostly <1h)
• Aggregate Functions (2h)
• Alter (1.5h)
• Benchmark (30m)
• CAS (content-addressed storage; Antalya only)
• ClickHouse Keeper (1h)
• Iceberg (2h)
• LDAP (1h)
• OAuth (5m)
• Parquet (1.5h)
• RBAC (1.5h)
• SSL Server (1h)
• S3 (2h)
• S3 Export (2h)
• Swarms (30m)
• Tiered Storage (2h)

[github-actions]

Workflow [PR], commit [e1f5be4]

[zvonand]

@blau-ai

[blau-ai]

CI triage

3 red checks: 0 PR-caused, 1 process (DCO), 1 pre-existing/infra (stateless), 1 roll-up.

This PR is a backport of upstream ClickHouse#126138 — it flips the default of openSSL.client.extendedVerification to true (verify the server cert hostname on outbound TLS) and adjusts a handful of TLS integration test configs. The relevant integration suite (Integration tests (amd_asan, targeted)) is green, as are all builds, unit tests, Fast test, and the asan stateless shards. Nothing here points at the TLS change.

1. Stateless tests (amd_debug, parallel) — Failed: 11 → not PR-caused (infra/slowness)

Every one of the 11 failures is a timeout, not a wrong result:

test	reason
04033_tpc_ds_q49, q72, q75	code 160 TOO_SLOW — "Estimated query execution time (647s) is too long. Maximum: 600"
04033_tpc_ds_q44, q23	code 159 — "Timeout exceeded while receiving data from server. Waited for 300 seconds"
04033_tpc_ds_q14, q09, 00061_storage_buffer, 00154_avro, 03634_autopr_input_bytes_estimation, 03634_autopr_output_bytes_estimation	harness Timeout! (test exceeded its wall-clock budget)

Evidence this is a slow/overloaded amd_debug runner and not a regression:

• The failures span completely unrelated code paths (TPC-DS window queries, Avro IO, Buffer engine, auto-parallel byte estimation) — a real regression doesn't hit all of those at once.
• They are all time failures (TOO_SLOW / receive-timeout / harness timeout), none are result mismatches.
• The same tests pass on the amd_asan stateless shards, and none of them exercise outbound TLS, so the only code change in this PR cannot reach them.
• The suite ran for ~2h with failures smeared across the whole window (15:56→17:45), the classic signature of a backed-up debug runner.

Next step: safe to re-run Stateless tests (amd_debug, parallel); I expect it green on a fresh runner. No PR change needed.

2. DCO — not PR-caused (process)

The single head commit e1f5be4 (upstream merge Revert "Revert "Verify the server certificate hostname...", authored by Alexey Milovidov, committed by @zvonand) has no Signed-off-by: trailer, which is all DCO checks for. This is expected for a cherry-picked upstream merge commit and is unrelated to correctness.

Next step: either add the sign-off trailer, or (as is usual for Altinity backports of upstream commits) have a maintainer override/set-status the DCO check. I did not amend the commit since that rewrites the PR head and you didn't ask for it — say the word if you want me to push an amended, signed-off commit.

3. PR — roll-up gate

This is the aggregate status; it's red only because of the two checks above. It clears once the stateless suite is re-run green and DCO is satisfied/overridden.

Bottom line: nothing is wrong with the change itself — re-run the debug stateless suite and sort out the DCO sign-off, and this should go green.