This article is a follow-up from the Crowdsec multi-server setup. It applies to a configuration with at least two servers (referred to as
server-1 and one of
To address security issues posed by clear http communication in our previous crowdsec multi-server installation, we propose solutions to achieve communication between Crowdsec agents over encrypted channels. On top of that, the third solution allows
server-3 to trust
server-1 identity, and avoid man-in -the -middle attacks.
Using self-signed certificates
Create the certificate
First we have to create a certificate. This can be achieved with the following one-liner.
openssl req -x509 -newkey rsa:4096 -keyout encrypted-key.pem -out cert.pem -days 365 -addext "subjectAltName = IP:172.31.100.242"
For now crowdsec is not able to ask for the passphrase of the private key when starting. Thus we have the choice to decipher by hand the private key each time we start or reload crowdsec or store the key unencrypted. In any way to strip the passphrase one can do:
openssl rsa -in encrypted-key.pem -out key.pem
Then, the unencrypted key file can be safely deleted after Crowdsec is started.
Configure crowdsec for using a self-signed certificate
server-1 we have to tell crowdsec to use the generated certificate. Hence, the
tls.key_file option in the
api.server section of the following
/etc/crowdec/config.yaml excerpt set to the generated certificate file.
api: server: log_level: info listen_uri: 10.0.0.1:8080 profiles_path: /etc/crowdsec/profiles.yaml online_client: # Crowdsec API credentials (to push signals and receive bad tls: cert_file: /etc/crowdsec/ssl/cert.pem key_file: /etc/crowdsec/ssl/key.pem
On the client side configuration changes happen in two files. First we have to modify
/etc/crowdec/config.yaml to accept self-signed certificates by setting the
We have to change
https in the
/etc/crowdsec/local_api_credentials.yaml file too in order to reflect the changes. This small change has to be done on all three servers (