[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 [db0beac]

[zvonand]

@blau-ai

[blau-ai]

CI triage — #2671 (backport of ClickHouse#126138, client extendedVerification → true)

Verdict: 4 red checks — 1 is PR-related but trivial (DCO sign-off); the other 3 are pre-existing / flaky / infra and unrelated to the TLS change. Builds, Fast test, all Stateless (13545), Unit (20871) and 7/8 Integration shards are green. This diff only flips the default of the outbound-TLS hostname check and adjusts a handful of SSL test configs; none of the real test failures trace back to it.

1. DCO — ❌ PR-related (process, not code)

The single commit db0beac (Merge pull request #126138 …) has no Signed-off-by: trailer, so the cncf/dco2 check fails. This is the only failure actually attributable to the PR.
Fix (author action): @zvonand re-create the commit with a sign-off and force-push your own branch, e.g. git commit --amend --signoff (or git rebase --signoff antalya-26.8) then git push -f. I can't do this — it needs a history rewrite / force-push on your branch, which is outside my permissions.

2. Integration tests (amd_asan_ubsan, db disk, old analyzer, 5/8) — ✅ not PR-caused

All 21/1286 failures are in one unrelated suite, test_storage_iceberg_with_spark/test_export_partition_iceberg.py. The error is an access-control grant, not TLS:

Code: 497. DB::Exception: default: Not enough privileges. To execute this query,
it's necessary to have the grant SHOW NAMED COLLECTIONS SECRETS ON s3. (ACCESS_DENIED)

This PR touches no access-control / named-collections code and adds no config to the iceberg test. Pre-existing breakage of that Spark/Iceberg suite — safe to re-run / independent of this PR.

3. Regression release — oauth — ✅ not PR-caused

2 of 112 subfeatures failed: /oauth/access control and /oauth/groups. Both are HTTP-status mismatches from the fork's grant model, e.g.:

Expected HTTP status code 500, but got 403. Response body: Code: 497. DB::Exception:
… Not enough privileges … grant CREATE TEMPORARY TABLE ON *.* / SELECT ON system.users (ACCESS_DENIED)

Crucially, /oauth/tls passed — the one subfeature that actually exercises outbound TLS to the IdP is green under the new extendedVerification=true default. So the OAuth failures are pre-existing access-control expectations, not the cert-hostname change.

4. Regression release — swarms — ✅ not PR-caused (flaky/resilience)

Only 4/1535 scenarios failed, all under node-disruption paths: cluster discovery/check cluster discovery with wrong cluster name, node failure/check restart swarm node, node failure/cpu overload, node failure/cpu overload all swarm nodes. The error is a generic connection failure on the plain TCP port 9000 (not the 9440 secure port):

Code: 279. DB::Exception: Cannot connect to any replica for query execution.
(ALL_CONNECTION_TRIES_FAILED)  … s3Cluster('swarm', 'http://minio:9000/…')

Evidence this is not the TLS change:

• Zero certificate verify / Unacceptable certificate lines anywhere in the swarms report.
• 1517/1535 scenarios passed, including ordinary s3Cluster distributed queries — if hostname verification had broken inter-node TLS, every distributed query would fail, not just the 4 that deliberately restart / CPU-starve a node.
• These node-failure scenarios have a history of flaking on Antalya (see closed issue Failure: swarms/node failure/check restart clickhouse on swarm node — consistent failure on Antalya 26.1 #1601, "check restart … swarm node — consistent failure").

Suggested next step: re-run the swarms regression; treat as known resilience-test flakiness.

Bottom line

Re-applying hostname verification itself looks healthy here: the TLS-exercising paths (/oauth/tls, the updated test_accept_invalid_certificate / test_acme_tls / test_bind_host / test_ssl_cert_authentication integration tests, and 1517 swarm distributed queries) are all green. The only thing truly blocking on the PR is the DCO sign-off. The Iceberg, OAuth-access-control and swarms-node-failure reds are pre-existing/flaky and should clear (or persist identically) on a re-run regardless of this change.

_{🤖 blau-ai · evidence: praktika result_pr.json, oauth/swarms regression reports for db0beac.}