How to generate self-signed TLS certificates

How to generate self-signed TLS certificates


Create basic folder hierarchy

$ sudo -i
$ mkdir /root/CA
$ cd /root/CA
$ mkdir newcerts private certs
$ touch index.txt
$ echo 01 > serial

Create a custom openssl.cnf

This step is to create a small and sane openssl.cnf, as to not rely on the provided global one that would differ per version and OS.

cat <<'EOF' > /root/CA/openssl.cnf
dir			= .

[ req ]
default_bits  	    = 1024		# Size of keys
default_keyfile     = key.pem		# name of generated keys
default_md          = sha256		# message digest algorithm
string_mask         = nombstr		# permitted characters
distinguished_name  = req_distinguished_name
req_extensions      = v3_req

[ req_distinguished_name ]
0.organizationName        = Organization Name (company)
organizationalUnitName    = Organizational Unit Name (department, division)
emailAddress              = Email Address
emailAddress_max          = 40
localityName              = Locality Name (city, district)
stateOrProvinceName       = State or Province Name (full name)
countryName               = Country Name (2 letter code)
countryName_min           = 2
countryName_max           = 2
commonName                = Common Name (hostname, IP, or your name)
commonName_max            = 64

0.organizationName_default         = Aerospike Inc
organizationalUnitName_default     = operations
emailAddress_default               =
localityName_default               = London
stateOrProvinceName_default	   = London
countryName_default		   = UK
commonName_default                 = superserver 

[ v3_ca ]
basicConstraints	= CA:TRUE
subjectKeyIdentifier	= hash
authorityKeyIdentifier	= keyid:always,issuer:always

[ v3_req ]
basicConstraints	= CA:FALSE
subjectKeyIdentifier	= hash

[ ca ]
default_ca		= CA_default

[ CA_default ]
serial			= $dir/serial
database		= $dir/index.txt
new_certs_dir		= $dir/newcerts
certificate		= $dir/certs/ca.crt
private_key		= $dir/private/ca.key
default_days		= 365
default_md		= sha256
preserve		= no
email_in_dn		= no
nameopt			= default_ca
certopt			= default_ca
policy			= policy_match

[ policy_match ]
countryName		= match
stateOrProvinceName	= match
organizationName	= match
organizationalUnitName	= optional
commonName		= supplied
emailAddress		= optional

Create CA certificate and private key

$ cd /root/CA
$ export commonName="someCommonName"
$ openssl req -new -nodes -x509 -extensions v3_ca -keyout private/ca.key -out certs/ca.crt -days 3650 -config ./openssl.cnf -subj "/C=US/ST=Denial/L=Springfield/O=Dis/CN=${commonName}"

Create the server certificates

Generate a certificate signing request (CSR)

The name you use in “Common Name” field will later be used in aerospike.conf as tls-name.

$ cd /root/CA
$ export commonName="someCommonName"
$ openssl req -new -nodes -keyout private/server.key -out server.csr -days 3650 -config ./openssl.cnf -subj "/C=US/ST=Denial/L=Springfield/O=Dis/CN=${commonName}"

Sign the certificate

$ cd /root/CA
$ openssl ca -batch -out certs/server.crt -config ./openssl.cnf -infiles server.csr

Define tls-name in aerospike.conf

Add the following to the ‘network’ stanza in the aerospike.conf, replacing with the chosen “Common Name”

tls <tlsname> {
    cert-file /root/CA/certs/server.crt
    ca-file /root/CA/certs/ca.crt
    key-file /root/CA/private/server.key

Generate more certificates if needed

If you want to use separate tls certificate for clients, fabric and heartbeat messages, follow the above “Create the server certificates” section again, changing the ‘server.*’ file names to another certificate name. Be sure to use a unique “Common Name” as well.

Enable use of TLS in service (client), fabric and/or heartbeat messages

Follow configuration reference for the ‘service’, ‘heartbeat’ and ‘fabric’ stanzas in aerospike.conf as specified here

To check details of an existing certificate

$ openssl x509 -in certs/server.crt -noout -text

Note on mutual authentication

The above will allow the fabric, heartbeat node-to-node authentication as well as server to authenticate to client (client to verify server). If you need the client to authenticate to server (server to verify client), you can for example:

  1. Generate another certificate using the “Create the server certificate” section above, calling it for example ‘client’
  2. In the ‘service’ stanza, change the ‘tls-authenticate-client false’ to 'tls-authenticate-client ’

Example network stanza with tls enabled:

network {
    tls someCommonName {
            cert-file /root/CA/certs/server.crt
            ca-file /root/CA/certs/ca.crt
            key-file /root/CA/private/server.key
    service {
            tls-port 4333
            tls-address any
            tls-name someCommonName
            tls-authenticate-client false

    heartbeat {
            mode mesh
            tls-port 3012
            tls-name server
            tls-mesh-seed-address-port 3012
            tls-mesh-seed-address-port 3012

            # To use unicast-mesh heartbeats, remove the 3 lines above, and see
            # aerospike_mesh.conf for alternative.

            interval 150
            timeout 10

    fabric {
            tls-port 3011
            tls-name server

    info {
            port 3003


The below test will work for both: mutual auth with server cert and server-side only auth. If using a separate client certificate, replace the server key and cert with client ones.

$ aql -h --tls-enable --tls-cafile=/root/CA/certs/ca.crt --tls-keyfile=/root/CA/private/server.key --tls-certfile=/root/CA/certs/server.crt
User:         None
Config File:  /etc/aerospike/astools.conf /root/.aerospike/astools.conf 
Aerospike Query Client
C Client Version 4.3.12
Copyright 2012-2017 Aerospike. All rights reserved.
aql> select * from test
0 rows in set (0.205 secs)


aql> exit




October 2018

1 Like
© 2021 Copyright Aerospike, Inc. | All rights reserved. Creators of the Aerospike Database.