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.
Method
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 and requires a service restart. All that needs to be done is to overwrite the current CA file referenced through the ca-file setting and restart the aerospike service.
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. The asd service should be restarted once with both older non-expired CA cert and newer non-expiring CA Cert. (Plan accordingly to transition from expiring CA to non-expiring CA)
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. A restart of the asd service after the openssl rehash command is required:
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