rqlite brings HTTPS connections to its command-line client

A secured database endpoint needs clients that can use its transport. rqlite already supports an HTTPS API, but the interactive command-line tool needs the corresponding connection controls to remain useful after an operator enables it. rqlite 3.8.0, released on 15 December, adds CLI access to secured nodes.

The release-tagged changelog attributes that work to pull requests 232 and 233. The concrete interface in this version is a scheme option and an explicit option to skip HTTPS certificate verification. This is a client transport change. It does not introduce HTTPS to the server for the first time or encrypt the separate Raft connection between nodes.

I value rqlite's small operational footprint, and a usable command-line client contributes to that. Securing the API should not force ordinary interactive queries into a separate improvised HTTP workflow. The client still needs to make the distinction between encrypted transport and verified server identity visible.

Selecting the API transport

The 3.8.0 CLI source defines --scheme with a default of http. It also accepts --host, --port and an HTTP URL prefix. A connection to an HTTPS endpoint can therefore select the protocol while retaining the ordinary host and port controls.

rqlite --scheme https --host db.example.com --port 4001

This example assumes a node already serves HTTPS on that address and presents a certificate the client can verify. It is a client invocation, not a command that enables server-side TLS. The server's certificate and private key configuration remain separate concerns.

The scheme option also has a short form, -s. Its meaning is the protocol scheme, rather than a general declaration that every connection in the cluster is secure. rqlite exposes distinct interfaces, and choosing HTTPS here affects the path between this client and the HTTP API.

The release's security documentation describes HTTPS as encrypting communication between clients and the cluster. It also describes a second TCP port for intra-cluster traffic. The distinction prevents a misleading inference that enabling HTTPS on the API changes how the Raft subsystem communicates.

Verification is the default

The new --insecure option defaults to false. When constructing its HTTP transport, the client sets the TLS configuration's InsecureSkipVerify field from that option. Certificate verification therefore remains enabled by default.

This matters because an encrypted connection and an authenticated server are related but different properties. Skipping verification changes what the client checks about the endpoint it reached. The option makes that choice explicit in the invocation instead of silently relaxing the checks whenever HTTPS is selected.

The source does not expose a separate custom-CA-file flag in this version's argument structure. A description of 3.8.0 should therefore avoid importing connection options from another release. Its actual controls are enough to explain the new capability without suggesting a certificate-management interface that is absent from the tagged client.

I prefer the verified default because the ordinary command can express the intended connection without an exception flag. The escape hatch remains visible for situations where the operator chooses it, but its presence should not be confused with a requirement for every HTTPS connection.

Leader forwarding remains part of the client

The CLI documentation says that users can connect to any node and the client forwards requests to the leader when necessary. The client source implements an explicit redirect loop for HTTP 301 responses. It obtains the next URL from the response's Location header and repeats the POST.

The request body is a JSON array containing the entered SQL statement. Redirecting preserves that body by constructing the request again. The client limits leader redirections to 21 and reports an error if that limit is exceeded. This prevents an unbounded forwarding loop from becoming an indefinitely waiting interactive operation.

TLS handling therefore belongs to a client that may contact more than the first address supplied at startup. A redirect identifies another HTTP endpoint, and the configured transport handles the resulting request. The release combines secured connections with the existing leader-aware workflow instead of making users select the leader manually for each statement.

API security has separate controls

The security guide at the release tag also describes Basic Auth and per-user permissions. Those permissions distinguish query access from execution, backups and cluster membership operations. They answer a different question from the scheme option. Transport chooses how a client reaches a node, while permissions determine which operations an authenticated user may perform.

Authentication configuration is local to each node in this version. The guide explicitly says to configure it correctly on every node. A cluster-level data model does not make those configuration files automatically replicated policy. This remains relevant when the CLI follows a leader redirect to another member.

Version 3.8.0 also corrects error reporting during backups and adds support for observing Raft changes. Those are separate operational improvements in the same release. The CLI change specifically restores interactive access when the API uses HTTPS, with verification enabled by default and an explicit control for choosing otherwise.