DEV Community

Michael
Michael

Posted on • Originally published at gbase.cn

Setting Up SSL in GBase 8a: Why Certificates Are Mandatory and How to Generate Them

Configuring SSL for GBase 8a requires more than editing a config file — you must generate and deploy certificates. The SSL/TLS protocol depends on certificate‑based asymmetric cryptography for identity verification. Without certificates, an encrypted connection cannot be established in your gbase database.

Why Certificates Are Non‑Negotiable

Editing the configuration merely turns on SSL capability. Certificates are the only way to achieve three essential security goals:

  1. Authentication (prevent MITM): The server certificate lets the client verify it's connecting to the real, trusted database — not an imposter. Client certificates let the server verify the client, if mutual authentication is required.
  2. Key exchange (build the encrypted channel): Certificates contain public keys. The two sides use these to securely negotiate a symmetric session key for encrypting all subsequent data.
  3. Integrity (prevent tampering): Certificates are signed by a CA (Certificate Authority). Both sides use the CA's public key to validate the certificate, ensuring the public key hasn't been altered.

Think of it this way: the config file is the law declaring encryption is required; certificates are the passports and visas used to verify identity and exchange keys. One is useless without the other.

Certificate Generation and Deployment

All certificates are generated on the server first. Some files are then distributed to clients. The example uses /usr/local/ssl.

1. Generate Certificates (on the server)

Create the CA root certificate (used to sign and verify all other certs)

mkdir -p /usr/local/ssl && cd /usr/local/ssl
# Generate CA private key and self‑signed root certificate (valid 10 years)
openssl req -sha1 -new -x509 -nodes -days 3650 -keyout ca-key.pem > ca-cert.pem
Enter fullscreen mode Exit fullscreen mode

Create the server certificate

# Generate server private key and Certificate Signing Request (CSR)
openssl req -sha1 -newkey rsa:2048 -days 730 -nodes -keyout server-key.pem > server-req.pem
# Convert the private key to RSA format
openssl rsa -in server-key.pem -out server-key.pem
# Sign the server CSR with the CA to produce the server certificate (valid 2 years)
openssl x509 -sha1 -req -in server-req.pem -days 730 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem
Enter fullscreen mode Exit fullscreen mode

Create the client certificate

# Generate client private key and CSR
openssl req -sha1 -newkey rsa:2048 -days 730 -nodes -keyout client-key.pem > client-req.pem
# Convert the private key to RSA format
openssl rsa -in client-key.pem -out client-key.pem
# Sign the client CSR with the CA to produce the client certificate (valid 2 years)
openssl x509 -sha1 -req -in client-req.pem -days 730 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
Enter fullscreen mode Exit fullscreen mode

2. Configure the Server

Add the following lines under the [gbased] section in gbase_8a_gcluster.cnf and restart the cluster:

ssl-ca=/usr/local/ssl/ca-cert.pem
ssl-cert=/usr/local/ssl/server-cert.pem
ssl-key=/usr/local/ssl/server-key.pem
Enter fullscreen mode Exit fullscreen mode

Run SHOW VARIABLES LIKE 'have_%ssl'. A result of YES confirms SSL is active.

3. Configure the Client

Copy ca-cert.pem, client-cert.pem, and client-key.pem to the client machine. Add the same paths under the [client] section of the client's configuration file. Connect with gccli and run status — if you see SSL: Cipher in use is ..., the encrypted connection is established.

Certificate File Summary

Certificate File Generated By Purpose Location
ca-cert.pem Self‑built CA Trust anchor, verifies server/client certificates Server, Client
server-cert.pem Signed by CA Server identity, contains server public key Server
server-key.pem Server Server private key, must be kept secret Server
client-cert.pem Signed by CA Client identity (needed for mutual authentication) Client
client-key.pem Client Client private key, must be kept secret Client

This entire process builds a miniature private PKI. Your self‑created CA acts as the trust anchor, signing certificates for both server and client. It delivers mutual authentication and encrypted communication, turning a gbase database connection into a secure, compliant channel.

Top comments (0)