TLS and certificates

The PKI the first node creates, TLS on the client port and mutual TLS between nodes.

TeselaDB encrypts all traffic from the first start, with its own implementation of TLS 1.3 and X.509.

Requirements

To use your own certificates, their PEM files on each node.
To rotate them, access to teseladb admin on the node.

The cluster PKI

The first node creates a certificate authority (pki/ca.pem) and its certificate (pki/node.pem). Each node that joins with a token receives a certificate signed by that CA. Between nodes only TLS 1.3 with certificates on both ends is spoken: a node without a certificate from the CA cannot talk to the cluster.

Client port

The client port requires TLS (--tlsMode requireTLS by default) and accepts TLS 1.2 and 1.3. To use your own certificates on that port, for example those signed by your corporate CA, you pass teseladb start the same TLS options that MongoDB uses:

Shell

teseladb start --tlsCertificateKeyFile /etc/teseladb/server.pem --tlsCAFile /etc/teseladb/ca.pem

With --tlsCAFile, the node asks for a client certificate; --tlsAllowConnectionsWithoutCertificates lets clients without one in. --tlsCRLFile rejects revoked certificates.

Rotate certificates

Shell

teseladb admin cert rotate

or db.adminCommand({ rotateCertificates: 1 }) to reload the configured files. Neither restarts the node.

Check

openssl s_client -connect node-01:27017 -CAfile ca.pem shows the protocol and the certificate the node presents on the client port.

Common problems

A node does not join the cluster because its certificate is not signed by the cluster CA. Between nodes only that CA is valid.
Clients without a certificate cannot connect when you start with --tlsCAFile. Add --tlsAllowConnectionsWithoutCertificates if you do not want to ask them for one.