How To Create Security Certificates Using OpenSSL

Securing a distributed database requires more than a single TLS certificate. To create security certificates using OpenSSL for a YugabyteDB cluster, you’ll need a certificate authority, individual node certificates, and optionally client certificates, each serving a distinct role in the trust chain.

This article covers what each certificate type does, how the generation process works, and what to know before deploying to a production cluster.

What Are Security Certificates and Why Does a Distributed Database Need Them?

A TLS certificate does two things: it authenticates identity, and it enables encrypted communication. In a distributed SQL database, that matters in two directions. 

• Node-to-node encryption protects inter-cluster traffic between YB-Master and YB-TServer nodes. 
• Client-to-node encryption protects the connection between your applications and the database.

A private Certificate Authority (CA) is the right approach for both. Internal cluster communication doesn’t need a publicly trusted certificate. A private CA gives you control over signing, validity periods, and revocation without depending on an external provider.

What Types of Certificates Does a YugabyteDB Cluster Need?

Three certificate types form the trust hierarchy for a YugabyteDB deployment:

1. CA certificate: The root of trust. All node and client certificates are signed by the CA, and every party in the cluster trusts it. The CA private key must stay on the machine where it was generated and should never be copied to any node.
2. Node certificates: One per node, used for node-to-node encryption and server-side authentication in client-to-node connections. Each certificate must include the node’s IP address or hostname in the Subject Alternative Name (SAN) field. A three-node cluster requires three separate node certificates.
3. Client certificates: Required when mutual TLS (mTLS) is configured. A client certificate authenticates the connecting application or user to the database. The Common Name (CN) maps directly to the YSQL username.

How Do You Generate Certificates With OpenSSL for a YugabyteDB Cluster?

Certificate generation follows three phases. For the complete procedural walkthrough with exact command sequences, see the YugabyteDB server certificates docs.

Phase 1: Generate the CA Key and Certificate

Use openssl genrsa to generate the CA private key, then openssl req with the -x509 flag to produce a self-signed CA certificate. A ca.conf file defines the CA policy: organization name, signing policy for node and client certificates, and certificate validity period. YugabyteDB’s recommended setup uses SHA-256 and explicitly excludes MD5.

Phase 2: Generate Node Certificates

For each node, generate a private key and a CSR with the node’s IP address in the CN or SAN. Use openssl ca to sign each CSR with the CA key and produce a signed node certificate. In a three-node cluster, run this process once per node.

Phase 3: Generate Client Certificates (if Using mTLS)

Generate a client private key and CSR. Set the CN to the YSQL username this certificate will authenticate. Sign with the CA using openssl ca. Distribute the resulting .key and .crt files to the connecting client.

After generation, verify each certificate with openssl verify -CAfile ca.crt <cert-file> before deployment.

Where Do the Certificate Files Need To Go on Each Node?

Each node needs three files in its tls-cert directory: the node certificate, the node private key, and the CA certificate. The CA private key goes nowhere near the nodes. After signing is complete, store it in a secure, offline location. See the server certificates docs for exact paths and file naming conventions.

Does YugabyteDB Support Automated Certificate Management?

Yes, and it’s worth knowing the options before defaulting to manual OpenSSL generation.

yugabyted includes a cert generate_server_certs command that generates node certificates automatically for local or multi-node clusters. This is the fastest path for development and testing environments.

For production deployments managed through YugabyteDB Anywhere (YBA), certificates can be auto-generated by the platform, or you can upload custom OpenSSL-generated certificates. 

The self-signed certificate docs for YBA cover both paths. Manual OpenSSL generation remains the right approach when the cluster must integrate with an existing organizational CA.

For a deeper look at TLS configuration at the YSQL layer, see this encryption in transit blog post.

What Are the Key Things To Get Right When Generating Certificates for a Distributed Cluster?

A few common mistakes have real consequences in a multi-node deployment:

CA key security: The CA private key must never be distributed to nodes or clients. Once all certificates are signed, move the CA key to secure offline storage.

SAN entries on node certificates: Node certificates must list the correct IP address or hostname in the SAN field. A mismatch causes TLS handshake failures, and the resulting error messages aren’t always obvious.

Certificate validity periods: Choose an expiration window that matches your rotation policy. Shorter lifetimes improve security but require more frequent rotation.

RSA key size: Use at least 2048-bit RSA keys. Environments running RHEL 8 or later with the FUTURE crypto policy require a 3072-bit minimum.

Certificate rotation in production: YugabyteDB Anywhere supports hot reload for zero-downtime cert rotation on supported versions. See the zero-downtime cert rotation guide for the procedure.

OpenSSL-based certificate generation is the standard, well-supported approach for securing YugabyteDB clusters, and both manual and automated paths are available depending on your deployment. 

If you want encryption in transit handled for you, try YugabyteDB Aeon free, where every cluster is provisioned with TLS enabled by default, or book a demo to walk through your security configuration.