Add OpenSSL verification modes and certificate handlers reference (DOC-134)

[dhtclk]

Summary

EXPERIMENTAL

• Adds a reference section to the TLS configuration guide documenting all verificationMode options and invalidCertificateHandler names
• Includes complete XML examples for disabling certificate verification across clickhouse-client, clickhouse-server, and Keeper
• Mentions the --accept-invalid-certificate CLI shortcut

Verification

Only Verified with CLAUDE:
All technical claims verified against ClickHouse source code:

Claim	Source	Confidence
4 verification modes (none, relaxed, once, strict)	base/poco/NetSSL_OpenSSL/src/Utility.cpp	High
once behaves as relaxed on client side	Poco::Net::Context upstream docs	High
Only Accept and Reject handlers exist	ClickHouse Poco fork (ConsoleCertificateHandler removed)	High
Handler works in both <server> and <client>	base/poco/NetSSL_OpenSSL/src/SSLManager.cpp	High
--accept-invalid-certificate flag	programs/client/Client.cpp	High
No ClickHouse-level restrictions on Poco	Searched src/ for additional validation — none found	Medium

Closes DOC-134

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
clickhouse-docs	Ready	Preview, Comment	Mar 23, 2026 5:11pm
clickhouse-docs-jp	Building	Preview, Comment	Mar 23, 2026 5:11pm

3 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
clickhouse-docs-ko	Ignored	Preview	Mar 23, 2026 5:11pm
clickhouse-docs-ru	Ignored	Preview	Mar 23, 2026 5:11pm
clickhouse-docs-zh	Ignored	Preview	Mar 23, 2026 5:11pm

[Blargian]

@dhtclk I find asking the LLM for verification is often unreliable. Did you cross check using a different LLM to verify?

[dhtclk]

@Blargian - I did not do that in this case, I'll follow up with manual validation and validating with a different LLM.

[Blargian]

@dhtclk This one has been open for some time. Could you check the claims using Copilot CLI and/or test the claims so we can merge

[dhtclk]

@Blargian — second-LLM re-verification against ClickHouse source and a Docker runtime via copilotCLI. It looks good to go from my perspective.

Claim	Status	Citation
4 verification modes (none,relaxed,once,strict)	VERIFIED	base/poco/NetSSL_OpenSSL/src/Utility.cpp:25-41; include/Poco/Net/Context.h:60-95
once semantics (server: initial-only; client: same as relaxed)	VERIFIED	include/Poco/Net/Context.h:89-95
Only Accept/Reject handlers present in vendored Poco	VERIFIED	base/poco/NetSSL_OpenSSL/src/CertificateHandlerFactoryMgr.cpp:24-28 (no ConsoleCertificateHandler found)
Handlers apply on server & client sides	VERIFIED	include/Poco/Net/InvalidCertificateHandler.h:59-63; AcceptCertificateHandler.cpp
--accept-invalid-certificate sets AcceptCertificateHandler + verificationMode=none	VERIFIED (source + runtime)	programs/client/Client.cpp:292-296,828-831; Docker runtime test
Examples for clickhouse-client/server/Keeper are consistent	VERIFIED (source + runtime)	programs/server/config.xml; programs/keeper-client/KeeperClient.cpp:639-647; Docker runtime test
ClickHouse-level restrictions on these Poco options	PARTIAL	No restricting code found in repo search (base/poco, programs/*); runtime Docker test succeeded — cannot prove a global negative exhaustively

Potential gap

• Minor Poco message mismatch: Utility.cpp throws an InvalidArgumentException message that omits "none" even though code accepts it (Utility.cpp:36-39).

Runtime repro (what was run)

• Started clickhouse/clickhouse-server in Docker with mounted config + certs + users.xml, then:
  clickhouse-client --secure --user default --password pass --host localhost --port 9440 --accept-invalid-certificate -q "SELECT 1" → returned 1

Artifacts & timestamp

• Source checks and Docker test performed 2026-05-07. Logs/artifacts: /tmp/ch_docker_test.9tko