CockroachDB gives certificates a directory convention
The April beta replaces individual certificate flags with certs-dir and a filename convention. Insecure mode now needs an explicit flag, and older clusters face a separate upgrade boundary.
Several independently supplied certificate paths can describe a valid set of credentials, but they also create repeated configuration in every command. CockroachDB's April 20 beta introduces a certificate directory and a naming convention to replace those individual flags. The server and client commands can infer each file's role from its name within the selected directory.
The release notes identify --certs-dir as the new interface, with ~/.cockroach-certs as its default. The old individual flags still work in this beta, with removal announced for the next release. Insecure mode also changes, requiring an explicit --insecure flag.
I like operational configuration that makes a deployment's assumptions visible. A named certificate directory reduces repeated command arguments, while an explicit insecure flag records a decision that should be recognizable in a startup command. The convention still needs to define which files are appropriate on each machine.
Filenames identify certificate roles
The contemporary certificate guide specifies ca.crt for the certificate authority certificate, node.crt and node.key for a server, and client.<user>.crt with client.<user>.key for a client identity. These names provide the structure that the directory flag alone would otherwise lack.
The implementation change describes using the configured user to select the client files. The directory is therefore not just a container of arbitrary paths. It is an interface whose filenames and selected username determine which credentials a command loads.
For an already populated directory named certs, the beta provides an inspection command:
cockroach cert list --certs-dir=certs
The guide's output identifies the files by usage and shows the username attached to a client certificate. That makes the convention inspectable without asking a person to reconstruct the meaning of each old flag in every invocation.
Node certificates still need the addresses at which the node can be reached. The generation command takes those addresses explicitly. A shared naming convention does not eliminate the identity information inside the certificate, and distributing files still needs to match the intended node or client.
The CA key remains separate
The certificate guide explicitly says CockroachDB commands never load the CA private key automatically. It recommends creating that key in a separate directory and identifying it with --ca-key when generating certificates. This separates the credentials needed to run a node from the authority needed to issue new identities.
The examples create certificates in one location and distribute the appropriate node and client files afterward. Each node uses the conventional server filenames, so generating another node's certificate in the same working directory requires deliberate overwrite handling. The --overwrite option controls that replacement.
Private-key files must not have group or world permissions. The directory convention therefore does not reduce security to possession of a directory path. File permissions and distribution still determine which process or person can use a private key.
I consider the CA-key separation the most useful part of understanding this interface. A convenient directory should contain the runtime material a command needs. It should not imply that every machine running the database also needs the ability to mint certificates for the cluster.
Certificate replacement gains a reload mechanism
The beta adds reloading of server certificates and keys on SIGHUP. That gives replacement of the files a documented relationship to the running process. Changing a file and causing the server to load its new contents are separate operations, and the new signal behavior connects them.
Some commands that previously required a node certificate can now use the root client certificate. This further distinguishes administrative client work from presenting a node identity. The notes do not say every command accepts every certificate, so the change should retain its stated scope.
Requiring --insecure explicitly also changes existing command lines. A deployment that previously depended on the absence of secure settings must now state the insecure mode. This is a backwards-compatibility issue even for an environment that intentionally operates without certificates.
Cluster-version compatibility is a separate boundary
The release cannot run concurrently with versions older than beta-20170413. An older cluster must first move to that beta or shut down every server before starting any server on the April 20 version. Updating certificate flags does not resolve this mixed-version restriction.
The distinction matters because a deployment can have correct credentials and still attempt an unsupported upgrade sequence. Command configuration and cluster-version compatibility are separate requirements described in the same announcement. Both must hold for the new process to participate as intended.
The beta also changes ^ from bitwise xor to exponentiation, moving xor to # for PostgreSQL compatibility. Existing DEFAULT or CHECK expressions using the old meaning need updating. Alongside the certificate convention, these explicit compatibility notes describe operational and stored-schema assumptions that a new binary cannot safely infer on behalf of the deployment.