How To: Enable Bacula TLS Encryption, Protect Your Data

Note that this is an updated version of an earlier post on enabling Bacula TLS encryption (TLS is a subset of SSL).
We would love to hear your feedback on this entry, so please let us know if you have questions or comments.

Bacula is a powerful, open-source backup system that can be installed in Ubuntu, CentOS, Scientific Linux, and RedHat (RHEL), among others.
If you’ve not already installed Bacula, please visit the Unixmen site and follow their excellent directions regarding the initial setup. 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 encrypt communications with TLS. This will ensure that any issues you encounter are related solely to the TLS SSL 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.
As a background, you must issue certificates to each of the clients you wish to back up as well as the Bacula server. You can create your own “CA” (Certificate Authority), or you can use a third-party site to create valid certificates. This article will walk you through creating your own CA if needed.

Example computer names used in this document

Bacula server:
Bacula client:

STEP 1: Establish the CA (Certificate Authority)

If you already have access to your own CA (Certificate Authority) like (or have previously created your own, private CA), please skip to the next section on creating the certificates and keys for your server(s) and clients. Note that you will need a copy of the pem or crt file for the CA that you can install in the /etc/bacula or /etc/bacula/certs directory.
Otherwise, follow along with these steps to create a private CA that will be used to sign all of the certificates for your Bacula clients and servers.

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:
  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 the Bacula settings (more on this later).
To make things easy, copy the cacert.pem file to /etc/bacula (optional: make a subdirectory called “certs” to store all the certificates and related files).

STEP 2: Create a certificate and key file for your server and clients

Run the following command for each of your Bacula server(s) and 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 while the second time you would enter
  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 so you can keep track of them

You should rename these files to reflect the computer for which they were created. You can technically discard the request (req) file, but it doesn’t hurt to keep it around.
For, rename the files as shown (follow a similar process for each client certificate):

  • newreq.pem >
  • newcert.pem >
  • newkey.pem >
  • newkey-daemon.pem >

STEP 3: Copy the certificate and key files to /etc/bacula on the server and client(s)

Out of all the files that have been created so far, Bacula needs three of them for each server or client computer:

  1. The CA (Certificate Authority) pem file – cacert.pem
  2. The server or client certificate (crt) file – servername.crt (this name will be different for each client or server computer but should end in crt)
  3. The server or client daemon key file (the one with the passphrase stripped out) – servername-daemon.key (this name will be different for each client or server computer but should end in -daemon.key)

The server will need copies of the certificates and key files for itself as well as for each client. The clients only need copies of the CA, their crt, and their key file.
Copy all files to /etc/bacula or /etc/bacula/certs.

STEP 4: Bacula Director Configuration (bacula-dir.conf)

Edit /etc/bacula/bacula-dir.conf on the Bacula server:

In the Director section, add the following items in bold text:

In the Clients section, add the following items in bold text (repeat this for each client defined): Clients section (repeat for each client you have defined):

STEP 5: Bacula Console Configuration (bconsole.conf)

Edit /etc/bacula/bconsole.conf on the Bacula server, in order to allow the bconsole command to communicate with the Bacula server. Add the following items listed in bold text:

STEP 6: Bacula Storage Daemon Configuration (bacula-sd.conf)

Edit /etc/bacula/bacula-sd.conf on the Bacula server, adding the text shown below in bold:

 STEP 7: Bacula File Daemon Configuration (bacula-fd.conf)

Edit /etc/bacula/bacula-fd.conf on each client by adding the following text show in bold. Note that if you are using Webmin, this will not work correctly since Webmin adds these options only to the “FileDaemon” section, but they must also appear in the Director section:

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


  1. Thanks for the great tutorial. I believe there is one mistake though:
    – In Step 4 the Client’s key definition should be “TLS Key = /etc/bacula/certs/”
    – In Step 7 when setting up the bacula-fd.conf you need to specify the client’s certificate under the “Director” section:
    So on the client’s bacula-fd.conf it would look like this:
    Director {
    Name = bacula-dir
    Password = “myPassword”
    TLS Certificate = /etc/bacula/certs/
    TLS Key = /etc/bacula/certs/
    TLS CA Certificate File = /etc/bacula/certs/cacert.pem
    TLS Enable = yes
    TLS Require = yes

  2. I’ve followed carefully each step. Creating self signed certificates in the Terminal CLI, gnoMint and tinyCA2 but still can’t make it work out. Server without TLS works perfectly fine but the TLS config come up always with same error:
    Negociación TLS fallida
    Director authorization problem.
    Most likely the passwords do not agree.
    I’m more than lost. If you can help with some lead, I’ll really appreciate it.
    All the best!!

    • Hi, I believe that you’ll find the issue lies either in /etc/bacula/bacula-dir.conf (Step 4) or in the Director section of /etc/bacula/bacula-fd.conf (Step 7).
      The passwords in these two sections must match.
      On the server, in /etc/bacula/bacula-dir.conf, make sure that the TLS certificate and key files are the correct ones for the server:
      TLS Certificate = /etc/bacula/certs/
      TLS Key = /etc/bacula/certs/
      TLS CA Certificate File = /etc/bacula/certs/cacert.pem
      On the client, in etc/bacula/bacula-fd.conf, make sure that the TLS certificate and key files are the ones for the client machine:
      TLS Certificate = /etc/bacula/certs/
      TLS Key = /etc/bacula/certs/
      TLS CA Certificate File = /etc/bacula/certs/cacert.pem
      Please let me know if you need more help with this!

  3. I have this error [root @ bacula74mysql bacula-7.2.0] # sudo bacula-dir -tc /etc/bacula/bacula-dir.conf
    29-Jan 20:47 bacula-dir JobId 0: Fatal error: TLS required but not configured in Bacula.
    how i can enable tls
    my configurations are this
    irector { # define myself
    Name =
    DIRport = 9101 # where we listen for UA connections
    QueryFile = “/etc/bacula/query.sql”
    WorkingDirectory = “/opt/bacula/working”
    PidDirectory = “/var/run”
    Maximum Concurrent Jobs = 20
    Password = “ti5npd6JlPEc9Hr28+I7t8vMafR47BcFyciiUhEpUv5i” # Console password
    Messages = Daemon
    TLS Certificate = /etc/bacula/cert/
    TLS Key = /etc/bacula/cert/
    TLS CA Certificate File = /etc/bacula/cert/cacert.pem
    TLS Enable = yes
    TLS Require = yes
    TLS Verify Peer = yes

  4. Thanks for the article, it was most helpful. I did hit a couple of stumbling blocks with this though.
    Firstly I had to specify the client certificate in bconsole.conf rather than the listed server certificate.
    The other gotcha was when I issued the client certificates with my own CA, but by default was signing all certs as serverAuth in the extendedKeyUsage. I’m using Bareos as opposed to Bacula, so this may not apply to that, but Bareos is strict about the specified certifcate usage and I needed to reissue the certificate with clientAuth as the extended key usage value. It might help others like me if that necessity is mentioned in section 2 (bconsole reported ‘Authorization problem with Director’, ‘Most likely the passwords do not agree’, so that may be the problem that Jorge Garay ran into).
    Thanks again for taking the time to share your knowledge, it’s very much appreciated.

  5. Hi I need help! I want to know which cacert.pem to used for client. Cacert.pem from Server only or cacert.pem from client or both. I’m confused.

1 Trackback / Pingback

  1. Configuring Bacula to Use TLS to Encrypt Connections | TecloTech IT Tips & Tricks

Leave a Reply

Your email address will not be published.