\chapter{\bacula{} \acs{TLS} -- Communications Encryption}
\label{blb:CommEncryption}
\index[general]{\acs{TLS} -- Communications Encryption}
\index[general]{Communications Encryption}
\index[general]{Encryption!Communications}
\index[general]{Encryption!Transport}
\index[general]{Transport Encryption}
\index[general]{PSK}
\index[general]{\acs{TLS}}

\bacula{} \ac{TLS} is built-in network encryption code
to provide secure network transport similar to that offered by \btool{stunnel} or \btool{ssh}.
The \bacula{} \ac{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 \acs{PKI} options described in \bilink{Data Encryption chapter}{blb:DataEncryption} of this manual.

The \bacula{} encryption implementation was initially written by Landon Fuller.

Supported features of this code include:
\begin{bitemize}
\item Client/Server \acs{TLS} Requirement Negotiation
\item \acs{TLS}v1.2 Connections with Server and Client Certificate
Validation
\item Forward Secrecy Support via Diffie-Hellman Ephemeral Keying
\item \acs{TLS-PSK} is used by default\footnote{starting with version 12.0} when TLS certificates are not configured.
\end{bitemize}

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 (\btool{bconsole}, \btool{tray monitor},
\ldots{}) use the same \acs{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 \acs{DH} anonymous ciphers increases the code complexity and places
explicit trust upon the two-way \acs{CRAM}-\acs{MD}5 implementation.  \acs{CRAM}-\acs{MD}5 is
subject to known plaintext attacks, and it should be considered
considerably less secure than \acs{PKI} certificate-based authentication.

Appropriate autoconf macros have been added to detect and use
\bfootref{https://www.openssl.org/}{OpenSSL}
if enabled on the \btool{./configure} line with \textbf{{-}{-}with-openssl}

\section{\acs{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 \texttt{FileDaemon} resource
and in the Storage \texttt{Storage} resource.

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

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

These new directives are defined as follows:

\begin{bdescription}
% To get the documentation available on every directive, we include this section
% in other parts of the manual
% BEGIN-TLS
\bwebdoc{Main:TlsEnable}
\item [\acs{TLS} Enable = \byesorno{}]

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

\bwebdoc{Main:TlsPskEnable}
\item [\acs{TLS} PSK Enable = \byesorno{}]

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

\bwebdoc{Main:TlsRequire}
\item [\acs{TLS} Require = \byesorno{}]

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

    If \acs{TLS} or \acs{TLS-PSK} is enabled and \acs{TLS} is required, then
    the \bacula{} component will refuse any connection request that does not use \acs{TLS}.

\bwebdoc{Main:TlsAuthenticate}
\item [\acs{TLS} Authenticate = \byesorno{}]
\index[general]{\acs{TLS} authentication}
When \bdirectivename{\acs{TLS} Authenticate} is enabled, after doing the \acs{CRAM}-\acs{MD}5
authentication, \bacula{} will also do \acs{TLS} authentication, then \acs{TLS}
encryption will be turned off, and the rest of the communication between
the two \bacula{} components will be done without encryption.
If \acs{TLS-PSK} is used instead of the regular \acs{TLS}, the
encryption is turned off after the \acs{TLS-PSK} authentication step.

If you want to encrypt communications data, use the normal \acs{TLS} directives
but do \textbf{not} turn on \bdirectivename{\acs{TLS} Authenticate}.

\bwebdoc{Main:TlsCertificate}
\item [\acs{TLS} Certificate = \bbracket{Filename}]
The full path and filename of a \acs{PEM} encoded \acs{TLS} certificate.  It will be
used as either a client or server certificate, depending on the connection direction.  \acs{PEM} stands for \acl{PEM}, but in this context refers to how the certificates are
encoded.  This format is used because \acs{PEM} files are base64 encoded and hence \acs{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 \bdirectivename{\acs{TLS} Verify Peer} is set to \bvalue{no} in the corresponding server context.

\bwebdoc{Main:EndX}

Example:

File Daemon configuration file (\bfilename{bacula-fd.conf}), \bDirector{} resource configuration has \bvalueddirective{\acs{TLS} Verify Peer}{no}:
\begin{bVerbatim}
  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
  }
\end{bVerbatim}

Having \bvalueddirective{\acs{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 \bdirectivename{\acs{TLS} Certificate File} neither \bdirectivename{\acs{TLS} Key} directives in the \bClient{} resource, director configuration file.  We can have the below client configuration in \bfilename{bacula-dir.conf}:

\begin{bVerbatim}
  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
  }
\end{bVerbatim}

\bwebdoc{Main:TlsKey}
\item [TLS Key = \bbracket{Filename}]
The full path and filename of a \acs{PEM} encoded \acs{TLS} private key.  It must
correspond to the \acs{TLS} certificate.

\bwebdoc{Main:TlsVerifyPeer}
\item [\acs{TLS} Verify Peer = \byesorno{}]\label{blb:tls:verifypeer}
Verify peer certificate.  Instructs server to request and verify the
client's \bfootref{https://en.wikipedia.org/wiki/X.509}{X.509} certificate.  Any client certificate signed by a known-\acs{CA}
will be accepted.  Additionally, the client's X509 certificate Common Name must meet the value of the \bdirectivename{Address} directive.  If the \bdirectivename{\acs{TLS}Allowed CN} onfiguration directive is used, the client's x509 certificate Common Name must also correspond to one of the \acs{CN} specified in the \bdirectivename{\acs{TLS} Allowed CN} directive.  This directive is valid only for a server and not in  client context.  The default is \bdefaultvalue{yes}.

\bwebdoc{Main:TlsAllowedCn}
\item [\acs{TLS} Allowed CN = \bbracket{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 \acs{CN} list will not be checked if \bdirectivename{\acs{TLS} Verify Peer} is set to \bvalue{no} (\bdirectivename{\acs{TLS} Verify Peer} is \bdefaultvalue{yes} by default).  This can be used to ensure that only the \acs{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 \acs{CN} list will only be checked if \bdirectivename{\acs{TLS} Verify Peer = yes} (default).  For example, in \bfilename{bacula-fd.conf}, \bDirector{} resource definition:
\begin{bVerbatim}
  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
  }
\end{bVerbatim}

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

\begin{bVerbatim}
  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
  }
\end{bVerbatim}

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

\begin{bVerbatim}
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".
\end{bVerbatim}

\bwebdoc{Main:TlsCaCertificateFile}
\item [\acs{TLS} CA Certificate File = \bbracket{Filename}]
The full path and filename specifying a \acs{PEM} encoded \acs{TLS} \acs{CA} certificate(s). Multiple certificates are permitted in the file.  One of \bdirectivename{\acs{TLS} \acs{CA} Certificate File} or \bdirectivename{\acs{TLS} \acs{CA} Certificate Dir} are required in a server context, unless \bdirectivename{\acs{TLS} Verify Peer} (see above) is set to \bvalue{no}, and are always required in a client context.

\bwebdoc{Main:TlsCaCertificateDir}
\item [\acs{TLS} CA Certificate Dir = \bbracket{Directory}]
Full path to \acs{TLS} \acs{CA} certificate directory.  In the current implementation,
certificates must be stored \acs{PEM} encoded with OpenSSL-compatible hashes,
which is the subject name's hash and an extension of \textbf{.0}.  One of \bdirectivename{\acs{TLS} \acs{CA} Certificate File} or \bdirectivename{\acs{TLS} \acs{CA} Certificate Dir} are required in a server context, unless \bdirectivename{\acs{TLS} Verify Peer} is set to \bvalue{no}, and are always required in a client context.

\bwebdoc{Main:TlsDhFile}
\item [\acs{TLS} DH File = \bbracket{Directory}]
Path to \acs{PEM} encoded Diffie-Hellman parameter file.  If this directive is
specified, \acs{DH} key exchange will be used for the ephemeral keying, allowing
for forward secrecy of communications.  \acs{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 \acs{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 \btool{openssl}:

\begin{bVerbatim}
openssl dhparam -out dh4096.pem -5 4096
\end{bVerbatim}

\bwebdoc{Main:TlsEnd}
% END-TLS
% End of the section that is used in other files
\end{bdescription}

\section{Creating a Self-Signed Certificate}
\index[general]{Creating a Self-Signed Certificate }
\index[general]{Certificate!Creating a Self-Signed }

A self-signed certificate for use with the \bacula{} \acs{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:

\begin{bVerbatim}
openssl req -new -x509 -nodes -out bacula.pem -keyout bacula.pem -days 3650
\end{bVerbatim}

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 \bfootref{https://www.ettercap-project.org/}{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$^{rd}$ 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.

%% To get a trusted certificate (\acs{CA} or \acl{CA} signed
%% certificate), you will either need to purchase certificates signed by a
%% commercial \acs{CA} or find a friend that has setup his own \acs{CA} or become a \acs{CA}
%% yourself, and thus you can sign all your own certificates.  The book
%% \bfootref{shop.oreilly.com/product/9780596002701.do}{OpenSSL by John Viega, Matt Mesier \& Pravir Chandra}\footnote{This link is valid as of the 07-december-2016}
%% from \bfootref{http://www.oreilly.com/}{O'Reilly} explains
%% how to do it, or you can read the documentation provided in the
%% \bfootref{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}{Open-source \acs{PKI} Book}.
%%          % project at Source Forge: \bref{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
%% Note, this link may change but is valid as of the 07 December 2016.

%% The program TinyCA has a very nice \ac{GUI}
%% that allows you to easily setup and maintain your own \acs{CA}.
%% TinyCA can be found at \bref{http://tinyca.sm-zone.net/}{tinyca.sm-zone.net/}. As of the 7th of December, 2016, this link is not valid. This project seems to be dead.
%% Dogtag is a quite usable CA package... in the RHEL world, it's the default and supported
%% CA suite. It is freely available in particular with Fedora, where you usually get
%% more or less the bleeding edge of its functionality.
%% It *is* quite a bit to swallow, though...


\section{Getting a \acs{CA} Signed Certificate}
\index[general]{Certificate!Getting a \acs{CA} Signed }
\index[general]{Getting a \acs{CA} Signed Certificate }

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

To get a \acs{CA} signed certificate, you will either need to find a friend that has setup his own, trusted \acs{CA}, or to become a \acs{CA} yourself, and thus you can sign all your own certificates.  The book \bfootref{shop.oreilly.com/product/9780596002701.do}{OpenSSL by John Viega, Matt Mesier \& Pravir Chandra from O'Reilly}\footnote{This link is valid as of the 27-september-2018} explains how to do it, or you can read the documentation provided in the \bfootref{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}{Open-source \acs{PKI} Book}.

\section{Example \acs{TLS} Configuration Files}
\index[general]{Example!\acs{TLS} Configuration Files}
\index[general]{\acs{TLS} Configuration Files}
A few examples of the \acs{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:
\begin{bVerbatim}
* 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
\end{bVerbatim}

The \bdirectivename{\acs{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 \textbf{default value used by \bacula{}}.  This means that both server and client certificates will be checked in the \acs{TLS} communication handshake. The \ac{CN} in the peer certificate will be checked against the \bdirectivename{Address} directive configured for the corresponding resource.

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

\begin{bVerbatim}
  # 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
\end{bVerbatim}

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

\subsection{Enable \acs{TLS} Communications Encryption Between Console and Director}

\subsubsection{Director and Console are on the Same ``darkstar'' Host}

\begin{benumerate}
\item\label{blb:enum:anonymousconsole} If you are using an anonymous console:\\
  You only need to define the \acs{TLS} directives in the \bDirector{} resource of both \bfilename{bacula-dir.conf} and \bfilename{bconsole.conf} files.
  \begin{bitemize}
  \item In \bfilename{bacula-dir.conf}:\\
    \begin{bVerbatim}
      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
      }
    \end{bVerbatim}
  \item In \bfilename{bconsole.conf}:\\
    \begin{bVerbatim}
      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
      }
    \end{bVerbatim}
  \end{bitemize}
\item If a named console is used:\\
  You only need to define the \acs{TLS} directives in the \bConsole{} resource of both \bfilename{bacula-dir.conf} and \bfilename{bconsole.conf}.
  \begin{bitemize}
  \item In \bfilename{bacula-dir.conf}:\\
    There is no need to configure \acs{TLS} in the \bDirector{} resource as for option \vref{blb:enum:anonymousconsole}\\
    \begin{bVerbatim}
      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
      }
    \end{bVerbatim}
    Instead, the named \bConsole{} resource has the \acs{TLS} configuration:\\
    \begin{bVerbatim}
      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
      }
    \end{bVerbatim}
  \item In \bfilename{bconsole.conf}:\\
    There is no need to configure \acs{TLS} in the \bDirector{} resource as for option \vref{blb:enum:anonymousconsole}:\\
    \begin{bVerbatim}
      Director {
        Name = darkstar-dir
        DIRport = 9111
        Address = darkstar.example.com
        Password = "password"
      }
    \end{bVerbatim}
    Instead, the \bConsole{} resource contains the \acs{TLS} configuration:
    \begin{bVerbatim}
      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
      }
    \end{bVerbatim}
  \end{bitemize}
\end{benumerate}

\subsubsection{Director and Console are on Different Hosts}

If you have your  \bconsole{} 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''.

\subsection{Enable \acs{TLS} Communications Encryption Between Console and Director}
\begin{benumerate}
  \item\label{blb:enum:diffhost:anonymous} If you're using an anonymous console:\\
  \begin{bitemize}
  \item In \bfilename{bacula-dir.conf}:\\
    \begin{bVerbatim}
      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
      }
    \end{bVerbatim}
  \item In \bfilename{bconsole.conf}:\\
    \begin{bVerbatim}
      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
      }
    \end{bVerbatim}
  \end{bitemize}
\item If you are using a named console:
  \begin{bitemize}
  \item In \bfilename{bacula-dir.conf}:\\
    There is no need to configure \acs{TLS} in the \bDirector{} resource as for option \vref{blb:enum:diffhost:anonymous}:\\
    \begin{bVerbatim}
      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
      }
    \end{bVerbatim}
    Instead, the \bConsole{} resource has the \acs{TLS} configurations:\\
    \begin{bVerbatim}
      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
      }
    \end{bVerbatim}
  \item In \bfilename{bconsole.conf}:
    It is not needed to configure \acs{TLS} in the \bDirector{} resource as for \vref{blb:enum:diffhost:anonymous}:\\
    \begin{bVerbatim}
      Director {
        Name = darkstar-dir
        DIRport = 9111
        Address = darkstar.example.com
        Password = "password"
      }
    \end{bVerbatim}
    Instead, the \bConsole{} resource needs the \acs{TLS} configuration:\\
    \begin{bVerbatim}
      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
      }
    \end{bVerbatim}
  \end{bitemize}
\end{benumerate}

\subsection{Enable \acs{TLS} Communications Encryption between Director and File Daemon}

\subsubsection{Director and File Daemon are on the Same ``darkstar'' Host}
\begin{bitemize}
\item In \bfilename{bacula-dir.conf}:\\
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\item In \bfilename{bacula-fd.conf}:
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\end{bitemize}

\subsubsection{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''.
\begin{bitemize}
\item In \bfilename{bacula-dir.conf}:\\
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\item In \bfilename{bacula-fd.conf}:\\
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\end{bitemize}

\subsection{Enable \acs{TLS} Communications Encryption Between Director and Storage Daemon}

\subsubsection{Director and Storage Daemon are on the Same ``darkstar'' Host}
\begin{bitemize}
\item In \bfilename{bacula-dir.conf}:\\
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\item In bacula-sd.conf:\\
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\end{bitemize}

\subsubsection{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''.
\begin{bitemize}
\item In \bfilename{bacula-dir.conf}:\\
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\item In bacula-sd.conf:\\
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\end{bitemize}

\subsection{Enable \acs{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 \acs{TLS}.

\begin{bitemize}
\item In \bfilename{bacula-fd.conf} file at darkstar.example.com:
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\item In \bfilename{bacula-fd.conf} file at ``arrakis.example.com'':
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\item In bacula-sd.conf file at ``caladan.example.com'':\\
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\end{bitemize}

Please note that the \bdirectivename{\acs{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 ``\acs{TLS} server'' and the File Daemon acting as a ``\acs{TLS} client''.  In this case, the client is the peer in the \acs{TLS} communications context.  The \ac{CN} in the client's certificate subject will be checked by the Storage Daemon if it is an ``\emph{Allowed \acs{CN}}''.  in the case of the above example, \bdirectivename{\acs{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 \acs{TLS}.

\subsection{Using Certificates Issued by Different Root \acsp{CA}}

It is possible to have a \acs{TLS} environment that uses certificates issued by different \acsp{CA}. In the above examples, we have been using only one root \acs{CA}:
\begin{bVerbatim}
# 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
\end{bVerbatim}

In the case of the use of multiple root \acs{CA} in your \bacula{} environment, there are two possible ways to configure:
\begin{benumerate}
\item to concatenate all the root \acs{CA} certificates into one \bfilename{.pem} file used in the \bdirectivename{\acs{TLS} \acs{CA} Certificate File} directive:\\
  \begin{bVerbatim}
# cat root_cert_ca1.pem root_cert_ca2.pem root_cert_ca3.pem > root_cert_ca.pem
  \end{bVerbatim}
  \begin{bitemize} 
  \item use \bdirectivename{\acs{TLS} CA Certificate File = /usr/local/bacula/etc/ssl/certs/root\_cert\_ca.pem} in resources \acs{TLS} directives definitions.
  \end{bitemize}
\item use the \bdirectivename{\acs{TLS} \acs{CA} Certificate Dir} directive instead.  In this case, the certificates should have Open\acs{SSL}-compatible hashes.  Please find below an example:
  \begin{bVerbatim}
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
  \end{bVerbatim}
  \begin{bitemize} 
  \item \bdirectivename{\acs{TLS} CA Certificate File = /usr/local/bacula/etc/ssl/certs/root\_cert\_ca.pem} in resources \acs{TLS} directives definitions.
  \end{bitemize}
\end{benumerate}

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

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

\subsubsection{Enabling \acs{TLS} Authentication Between Director and Console}
\begin{benumerate}
  \item\label{blb:enum:tlsdircons:anonymous} If you're using an anonymous console:\\
  You only need to define the \acs{TLS} directives in the \bDirector{} resource of both \bfilename{bacula-dir.conf} and \bfilename{bconsole.conf} files.
  \begin{bitemize}
  \item In \bfilename{bacula-dir.conf}:
    \begin{bVerbatim}
      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
      }
    \end{bVerbatim}
  \item In \bfilename{bconsole.conf}:
    \begin{bVerbatim}
      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
      }
    \end{bVerbatim}
  \end{bitemize}
\item If you are using a named console:\\
  You only need to define the \acs{TLS} directives in the \bConsole{} resource of both \bfilename{bacula-dir.conf} and \bfilename{bconsole.conf}.
  \begin{bitemize}
  \item In \bfilename{bacula-dir.conf}:\\
    There is no need to configure \acs{TLS} in the \bDirector{} resource as for option \vref{blb:enum:tlsdircons:anonymous}:
    \begin{bVerbatim}
      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
      }
    \end{bVerbatim}
    Instead, the \bConsole{} resource has the \acs{TLS} configurations:\\
    \begin{bVerbatim}
      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
      }
    \end{bVerbatim}
  \item In \bfilename{bconsole.conf}:\\
    There is no need to configure \acs{TLS} in the \bDirector{} resource as for option \vref{blb:enum:tlsdircons:anonymous}:
    \begin{bVerbatim}
      Director {
        Name = darkstar-dir
        DIRport = 9111
        Address = darkstar.example.com
        Password = "password"
      }
    \end{bVerbatim}
    Instead, the \bConsole{} resource has the \acs{TLS} configurations:
    \begin{bVerbatim}
      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
      }
    \end{bVerbatim}
  \end{bitemize}
\end{benumerate}

\subsubsection{Enabling \acs{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''.
\begin{bitemize}
\item In \bfilename{bacula-dir.conf}:\\
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\item In \bfilename{bacula-fd.conf}:\\
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\end{bitemize}

\subsubsection{Enabling \acs{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''.
\begin{bitemize}
\item In \bfilename{bacula-dir.conf}:\\
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\item In bacula-sd.conf:\\
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\end{bitemize}

\subsubsection{Enabling \acs{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 \acs{TLS}.
\begin{bitemize}
\item In \bfilename{bacula-fd.conf} file at darkstar.example.com:\\
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\item In \bfilename{bacula-fd.conf} file at ``arrakis.example.com'':\\
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\item In bacula-sd.conf file at ``caladan.example.com'':\\
  \begin{bVerbatim}
    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
    }
  \end{bVerbatim}
\end{bitemize}
