19. 10. 2021 Alessandro Valentini NetEye

TLS Certificate Authorities on Satellites

Since the introduction of Satellites in NetEye 4.19 one of the most frequently asked questions has been how CAs and Certificates work on Satellites. In this short blog post I’ll try to answer this question.

First of all a bit of introduction about Satellites. A Satellite is a NetEye machine connected to a Master, which performs several tasks related to distributed monitoring. At the moment of this blog post (NetEye 4.20) the two most relevant features of Satellites are the NATS instance configured as a NATS leaf, and an Icinga 2 instance configured as an Icinga 2 satellite. The former allows data to be sent from the Satellite zone to the Master (for example, metrics collected via Telegraf agents) from hosts which are unable to directly contact the Master, while the latter allows the Master to delegate check execution to the Satellite for specific hosts.

All communications between Master and Satellites are secured via TLS and therefore certificates are required. On a satellite we have three different CAs installed by default:

usr/share/pki/ca-trust-source/anchors/master-root-ca.crt which is the certificate authority of the Master
neteye/local/icinga2/data/lib/icinga2/certs/ca.crt which is the Icinga 2 CA of the master
/usr/share/pki/ca-trust-source/anchors/root-ca.crt which is the certificate generated directly on the Satellites. This CA can also be found under /root/security/ca/root-ca.crt

Let’s see how they are used!

NATS communications between Master and Satellites are secured using certificates generated on the Master, where the related certificate authority is master-root-ca.crt. The master’s CA key is not present on Satellites for security reasons: if a Satellite were to be compromised, an attacker could not then generate valid certificates for the Master.

Unlike other services in NetEye, Icinga 2 uses its own CA. Since the certificates to authenticate icinga2-satellite to icinga2-master are generated on the Master side, we need to also copy this CA to the Satellite.

root-ca.crt is the CA used to validate all certificates generated on the Satellites’ side: for example the Telegraf local instance authenticates to the Satellite’s NATS using a certificate related to this CA. If you check the Satellite NATS configuration, you will find server and client certificates valid for this CA used to secure Host-to-Satellite communications.

As a general rule of thumb, the Satellite user should not care about master-root-ca.crt, ca.crt and the related certificates, since they are generated on the Master side and are automatically handled by the neteye satellite setup command. Instead, if you need to connect an external agent to NATS for example, you should generate certificates using root-ca.crt and the related key.