How to replace expiring CA certs in Aerospike Server

How to replace expiring CA certs in Aerospike Server

Context

CA certificates usually have a far-off expiration date (10 to 20 years) compared to signed server or clients certificates expiration. This article will focus on the CA certificate expiration and the options available to replace the expiring Certificate Authority (CA) certificates.

As a side note, replacing certs signed by the CA is much easier. In that particular case, the root CA certificate (server ca-file and client truststore) does not change. The server cert-file/key-file or client keystore may change and the client/server will still trust both old/new certs signed by that valid CA.

Methods

There are two ways of handling the expiration of a CA on the Aerospike server. The right step forward will depend on the statically configured TLS setting for the CA in aerospike.conf. A CA can be configured with either ca-file or ca-path

Expiring CA certs configured with ca-file

ca-file configured in aerospike.conf:

tls <tlsname> {
    ...
    ca-file /path/to/CA/CA.crt
    ...
}

The ca-file setting will only support one file. The steps to replace the expiring certificates is simple for server versions 3.15.0.1 and above (previous versions required a service restart). All that needs to be done is to overwrite the current CA file referenced through the ca-file setting. The new CA will automatically be reloaded on subsequent connections after the file has been overwritten.

mv  newCA.crt /path/to/CA/CA.crt

The issue that can arise with this method is with mutual authentication were both server and client CA would have to be replaced in tandem. Any delay between Client and Server having the same CA would impact new connections to the server from these clients.

Configuring the CA with a ca-path will address the above situation.

Expiring CA certs configured with ca-path

ca-path configured in aerospike.conf:

tls <tlsname> { 
    ...
    ca-path /path/to/CA
    ...
}

The ca-path setting specifies a directory that can contain multiple certificate authority certs. These files will need to be indexed locally using the openssl rehash command. No need to restart the asd service after the openssl rehash command.

openssl rehash /path/to/ca

The advantage here is you could have both the old and new CA certificates under that path. Client using the older CA that has not yet expired or the newer CA would still be able to connect to the server.

Example

  • asinfo TLS test fails due to CA expiration:
asinfo -h 127.0.0.1:aerospike:4333 --tls-enable --tls-capath='/home/vagrant/ca/capaths' --tls-keyfile=/home/vagrant/ca/private/client.key --tls-certfile=/home/vagrant/ca/certs/client.crt
TLS connection exception: [('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')]
ERROR: Not able to connect any cluster with ('127.0.0.1', 4333, 'aerospike').
  • One CA certificate is configured under the ca-path directory:
ls -ltrh
total 4.0K
-rw-rw-r-- 1 vagrant vagrant 1.3K Jul 31 10:44 old-ca.crt
lrwxrwxrwx 1 vagrant vagrant   10 Jul 31 11:22 95cc7d3b.0 -> old-ca.crt
  • Copy the new CA to that directory:
cp ca.crt /home/vagrant/ca/capaths/
  • Rehash that directory so that openssl can reference these files and auto-create symlinks. No need to restart the asd service after the openssl rehash command:
openssl rehash /home/vagrant/ca/capaths/

ls -al capaths/
total 16
drwxrwxr-x 2 vagrant vagrant 4096 Jul 31 11:24 .
drwxrwxr-x 8 vagrant vagrant 4096 Jul 30 14:22 ..
lrwxrwxrwx 1 vagrant vagrant   10 Jul 31 11:22 95cc7d3b.0 -> old-ca.crt
lrwxrwxrwx 1 vagrant vagrant    6 Jul 31 11:24 95cc7d3b.1 -> ca.crt
-rw-rw-r-- 1 vagrant vagrant 1326 Jul 31 11:24 ca.crt
-rw-rw-r-- 1 vagrant vagrant 1326 Jul 31 10:44 old-ca.crt
  • test the TLS connection with asinfo:
asinfo -h 127.0.0.1:aerospike:4333 --tls-enable --tls-capath='/home/vagrant/ca/capaths' --tls-keyfile=/home/vagrant/ca/private/client.key --tls-certfile=/home/vagrant/ca/certs/client.crt
1 :  node
     BB901110A000064
2 :  statistics

Keywords

SSL TLS certificates CA expirations openssl rehash

Timestamp

August 2019

© 2015 Copyright Aerospike, Inc. | All rights reserved. Creators of the Aerospike Database.