Configuring Bacula to Use TLS to Encrypt Connections

UPDATE: There is a new version of this post located here.


ARCHIVED VERSION

Bacula is a powerful, open-source backup system that can be installed in CentOS, Fedora, and RedHat (RHEL).

The best write-up of the initial configuration can be found on Cotton’s page here. If you are have not yet set up Bacula, please visit her site and follow the excellent directions. Then, come back here to set up a secure TLS connection for your server and backup clients.

Note: Please make sure that you can successfully run a backup before you attempt to enable TLS. This will ensure that any issues you encounter are related solely to the TLS configuration and not some other issue.

The steps involved include setting options through Webmin and via the command line. While Webmin makes it very easy to control Bacula, not all of the TLS options are exposed through Webmin, and there is no way to get TLS to work without using the command line.

Example computer names used in this document

Bacula server: server1.example.com

Bacula client: client1.example.com


Regarding Certificate Authorities

You must be able to sign the certificates you will be issuing for each of your servers and backup clients. This can be accomplished either through the use of an actual Certificate Authority like CAcert.org, or you can set up your own, private Certificate Authority on your Bacula server.

If you already have your own Certificate Authority, skip to the next section on creating the certificates and keys for your server(s) and clients.

Setting up your own, private Certificate Authority

Run the following command:

  1. Press enter to create a Certificate Authority.
  2. Enter a passphrase.
  3. Fill in the country, state, city, and organization names (optional — you can just press enter to accept the defaults).
  4. IMPORTANT: When asked for the “Common Name,” enter the FQDN (fully qualified domain name) of the server on which you are running this command (the server which will be your Certificate Authority). Using the names in this example document, you would fill in the following: server1.example.com
  5. Enter an email address for the  server administrator (optional).
  6. The challenge password and optional company name can be left blank. (Just press enter to accept the defaults.)

This will create a file called cacert.pem in /etc/pki/CA/ (there is also a private key created called cakey.pem stored in /etc/pki/CA/private/./). The cacert.pem file is what you will use when asked for the “TLS PEM certificate authority file” in bacula.

You could create a certs directory under /etc/bacula to store a copy of this file and the other certificates and keys you will create.


Create a certificate and key file for your server and clients

Run the following command once for your bacula server and each of the clients:

  1. Enter a passphrase for the key file that will be created.
  2. Fill in the country, state, city, and organization names (optional — you can just press enter to accept the defaults).
  3. IMPORTANT: The “Common Name” is the FQDN (fully qualified domain name) of the computer that this certificate and key file is intended for. Using our example computer names, the first time you run this command, you would enter server1.example.com while the second time you would enter client1.example.com.
  4. The challenge password and optional company name can be left blank.

The command creates two files — newreq.pem (a request file) and newkey.pem (a password protected key file).

Sign the certificate request

Run the following command to sign the newreq.pem file:

  1. Enter the passphrase you assigned to the keyfile in the previous step, and choose Y to sign.

The signed certificate is called newcert.pem.

Strip the passphrase from the key file so it can be used by Bacula

The newkey.pem file cannot be used by the Bacula daemon since the daemon does not support password-protected key files. Luckily, there is an easy command to strip the passphrase. Run the following:

This creates another key file, this time without a passphrase, called newkey-daemon.pem.

Rename the request, certificate, and key files

You should rename these files to reflect the computer for which they were created. Technically you will not use the request file again, but I recommend keeping it around.

A good procedure is to name the files with the FQDN of the computer for which they were created.

For server1.example.com, rename the files like this:

  • newreq.pem > server1.example.com.req
  • newcert.pem > server1.example.com.crt
  • newkey.pem > server1.example.com.key
  • newkey-daemon.pem > server1.example.com-daemon.key

 

Copy the certificate and key files in appropriate places on the server and client(s)

One place where these files can be kept is in the /etc/bacula directory. There are three files used by Bacula:

  • The cacert.pem certificate authority file.
  • The machine key file.
  • The machine certificate file.

Bacula configuration

While Webmin can be used to set some of these settings, the interface is not complete and you will not be able to set all of the options. Therefore, the following commands require you to edit the Bacula configuration files directly.

/etc/bacula/bacula-dir.conf

In the Directory section, add the following:

Director section:

Clients section (repeat for each client you have defined). Both of the example computers “client1” and “server1” are backup clients to in our Bacula installation:

/etc/bacula/bconsole.conf

This file is used by the bconsole utility to communicate with Bacula. This file cannot be edited via Webmin, but if these options are not filled out, Webmin will no longer be able to manage Bacula.

/etc/bacula/bacula-sd.conf

The storage daemon on the server should be configured to use TLS.

/etc/bacula/bacula-fd.conf (On the client)

Note: This is where Webmin screws up. It doesn’t add the TLS options in the director section. Instead, it only adds it to the FileDaemon section. However, the TLS options must be listed in both places for this to work!

That’s it! Restart the Bacula daemons, and you should be good to go!

Comments

comments

8 Comments

  1. I got some great info out of this post, thanks for sharing!
    I’d like to add one more detail to help future googlers.

    I was getting error messages like:
    10-Mar 13:35 server1.example.com-dir JobId 0: Fatal error: Authorization problem: Remote server requires TLS.
    10-Mar 13:35 server1.example.com-dir JobId 0: Fatal error: bnet.c:343 TLS host certificate verification failed. Host name “client1.example.com” did not match presented certificate
    10-Mar 13:35 server1.example.com-dir JobId 0: Fatal error: TLS negotiation failed with FD at “client1.example.com:9102”.

    To fix this add:
    TLS Allowed CN = “server1.example.com”
    to the Director sections of
    /etc/bacula/bacula-dir.conf
    /etc/bacula/bacula-fd.conf (On the client)

    (Of course using your own server names instead of server1.example.com and client1.example.com)

    Then everything worked fine after that.

  2. I followed line by line the tutorial and I got the same error reported above, even though I have configured the TLS Allowed CN, as nim sad.
    The only way I could got it to work was.

    “Server Side” – Configure the bacula-dir.conf(server side) on the Clients section these certificates, for all the client machines:
    TLS Certificate = /etc/bacula/certs/server1.example.com.crt
    TLS Key = /etc/bacula/certs/server1.example.com-daemon.key
    TLS CA Certificate File = /etc/bacula/certs/cacert.pem

    “Client Side” – And in the bacula-fd.conf on the client machines, I configured on director and on FD section theses certificates, for all client machines:
    TLS Certificate = /etc/bacula/certs/server1.example.com.crt
    TLS Key = /etc/bacula/certs/server1.example.com-daemon.key
    TLS CA Certificate File = /etc/bacula/certs/cacert.pem

    Of course change the server1 and client1 for your machine names.

  3. Thanks for this really great article. In the renaming section, I think “newkey.pem > server1.example.com-daemon.key” perhaps should be “newkey-daemon.pem > server1.example.com-daemon.key”? That worked for me.

  4. Adding my thanks here too, the instructions work equally well for Bareos. I spent a very long time trying to get it to work with certs signed by public CAs, but never found the exact right incantation, so eventually went with certs from TinyCA. Still not 100% comfortable with situating client private keys off the host they belong to, but happy anyway that it’s working, and I’m able to back up my externally hosted box.

  5. Hello,
    I have set up bacula server and I have configure the encryption TLS as chown in this tutorial, but I don’t know how to set a remote client to use TLS communication with the bacula server, I don’t know exactly how to manage the certificates with the client. Please, help me

2 Trackbacks / Pingbacks

  1. Bacula: Set up backup source (client computer or server) | TecloTech IT Tips & Tricks
  2. Configuring Bacula to Use TLS to Encrypt Connections – UPDATED VERSION 2 | TecloTech IT Tips & Tricks

Leave a Reply to JB Cancel reply

Your email address will not be published.


*