Enabling and Validating TLS

Aerospike_Knowledge · April 20, 2018, 10:12pm

The Aerospike Knowledge Base has moved to https://support.aerospike.com. Content on https://discuss.aerospike.com is being migrated to either https://support.aerospike.com or https://docs.aerospike.com. Maintenance on articles stored in this repository ceased on December 31st 2022 and this article may be stale. If you have any questions, please do not hesitate to raise a case via https://support.aerospike.com.

Enabling and Validating TLS

Introduction

Transport Layer Security (TLS), is a cryptographic protocol designed to provide secure communication over a network. Enabling TLS for the traffic between clients and Aerospike nodes requires changes to be made both on the Aerospike nodes and clients. This document provides the changes required to be made on the Aerospike nodes so that clients can communicate with the cluster via TLS enabled ports. In addition to providing the step by step procedure, the appendix of this document also provides a sample setup through which each step is executed and validated. The scope of this document covers Standard and Mutual authentication modes of TLS with cluster name match and validating with the C and Java clients.

Server Side Configuration

Procedure Overview

Prerequisites:

Have the required specific certificates, private keys and signing CA certificates available.
Set the cluster nodes with a cluster-name [optional but recommended] .

Introduce the TLS configuration parameters in the configuration file on one node and restart the Aerospike service.
Repeat step 2 for all nodes in the cluster.
Validate the TLS setup on the server side. At this point, applications will continue to communicate with the Aerospike cluster via clear ports.
Ensure all clients have been updated to exclusively connect to the TLS port.
Remove the non TLS port from the configuration and proceed with a rolling restart of the cluster.

1- Prerequisites

Certificate requirements

Standard authentication

Server certificate: A server certificate is a digital certificate issued to a server by a trusted certification authority (CA) containing a name, a signature and a public key. Sometimes, a server certificate may not be a single certificate but a chain of certificates. A certificate chain is an ordered list of certificates. The chain begins with the SSL certificate, and each certificate in the chain is signed by the entity identified by the next certificate in the chain. Any certificate that sits between the OpenSSL certificate and the root certificate is called a chain or intermediate certificate. The intermediate certificate is the signer/issuer of the OpenSSL certificate. The root CA Certificate is the signer/issuer of the Intermediate Certificate. The cert-file configuration parameter must be set and point to this file. It is the all-in-one .pem file, which includes the server’s own certificate. If the certificate is chain-signed, it must also include the chained CA Certificate files in certificate chain order.
Server Key: This is the private key for the server certificate. The key-file configuration parameter must be set. It is the .pem file with the private key associated with the certificate.
The client must have the relevant root CA (Certificate Authority) certificate configured. A CA certificate has the same structure as a server certificate and contains a name, a signature and public key and is used to verify the server certificate has the right signature and is correct for its name.
For the example described here (cluster name matching), all Aerospike cluster nodes use same set of certificates.
The certificates must have cluster-name defined in the Subject/CN field. For example:

Subject: C=US, ST=California, L=San Jose, O=Acme, Inc., OU=Aerospike Cluster, CN=aerocluster

Mutual authentication

In addition to the files required for the client to authenticate the cluster nodes, the following files are required for the cluster nodes to authenticate the clients:

Client certificate: The certificate must be a valid certificate chain, and must be signed by the same CA (Certificate Authority) as the server.
Client Key: This is the private key for the client certificate.
Root CA certificate: The client’s signing CA certificate. The ca-file/ca-path configuration parameter must point to this file or path containing the relevant CA certificate.

Have the required specific certificates, private keys and signing CA certificates available.

Aerospike Server Enterprise Edition version 3.11 and above is required, but 3.15 and versions above are recommended.

Heartbeat protocol requirements and cluster-name setting

The cluster-name configuration parameter is available as of heartbeat protocol version 3. So, we need to ensure that all the Aerospike nodes are on heartbeat protocol V3. Please refer to the following article to change protocol version from V2 to V3.

Note: If running version 3.14 or above, the heartbeat protocol version would already be set to v3.

Perform the following steps through the asadm tool (for example from one of the nodes in the cluster). This ensures that the command is executed on all nodes in the cluster.

Dynamically change the cluster name on the entire cluster using asadm:

Admin> asinfo -v 'set-config:context=service;cluster-name=aerocluster'

Validate the cluster name change using asadm.

Admin> show config like cluster-name

Ensure the stability of the cluster using asadm:

There are no migrations happening.
The size of the cluster is correct.

The info command within asadm shows the information about migrations and cluster size

Admin> info

Edit the Aerospike configuration file (aerospike.conf) on each node to introduce the cluster-name configuration parameter in the service section. This ensures that the cluster-name configured dynamically doesn’t revert upon the subsequent restart of the Aerospike service. Replace the value of the parameter cluster-name with the custom value.

service {
    ... 
    cluster-name  aerocluster
    ...
}

2- Enable TLS on the cluster nodes

Copy the certificates to all the Aerospike nodes in the cluster
Introduce the TLS configuration parameters

Note: The following step refers to the section in the Aerospike configuration file: aerospike.conf. As each Aerospike node has an individual configuration file, these steps must be performed on each node.

Standard authentication

network / tls section:
- Add a tls sub-stanza named <cluster-name> with the following 2 entries:
  - The value for cert-file must be the path to server certificate.
  - The value for key-file must be the path to key file.
network / service section:
- Set the tls-address configuration parameter to the bind address for TLS (the IP address at which the server listens for client connections, defaults to any if not set, which will bind to all available interfaces).
- Set the tls-port.
- tls-authenticate-client must be set to false (for older server versions, tls-mode must be authenticate-server)
- tls-name picks up the cluster-name mentioned in the service section when a value of <cluster-name> is specified and will correlate the settings from the relevant tls sub-stanza.
Example configuration:

network {
  tls <cluster-name> {
     cert-file /home/user/cluster_chain.pem
     key-file /home/user/key.pem
  }
  service {
      ...
      address 10.0.0.100
      port 3000
      tls-address 10.0.0.100
      tls-port 4333
      tls-name <cluster-name>
      tls-authenticate-client false
      ...
  }
}

For server versions prior to 3.15, the configuration is slightly different:

network {
  service {
      ...
      address 10.0.0.100
      port 3000
      tls-address 10.0.0.100
      tls-port 4333
      tls-mode authenticate-server
      tls-name <cluster-name>
      tls-certfile /home/user/cluster_chain.pem
      tls-keyfile /home/user/key.pem
      ... 
  }
...
}

Mutual authentication

network / service section - on top of the previously mentioned configuration settings:
- tls-authenticate-client must be set to any (for older server versions, tls-mode must be authenticate-both)
- The value for ca-file must be the path to CA certificate (alternatively, ca-path can be used).
Example configuration:

network {
  tls <cluster-name> {
     cert-file /home/user/cluster_chain.pem
     key-file /home/user/key.pem
     ca-file /etc/aerospike/certs/rootCA.pem
  }
  service {
      ...
      address 10.0.0.100
      port 3000
      tls-address 10.0.0.100
      tls-port 4333
      tls-name <cluster-name>
      tls-authenticate-client any
      ...
  }
}

For server versions prior to 3.15, the configuration is slightly different:

network {
  service {
      ...
      address 10.0.0.100
      port 3000
      tls-address 10.0.0.100
      tls-port 4333
      tls-mode authenticate-both
      tls-name <cluster-name>
      tls-certfile /home/user/cluster_chain.pem
      tls-keyfile /home/user/key.pem
      tls-cafile /home/user/rootCA.pem
      ... 
  }
...
}

3- Restart the node and repeat for each node in the cluster in a rolling manner

Restart the aerospike service on this node

sudo service aerospike restart

Ensure the stability of the cluster using asadm:

Make sure the size of the cluster is correct. The info command within asadm shows the information about migrations and cluster size.

Admin> info

For versions prior to 3.13 running the older cluster protocol, you may want to wait or not wait for the migrations to complete before proceeding to the next node.

Note:

To manage migrations refer to the migration tuning documentation.
For further assistance, contact Aerospike support at: support@aerospike.com.

4- Validate the TLS setup on the server side.

At this point, applications will continue to communicate with the Aerospike cluster via clear ports. Before proceeding to the next step and enable TLS on the clients, a quick validation of the TLS enabled ports on the Aerospike nodes can be performed using one of the command line tools, asadm or aql.

Alternatively, try running some test loads using one of the client libraries as described next in this document.

Using the C benchmark tool

Run the traffic to Aerospike nodes via TLS enabled ports using the Aerospike C benchmark tool. Refer to the complete documentation on this page.

Standard Authentication

./target/benchmarks -h "<IP value>:<tls-name>:4333" --tlsEnable --tlsCaFile <Path to Root CA certificate>

Mutual Authentication

./target/benchmarks -h "<IP value>:<tls-name>:4333" --tlsEnable --tlsCaFile <Path to Root CA certificate> --tlsCertFile <Path to Client certificate> --tlsKeyFile <Path to key file>

Using the Java benchmark tool

Run the traffic to Aerospike nodes via TLS enabled ports using the Aerospike Java benchmark tool. Refer to the complete documentation on this page.

Standard Authentication

java -Djavax.net.ssl.trustStore=<Path to trustStore> -Djavax.net.ssl.trustStorePassword=<trustStore password> -jar target/aerospike-benchmarks-*-jar-with-dependencies.jar -h "<IP address>:<tls-name>:4333" -tlsEnable

Mutual Authentication

java -Djavax.net.ssl.trustStore=<Path to trustStore> -Djavax.net.ssl.trustStorePassword=<trustStore password> -Djavax.net.ssl.keyStore=<Path to KeyStore> -Djavax.net.ssl.keyStorePassword=<keyStore password> -jar target/aerospike-benchmarks-*-jar-with-dependencies.jar -h "<IP address>:<tls-name>:4333" -tlsEnable

5- Update all clients to exclusively connect to the TLS port

6- Remove the non TLS port from the configuration and proceed with a rolling restart of the cluster

Example with a Sample Environment

The following example of a sample environment is only provided as a reference and a validation to the above steps.

Note: For versions 3.15 and above the config parameter names have changed (refer to the previous sections of this document)

Aerospike node: Oracle VM on Vagrant box
Client: Oracle VM on Vagrant box
Operating System: Ubuntu 14.04
Aerospike Enterprise Edition: E-3.12.1.3
Aerospike C Client: C Client Library 4.1.3
Aerospike Java Client: Java Client Library 3.3.2
Aerospike cluster size: 3
Aerospike node IPs: 10.0.0.100, 10.0.0.103, 10.0.0.104
Client IP: 10.0.2.15
Number of Clients: 1
Cluster Name: aerocluster - cluster-name configuration parameter
TLS Name: cluster-name - tls-name configuration parameter
Root CA certificate: cacert.pem (When using a C Client)/ client.cert (When using a Java Client) - tls-cafile configuration parameter
Server certificate: cluster_chain.pem - tls-certfile configuration parameter
Key: key.pem - tls-keyfile configuration parameter

Prerequisites

Before configuring TLS in an Aerospike environment, ensure all prerequisites are complete.

Install Aerospike server Enterprise Edition version 3.11 or above. Set the heartbeat protocol to v3 across the cluster.

Set the cluster name

Dynamically change the cluster name on the entire cluster using asadm:

Admin> asinfo -v 'set-config:context=service;cluster-name=aerocluster'
10.0.0.104:3000 (10.0.0.104) returned:
ok

vagrant-ubuntu-trusty-64:3000 (10.0.0.100) returned:
ok

10.0.0.103:3000 (10.0.0.103) returned:
ok

Validate the cluster name change on each node:

Admin> show config like cluster-name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Service Configuration~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NODE        :   10.0.0.103:3000     10.0.0.104:3000     vagrant-ubuntu-trusty-64:3000   
cluster-name:   aerocluster         aerocluster         aerocluster

Check the stability of the cluster using asadm:

Check that there are no migrations pending, under the “Pending Migrations” column
Check that the size of the cluster is 3, under the “Cluster Size” column

Admin> info
~~~~~~~~~~~~~~~~~~~~~~Network Information~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Cluster         Node       […] Cluster […]  Cluster  […]  Uptime   
               Name          .         […]  Size   […] Integrity […]       .   
aerocluster           10.0.0.103:3000  […]     3   […] True      […] 14:12:12   
aerocluster           10.0.0.104:3000  […]     3   […] True      […] 14:11:11   
aerocluster           10.0.0.100:3000  […]     3   […] True      […] 08:35:35   
Number of rows: 3
~~~~~~~~~~~~~~Namespace Information~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace         Node    […]               Master              Replica […]       Pending      […]
        .          .      […] (Objects,Tombstones) (Objects,Tombstones) […]      Migrates      […]
        .          .      […]                    .                    . […]            (tx,rx) […]
bar       10.0.0.103:3000 […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
bar       10.0.0.104:3000 […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
bar       10.0.0.100:3000 […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
bar                       […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
test      10.0.0.103:3000 […] (45.515 K, 0.000  )  (45.502 K, 0.000  )  […] (0.000  , 0.000  ) […]
test      10.0.0.104:3000 […] (43.278 K, 0.000  )  (43.613 K, 0.000  )  […] (0.000  , 0.000  ) […]
test      10.0.0.100:3000 […] (44.069 K, 0.000  )  (43.747 K, 0.000  )  […] (0.000  , 0.000  ) […]
test                      […] (132.862 K, 0.000  ) (132.862 K, 0.000  ) […] (0.000  , 0.000  ) […]
Number of rows: 8

Edit the Aerospike configuration file(aerospike.conf) on each node, to add the cluster-name in the service section. This ensures that the cluster-name doesn’t get reset upon the next restart of the Aerospike service.

service {
       ...
       cluster-name aerocluster
       ...
}

Configure the server nodes for TLS

Standard authentication

tls-certfile /home/user/cluster_chain.pem
tls-keyfile /home/user/key.pem

For version 3.15 and above the config parameters are renamed as below

cert-file /home/user/cluster_chain.pem
key-file /home/user/key.pem

Mutual authentication

tls-certfile /home/user/cluster_chain.pem
tls-keyfile /home/user/key.pem
tls-cafile /home/user/cacert.pem

For version 3.15 and above the config parameters are renamed as below.

cert-file /home/user/cluster_chain.pem
key-file /home/user/key.pem
ca-file /home/user/cacert.pem

Copy the certificates to all the Aerospike nodes in the cluster
Configure the nodes as described in the beginning of this document
Restart the aerospike service on node 10.0.0.100:

vagrant@vagrant-ubuntu-trusty-64:~$ sudo service aerospike restart
 * Stopping aerospike                                                               [ OK ] 
 * Starting aerospike                                                               [ OK ]

Ensure the stability of the cluster using asadm:

Make sure the size of the cluster is correct. The info command within asadm shows the information about migrations and cluster size:

Admin> info
~~~~~~~~~~~~~~~~~~~~~~Network Information~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Cluster         Node       […] Cluster […]  Cluster  […]  Uptime   
               Name          .         […]  Size   […] Integrity […]       .   
aerocluster           10.0.0.103:3000  […]     3   […] True      […] 14:12:12   
aerocluster           10.0.0.104:3000  […]     3   […] True      […] 14:11:11   
aerocluster           10.0.0.100:3000  […]     3   […] True      […] 08:35:35   
Number of rows: 3
~~~~~~~~~~~~~~Namespace Information~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Namespace         Node    […]               Master              Replica […]       Pending      […]
        .          .      […] (Objects,Tombstones) (Objects,Tombstones) […]      Migrates      […]
        .          .      […]                    .                    . […]            (tx,rx) […]
bar       10.0.0.103:3000 […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
bar       10.0.0.104:3000 […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
bar       10.0.0.100:3000 […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
bar                       […] (0.000  , 0.000  )   (0.000  , 0.000  )   […] (0.000  , 0.000  ) […]
test      10.0.0.103:3000 […] (45.515 K, 0.000  )  (45.502 K, 0.000  )  […] (0.000  , 0.000  ) […]
test      10.0.0.104:3000 […] (43.278 K, 0.000  )  (43.613 K, 0.000  )  […] (0.000  , 0.000  ) […]
test      10.0.0.100:3000 […] (44.069 K, 0.000  )  (43.747 K, 0.000  )  […] (0.000  , 0.000  ) […]
test                      […] (132.862 K, 0.000  ) (132.862 K, 0.000  ) […] (0.000  , 0.000  ) […]
Number of rows: 8

Restart the other 2 nodes one at a time.
Connect to the TLS ports using asadm:

[vagrant@localhost ~]$ asadm -t aerocluster --tls_enable --tls_cafile /home/user/cacert.pem --tls_keyfile /home/user/key.pem --tls_certfile /home/user/cluster_chain.pem -h 10.0.0.100 -p 4333 --tls_protocols TLSv1.2
Aerospike Interactive Shell, version 0.1.15

Found 3 nodes
Online: 10.0.0.100:4333,10.0.0.103:4333,10.0.0.104:4333

Run the C benchmark tool:

Standard Authentication

$ ./target/benchmarks -h "10.0.0.104:aerocluster:4333" --tlsEnable --tlsCaFile /vagrant_data/test-master/x509_certificates/ca/subject/Platinum/cacert.pem
hosts:          10.0.0.104:aerocluster:4333
port:           3000
user:           (null)
namespace:      test
set:            testset
startKey:       1
keys/records:   1000000
bins:           1
object spec:    int
random values:  false
minimum number of transactions:  -1
workload:       read 50% write 50%
threads:        16
max throughput: unlimited
read timeout:   0 ms
write timeout:  0 ms
max retries:    1
debug:          false
latency:        false
shared memory:  false
read replica:   master
read consistency level: one
write commit level: all
asynchronous mode:  off
TLS:                    enabled
TLS encrypt only:       false
TLS cafile:             /vagrant_data/test-master/x509_certificates/ca/subject/Platinum/cacert.pem
TLS capath:             (null)
TLS protocols:          (null)
TLS cipher suite:       (null)
TLS crl check:          false
TLS crl check all:      false
TLS cert blacklist:     (null)
TLS log session info:   false
TLS keyfile:            (null)
TLS certfile:           (null)
2017-09-19 17:28:21 INFO Add node BB9C8A831270008 10.0.0.104:4333
2017-09-19 17:28:21 INFO Add node BB9FAE279270008 10.0.0.103:4333
2017-09-19 17:28:21 INFO Add node BB910272D270008 10.0.0.100:4333
2017-09-19 17:28:21 INFO Read/write using 1000000 records
2017-09-19 17:28:21 INFO Start 16 generator threads
2017-09-19 17:28:22 INFO write(tps=3340 timeouts=0 errors=0) read(tps=3306 timeouts=0 errors=0) total(tps=6646 timeouts=0 errors=0)
2017-09-19 17:28:23 INFO write(tps=3136 timeouts=0 errors=0) read(tps=2969 timeouts=0 errors=0) total(tps=6105 timeouts=0 errors=0)
2017-09-19 17:28:24 INFO write(tps=3249 timeouts=0 errors=0) read(tps=3233 timeouts=0 errors=0) total(tps=6482 timeouts=0 errors=0)
2017-09-19 17:28:25 INFO write(tps=2984 timeouts=0 errors=0) read(tps=3037 timeouts=0 errors=0) total(tps=6021 timeouts=0 errors=0)
2017-09-19 17:28:26 INFO write(tps=3321 timeouts=0 errors=0) read(tps=3329 timeouts=0 errors=0) total(tps=6650 timeouts=0 errors=0)
2017-09-19 17:28:27 INFO write(tps=3101 timeouts=0 errors=0) read(tps=3085 timeouts=0 errors=0) total(tps=6186 timeouts=0 errors=0)
2017-09-19 17:28:28 INFO write(tps=3109 timeouts=0 errors=0) read(tps=3088 timeouts=0 errors=0) total(tps=6197 timeouts=0 errors=0)
2017-09-19 17:28:29 INFO write(tps=2857 timeouts=0 errors=0) read(tps=2938 timeouts=0 errors=0) total(tps=5795 timeouts=0 errors=0)
2017-09-19 17:28:30 INFO write(tps=3482 timeouts=0 errors=0) read(tps=3419 timeouts=0 errors=0) total(tps=6901 timeouts=0 errors=0)

Mutual Authentication

$ ./target/benchmarks -h "10.0.0.103:aerocluster:4333" --tlsEnable --tlsCaFile /vagrant_data/test-master/x509_certificates/ca/subject/Platinum/cacert.pem --tlsCertFile /vagrant_data/test-master/x509_certificates/ca/subject/client_chain.pem --tlsKeyFile /vagrant_data/test-master/x509_certificates/ca/subject/Client/key.pem
hosts:          10.0.0.103:aerocluster:4333
port:           3000
user:           (null)
namespace:      test
set:            testset
startKey:       1
keys/records:   1000000
bins:           1
object spec:    int
random values:  false
minimum number of transactions:  -1
workload:       read 50% write 50%
threads:        16
max throughput: unlimited
read timeout:   0 ms
write timeout:  0 ms
max retries:    1
debug:          false
latency:        false
shared memory:  false
read replica:   master
read consistency level: one
write commit level: all
asynchronous mode:  off
TLS:                    enabled
TLS encrypt only:       false
TLS cafile:             /vagrant_data/test-master/x509_certificates/ca/subject/Platinum/cacert.pem
TLS capath:             (null)
TLS protocols:          (null)
TLS cipher suite:       (null)
TLS crl check:          false
TLS crl check all:      false
TLS cert blacklist:     (null)
TLS log session info:   false
TLS keyfile:            /vagrant_data/test-master/x509_certificates/ca/subject/Client/key.pem
TLS certfile:           /vagrant_data/test-master/x509_certificates/ca/subject/client_chain.pem
2017-09-19 17:41:46 INFO Add node BB9FAE279270008 10.0.0.103:4333
2017-09-19 17:41:46 INFO Add node BB9C8A831270008 10.0.0.104:4333
2017-09-19 17:41:46 INFO Add node BB910272D270008 10.0.0.100:4333
2017-09-19 17:41:46 INFO Read/write using 1000000 records
2017-09-19 17:41:46 INFO Start 16 generator threads
2017-09-19 17:41:47 INFO write(tps=2713 timeouts=0 errors=0) read(tps=2716 timeouts=0 errors=0) total(tps=5429 timeouts=0 errors=0)
2017-09-19 17:41:48 INFO write(tps=3055 timeouts=0 errors=0) read(tps=2942 timeouts=0 errors=0) total(tps=5997 timeouts=0 errors=0)
2017-09-19 17:41:49 INFO write(tps=2998 timeouts=0 errors=0) read(tps=2966 timeouts=0 errors=0) total(tps=5964 timeouts=0 errors=0)
2017-09-19 17:41:50 INFO write(tps=3306 timeouts=0 errors=0) read(tps=3414 timeouts=0 errors=0) total(tps=6720 timeouts=0 errors=0)
2017-09-19 17:41:51 INFO write(tps=3027 timeouts=0 errors=0) read(tps=2990 timeouts=0 errors=0) total(tps=6017 timeouts=0 errors=0)
2017-09-19 17:41:52 INFO write(tps=2508 timeouts=0 errors=0) read(tps=2573 timeouts=0 errors=0) total(tps=5081 timeouts=0 errors=0)

Run the Java benchmark tool:

Standard Authentication

$ java -Djavax.net.ssl.trustStore=/home/vagrant/trustStore -Djavax.net.ssl.trustStorePassword=123456 -jar target/aerospike-benchmarks-3.3.2-jar-with-dependencies.jar -h "10.0.0.100:aerocluster:4333" -tlsEnable
Benchmark: 10.0.0.100 4333, namespace: test, set: testset, threads: 16, workload: READ_UPDATE
read: 50% (all bins: 100%, single bin: 0%), write: 50% (all bins: 100%, single bin: 0%)
keys: 100000, start key: 0, transactions: 0, bins: 1, random values: false, throughput: unlimited
read policy: timeout: 0, maxRetries: 1, sleepBetweenRetries: 500, consistencyLevel: CONSISTENCY_ONE, replica: MASTER, reportNotFound: false
write policy: timeout: 0, maxRetries: 1, sleepBetweenRetries: 500, commitLevel: COMMIT_ALL
bin[0]: integer
debug: false
2017-09-19 17:53:55.664 INFO Thread 1 Add node BB910272D270008 10.0.0.100 4333
2017-09-19 17:53:55.786 INFO Thread 1 Add node BB9C8A831270008 10.0.0.104 4333
2017-09-19 17:53:55.787 INFO Thread 1 Add node BB9FAE279270008 10.0.0.103 4333
2017-09-19 17:53:55.903 write(tps=2 timeouts=0 errors=0) read(tps=0 timeouts=0 errors=0) total(tps=2 timeouts=0 errors=0)
2017-09-19 17:53:56.906 write(tps=1495 timeouts=0 errors=0) read(tps=1369 timeouts=0 errors=0) total(tps=2864 timeouts=0 errors=0)
2017-09-19 17:53:57.908 write(tps=2155 timeouts=0 errors=0) read(tps=2097 timeouts=0 errors=0) total(tps=4252 timeouts=0 errors=0)
2017-09-19 17:53:58.909 write(tps=2227 timeouts=0 errors=0) read(tps=2180 timeouts=0 errors=0) total(tps=4407 timeouts=0 errors=0)
2017-09-19 17:53:59.911 write(tps=2207 timeouts=0 errors=0) read(tps=2295 timeouts=0 errors=0) total(tps=4502 timeouts=0 errors=0)
2017-09-19 17:54:00.913 write(tps=2225 timeouts=0 errors=0) read(tps=2321 timeouts=0 errors=0) total(tps=4546 timeouts=0 errors=0)
2017-09-19 17:54:01.920 write(tps=1861 timeouts=0 errors=0) read(tps=1819 timeouts=0 errors=0) total(tps=3680 timeouts=0 errors=0)
2017-09-19 17:54:02.921 write(tps=2136 timeouts=0 errors=0) read(tps=2154 timeouts=0 errors=0) total(tps=4290 timeouts=0 errors=0)
2017-09-19 17:54:03.923 write(tps=1747 timeouts=0 errors=0) read(tps=1699 timeouts=0 errors=0) total(tps=3446 timeouts=0 errors=0)

Mutual Authentication

$ java -Djavax.net.ssl.trustStore=/home/vagrant/trustStore -Djavax.net.ssl.trustStorePassword=123456 -Djavax.net.ssl.keyStore=/home/vagrant/keyStore -Djavax.net.ssl.keyStorePassword=123456 -jar target/aerospike-benchmarks-3.3.2-jar-with-dependencies.jar -h "10.0.0.100:aerocluster:4333" -tlsEnable
Benchmark: 10.0.0.100 4333, namespace: test, set: testset, threads: 16, workload: READ_UPDATE
read: 50% (all bins: 100%, single bin: 0%), write: 50% (all bins: 100%, single bin: 0%)
keys: 100000, start key: 0, transactions: 0, bins: 1, random values: false, throughput: unlimited
read policy: timeout: 0, maxRetries: 1, sleepBetweenRetries: 500, consistencyLevel: CONSISTENCY_ONE, replica: MASTER, reportNotFound: false
write policy: timeout: 0, maxRetries: 1, sleepBetweenRetries: 500, commitLevel: COMMIT_ALL
bin[0]: integer
debug: false
2017-09-19 18:20:50.665 INFO Thread 1 Add node BB910272D270008 10.0.0.100 4333
2017-09-19 18:20:50.783 INFO Thread 1 Add node BB9C8A831270008 10.0.0.104 4333
2017-09-19 18:20:50.783 INFO Thread 1 Add node BB9FAE279270008 10.0.0.103 4333
2017-09-19 18:20:50.901 write(tps=1 timeouts=0 errors=0) read(tps=2 timeouts=0 errors=0) total(tps=3 timeouts=0 errors=0)
2017-09-19 18:20:51.903 write(tps=1510 timeouts=0 errors=0) read(tps=1499 timeouts=0 errors=0) total(tps=3009 timeouts=0 errors=0)
2017-09-19 18:20:52.904 write(tps=1947 timeouts=0 errors=0) read(tps=1840 timeouts=0 errors=0) total(tps=3787 timeouts=0 errors=0)
2017-09-19 18:20:53.905 write(tps=2183 timeouts=0 errors=0) read(tps=2253 timeouts=0 errors=0) total(tps=4436 timeouts=0 errors=0)
2017-09-19 18:20:54.907 write(tps=2278 timeouts=0 errors=0) read(tps=2160 timeouts=0 errors=0) total(tps=4438 timeouts=0 errors=0)
2017-09-19 18:20:55.908 write(tps=2229 timeouts=0 errors=0) read(tps=2226 timeouts=0 errors=0) total(tps=4455 timeouts=0 errors=0)

Topic		Replies	Views
TLS Configuration in Multicast Configuration	1	888	May 14, 2019
Developer access for production systems	4	564	July 28, 2023
Security mechanisms to prevent MongoDB security issue Security	3	2307	March 11, 2015
Cluster integrity fault: Unable to create two node cluster Configuration	4	3081	July 8, 2015
Aerospike upgrade using a parallel upgraded cluster setup Upgrading	1	907	May 24, 2019

Enabling and Validating TLS

Enabling and Validating TLS

Introduction

Server Side Configuration

Procedure Overview

1- Prerequisites

Certificate requirements

Standard authentication

Mutual authentication

Heartbeat protocol requirements and cluster-name setting

2- Enable TLS on the cluster nodes

Standard authentication

Mutual authentication

3- Restart the node and repeat for each node in the cluster in a rolling manner

4- Validate the TLS setup on the server side.

Using the C benchmark tool

Using the Java benchmark tool

5- Update all clients to exclusively connect to the TLS port

6- Remove the non TLS port from the configuration and proceed with a rolling restart of the cluster

Example with a Sample Environment

Prerequisites

Configure the server nodes for TLS

Related Topics