rqlite CLI queries can trust a supplied certificate authority
rqlite 4.5.0 lets SQL requests use a supplied root CA file. The implementation creates a dedicated trust pool, with a separate diagnostic request path that does not yet use it.
A private certificate authority creates a practical problem for a database command-line client. The server can provide an encrypted HTTPS endpoint, but the client still needs a reason to trust its certificate. rqlite 4.5.0, released on 25 April, adds a root CA option to the CLI. SQL requests can now verify the server using a supplied certificate file.
The useful change is preserving verification when the deployment's authority is absent from the machine's default trust set. The CLI already has an insecure option that disables HTTPS certificate verification. Supplying a root establishes the authority the client should accept while leaving verification enabled. These settings express different policies even when both permit a connection to complete.
I value rqlite's compact deployment model, but the client still needs to fit the deployment's trust model. A small replicated database can use an organization-specific CA without requiring an operator to disable server verification for routine SQL access. A file argument is a practical way to make that trust choice explicit for the client invocation.
The CA file becomes a root pool
The 4.5.0 CLI source defines --ca-cert, with -c as its short form, as a path to a trusted X.509 root CA certificate. It retains --scheme for choosing HTTP or HTTPS and --host for the destination. An illustrative invocation is therefore:
rqlite --scheme https --host database.example --ca-cert ./root-ca.pem
The example assumes the hostname and certificate file belong to the intended deployment. Supplying the CA path does not itself switch the protocol from the default HTTP scheme. The scheme remains a separate option, so using HTTPS must be part of the invocation when certificate verification is required.
Before sending SQL, the client reads the file and creates a new x509.CertPool. It appends certificates parsed from the PEM data, then assigns that pool to the TLS configuration's RootCAs field. A file-read failure returns an error. A file from which no certificates can be appended produces a specific root-certificate parsing error.
The dedicated pool has an operational consequence. This implementation starts with NewCertPool. It does not load the system pool and then append the file. According to the Go 1.12.3 TLS configuration documentation, a nil RootCAs uses the host's root set. A supplied non-nil pool instead defines the client's roots. The flag should not be described as automatically extending every machine-trusted authority.
Trusting a root preserves identity checks
The Go TLS documentation distinguishes the trusted root set from InsecureSkipVerify. That switch disables certificate-chain and hostname verification. The new rqlite argument configures roots while the insecure flag remains false by default. The client can therefore accept a privately issued server certificate through verification, provided the connection satisfies the normal TLS requirements.
The distinction matters if a certificate chains to the supplied root but names a different server. Trusting an issuer is not an instruction to ignore server identity. Keeping verification enabled retains the hostname check described by the TLS configuration. An operator should choose the hostname that the server certificate is intended to identify.
This client-side setting also has a narrower scope than configuring the database cluster. The release-pinned security documentation separates HTTPS access from node-to-node encryption. The CLI communicates through the API endpoint. It does not configure the certificates or trust rules used between Raft nodes merely by loading a root for its own HTTP client.
Redirected SQL uses the same client
The SQL request helper constructs its HTTP client with the supplied root pool before entering its redirect loop. It explicitly handles permanent redirects and posts to the returned location with that same client. Consequently, SQL redirected to a leader retains the trust configuration selected for the original request.
That behavior also constrains certificate deployment. The redirected destination must be acceptable to the same client configuration. Trusting the first endpoint does not justify accepting any certificate at a later endpoint. The helper preserves its TLS policy while following leadership redirection, which is the relevant behavior for a clustered database client.
Diagnostics use another request path
The source reveals a limitation worth stating precisely. The .status and .expvar commands use a separate cliJSON helper. In this release that helper creates its TLS configuration with the insecure setting but does not load the new CA file. SQL requests and diagnostic requests therefore do not have identical custom-root support in 4.5.0.
I prefer to describe the implementation at that level because a successful verified SQL query does not prove that every CLI command uses the same trust pool. The release improves the SQL request path. The distinct diagnostic helper remains relevant when an operator checks the same privately certified node through .status or .expvar.