Chronicle 16.20.0 validates TLS by default, so the CLI can no longer connect to a local server out of the box

[woksin]

Chronicle 16.20.0 inverted the client's TLS default. From its release notes:

Changed — Validate TLS certificates by default; the Development connection string remains the explicit self-signed-certificate opt-out. (Cratis/Chronicle#3606)

Deliberate hardening upstream, and the right default for a client library. But the CLI's default server is a bare connection string with no opt-out, and a development Chronicle serves a self-signed certificate — so on Chronicle ≥ 16.20.0 the commonest workflow in the product stops working until the user hand-edits their connection string.

The default appears with no skipTlsValidation at four places:

• Source/Cli/FirstRunDetector.cs:13 — const string DefaultServer = "chronicle://localhost:35000";
• Source/Cli/Program.cs:23 — var server = ctx.Server ?? "chronicle://localhost:35000";
• Source/Cli/Commands/Chronicle/ChronicleSettings.cs:44
• Source/Cli/Commands/Init/ChronicleDocGenerator.cs:38,42 — the connection string the CLI writes into generated docs for users

Evidence

Bisected against a fixed local server image, so the server side is constant and only the client version moves:

Chronicle client	Integration specs
16.19.1	161/161 pass
16.19.2	161/161 pass
16.19.3	161/161 pass
16.20.0	108 of 161 fail
16.21.0	108 fail
16.22.0	108 fail

All failures are "The SSL connection could not be established". Not flaky and not environmental — a workflow_dispatch of Build on unchanged main passed at the same moment.

Upstream added ?skipTlsValidation=true to its own Development connection-string constant in the same release, which is the shape of the intended opt-out.

The documentation is now wrong in two places

Documentation/reference/connection.md:20:

in development, the server auto-generates a self-signed certificate for localhost and the CLI trusts it automatically — no certificate setup is required to connect to a local server

Documentation/reference/connection.md:26:

skipTlsValidation — ... On by default, which is what lets the CLI trust a development server's self-signed certificate; set it to false to require a valid certificate.

Both describe the pre-16.20.0 behaviour. Whichever way this is resolved, these two need to change.

Why this is not just a version bump

#66 deliberately stopped Chronicle at 16.19.3 rather than taking the current 16.22.0, because carrying this into a minor release would break every out-of-the-box local connection. That pin is a holding position, not a preference — it should be lifted once this is decided.

Options

1. Default skipTlsValidation=true for loopback only — append it to the default connection string when the host is localhost/127.0.0.1/::1, and leave every explicitly-configured server alone. Restores the documented behaviour, keeps the hardening everywhere it matters, stays minor. Loses the protection for a local server, which is where it is worth least.
2. Take the break — require users to add ?skipTlsValidation=true themselves, update both doc sites, and release major. Honest about the change, and matches upstream's intent most literally, but every existing context and every generated doc becomes wrong.
3. Trust the development certificate explicitly — have the CLI recognise and pin the server's auto-generated development certificate rather than skipping validation wholesale. The best end state, and the most work.

Option 1 seems right to me, but this is a security-default question and worth an explicit call rather than a default.

[woksin]

Fixed upstream — no longer reproduces on Chronicle 16.30.1.

Chronicle/Chronicle#3707 merged today (2026-08-13 18:15 UTC) and shipped in v16.30.1: "The .NET client skips TLS certificate validation by default again, so a development server and client connect with no certificate setup on either side." It also fixes the option ambiguity that motivated the original change — skipTlsValidation and Tls.SkipCertificateValidation no longer combine so that an omitted value overrides an explicit one (Chronicle#3606, which is the issue the original hardening cited).

Confirmed in the released code rather than from the release note — Source/Clients/DotNET/Tls.cs at the tag:

public bool SkipCertificateValidation { get; set; } = true;   // v16.30.1
public bool SkipCertificateValidation { get; set; }           // v16.29.1

Tested the workflow this issue is about, because the integration suite would not have proven it: its a_connected_cli fixture connects with a certificatePath, so it passes whatever the default is. Ran the CLI directly against a cratis/chronicle:16.30.1-development container with a bare connection string and no skipTlsValidation, moving only the client version:

client	result
16.30.1	["System"]
16.29.1	Cannot connect to Chronicle server

The three options above are moot — none is needed. And the two documentation statements this issue records as wrong are correct again, since 16.30.1 restores exactly the behavior they describe.

Pin lifted in #68 (patch): 436 unit specs and 161/161 integration specs, the same suite that had 108 failures on 16.20.0. Closing once that merges.

[woksin]

Fixed upstream in Chronicle 16.30.1 (Chronicle/Chronicle#3707) and the pin is lifted in #68, now merged.

Verified in the released code — Tls.SkipCertificateValidation is = true at v16.30.1 and has no initializer at v16.29.1 — and by running the CLI against a cratis/chronicle:16.30.1-development container with a bare connection string and no skipTlsValidation: 16.30.1 answers ["System"], 16.29.1 answers Cannot connect, same server, only the client moving.

None of the three options this issue proposes is needed, and both documentation statements it flags are correct again — 16.30.1 restores exactly the behavior they describe.