I wrote this some time ago, but never published it. Here we go…
Bacula is a fantastic backup solution. It’s open source. It uses a database to keep track of backups.
I’ve been writing recently about using ssl-admin as a certificate authority tool. Today, I started using ssl-admin for generating certificates for my backup clients.
In this post, I’m using Bacula 5.2.12 and using this reference page as a guide.
I started playing with a couple of TLS directives to see if / how they worked. I added the following configuration items to an existing bacula client which was already using TLS:
TLS Allowed CN = dir001.example.org TLS Verify Peer = yes
The first line says: Only allow this host to contact me. Nobody else. This directive can be specified multiple times. This line contains the Common Name (or hostname) in the certificate used by the Bacula Director which is allowed to communicate with this Bacula client.
The Verify Peer directives is documented as a server-only directive. However, my testing shows that clients take note of this directive as well.
For example, if I change dir001.example.org to invalid.example.org:
TLS Allowed CN = invalid.example.org TLS Verify Peer = yes
TAnd then, restart bacula-fd, and run a status fron bconsole, I get:
*st client=bast-fd Connecting to Client bast-fd at bast.example.org:9102 Failed to connect to Client bast-fd. ==== You have messages. *m 03-Jan 19:11 bacula-dir JobId 0: Error: openssl.c:86 TLS read/write failure.: ERR=error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number 03-Jan 19:11 bacula-dir JobId 0: Fatal error: Bad response from File daemon at "bast.example.org:9102" to Hello command: ERR=Broken pipe *
If I then change ‘TLS Verify Peer = no’:
TLS Allowed CN = invalid.example.org TLS Verify Peer = no
I restart bacula-fd, and then ask for a status, it succeeds.
Clearly, the client is taking note of ‘TLS Verify Peer’ despite what the documentation claims.
