Bacula TLS (Transport Layer Security) is built-in network
encryption code to provide secure network transport similar to
-that offered by {\bf stunnel} or {\bs ssh}. The Bacula code was
+that offered by {\bf stunnel} or {\bf ssh}. The Bacula code was
written by Landon Fuller.
Supported features of this code include:
\item Forward Secrecy Support via Diffie-Hellman Ephemeral Keying
\end{itemize}
-This document will refer to both ``server'' and ``client'' contexts. These
+This document will refer to both "server" and "client" contexts. These
terms refer to the accepting and initiating peer, respectively.
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
+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 {\bf ./configure} line with {\bf \verb?--?enable-openssl}
-
\subsection*{TLS Configuration Directives}
\addcontentsline{toc}{section}{TLS Configuration Directives}
Additional configuration directives have been added to all the daemons
Require TLS connections.
\item [TLS Certificate = \lt{}Directory\gt{}]
-Path to PEM encoded TLS certificate. Used as either a client or server
-certificate.
+Path to a PEM encoded TLS certificate. It can be used as either a client
+or server certificate. PEM stands for Privacy Enhanced Mail, but in
+this context refers to how the certificates are encoded. It is used
+because PEM files are base64 encoded and hence ASCII text based
+rather than binary. They may also contain encrypted information.
\item [TLS Key = \lt{}Directory\gt{}]
-Path to PEM encoded TLS private key. Must correspond with the TLS
+Path to a PEM encoded TLS private key. It must correspond to the TLS
certificate.
\item [TLS Verify Peer = \lt{}yes|no\gt{}]
Verify peer certificate. Instructs server to request and verify the
client's x509 certificate. Any client certificate signed by a known-CA
-will be accepted unless the TLS Allowed CN configuration directive is used.
-Not valid in a client context.
+will be accepted unless the TLS Allowed CN configuration directive is used,
+in which case the client certificate must correspond to the Allowed
+Common Name specified. This directive is valid only for a server
+and not in a client context.
\item [TLS Allowed CN = \lt{}string list\gt{}]
-Common name attribute of allowed peer certificates. If directive is
+Common name attribute of allowed peer certificates. If this directive is
specified, all client certificates will be verified against this list.
-This directive may be specified more than once. Not valid in a client
+This directive may be specified more than once. It is not valid in a client
context.
-\item [TLS CA Certificate File = \lt{}Directory\gt{}]
-Path to PEM encoded TLS CA certificate(s). Multiple certificates are
+\item [TLS CA Certificate File = \lt{}Filename\gt{}]
+The full path and filename specifying a
+PEM encoded TLS CA certificate(s). Multiple certificates are
permitted in the file. One of \emph{TLS CA Certificate File} or \emph{TLS
CA Certificate Dir} are required in a server context if \emph{TLS
Verify Peer} (see above) is also specified, and are always required in a client
context.
\item [TLS CA Certificate Dir = \lt{}Directory\gt{}]
-Path to TLS CA certificate directory. In the current implementation,
-certificates must be stored PEM encoded with OpenSSL-compatible hashes.
+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 {bf .0}.
One of \emph{TLS CA Certificate File} or \emph{TLS CA Certificate Dir} are
required in a server context if \emph{TLS Verify Peer} is also specified,
and are always required in a client context.
\item [TLS DH File = \lt{}Directory\gt{}]
Path to PEM encoded Diffie-Hellman parameter file. If this directive is
-specified, DH ephemeral keying will be enabled, allowing for forward
-secrecy of communications. This directive is only valid within a server
-context. To generate the parameter file, you may use openssl:
+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:
\begin{verbatim}
openssl dhparam -out dh1024.pem -5 1024
\end{verbatim}
-\end{itemize}
+\end{description}
\subsection*{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 can be made with the
-following, which I put in a file named {\bf makepem}:
+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:
\footnotesize
\begin{verbatim}
-#!/bin/sh
-#
-# Simple shell script to make a .pem file that can be used
-# with stunnel and Bacula
-#
-OPENSSL=openssl
- umask 77
- PEM1=`/bin/mktemp openssl.XXXXXX`
- PEM2=`/bin/mktemp openssl.XXXXXX`
- ${OPENSSL} req -newkey rsa:1024 -keyout $PEM1 -nodes \
- -x509 -days 365 -out $PEM2
- cat $PEM1 > stunnel.pem
- echo "" >>stunnel.pem
- cat $PEM2 >>stunnel.pem
- rm $PEM1 $PEM2
+ openssl req -new -x509 -nodes -out bacula.pem -keyout bacula.pem -days 3650
\end{verbatim}
\normalsize
http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
Note, this link may change.
+
+\subsection*{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.
+
+{\bf bacula-dir.conf}
+\footnotesize
+\begin{verbatim}
+ Director { # define myself
+ Name = backup1-dir
+ ...
+ TLS Require = yes
+ TLS Verify Peer = yes
+ TLS Allowed CN = "bacula@backup1.example.com"
+ TLS Allowed CN = "administrator@example.com"
+ TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
+ # This is a server certificate, used for incoming
+ # console connections.
+ TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
+ TLS Key = /usr/local/etc/ssl/backup1/key.pem
+ }
+
+ Storage {
+ Name = File
+ Address = backup1.example.com
+ ...
+ TLS Require = yes
+ TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
+ # This is a client certificate, used by the director to
+ # connect to the storage daemon
+ TLS Certificate = /usr/local/etc/ssl/bacula@backup1/cert.pem
+ TLS Key = /usr/local/etc/ssl/bacula@backup1/key.pem
+ }
+\end{verbatim}
+\normalsize
+
+{\bf bacula-fd.conf}
+\footnotesize
+\begin{verbatim}
+ Director {
+ Name = backup1-dir
+ ...
+ TLS Require = yes
+ TLS Verify Peer = yes
+ # Allow only the Director to connect
+ TLS Allowed CN = "bacula@backup1.example.com"
+ TLS CA Certificate File = /usr/local/etc/ssl/ca.pem\
+ # This is a server certificate. It is used by connecting
+ # directors to verify the authenticity of this file daemon
+ TLS Certificate = /usr/local/etc/ssl/server1/cert.pem
+ TLS Key = /usr/local/etc/ssl/server1/key.pem
+ }
+\end{verbatim}
+\normalsize
+
+{\bf bacula-sd.conf}
+\footnotesize
+\begin{verbatim}
+ Storage { # definition of myself
+ Name = backup1-sd
+ ...
+ # These TLS configuration options are used for incoming
+ # file daemon connections. Director TLS settings are handled
+ # below.
+ TLS Require = yes
+ # Peer certificate is not required/requested -- peer validity
+ # is verified by the storage connection cookie provided to the
+ # File Daemon by the director.
+ TLS Verify Peer = no
+ TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
+ # This is a server certificate. It is used by connecting
+ # file daemons to verify the authenticity of this storage daemon
+ TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
+ TLS Key = /usr/local/etc/ssl/backup1/key.pem
+ }
+
+ #
+ # List Directors who are permitted to contact Storage daemon
+ #
+ Director {
+ Name = backup1-dir
+ ...
+ TLS Require = yes
+ # Require the connecting director to provide a certificate
+ # with the matching CN.
+ TLS Verify Peer = yes
+ TLS Allowed CN = "bacula@backup1.example.com"
+ TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
+ # This is a server certificate. It is used by the connecting
+ # director to verify the authenticity of this storage daemon
+ TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
+ TLS Key = /usr/local/etc/ssl/backup1/key.pem
+ }
+\end{verbatim}
+\normalsize
+
+
+
projects / bacula / docs / blobdiff