Bacula: TLS Allowed CN

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  =
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 to

TLS Allowed CN  =
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
Failed to connect to Client bast-fd.
You have messages.
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 "" to Hello command: ERR=Broken pipe

If I then change ‘TLS Verify Peer = no’:

TLS Allowed CN  =
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.

Website Pin Facebook Twitter Myspace Friendfeed Technorati Digg Google StumbleUpon Premium Responsive

Leave a Comment