Using multiple tls-authenticate-client directive


#1

Using multiple tls-authenticate-client directive

There are 3 modes of authentication that can be specified when configuring TLS between server and client:

  1. standard authentication (server only)
  2. mutual authentication (TLS client and TLS server)
  3. mutual authentication with subject validation

If not specified, it will default to any i.e. mutual authentication without subject validation.

  • 1st mode: “false” : will cause clients to authenticate the server.

  • 2nd mode: “any” : this is for a two way (mutual) authentication, both client and server need to be authenticated.

  • 3rd mode: “<subject-name>” : this is for two way (mutual) authentication along with subject name validation. This would be the TLS name a server node would expect clients to present on incoming connections.

Here’s our configuration snippet shown to use the 3rd mode.

tls spkOPSTeam {
                ca-file /app/TLS-Cert-Gen-Tool/spkCACert.pem
                key-file /app/TLS-Cert-Gen-Tool/spkOPSTeamKey.pem
                cert-file /app/TLS-Cert-Gen-Tool/spkOPSTeamCert.pem
}

tls spkDEVTeam {
                ca-file /app/TLS-Cert-Gen-Tool/spkCACert.pem
                key-file /app/TLS-Cert-Gen-Tool/spkDEVTeamKey.pem
                cert-file /app/TLS-Cert-Gen-Tool/spkDEVTeamCert.pem
}

tls spkQATeam {
                ca-file /app/TLS-Cert-Gen-Tool/spkCACert.pem
                key-file /app/TLS-Cert-Gen-Tool/spkQATeamKey.pem
                cert-file /app/TLS-Cert-Gen-Tool/spkQATeamCert.pem
}

service {
                tls-authenticate-client spkQATeam
                tls-authenticate-client spkDEVTeam
                tls-name spkOPSTeam
                tls-port 4333
                address any
}

Here we can see that we have opted for two-way authentication with subject name validation. This method is useful when we want to group the clients connecting to the cluster and expect different set of certificates from each group of clients. The most common use-case is when we want to use a different set of certificates for XDR client traffic and normal client traffic. Let’s try to implement that use-case in this guide.

Here are our three sets of certificates ‘spkOPSTeam’, ‘spkDEVTeam’, and ‘spkQATeam’ issued by common CA ‘spkCA’:

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=Aerospike Inc, OU=operations/emailAddress=operations@aerospike.com, L=Bangalore, ST=Karnataka, C=IN, CN=spkCA
        Validity
            Not Before: Sep 14 09:07:01 2018 GMT
            Not After : Sep 14 09:07:01 2019 GMT
        Subject: C=IN, ST=Karnataka, O=Aerospike Inc, OU=operations, CN=spkOPSTeam
...

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 2 (0x2)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=Aerospike Inc, OU=operations/emailAddress=operations@aerospike.com, L=Bangalore, ST=Karnataka, C=IN, CN=spkCA
        Validity
            Not Before: Sep 14 09:08:34 2018 GMT
            Not After : Sep 14 09:08:34 2019 GMT
        Subject: C=IN, ST=Karnataka, O=Aerospike Inc, OU=operations, CN=spkDEVTeam
...

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 3 (0x3)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=Aerospike Inc, OU=operations/emailAddress=operations@aerospike.com, L=Bangalore, ST=Karnataka, C=IN, CN=spkCA
        Validity
            Not Before: Sep 14 09:09:27 2018 GMT
            Not After : Sep 14 09:09:27 2019 GMT
        Subject: C=IN, ST=Karnataka, O=Aerospike Inc, OU=operations, CN=spkQATeam
...

Now we will be using the “spkDEVTeam” certificate for XDR traffic and “spkQATeam” certificate for normal client traffic. The configuration on server will be as shown above. Now the XDR configuration on source cluster nodes will be:

xdr {
        xdr-digestlog-path /opt/aerospike/xdr/digestlog 1G
        enable-xdr true
        datacenter DC1 {
                tls-node 172.17.0.4 spkOPSTeam 4333
                tls-name spkDEVTeam
        }
}

network {
        tls spkDEVTeam {
                        ca-file /app/TLS-Cert-Gen-Tool/spkCACert.pem
                        key-file /app/TLS-Cert-Gen-Tool/spkDEVTeamKey.pem
                        cert-file /app/TLS-Cert-Gen-Tool/spkDEVTeamCert.pem
        }
        ....
        ....
}

The tls-name parameter in above xdr configuration will indicate which tls-parameters and certificates to use on an outgoing XDR client connection. "tls-node" contains the IP address, tls-name and tls-port number of remote cluster.

Now with this configuration, our XDR client is ready to connect to remote cluster.

Inserting record on XDR source using AQL:

root@6c5d3788b1f2:/# aql -h 172.17.0.5
Seed:         172.17.0.5
User:         None
Config File:  /etc/aerospike/astools.conf /root/.aerospike/astools.conf 
Aerospike Query Client
Version 3.15.3.14
C Client Version 4.3.12
Copyright 2012-2017 Aerospike. All rights reserved.
aql> insert into test.testset(PK, name, id, message) values(1, "XDR-client", 1, "Data from XDR")
OK, 1 record affected.

aql> q

Now verifying the data from XDR client on destination (TLS enabled cluster) via AQL using “spkQATeam” certificates.

root@758a4c167dfa:/app/TLS-Cert-Gen-Tool# aql --tls-enable --tls-certfile=/app/TLS-Cert-Gen-Tool/spkQATeamCert.pem --tls-keyfile=/app/TLS-Cert-Gen-Tool/spkQATeamKey.pem --tls-cafile=/app/TLS-Cert-Gen-Tool/spkCACert.pem -h "172.17.0.4:spkOPSTeam:4333"
Seed:         172.17.0.4:spkOPSTeam:4333
User:         None
Config File:  /etc/aerospike/astools.conf /root/.aerospike/astools.conf 
Aerospike Query Client
Version 3.15.3.14
C Client Version 4.3.12
Copyright 2012-2017 Aerospike. All rights reserved.
aql> select * from test.testset
+--------------+----+-----------------+
| name         | id | message         |
+--------------+----+-----------------+
| "XDR-client" | 1  | "Data from XDR" |
+--------------+----+-----------------+
1 row in set (0.148 secs)

OK

aql> q

We can see that we are able to connect to the “spkOPSTeam” cluster using both set of certificates(“spkQATeam” and “spkDEVTeam”).