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:
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
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:
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.
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.
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.
If you want to encrypt communications data, use the normal TLS directives but do not turn on TLS Authenticate.
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 }
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".
To generate the parameter file, you may use openssl:
openssl dhparam -out dh4096.pem -5 4096
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.
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.
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.
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 }
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 }
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 }
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 }
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”.
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 }
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 }
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 }
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 }
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 }
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 }
Let's consider “darkstart-dir” director at “darkstar.example.com” and the “arrakis-fd” file daemon on “arrakis.example.com”.
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 }
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 }
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 }
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 }
Let's consider the “darkstart-dir” director on “darkstar.example.com” and the “caladan-sd” storage daemon running on “caladan.example.com”.
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 }
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 }
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.
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 }
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 }
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.
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:
# cat root_cert_ca1.pem root_cert_ca2.pem root_cert_ca3.pem > root_cert_ca.pem
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
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.
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 }
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 }
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 }
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 }
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 }
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 }
Let's consider “darkstart-dir” director at “darkstar.example.com” and the “caladan-sd” storage daemon on “caladan.example.com”.
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 }
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 }
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.
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 }
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 }
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 }