Bacula TLS - Communications Encryption

Bacula Transport Layer Security (TLS) is built-in network encryption code to provide secure network transport similar to that offered by stunnel or ssh. The Bacula TLS encryption applies only to information transmitted across a network, so the data written to Volumes by the Storage daemon is not encrypted by this code. For data encryption, please see the PKI options described in Data Encryption chapter of this manual.

The Bacula encryption implementation was initially written by Landon Fuller.

Supported features of this code include:

• Client/Server TLS Requirement Negotiation
• TLSv1.2 Connections with Server and Client Certificate Validation
• Forward Secrecy Support via Diffie-Hellman Ephemeral Keying
• TLS-PSK is used by defaultnotestarting with version 12.0 when TLS certificates are not configured.

This document will refer to both “server” and “client” contexts. These terms refer to the accepting and initiating peer, respectively. In addition, each of the three daemons (Director, File daemon, Storage daemon) as well as the user interface programs (bconsole, tray monitor, ...) use the same TLS configuration directives. When we are speaking of one or all of these daemons/programs, we will generally refer to them as a “component”.

Diffie-Hellman anonymous ciphers are not supported by this code. The use of DH anonymous ciphers increases the code complexity and places explicit trust upon the two-way CRAM-MD5 implementation. CRAM-MD5 is subject to known plaintext attacks, and it should be considered considerably less secure than PKI certificate-based authentication.

Appropriate autoconf macros have been added to detect and use OpenSSL if enabled on the ./configure line with -with-openssl

TLS Configuration Directives

Additional configuration directives have been added to all the components (daemons) (Director, File daemon, and Storage daemon) as well as the various different Console programs).

Note that for the connection between a Storage Daemon and a File Daemon or between two Storage Daemons, the TLS directives that will be used are the ones defined in the Client FileDaemon resource and in the Storage Storage resource.

The default value of the directive TLS-PSK Enable is yes, if both TLS Enable and TLS-PSK Enable are enable on both side, then Bacula will use TLS certificates.

If none of TLS or TLS-PSK are enabled, then the TLS directives have no effect.

These new directives are defined as follows:

TLS Enable = <yes|no>

Enable TLS support. If TLS is not enabled, none of the other TLS directives have any effect. In other words, even if you set TLS Require = yes you need to have TLS enabled or TLS will not be used.

TLS PSK Enable = <yes|no>

Enable or Disable automatic TLS PSK support. TLS PSK is enabled by default between all Bacula components. The Pre-Shared Key used between the programs is the Bacula password. If both TLS Enable and TLS PSK Enable are enabled, the system will use TLS certificates.

TLS Require = <yes|no>

Require TLS or TLS-PSK encryption. This directive is ignored unless one of TLS Enable or TLS PSK Enable is set to yes. If TLS is not required while TLS or TLS-PSK are enabled, then the Bacula component will connect with other components either with or without TLS or TLS-PSK

If TLS or TLS-PSK is enabled and TLS is required, then the Bacula component will refuse any connection request that does not use TLS.

TLS Authenticate = <yes|no>

When TLS Authenticate is enabled, after doing the CRAM-MD5 authentication, Bacula will also do TLS authentication, then TLS encryption will be turned off, and the rest of the communication between the two Bacula components will be done without encryption. If TLS-PSK is used instead of the regular TLS, the encryption is turned off after the TLS-PSK authentication step.

If you want to encrypt communications data, use the normal TLS directives but do not turn on TLS Authenticate.

TLS Certificate = <Filename>

The full path and filename of a PEM encoded TLS certificate. It will be used as either a client or server certificate, depending on the connection direction. PEM stands for Privacy Enhanced Mail, but in this context refers to how the certificates are encoded. This format is used because PEM files are base64 encoded and hence ASCII text based rather than binary. They may also contain encrypted information.

This directive is required in a server context, but it may not be specified in a client context if TLS Verify Peer is set to no in the corresponding server context.

Example:

File Daemon configuration file (bacula-fd.conf), Director resource configuration has TLS Verify Peer = no:

  Director {
    Name = bacula-dir
    Password = "password"
    Address = director.example.com
    
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    TLS Verify Peer = no
    TLS CA Certificate File = /opt/bacula/ssl/certs/root_cert.pem
    TLS Certificate = /opt/bacula/ssl/certs/client1_cert.pem
    TLS Key = /opt/bacula/ssl/keys/client1_key.pem
  }

Having TLS Verify Peer = no, means the File Daemon, server context, will not check Director’s public certificate, client context. There is no need to specify TLS Certificate File neither TLS Key directives in the Client resource, director configuration file. We can have the below client configuration in bacula-dir.conf:

  Client {
    Name = client1-fd
    Address = client1.example.com
    FDPort = 9102
    Catalog = MyCatalog
    Password = "password"
    ...
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    TLS CA Certificate File = /opt/bacula/ssl/certs/ca_client1_cert.pem
  }

TLS Key = <Filename>

The full path and filename of a PEM encoded TLS private key. It must correspond to the TLS certificate.

TLS Verify Peer = <yes|no>

Verify peer certificate. Instructs server to request and verify the client's X.509 certificate. Any client certificate signed by a known-CA will be accepted. Additionally, the client's X509 certificate Common Name must meet the value of the Address directive. If the TLSAllowed CN onfiguration directive is used, the client's x509 certificate Common Name must also correspond to one of the CN specified in the TLS Allowed CN directive. This directive is valid only for a server and not in client context. The default is yes.

TLS Allowed CN = <string list>

Common name attribute of allowed peer certificates. This directive is valid for a server and in a client context. If this directive is specified, the peer certificate will be verified against this list. In the case this directive is configured on a server side, the allowed CN list will not be checked if TLS Verify Peer is set to no (TLS Verify Peer is yes by default). This can be used to ensure that only the CN-approved component may connect. This directive may be specified more than once.

In the case this directive is configured in a server side, the allowed CN list will only be checked if TLS Verify Peer = yes (default). For example, in bacula-fd.conf, Director resource definition:

  Director {
    Name = bacula-dir
    Password = "password"
    Address = director.example.com
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    # if TLS Verify Peer = no, then TLS Allowed CN will not be checked.
    TLS Verify Peer = yes
    TLS Allowed CN = director.example.com
    TLS CA Certificate File = /opt/bacula/ssl/certs/root_cert.pem
    TLS Certificate = /opt/bacula/ssl/certs/client1_cert.pem
    TLS Key = /opt/bacula/ssl/keys/client1_key.pem
  }

In the case this directive is configured in a client side, the allowed CN list will always be checked.

  Client {
    Name = client1-fd
    Address = client1.example.com
    FDPort = 9102
    Catalog = MyCatalog
    Password = "password"
    ...
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    # the Allowed CN will be checked for this client by director
    # the client's certificate Common Name must match any of
    # the values of the Allowed CN list
    TLS Allowed CN = client1.example.com
    TLS CA Certificate File = /opt/bacula/ssl/certs/ca_client1_cert.pem
    TLS Certificate = /opt/bacula/ssl/certs/director_cert.pem
    TLS Key = /opt/bacula/ssl/keys/director_key.pem
  }

If the client doesn’t provide a certificate with a Common Name that meets any value in the TLS Allowed CN list, an error message will be issued:

16-Nov 17:30 bacula-dir JobId 0: Fatal error: bnet.c:273 TLS certificate
verification failed. Peer certificate did not match a required commonName
16-Nov 17:30 bacula-dir JobId 0: Fatal error: TLS negotiation failed with FD at
"192.168.100.2:9102".

TLS CA Certificate File = <Filename>

The full path and filename specifying a PEM encoded TLS CA certificate(s). Multiple certificates are permitted in the file. One of TLS CA Certificate File or TLS CA Certificate Dir are required in a server context, unless TLS Verify Peer (see above) is set to no, and are always required in a client context.

TLS CA Certificate Dir = <Directory>

Full path to TLS CA certificate directory. In the current implementation, certificates must be stored PEM encoded with OpenSSL-compatible hashes, which is the subject name's hash and an extension of .0. One of TLS CA Certificate File or TLS CA Certificate Dir are required in a server context, unless TLS Verify Peer is set to no, and are always required in a client context.

TLS DH File = <Directory>

Path to PEM encoded Diffie-Hellman parameter file. If this directive is specified, DH key exchange will be used for the ephemeral keying, allowing for forward secrecy of communications. DH key exchange adds an additional level of security because the key used for encryption/decryption by the server and the client is computed on each end and thus is never passed over the network if Diffie-Hellman key exchange is used. Even if DH key exchange is not used, the encryption/decryption key is always passed encrypted. This directive is only valid within a server context.

To generate the parameter file, you may use openssl:

openssl dhparam -out dh4096.pem -5 4096

Creating a Self-Signed Certificate

A self-signed certificate for use with the Bacula TLS that will work, but will not allow proper certificate validation can be created easily. The .pem file containing both the certificate and the key valid for about ten years can be created as follows:

openssl req -new -x509 -nodes -out bacula.pem -keyout bacula.pem -days 3650

The above command will ask a number of questions. You may simply answer each of them by entering a return, or if you wish you may enter your own data.

Note, however, that self-signed certificates will only work for the outgoing end of connections. For example, in the case of the Director making a connection to a File Daemon, the File Daemon may be configured to allow self-signed certificates, but the certificate used by the Director must be signed by a certificate that is explicitly trusted on the File Daemon end.

This is necessary to prevent “man in the middle” attacks from tools such as ettercap. Essentially, if the Director does not verify that it is talking to a trusted remote endpoint, it can be tricked into talking to any malicious 3 party who is relaying and capturing all traffic by presenting its own certificates to the Director and File Daemons. The only way to prevent this is by using trusted certificates, so that the man in the middle is incapable of spoofing the connection using his own.

Getting a CA Signed Certificate

The process of getting a certificate that is signed by a CA is quite a bit more complicated. You can purchase one from a number of PKI vendors, but that is not at all necessary for use with Bacula.

To get a CA signed certificate, you will either need to find a friend that has setup his own, trusted CA, or to become a CA yourself, and thus you can sign all your own certificates. The book OpenSSL by John Viega, Matt Mesier & Pravir Chandra from O'ReillynoteThis link is valid as of the 27-september-2018 explains how to do it, or you can read the documentation provided in the Open-source PKI Book.

Example TLS Configuration Files

A few examples of the TLS portions of configuration files are shown, which should help you setting up your own.

For the examples in this section, we will consider three hosts named darkstar, arrakis and caladan, in order to have examples with components running in different machines. The following private key and public certificate files will be used:

* host darkstar.example.com:

/opt/bacula/ssl/keys/darkstar_key.pem
/opt/bacula/ssl//certs/darkstar_cert.pem

* host arrakis.example.com:

/opt/bacula/ssl/keys/arrakis_key.pem
/opt/bacula/ssl//certs/arrakis_cert.pem

* host caladan.example.com:

/opt/bacula/ssl/keys/caladan_key.pem
/opt/bacula/ssl//certs/caladan_cert.pem

The TLS Verify Peer = yes is present in the below examples to emphasize where it can be configured, but there is no need since this is the default value used by Bacula. This means that both server and client certificates will be checked in the TLS communication handshake. The Common Name (CN) in the peer certificate will be checked against the Address directive configured for the corresponding resource.

The TLS Allowed CN = <FQDN or IP address> is configured to ensure that only the peer certificates with a CN Subject field listed here are authorized to communicate. For example, consider the below certificate:

  # openssl x509 -in ../ssl/certs/arrakis_cert.pem -text -noout
  Certificate:
  Data:
    Version: 3 (0x2)
    Serial Number: 1 (0x1)
  Signature Algorithm: sha256WithRSAEncryption
  Issuer: C=US, ST=Yverdon-les-Bains, L=Vaud, O=Bacula Systems, CN=ca.baculasystems.com/emailAddress=example@baculasystems.com
  Validity
    Not Before: Sep 7 09:50:27 2016 GMT
    Not After : Dec 31 23:59:00 2021 GMT
  Subject: C=CH, ST=Madrid, O=BaculaSystems, CN=arrakis.example.com
  Subject Public Key Info:
  Public Key Algorithm: rsaEncryption
  Public-Key: (4096 bit)
  Modulus:
     00:ae:7f:3f:6f:22:27:c3:c5:f5:d3:d6:f9:fd:8f:
     a0:7c:40:33:4c:90:1e:43:b2:14:fa:d3:82:00:b0:
     88:df:71:43:29:f7:7b:de:b4:87:0a:52:80:43:f7:
     1a:c9:1f:0f:c1:7c:27:00:45:5b:c4:a3:c3:a0:4a:
     14:53:7b:f6:33:54:44:70:41:8c:50:70:a1:eb:50:
     7a:52:87:6d:6c:84:2e:e5:48:86:9c:60:48:96:8e:
     48:2c:4b:13:87:af:94:cf:56:c1:74:e9:f5:4b:f9:
     16:32:fe:3a:65:a1:ef:eb:99:97:1a:10:e6:7f:6e:
     f3:18:1f:1f:67:f7:2a:38:0b:4b:00:70:0b:34:37:
     8c:04:56:02:ec:41:43:35:0c:c5:0c:8a:b2:91:00:
     7c:39:95:65:1e:b4:49:44:f6:af:87:d9:27:1e:a2:
     74:b3:5d:98:ac:da:53:fe:f6:9b:ee:15:fa:34:29:
     14:48:90:d6:61:31:43:3e:c0:30:f6:59:bb:b8:00:
     3b:98:a3:e8:d5:73:f1:ff:f5:23:d5:ac:87:57:ce:
     18:9f:35:1f:c2:4d:ba:44:05:b4:e3:ba:47:17:6a:
     76:5c:84:5c:f9:ce:83:19:87:ff:67:5b:82:24:4a:
     35:99:b1:91:7c:43:c9:84:2f:d4:1d:cf:6f:23:84:
     13:ae:59:28:66:a5:da:a4:5d:14:a4:04:69:21:4b:
     dd:d3:68:a3:16:0e:5f:23:4d:51:12:10:e3:f5:24:
     38:51:67:bf:cf:73:10:9a:b3:44:ff:87:bf:23:47:
     db:36:f0:c4:4a:6a:16:21:1f:ec:3c:1e:a9:c8:84:
     b4:2e:e5:d7:a1:d7:29:57:69:be:67:e9:1f:f5:66:
     dc:4b:c8:89:58:53:cd:c3:63:5e:58:86:48:db:71:
     3b:9f:25:1a:91:27:93:bf:1f:20:49:fc:b9:5b:ea:
     ba:b5:29:28:f2:a2:10:c5:ed:1c:fa:75:11:d2:22:
     7a:fd:50:be:56:e7:13:b1:a6:59:3b:aa:4b:8e:54:
     4b:1a:10:d8:6b:9c:46:ce:d8:7e:9a:f5:e7:28:62:
     6b:25:7c:ad:e6:64:4c:c0:4e:dc:1a:d8:c6:20:68:
     8b:3a:7a:8d:86:df:2e:e5:ab:39:7d:a1:3a:84:19:
     55:9b:46:2c:81:19:77:2c:2f:ca:6f:49:e0:92:98:
     c5:36:5a:db:4c:d8:58:04:4c:af:17:38:0e:2c:b1:
     21:1d:8b:88:69:69:fa:de:e7:fc:f0:9a:1a:71:1b:
     5e:68:51:b1:ef:44:1c:d6:a4:2d:55:93:b8:4c:e7:
     e2:dc:5b:99:ed:79:3a:02:6e:4e:61:32:62:03:a8:
     be:b2:4d
   Exponent: 65537 (0x10001)
   X509v3 extensions:
     X509v3 Basic Constraints:
     CA:FALSE
   Netscape Comment:
     OpenSSL Generated Certificate
   X509v3 Subject Key Identifier:
     EC:FC:DC:5C:A5:50:1B:AE:B5:04:40:E3:C6:72:63:9F:F8:34:A3:89
   X509v3 Authority Key Identifier:
     keyid:3B:36:FF:19:37:DF:12:D1:78:CC:F7:88:13:25:3D:CD:62:59:0F:9B
   Signature Algorithm: sha256WithRSAEncryption
     6d:f0:74:43:a7:9a:1b:99:ee:9e:51:e8:9c:5f:4c:f3:c3:f4:
     ff:f5:5c:b4:e2:33:07:ed:fd:d5:09:e8:6f:b5:83:51:66:58:
     53:66:04:75:46:6b:5b:2a:ac:d8:54:78:df:de:d0:fc:6c:57:
     6e:0c:c9:3c:cf:62:64:63:cd:f3:a2:5b:fe:57:8c:12:7a:08:
     6a:53:b0:de:0e:c2:c7:35:9c:78:d5:27:98:05:b3:8c:54:fa:
     4f:0a:34:fc:4d:5f:14:93:5a:b1:86:2d:4a:74:e4:d8:83:e7:
     99:dd:36:56:a0:11:ff:d8:68:d2:62:13:72:96:4f:66:08:7c:
     f7:ce:7f:8f:2a:7d:c0:fc:fe:bf:1a:38:43:cc:01:aa:46:e4:
     ac:d7:be:65:51:a6:bc:6c:80:ed:54:76:0b:b8:b8:4b:a1:85:
     d5:9b:14:2b:65:19:cf:0f:65:5f:32:b8:9e:36:5c:c2:6f:92:
     7c:c5:db:90:11:40:db:e7:37:23:c5:78:1f:c0:09:c5:11:b8:
     06:30:3b:95:82:17:3e:49:51:7e:91:45:2e:a6:d1:89:1f:49:
     dc:6d:a9:1d:92:53:bd:ff:a2:cf:7b:8e:40:ab:96:4a:82:fd:
     5e:c7:04:53:2d:55:0c:78:57:03:5c:c1:6c:b1:12:ce:5f:be:
     10:9f:76:2c:5a:79:5a:a3:3c:68:ee:8c:69:c8:ac:cc:c5:09:
     fb:19:50:cb:5e:61:8a:9b:47:74:60:68:2a:94:49:6f:0f:22:
     78:6d:9b:ff:76:24:60:d1:ee:c6:59:59:e2:6f:f2:69:3f:ae:
     43:53:54:a1:ab:e0:ae:30:13:82:64:9c:ce:c1:fa:de:6a:7d:
     bb:94:a4:05:6e:03:84:d2:f1:f2:5d:1d:45:4c:bb:88:0b:6a:
     b6:74:8b:4b:fb:cf:99:6e:1d:ed:df:67:97:92:a7:0d:08:a7:
     57:be:7e:6e:06:13:f7:42:12:7a:05:aa:a9:1c:1b:1d:86:73:
     00:66:a7:07:88:d0:2d:eb:2b:dc:6e:e0:61:15:d9:ff:43:65:
     2d:99:c1:e6:80:ea:26:c4:08:ae:3c:12:ef:f0:6e:15:00:33:
     53:6a:c1:e3:14:5c:f3:ec:df:72:c1:ee:ca:ff:f6:c9:51:22:
     79:62:af:00:07:92:7c:0c:75:17:98:1d:b2:43:b2:fa:a7:41:
     d4:64:8e:3e:47:1c:f6:a0:aa:e3:30:d1:d7:5c:91:5c:ea:80:
     dc:31:8f:a2:40:fc:ac:4d:05:02:cb:c3:b4:f6:b5:98:58:7e:
     31:c2:0c:85:1b:a4:95:ed:77:bb:dc:95:12:81:45:6c:5c:2f:
     c4:7e:d3:86:9c:b0:1a:d4

If a component (director, file daemon, storage daemon or console) has TLS Allowed CN = arrakis.example.com, it will accept only connections from peers that have “CN=arrakis.example.com” in the subject field of their certificate. The TLS Allowed CN directive can have a list of values like TLS Allowed CN = darkstar.example.com, arrakis.example.com. This will permit the clients with CN Subject field equal to darkstar.example.com or arrakis.example.com to be allowed for connection. The below examples are configured with TLS Allowed CN to show where and how to configure this directive.

Enable TLS Communications Encryption Between Console and Director

Director and Console are on the Same “darkstar” Host

1. If you are using an anonymous console:
   You only need to define the TLS directives in the Director resource of both bacula-dir.conf and bconsole.conf files.
   • In bacula-dir.conf:
     

           Director {
             Name = darkstar-dir
             DIR Port = 9111
             DIR Address = darkstar.example.com
             QueryFile = "/usr/local/bacula/scripts/query.sql"
             WorkingDirectory = "/usr/local/bacula/working"
             PidDirectory = "/var/run"
             Maximum Concurrent Jobs = 10
             Password = "password"
             Messages = Daemon
             TLS Enable = yes
             TLS Require = yes
             TLS Verify Peer = yes
             TLS Allowed CN = darkstar.example.com
             TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
             TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
             TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
           }
     

   • In bconsole.conf:
     

           Director {
             Name = darkstar-dir
             DIRport = 9111
             Address = darkstar.example.com
             Password = "password"
             TLS Enable = yes
             TLS Require = yes
             TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
             TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
             TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
           }
     

2. If a named console is used:
   You only need to define the TLS directives in the Console resource of both bacula-dir.conf and bconsole.conf.
   • In bacula-dir.conf:
     There is no need to configure TLS in the Director resource as for option (here)
     

           Director {
             Name = darkstar-dir
             DIR Port = 9111
             DIR Address = darkstar.example.com
             QueryFile = "/usr/local/bacula/scripts/query.sql"
             WorkingDirectory = "/usr/local/bacula/working"
             PidDirectory = "/var/run"
             Maximum Concurrent Jobs = 10
             Password = "password"
             Messages = Daemon
           }
     

     Instead, the named Console resource has the TLS configuration:
     

           Console {
             Name = darkstar-con
             Password = "password"
             TLS Enable = yes
             TLS Require = yes
             TLS Verify Peer = yes
             TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
             TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
             TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
           }
     

   • In bconsole.conf:
     There is no need to configure TLS in the Director resource as for option (here):
     

           Director {
             Name = darkstar-dir
             DIRport = 9111
             Address = darkstar.example.com
             Password = "password"
           }
     

     Instead, the Console resource contains the TLS configuration:

           Console {
             Name = darkstar-con
             Password = "password"
             TLS Enable = yes
             TLS Require = yes
             TLS Verify Peer = yes
             TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
             TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
             TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
           }
     

Director and Console are on Different Hosts

If you have your Bacula Console installed on another host than the Director one, then it is more likely that different public certificate and private key files for director and for console are used. Let's consider “darkstart-dir” director on “darkstar.example.com” and “arrakis-con” console on “arrakis.example.com”.

Enable TLS Communications Encryption Between Console and Director

1. If you're using an anonymous console:
   
   • In bacula-dir.conf:
     

           Director {
             Name = darkstar-dir
             DIR Port = 9111
             DIR Address = darkstar.example.com
             QueryFile = "/usr/local/bacula/scripts/query.sql"
             WorkingDirectory = "/usr/local/bacula/working"
             PidDirectory = "/var/run"
             Maximum Concurrent Jobs = 10
             Password = "password"
             Messages = Daemon
             TLS Enable = yes
             TLS Require = yes
             TLS Verify Peer = yes
             TLS Allowed CN = darkstar.example.com
             TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
             TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
             TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
           }
     

   • In bconsole.conf:
     

           Director {
             Name = darkstar-dir
             DIRport = 9111
             Address = darkstar.example.com
             Password = "password"
             TLS Enable = yes
             TLS Require = yes
             TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
             TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
             TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
           }
     

2. If you are using a named console:
   • In bacula-dir.conf:
     There is no need to configure TLS in the Director resource as for option (here):
     

           Director {
             Name = darkstar-dir
             DIR Port = 9111
             DIR Address = darkstar.example.com
             QueryFile = "/usr/local/bacula/scripts/query.sql"
             WorkingDirectory = "/usr/local/bacula/working"
             PidDirectory = "/var/run"
             Maximum Concurrent Jobs = 10
             Password = "password"
             Messages = Daemon
           }
     

     Instead, the Console resource has the TLS configurations:
     

           Console {
             Name = arrakis-con
             Password = "password"
             TLS Enable = yes
             TLS Require = yes
             TLS Allowed CN = arrakis.example.com
             TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
             TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
             TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
           }
     

   • In bconsole.conf: It is not needed to configure TLS in the Director resource as for (here):
     

           Director {
             Name = darkstar-dir
             DIRport = 9111
             Address = darkstar.example.com
             Password = "password"
           }
     

     Instead, the Console resource needs the TLS configuration:
     

           Console {
             Name = arrakis-con
             Password = "password"
             TLS Enable = yes
             TLS Require = yes
             TLS Verify Peer = yes
             TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
             TLS Certificate = /usr/local/bacula/etc/ssl/certs/arrakis_cert.pem
             TLS Key = /usr/local/bacula/etc/ssl/keys/arrakis_key.pem
           }
     

Enable TLS Communications Encryption between Director and File Daemon

Director and File Daemon are on the Same “darkstar” Host

• In bacula-dir.conf:
  

      Client {
        Name = darkstar-fd
        Address = darkstar.example.com
        FD Port = 9112
        Catalog = MyCatalog
        Password = "password"
        AutoPrune = no
        Maximum Concurrent Jobs = 4
        TLS Enable = yes
        TLS Require = yes
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
      }
  

• In bacula-fd.conf:

      Director {
        Name = darkstar-dir
        Password = "password"
        TLS Enable = yes
        TLS Require = yes
        TLS Verify Peer = yes
        TLS Allowed CN = darkstart.example.com
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
      }
  

Director and File Daemon are on Different Hosts

Let's consider “darkstart-dir” director at “darkstar.example.com” and the “arrakis-fd” file daemon on “arrakis.example.com”.

• In bacula-dir.conf:
  

      Client {
        Name = arrakis-fd
        Address = arrakis.example.com
        FD Port = 9112
        Catalog = MyCatalog
        Password = "password"
        AutoPrune = no
        Maximum Concurrent Jobs = 4
        TLS Enable = yes
        TLS Require = yes
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
      }
  

• In bacula-fd.conf:
  

      Director {
        Name = darkstar-dir
        Password = "password"
        TLS Enable = yes
        TLS Require = yes
        TLS Require = yes
        TLS Verify Peer = yes
        TLS Allowed CN = arrakis.example.com
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/arrakis_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/arrakis_key.pem
      }
  

Enable TLS Communications Encryption Between Director and Storage Daemon

Director and Storage Daemon are on the Same “darkstar” Host

• In bacula-dir.conf:
  

      Storage {
        Name = VTL-storage
        SD Port = 9113
        Address = darkstar.example.com
        Password = "password"
        Device = "Virtual Tape Library"
        Autochanger = yes
        Media Type = VTL
        Maximum Concurrent Jobs = 30
        TLS Enable = yes
        TLS Require = yes
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
      }
  

• In bacula-sd.conf:
  

      Director {
        Name = darkstar-dir
        Password = "password"
        TLS Enable = yes
        TLS Require = yes
        TLS Verify Peer = yes
        TLS Allowed CN = darkstart.example.com
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
      }
  

Director and Storage Daemon are on Different Hosts

Let's consider the “darkstart-dir” director on “darkstar.example.com” and the “caladan-sd” storage daemon running on “caladan.example.com”.

• In bacula-dir.conf:
  

      Storage {
        Name = VTL-storage
        SD Port = 9113
        Address = caladan.example.com
        Password = "password"
        Device = "Virtual Tape Library"
        Autochanger = yes
        Media Type = VTL
        Maximum Concurrent Jobs = 30
        TLS Enable = yes
        TLS Require = yes
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
      }
  

• In bacula-sd.conf:
  

      Director {
        Name = darkstar-dir
        Password = "password"
        TLS Enable = yes
        TLS Require = yes
        TLS Verify Peer = yes
        TLS Allowed CN = caladan.example.com
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/caladan_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/caladan_key.pem
      }
  

Enable TLS Communications Encryption Between File Daemon and Storage Daemon

Let's consider “darkstar-fd” (on “darkstar.example.com”) and “arrakis-fd” (at “arrakis.example.com”) clients, needing to connect to “caladan-sd” storage daemon at “caladan.example.com” using TLS.

• In bacula-fd.conf file at darkstar.example.com:

      FileDaemon {
        Name = darkstar-fd
        FD Port = 9112
        FD Address = darkstar.example.com
        WorkingDirectory = /usr/local/bacula/working
        Pid Directory = /var/run
        Maximum Concurrent Jobs = 10
        TLS Enable = yes
        TLS Require = yes
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
      }
  

• In bacula-fd.conf file at “arrakis.example.com”:

      FileDaemon {
        Name = arrakis-fd
        FD Port = 9112
        FD Address = arrakis.example.com
        WorkingDirectory = /usr/local/bacula/working
        Pid Directory = /var/run
        Maximum Concurrent Jobs = 10
        TLS Enable = yes
        TLS Require = yes
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/arrakis_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/arrakis_key.pem
      }
  

• In bacula-sd.conf file at “caladan.example.com”:
  

      Storage {
        Name = caladan-sd
        SD Port = 9113
        SD Address = caladan.example.com
        WorkingDirectory = "/usr/local/bacula/working"
        Pid Directory = "/var/run"
        Maximum Concurrent Jobs = 40
        TLS Enable = yes
        TLS Require = yes
        TLS Allowed CN = darkstar.example.com , arrakis.example.com
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/caladan_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/caladan_key.pem
      }
  

Please note that the TLS Allowed CN directive is only configured on the Storage Daemon side. This is due to the fact that the communication in this case is always between the Storage Daemon acting as a “TLS server” and the File Daemon acting as a “TLS client”. In this case, the client is the peer in the TLS communications context. The CN in the client's certificate subject will be checked by the Storage Daemon if it is an “Allowed CN”. in the case of the above example, TLS Allowed CN = darkstar.example.com, arrakis.example.com is allowing “darkstar-fd” (at darkstar.example.com) and “arrakis-fd” (at arrakis.example.com) clients to connect to “caladan-sd” storage daemon at “caladan.example.com” using TLS.

Using Certificates Issued by Different Root CAs

It is possible to have a TLS environment that uses certificates issued by different CAs. In the above examples, we have been using only one root CA:

# openssl genrsa -out ./keys/root_key.pem 4096
# openssl req -new -x509 -batch -config ./openssl.cnf -key ./keys/root_key.pem -days 36500 -out ./certs/root_cert.pem

In the case of the use of multiple root CA in your Bacula environment, there are two possible ways to configure:

1. to concatenate all the root CA certificates into one .pem file used in the TLS CA Certificate File directive:
   

   # cat root_cert_ca1.pem root_cert_ca2.pem root_cert_ca3.pem > root_cert_ca.pem
   

   • use TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert_ca.pem in resources TLS directives definitions.
2. use the TLS CA Certificate Dir directive instead. In this case, the certificates should have OpenSSL-compatible hashes. Please find below an example:

   root@darkstar:/opt/bacula/ssl/certs# ls -l
   ...
   lrwxrwxrwx 1 root root 19 Oct 25 23:10 7293a8c5.0 -> root_ca1_cert.pem
   lrwxrwxrwx 1 root root 19 Oct 25 23:10 8fb0c2b0.0 -> root_ca2_cert.pem
   lrwxrwxrwx 1 root root 18 Oct 25 23:10 a6476ecf.0 -> root_ca3_cert.pem
   -rw-r--r-- 1 root root 2134 Sep 7 16:03 root_ca1_cert.pem
   -rw-r--r-- 1 root root 2134 Sep 7 15:56 root_ca2_cert.pem
   -rw-r--r-- 1 root root 2134 Sep 7 11:47 root_ca3_cert.pem
   

   • TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert_ca.pem in resources TLS directives definitions.

Using TLS Authenticate to Enable a TLS Authentication Between Daemons

Bacula by default uses CRAM-MD5 authentication using the Password directive as a shared secret for each daemon. In addition to this, you can also use TLS to provide a more secure authentication between the daemons. This is achieved by using the TLS Authenticate = yes directive in the main daemon configuration resource in addition to configuring TLS Enable, TLS Require, TLS Certificate CA File, TLS Certificate and TLS Key directives. Please find examples below.

Please notice a very important feature of enabling TLS Authenticate to your daemons: if you enable the TLS authentication, the TLS encryption will be turned off and communication between the daemons will be done without Encryption.

Enabling TLS Authentication Between Director and Console

1. If you're using an anonymous console:
   You only need to define the TLS directives in the Director resource of both bacula-dir.conf and bconsole.conf files.
   • In bacula-dir.conf:

           Director {
             Name = darkstar-dir
             DIR Port = 9111
             DIR Address = darkstar.example.com
             QueryFile = "/usr/local/bacula/scripts/query.sql"
             WorkingDirectory = "/usr/local/bacula/working"
             PidDirectory = "/var/run"
             Maximum Concurrent Jobs = 10
             Password = "password"
             Messages = Daemon
             TLS Enable = yes
             TLS Require = yes
             TLS Verify Peer = yes
             TLS Authenticate = yes
             TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
             TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
             TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
           }
     

   • In bconsole.conf:

           Director {
             Name = darkstar-dir
             DIRport = 9111
             Address = darkstar.example.com
             Password = "password"
             TLS Enable = yes
             TLS Require = yes
             TLS Authenticate = yes
             TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
             TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
             TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
           }
     

2. If you are using a named console:
   You only need to define the TLS directives in the Console resource of both bacula-dir.conf and bconsole.conf.
   • In bacula-dir.conf:
     There is no need to configure TLS in the Director resource as for option (here):

           Director {
             Name = darkstar-dir
             DIR Port = 9111
             DIR Address = darkstar.example.com
             QueryFile = "/usr/local/bacula/scripts/query.sql"
             WorkingDirectory = "/usr/local/bacula/working"
             PidDirectory = "/var/run"
             Maximum Concurrent Jobs = 10
             Password = "password"
             Messages = Daemon
           }
     

     Instead, the Console resource has the TLS configurations:
     

           Console {
             Name = darkstar-con
             Password = "password"
             TLS Enable = yes
             TLS Require = yes
             TLS Verify Peer = yes
             TLS Authenticate = yes
             TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
             TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
             TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
           }
     

   • In bconsole.conf:
     There is no need to configure TLS in the Director resource as for option (here):

           Director {
             Name = darkstar-dir
             DIRport = 9111
             Address = darkstar.example.com
             Password = "password"
           }
     

     Instead, the Console resource has the TLS configurations:

           Console {
             Name = darkstar-con
             Password = "password"
             TLS Enable = yes
             TLS Require = yes
             TLS Verify Peer = yes
             TLS Authenticate = yes
             TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
             TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
             TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
           }
     

Enabling TLS Authentication Between Director and Client

Let's consider “darkstart-dir” director at “darkstar.example.com and” and the “arrakis-fd” file daemon at “arrakis.example.com”.

• In bacula-dir.conf:
  

      Client {
        Name = arrakis-fd
        Address = arrakis.example.com
        FD Port = 9112
        Catalog = MyCatalog
        Password = "password"
        AutoPrune = no
        Maximum Concurrent Jobs = 4
        TLS Enable = yes
        TLS Require = yes
        TLS Authenticate = yes
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
      }
  

• In bacula-fd.conf:
  

      Director {
        Name = darkstar-dir
        Password = "password"
        TLS Enable = yes
        TLS Require = yes
        TLS Verify Peer = yes
        TLS Authenticate = yes
        TLS Allowed CN = arrakis.example.com
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/arrakis_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/arrakis_key.pem
      }
  

Enabling TLS Authentication Between Director and Storage

Let's consider “darkstart-dir” director at “darkstar.example.com” and the “caladan-sd” storage daemon on “caladan.example.com”.

• In bacula-dir.conf:
  

      Storage {
        Name = VTL-storage
        SD Port = 9113Address = caladan.example.com
        Password = "password"
        Device = "Virtual Tape Library"
        Autochanger = yes
        Media Type = VTL
        Maximum Concurrent Jobs = 30
        TLS Enable = yes
        TLS Require = yes
        TLS Authenticate = yes
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
      }
  

• In bacula-sd.conf:
  

      Director {
        Name = darkstar-dir
        Password = "password"
        TLS Enable = yes
        TLS Require = yes
        TLS Verify Peer = yes
        TLS Authenticate = yes
        TLS Allowed CN = caladan.example.com
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/caladan_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/caladan_key.pem
      }
  

Enabling TLS Authentication Between Client and Storage

Let's consider “darkstar-fd” (on “darkstar.example.com”) and “arrakis-fd” (at “arrakis.example.com”) clients need to connect to the “aladan-sd” storage daemon running on “caladan.example.com” using TLS.

• In bacula-fd.conf file at darkstar.example.com:
  

      FileDaemon {
        Name = darkstar-fd
        FD Port = 9112
        FD Address = darkstar.example.com
        WorkingDirectory = /usr/local/bacula/working
        Pid Directory = /var/run
        Maximum Concurrent Jobs = 10
        TLS Enable = yes
        TLS Require = yes
        TLS Authenticate = yes
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/darkstar_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/darkstar_key.pem
      }
  

• In bacula-fd.conf file at “arrakis.example.com”:
  

      FileDaemon {
        Name = arrakis-fd
        FD Port = 9112
        FD Address = arrakis.example.com
        WorkingDirectory = /usr/local/bacula/working
        Pid Directory = /var/run
        Maximum Concurrent Jobs = 10
        TLS Enable = yes
        TLS Require = yes
        TLS Authenticate = yes
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/arrakis_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/arrakis_key.pem
      }
  

• In bacula-sd.conf file at “caladan.example.com”:
  

      Storage {
        Name = caladan-sd
        SD Port = 9113
        SD Address = caladan.example.com
        WorkingDirectory = "/usr/local/bacula/working"
        Pid Directory = "/var/run"
        Maximum Concurrent Jobs = 40
        TLS Enable = yes
        TLS Require = yes
        TLS Authenticate = yes
        TLS Allowed CN = darkstar.example.com , arrakis.example.com
        TLS CA Certificate File = /usr/local/bacula/etc/ssl/certs/root_cert.pem
        TLS Certificate = /usr/local/bacula/etc/ssl/certs/caladan_cert.pem
        TLS Key = /usr/local/bacula/etc/ssl/keys/caladan_key.pem
      }