-\section*{Bacula TLS -- Communications Encryption}
+\chapter{Bacula TLS -- Communications Encryption}
\label{CommEncryption}
\index[general]{TLS -- Communications Encryption}
\index[general]{Communications Encryption}
\index[general]{Encryption!Transport}
\index[general]{Transport Encryption}
\index[general]{TLS}
-\addcontentsline{toc}{section}{TLS -- Communications Encryption}
Bacula TLS (Transport Layer Security) is built-in network
encryption code to provide secure network transport similar to
considerably less secure than PKI certificate-based authentication.
Appropriate autoconf macros have been added to detect and use OpenSSL
-if enabled on the {\bf ./configure} line with {\bf \verb?--?enable-openssl}
+if enabled on the {\bf ./configure} line with {\bf \verb?--?with-openssl}
-\subsection*{TLS Configuration Directives}
-\addcontentsline{toc}{section}{TLS Configuration Directives}
+\section{TLS Configuration Directives}
Additional configuration directives have been added to all the daemons
(Director, File daemon, and Storage daemon) as well as the various
different Console programs.
\end{description}
-\subsection*{Creating a Self-signed Certificate}
+\section{Creating a Self-signed Certificate}
\index[general]{Creating a Self-signed Certificate }
\index[general]{Certificate!Creating a Self-signed }
-\addcontentsline{toc}{subsection}{Creating a Self-signed Certificate}
You may create a self-signed certificate for use with the Bacula TLS that
will permit you to make it function, but will not allow certificate
validation. The .pem file containing both the certificate and the key
-valid for 10 years can be made with the following:
+valid for ten years can be made with the following:
\footnotesize
\begin{verbatim}
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 certifictes, but the certificate used by the
+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 neccessary to prevent ``man in the middle'' attacks from tools such
+This is necessary to prevent ``man in the middle'' attacks from tools such
as \elink{ettercap}{http://ettercap.sourceforge.net/}. Essentially, if the
Director does not verify that it is talking to a trusted remote endpoint,
it can be tricked into talking to a malicious 3rd party who is relaying and
\elink{http://tinyca.sm-zone.net/}{http://tinyca.sm-zone.net/}.
-\subsection*{Getting a CA Signed Certificate}
+\section{Getting a CA Signed Certificate}
\index[general]{Certificate!Getting a CA Signed }
\index[general]{Getting a CA Signed Certificate }
-\addcontentsline{toc}{subsection}{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 quite a number of PKI vendors, but
{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
Note, this link may change.
-\subsection*{Example TLS Configuration Files}
+\section{Example TLS Configuration Files}
\index[general]{Example!TLS Configuration Files}
\index[general]{TLS Configuration Files}
-\addcontentsline{toc}{subsection}{Example TLS Configuration Files}
Landon has supplied us with the TLS portions of his configuration
files, which should help you setting up your own.