<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html401/loose.dtd">
<html>
<!-- Created on September, 10 2009 by texi2html 1.78 -->
<!--
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
Karl Berry <karl@freefriends.org>
Olaf Bachmann <obachman@mathematik.uni-kl.de>
and many others.
Maintained by: Many creative people.
Send bugs and suggestions to <texi2html-bug@nongnu.org>
-->
<head>
<title>Specification of the Exim Mail Transfer Agent: 39. Encrypted SMTP connections using TLS/SSL</title>
<meta name="description" content="Specification of the Exim Mail Transfer Agent: 39. Encrypted SMTP connections using TLS/SSL">
<meta name="keywords" content="Specification of the Exim Mail Transfer Agent: 39. Encrypted SMTP connections using TLS/SSL">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="texi2html 1.78">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
pre.display {font-family: serif}
pre.format {font-family: serif}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: serif; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: serif; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.roman {font-family:serif; font-weight:normal;}
span.sansserif {font-family:sans-serif; font-weight:normal;}
ul.toc {list-style: none}
-->
</style>
</head>
<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<a name="Encrypted-SMTP-connections"></a>
<a name="SEC294"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="spec_38.html#SEC293" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC295" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec_38.html#SEC291" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h1 class="chapter"> 39. Encrypted SMTP connections using TLS/SSL </h1>
<p>Support for TLS (Transport Layer Security), formerly known as SSL (Secure
Sockets Layer), is implemented by making use of the OpenSSL library or the
GnuTLS library (Exim requires GnuTLS release 1.0 or later). There is no
cryptographic code in the Exim distribution itself for implementing TLS. In
order to use this feature you must install OpenSSL or GnuTLS, and then build a
version of Exim that includes TLS support (see section <a href="spec_4.html#SEC37">Including TLS/SSL encryption support</a>).
You also need to understand the basic concepts of encryption at a managerial
level, and in particular, the way that public keys, private keys, and
certificates are used.
</p>
<p>RFC 3207 defines how SMTP connections can make use of encryption. Once a
connection is established, the client issues a STARTTLS command. If the
server accepts this, the client and the server negotiate an encryption
mechanism. If the negotiation succeeds, the data that subsequently passes
between them is encrypted.
</p>
<p>Exim's ACLs can detect whether the current SMTP session is encrypted or not,
and if so, what cipher suite is in use, whether the client supplied a
certificate, and whether or not that certificate was verified. This makes it
possible for an Exim server to deny or accept certain commands based on the
encryption state.
</p>
<p><strong>Warning</strong>: Certain types of firewall and certain anti-virus products can
disrupt TLS connections. You need to turn off SMTP scanning for these products
in order to get TLS to work.
</p>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top"><a href="#SEC295">39.1 Support for the legacy "ssmtp" (aka "smtps") protocol</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC296">39.2 OpenSSL vs GnuTLS</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC297">39.3 GnuTLS parameter computation</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC298">39.4 Requiring specific ciphers in OpenSSL</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC299">39.5 Requiring specific ciphers or other parameters in GnuTLS</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC300">39.6 Configuring an Exim server to use TLS</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC301">39.7 Requesting and verifying client certificates</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC302">39.8 Revoked certificates</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC303">39.9 Configuring an Exim client to use TLS</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC304">39.10 Multiple messages on the same encrypted TCP/IP connection</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC305">39.11 Certificates and all that</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC306">39.12 Certificate chains</a></td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top"><a href="#SEC307">39.13 Self-signed certificates</a></td><td> </td><td align="left" valign="top">
</td></tr>
</table>
<hr size="6">
<a name="Support-for-the-legacy-_0022ssmtp_0022-_005baka-_0022smtps_0022_005d-protocol"></a>
<a name="SEC295"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC294" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC296" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC294" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC294" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 39.1 Support for the legacy "ssmtp" (aka "smtps") protocol </h2>
<p>Early implementations of encrypted SMTP used a different TCP port from normal
SMTP, and expected an encryption negotiation to start immediately, instead of
waiting for a STARTTLS command from the client using the standard SMTP
port. The protocol was called "ssmtp" or "smtps", and port 465 was
allocated for this purpose.
</p>
<p>This approach was abandoned when encrypted SMTP was standardized, but there are
still some legacy clients that use it. Exim supports these clients by means of
the <code>tls_on_connect_ports</code> global option. Its value must be a list of port
numbers; the most common use is expected to be:
</p>
<table><tr><td> </td><td><pre class="example">tls_on_connect_ports = 465
</pre></td></tr></table>
<p>The port numbers specified by this option apply to all SMTP connections, both
via the daemon and via <em>inetd</em>. You still need to specify all the ports that
the daemon uses (by setting <code>daemon_smtp_ports</code> or <code>local_interfaces</code> or
the <code>-oX</code> command line option) because <code>tls_on_connect_ports</code> does not add
an extra port - rather, it specifies different behaviour on a port that is
defined elsewhere.
</p>
<p>There is also a <code>-tls-on-connect</code> command line option. This overrides
<code>tls_on_connect_ports</code>; it forces the legacy behaviour for all ports.
</p>
<hr size="6">
<a name="OpenSSL-vs-GnuTLS"></a>
<a name="SEC296"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC295" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC297" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC294" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC294" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 39.2 OpenSSL vs GnuTLS </h2>
<p>The first TLS support in Exim was implemented using OpenSSL. Support for GnuTLS
followed later, when the first versions of GnuTLS were released. To build Exim
to use GnuTLS, you need to set
</p>
<table><tr><td> </td><td><pre class="example">USE_GNUTLS=yes
</pre></td></tr></table>
<p>in Local/Makefile, in addition to
</p>
<table><tr><td> </td><td><pre class="example">SUPPORT_TLS=yes
</pre></td></tr></table>
<p>You must also set TLS_LIBS and TLS_INCLUDE appropriately, so that the
include files and libraries for GnuTLS can be found.
</p>
<p>There are some differences in usage when using GnuTLS instead of OpenSSL:
</p>
<ul class="toc">
<li>
The <code>tls_verify_certificates</code> option must contain the name of a file, not the
name of a directory (for OpenSSL it can be either).
</li><li>
The <code>tls_dhparam</code> option is ignored, because early versions of GnuTLS had no
facility for varying its Diffie-Hellman parameters. I understand that this has
changed, but Exim has not been updated to provide this facility.
</li><li>
<a name="IDX2463"></a>
Distinguished Name (DN) strings reported by the OpenSSL library use a slash for
separating fields; GnuTLS uses commas, in accordance with RFC 2253. This
affects the value of the <code>$tls_peerdn</code> variable.
</li><li>
OpenSSL identifies cipher suites using hyphens as separators, for example:
DES-CBC3-SHA. GnuTLS uses underscores, for example: RSA_ARCFOUR_SHA. What is
more, OpenSSL complains if underscores are present in a cipher list. To make
life simpler, Exim changes underscores to hyphens for OpenSSL and hyphens to
underscores for GnuTLS when processing lists of cipher suites in the
<code>tls_require_ciphers</code> options (the global option and the <code>smtp</code> transport
option).
</li><li>
The <code>tls_require_ciphers</code> options operate differently, as described in the
sections <a href="#SEC298">Requiring specific ciphers in OpenSSL</a> and <a href="#SEC299">Requiring specific ciphers or other parameters in GnuTLS</a>.
</li></ul>
<hr size="6">
<a name="GnuTLS-parameter-computation"></a>
<a name="SEC297"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC296" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC298" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC294" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC294" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 39.3 GnuTLS parameter computation </h2>
<p>GnuTLS uses RSA and D-H parameters that may take a substantial amount of time
to compute. It is unreasonable to re-compute them for every TLS session.
Therefore, Exim keeps this data in a file in its spool directory, called
‘<tt>gnutls-params</tt>’. The file is owned by the Exim user and is readable only by
its owner. Every Exim process that start up GnuTLS reads the RSA and D-H
parameters from this file. If the file does not exist, the first Exim process
that needs it computes the data and writes it to a temporary file which is
renamed once it is complete. It does not matter if several Exim processes do
this simultaneously (apart from wasting a few resources). Once a file is in
place, new Exim processes immediately start using it.
</p>
<p>For maximum security, the parameters that are stored in this file should be
recalculated periodically, the frequency depending on your paranoia level.
Arranging this is easy in principle; just delete the file when you want new
values to be computed. However, there may be a problem. The calculation of new
parameters needs random numbers, and these are obtained from ‘<tt>/dev/random</tt>’.
If the system is not very active, ‘<tt>/dev/random</tt>’ may delay returning data
until enough randomness (entropy) is available. This may cause Exim to hang for
a substantial amount of time, causing timeouts on incoming connections.
</p>
<p>The solution is to generate the parameters externally to Exim. They are stored
in ‘<tt>gnutls-params</tt>’ in PEM format, which means that they can be generated
externally using the <code>certtool</code> command that is part of GnuTLS.
</p>
<p>To replace the parameters with new ones, instead of deleting the file
and letting Exim re-create it, you can generate new parameters using
<code>certtool</code> and, when this has been done, replace Exim's cache file by
renaming. The relevant commands are something like this:
</p>
<table><tr><td> </td><td><pre class="example"># rm -f new-params
# touch new-params
# chown exim:exim new-params
# chmod 0400 new-params
# certtool --generate-privkey --bits 512 >new-params
# echo "" >>new-params
# certtool --generate-dh-params --bits 1024 >> new-params
# mv new-params gnutls-params
</pre></td></tr></table>
<p>If Exim never has to generate the parameters itself, the possibility of
stalling is removed.
</p>
<hr size="6">
<a name="Requiring-specific-ciphers-in-OpenSSL"></a>
<a name="SEC298"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC297" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC299" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC294" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC294" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 39.4 Requiring specific ciphers in OpenSSL </h2>
<p>There is a function in the OpenSSL library that can be passed a list of cipher
suites before the cipher negotiation takes place. This specifies which ciphers
are acceptable. The list is colon separated and may contain names like
DES-CBC3-SHA. Exim passes the expanded value of <code>tls_require_ciphers</code>
directly to this function call. The following quotation from the OpenSSL
documentation specifies what forms of item are allowed in the cipher string:
</p>
<ul class="toc">
<li>
It can consist of a single cipher suite such as RC4-SHA.
</li><li>
It can represent a list of cipher suites containing a certain algorithm,
or cipher suites of a certain type. For example SHA1 represents all
ciphers suites using the digest algorithm SHA1 and SSLv3 represents all
SSL v3 algorithms.
</li><li>
Lists of cipher suites can be combined in a single cipher string using
the + character. This is used as a logical and operation. For example
SHA1+DES represents all cipher suites containing the SHA1 and the DES
algorithms.
</li></ul>
<p>Each cipher string can be optionally preceded by one of the characters ‘<samp>!</samp>’,
‘<samp>-</samp>’ or ‘<samp>+</samp>’.
</p>
<ul class="toc">
<li>
If ‘<samp>!</samp>’ is used, the ciphers are permanently deleted from the list. The
ciphers deleted can never reappear in the list even if they are explicitly
stated.
</li><li>
If ‘<samp>-</samp>’ is used, the ciphers are deleted from the list, but some or all
of the ciphers can be added again by later options.
</li><li>
If ‘<samp>+</samp>’ is used, the ciphers are moved to the end of the list. This
option does not add any new ciphers; it just moves matching existing ones.
</li></ul>
<p>If none of these characters is present, the string is interpreted as
a list of ciphers to be appended to the current preference list. If the list
includes any ciphers already present they will be ignored: that is, they will
not be moved to the end of the list.
</p>
<hr size="6">
<a name="Requiring-specific-ciphers-or-other-parameters-in-GnuTLS"></a>
<a name="SEC299"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC298" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC300" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC294" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC294" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 39.5 Requiring specific ciphers or other parameters in GnuTLS </h2>
<p>The GnuTLS library allows the caller to specify separate lists of permitted key
exchange methods, main cipher algorithms, MAC algorithms, and protocols.
Unfortunately, these lists are numerical, and the library does not have a
function for turning names into numbers. Consequently, lists of recognized
names have to be built into the application. The permitted key exchange
methods, ciphers, and MAC algorithms may be used in any combination to form a
cipher suite. This is unlike OpenSSL, where complete cipher suite names are
passed to its control function.
</p>
<p>For compatibility with OpenSSL, the <code>tls_require_ciphers</code> option can be set
to complete cipher suite names such as RSA_ARCFOUR_SHA, but for GnuTLS this
option controls only the cipher algorithms. Exim searches each item in the
list for the name of an available algorithm. For example, if the list
contains RSA_AES_SHA, then AES is recognized, and the behaviour is exactly
the same as if just AES were given.
</p>
<a name="IDX2464"></a>
<a name="IDX2465"></a>
<a name="IDX2466"></a>
<p>There are additional options called <code>gnutls_require_kx</code>,
<code>gnutls_require_mac</code>, and <code>gnutls_require_protocols</code> that can be used to
restrict the key exchange methods, MAC algorithms, and protocols, respectively.
These options are ignored if OpenSSL is in use.
</p>
<p>All four options are available as global options, controlling how Exim
behaves as a server, and also as options of the <code>smtp</code> transport, controlling
how Exim behaves as a client. All the values are string expanded. After
expansion, the values must be colon-separated lists, though the separator
can be changed in the usual way.
</p>
<p>Each of the four lists starts out with a default set of algorithms. If the
first item in a list does <em>not</em> start with an exclamation mark, all the
default items are deleted. In this case, only those that are explicitly
specified can be used. If the first item in a list <em>does</em> start with an
exclamation mark, the defaults are left on the list.
</p>
<p>Then, any item that starts with an exclamation mark causes the relevant
entry to be removed from the list, and any item that does not start with an
exclamation mark causes a new entry to be added to the list. Unrecognized
items in the list are ignored. Thus:
</p>
<table><tr><td> </td><td><pre class="example">tls_require_ciphers = !ARCFOUR
</pre></td></tr></table>
<p>allows all the defaults except ARCFOUR, whereas
</p>
<table><tr><td> </td><td><pre class="example">tls_require_ciphers = AES : 3DES
</pre></td></tr></table>
<p>allows only cipher suites that use AES or 3DES.
</p>
<p>For <code>tls_require_ciphers</code> the recognized names are AES_256, AES_128, AES
(both of the preceding), 3DES, ARCFOUR_128, ARCFOUR_40, and ARCFOUR (both of
the preceding). The default list does not contain all of these; it just has
AES_256, AES_128, 3DES, and ARCFOUR_128.
</p>
<p>For <code>gnutls_require_kx</code>, the recognized names are DHE_RSA, RSA (which
includes DHE_RSA), DHE_DSS, and DHE (which includes both DHE_RSA and
DHE_DSS). The default list contains RSA, DHE_DSS, DHE_RSA.
</p>
<p>For <code>gnutls_require_mac</code>, the recognized names are SHA (synonym SHA1), and
MD5. The default list contains SHA, MD5.
</p>
<p>For <code>gnutls_require_protocols</code>, the recognized names are TLS1 and SSL3.
The default list contains TLS1, SSL3.
</p>
<p>In a server, the order of items in these lists is unimportant. The server
advertises the availability of all the relevant cipher suites. However, in a
client, the order in the <code>tls_require_ciphers</code> list specifies a preference
order for the cipher algorithms. The first one in the client's list that is
also advertised by the server is tried first. The default order is as listed
above.
</p>
<hr size="6">
<a name="Configuring-an-Exim-server-to-use-TLS"></a>
<a name="SEC300"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC299" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC301" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC294" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC294" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 39.6 Configuring an Exim server to use TLS </h2>
<p>When Exim has been built with TLS support, it advertises the availability of
the STARTTLS command to client hosts that match <code>tls_advertise_hosts</code>,
but not to any others. The default value of this option is unset, which means
that STARTTLS is not advertised at all. This default is chosen because you
need to set some other options in order to make TLS available, and also it is
sensible for systems that want to use TLS only as a client.
</p>
<p>If a client issues a STARTTLS command and there is some configuration
problem in the server, the command is rejected with a 454 error. If the client
persists in trying to issue SMTP commands, all except QUIT are rejected
with the error
</p>
<table><tr><td> </td><td><pre class="example">554 Security failure
</pre></td></tr></table>
<p>If a STARTTLS command is issued within an existing TLS session, it is
rejected with a 554 error code.
</p>
<p>To enable TLS operations on a server, you must set <code>tls_advertise_hosts</code> to
match some hosts. You can, of course, set it to * to match all hosts.
However, this is not all you need to do. TLS sessions to a server won't work
without some further configuration at the server end.
</p>
<p>It is rumoured that all existing clients that support TLS/SSL use RSA
encryption. To make this work you need to set, in the server,
</p>
<table><tr><td> </td><td><pre class="example">tls_certificate = /some/file/name
tls_privatekey = /some/file/name
</pre></td></tr></table>
<p>These options are, in fact, expanded strings, so you can make them depend on
the identity of the client that is connected if you wish. The first file
contains the server's X509 certificate, and the second contains the private key
that goes with it. These files need to be readable by the Exim user, and must
always be given as full path names. They can be the same file if both the
certificate and the key are contained within it. If <code>tls_privatekey</code> is not
set, or if its expansion is forced to fail or results in an empty string, this
is assumed to be the case. The certificate file may also contain intermediate
certificates that need to be sent to the client to enable it to authenticate
the server's certificate.
</p>
<p>If you do not understand about certificates and keys, please try to find a
source of this background information, which is not Exim-specific. (There are a
few comments below in section <a href="#SEC305">Certificates and all that</a>.)
</p>
<p><strong>Note</strong>: These options do not apply when Exim is operating as a client -
they apply only in the case of a server. If you need to use a certificate in an
Exim client, you must set the options of the same names in an <code>smtp</code>
transport.
</p>
<p>With just these options, an Exim server will be able to use TLS. It does not
require the client to have a certificate (but see below for how to insist on
this). There is one other option that may be needed in other situations. If
</p>
<table><tr><td> </td><td><pre class="example">tls_dhparam = /some/file/name
</pre></td></tr></table>
<p>is set, the SSL library is initialized for the use of Diffie-Hellman ciphers
with the parameters contained in the file. This increases the set of cipher
suites that the server supports. See the command
</p>
<table><tr><td> </td><td><pre class="example">openssl dhparam
</pre></td></tr></table>
<p>for a way of generating this data. At present, <code>tls_dhparam</code> is used only
when Exim is linked with OpenSSL. It is ignored if GnuTLS is being used.
</p>
<p>The strings supplied for these three options are expanded every time a client
host connects. It is therefore possible to use different certificates and keys
for different hosts, if you so wish, by making use of the client's IP address
in <code>$sender_host_address</code> to control the expansion. If a string expansion is
forced to fail, Exim behaves as if the option is not set.
</p>
<a name="IDX2467"></a>
<a name="IDX2468"></a>
<a name="IDX2469"></a>
<p>The variable <code>$tls_cipher</code> is set to the cipher suite that was negotiated for
an incoming TLS connection. It is included in the <em>Received:</em> header of an
incoming message (by default - you can, of course, change this), and it is
also included in the log line that records a message's arrival, keyed by
"X=", unless the <code>tls_cipher</code> log selector is turned off. The <code>encrypted</code>
condition can be used to test for specific cipher suites in ACLs.
(For outgoing SMTP deliveries, <code>$tls_cipher</code> is reset - see section
<a href="#SEC303">Configuring an Exim client to use TLS</a>.)
</p>
<p>Once TLS has been established, the ACLs that run for subsequent SMTP commands
can check the name of the cipher suite and vary their actions accordingly. The
cipher suite names vary, depending on which TLS library is being used. For
example, OpenSSL uses the name DES-CBC3-SHA for the cipher suite which in other
contexts is known as TLS_RSA_WITH_3DES_EDE_CBC_SHA. Check the OpenSSL or GnuTLS
documentation for more details.
</p>
<hr size="6">
<a name="Requesting-and-verifying-client-certificates"></a>
<a name="SEC301"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC300" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC302" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC294" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC294" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 39.7 Requesting and verifying client certificates </h2>
<p>If you want an Exim server to request a certificate when negotiating a TLS
session with a client, you must set either <code>tls_verify_hosts</code> or
<code>tls_try_verify_hosts</code>. You can, of course, set either of them to * to
apply to all TLS connections. For any host that matches one of these options,
Exim requests a certificate as part of the setup of the TLS session. The
contents of the certificate are verified by comparing it with a list of
expected certificates. These must be available in a file or,
for OpenSSL only (not GnuTLS), a directory, identified by
<code>tls_verify_certificates</code>.
</p>
<p>A file can contain multiple certificates, concatenated end to end. If a
directory is used
(OpenSSL only),
each certificate must be in a separate file, with a name (or a symbolic link)
of the form <<em>hash</em>>.0, where <<em>hash</em>> is a hash value constructed from the
certificate. You can compute the relevant hash by running the command
</p>
<table><tr><td> </td><td><pre class="example">openssl x509 -hash -noout -in /cert/file
</pre></td></tr></table>
<p>where ‘<tt>/cert/file</tt>’ contains a single certificate.
</p>
<p>The difference between <code>tls_verify_hosts</code> and <code>tls_try_verify_hosts</code> is
what happens if the client does not supply a certificate, or if the certificate
does not match any of the certificates in the collection named by
<code>tls_verify_certificates</code>. If the client matches <code>tls_verify_hosts</code>, the
attempt to set up a TLS session is aborted, and the incoming connection is
dropped. If the client matches <code>tls_try_verify_hosts</code>, the (encrypted) SMTP
session continues. ACLs that run for subsequent SMTP commands can detect the
fact that no certificate was verified, and vary their actions accordingly. For
example, you can insist on a certificate before accepting a message for
relaying, but not when the message is destined for local delivery.
</p>
<a name="IDX2470"></a>
<p>When a client supplies a certificate (whether it verifies or not), the value of
the Distinguished Name of the certificate is made available in the variable
<code>$tls_peerdn</code> during subsequent processing of the message.
</p>
<a name="IDX2471"></a>
<p>Because it is often a long text string, it is not included in the log line or
<em>Received:</em> header by default. You can arrange for it to be logged, keyed by
"DN=", by setting the <code>tls_peerdn</code> log selector, and you can use
<code>received_header_text</code> to change the <em>Received:</em> header. When no
certificate is supplied, <code>$tls_peerdn</code> is empty.
</p>
<hr size="6">
<a name="Revoked-certificates"></a>
<a name="SEC302"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC301" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC303" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC294" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC294" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 39.8 Revoked certificates </h2>
<p>Certificate issuing authorities issue Certificate Revocation Lists (CRLs) when
certificates are revoked. If you have such a list, you can pass it to an Exim
server using the global option called <code>tls_crl</code> and to an Exim client using
an identically named option for the <code>smtp</code> transport. In each case, the value
of the option is expanded and must then be the name of a file that contains a
CRL in PEM format.
</p>
<hr size="6">
<a name="Configuring-an-Exim-client-to-use-TLS"></a>
<a name="SEC303"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC302" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC304" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC294" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC294" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 39.9 Configuring an Exim client to use TLS </h2>
<p>The <code>tls_cipher</code> and <code>tls_peerdn</code> log selectors apply to outgoing SMTP
deliveries as well as to incoming, the latter one causing logging of the
server certificate's DN. The remaining client configuration for TLS is all
within the <code>smtp</code> transport.
</p>
<p>It is not necessary to set any options to have TLS work in the <code>smtp</code>
transport. If Exim is built with TLS support, and TLS is advertised by a
server, the <code>smtp</code> transport always tries to start a TLS session. However,
this can be prevented by setting <code>hosts_avoid_tls</code> (an option of the
transport) to a list of server hosts for which TLS should not be used.
</p>
<p>If you do not want Exim to attempt to send messages unencrypted when an attempt
to set up an encrypted connection fails in any way, you can set
<code>hosts_require_tls</code> to a list of hosts for which encryption is mandatory. For
those hosts, delivery is always deferred if an encrypted connection cannot be
set up. If there are any other hosts for the address, they are tried in the
usual way.
</p>
<p>When the server host is not in <code>hosts_require_tls</code>, Exim may try to deliver
the message unencrypted. It always does this if the response to STARTTLS is
a 5<em>xx</em> code. For a temporary error code, or for a failure to negotiate a TLS
session after a success response code, what happens is controlled by the
<code>tls_tempfail_tryclear</code> option of the <code>smtp</code> transport. If it is false,
delivery to this host is deferred, and other hosts (if available) are tried. If
it is true, Exim attempts to deliver unencrypted after a 4<em>xx</em> response to
STARTTLS, and if STARTTLS is accepted, but the subsequent TLS
negotiation fails, Exim closes the current connection (because it is in an
unknown state), opens a new one to the same host, and then tries the delivery
unencrypted.
</p>
<p>The <code>tls_certificate</code> and <code>tls_privatekey</code> options of the <code>smtp</code>
transport provide the client with a certificate, which is passed to the server
if it requests it. If the server is Exim, it will request a certificate only if
<code>tls_verify_hosts</code> or <code>tls_try_verify_hosts</code> matches the client. <strong>Note</strong>:
These options must be set in the <code>smtp</code> transport for Exim to use TLS when it
is operating as a client. Exim does not assume that a server certificate (set
by the global options of the same name) should also be used when operating as a
client.
</p>
<p>If <code>tls_verify_certificates</code> is set, it must name a file or,
for OpenSSL only (not GnuTLS), a directory, that contains a collection of
expected server certificates. The client verifies the server's certificate
against this collection, taking into account any revoked certificates that are
in the list defined by <code>tls_crl</code>.
</p>
<p>If
<code>tls_require_ciphers</code> is set on the <code>smtp</code> transport, it must contain a
list of permitted cipher suites. If either of these checks fails, delivery to
the current host is abandoned, and the <code>smtp</code> transport tries to deliver to
alternative hosts, if any.
</p>
<a name="IDX2472"></a>
<a name="IDX2473"></a>
<p>All the TLS options in the <code>smtp</code> transport are expanded before use, with
<code>$host</code> and <code>$host_address</code> containing the name and address of the server to
which the client is connected. Forced failure of an expansion causes Exim to
behave as if the relevant option were unset.
</p>
<a name="IDX2474"></a>
<a name="IDX2475"></a>
<p>Before an SMTP connection is established, the <code>$tls_cipher</code> and <code>$tls_peerdn</code>
variables are emptied. (Until the first connection, they contain the values
that were set when the message was received.) If STARTTLS is subsequently
successfully obeyed, these variables are set to the relevant values for the
outgoing connection.
</p>
<hr size="6">
<a name="Multiple-messages-on-the-same-encrypted-TCP_002fIP-connection"></a>
<a name="SEC304"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC303" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC305" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC294" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC294" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 39.10 Multiple messages on the same encrypted TCP/IP connection </h2>
<p>Exim sends multiple messages down the same TCP/IP connection by starting up
an entirely new delivery process for each message, passing the socket from
one process to the next. This implementation does not fit well with the use
of TLS, because there is quite a lot of state information associated with a TLS
connection, not just a socket identification. Passing all the state information
to a new process is not feasible. Consequently, Exim shuts down an existing TLS
session before passing the socket to a new process. The new process may then
try to start a new TLS session, and if successful, may try to re-authenticate
if AUTH is in use, before sending the next message.
</p>
<p>The RFC is not clear as to whether or not an SMTP session continues in clear
after TLS has been shut down, or whether TLS may be restarted again later, as
just described. However, if the server is Exim, this shutdown and
reinitialization works. It is not known which (if any) other servers operate
successfully if the client closes a TLS session and continues with unencrypted
SMTP, but there are certainly some that do not work. For such servers, Exim
should not pass the socket to another process, because the failure of the
subsequent attempt to use it would cause Exim to record a temporary host error,
and delay other deliveries to that host.
</p>
<p>To test for this case, Exim sends an EHLO command to the server after
closing down the TLS session. If this fails in any way, the connection is
closed instead of being passed to a new delivery process, but no retry
information is recorded.
</p>
<p>There is also a manual override; you can set <code>hosts_nopass_tls</code> on the
<code>smtp</code> transport to match those hosts for which Exim should not pass
connections to new processes if TLS has been used.
</p>
<hr size="6">
<a name="Certificates-and-all-that"></a>
<a name="SEC305"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC304" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC306" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC294" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC294" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 39.11 Certificates and all that </h2>
<p>In order to understand fully how TLS works, you need to know about
certificates, certificate signing, and certificate authorities. This is not the
place to give a tutorial, especially as I do not know very much about it
myself. Some helpful introduction can be found in the FAQ for the SSL addition
to Apache, currently at
</p>
<table><tr><td> </td><td><pre class="display">http://www.modssl.org/docs/2.7/ssl_faq.html#ToC24
</pre></td></tr></table>
<p>Other parts of the <em>modssl</em> documentation are also helpful, and have
links to further files.
Eric Rescorla's book, <em>SSL and TLS</em>, published by Addison-Wesley (ISBN
0-201-61598-3), contains both introductory and more in-depth descriptions.
Some sample programs taken from the book are available from
</p>
<table><tr><td> </td><td><pre class="display">http://www.rtfm.com/openssl-examples/
</pre></td></tr></table>
<hr size="6">
<a name="Certificate-chains"></a>
<a name="SEC306"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC305" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#SEC307" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC294" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC294" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 39.12 Certificate chains </h2>
<p>The file named by <code>tls_certificate</code> may contain more than one
certificate. This is useful in the case where the certificate that is being
sent is validated by an intermediate certificate which the other end does
not have. Multiple certificates must be in the correct order in the file.
First the host's certificate itself, then the first intermediate
certificate to validate the issuer of the host certificate, then the next
intermediate certificate to validate the issuer of the first intermediate
certificate, and so on, until finally (optionally) the root certificate.
The root certificate must already be trusted by the recipient for
validation to succeed, of course, but if it's not preinstalled, sending the
root certificate along with the rest makes it available for the user to
install if the receiving end is a client MUA that can interact with a user.
</p>
<hr size="6">
<a name="Self_002dsigned-certificates"></a>
<a name="SEC307"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC306" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#SEC294" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#SEC294" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<h2 class="section"> 39.13 Self-signed certificates </h2>
<p>You can create a self-signed certificate using the <em>req</em> command provided
with OpenSSL, like this:
</p>
<table><tr><td> </td><td><pre class="example">openssl req -x509 -newkey rsa:1024 -keyout file1 -out file2 \
-days 9999 -nodes
</pre></td></tr></table>
<p>‘<tt>file1</tt>’ and ‘<tt>file2</tt>’ can be the same file; the key and the certificate are
delimited and so can be identified independently. The <code>-days</code> option
specifies a period for which the certificate is valid. The <code>-nodes</code> option is
important: if you do not set it, the key is encrypted with a passphrase
that you are prompted for, and any use that is made of the key causes more
prompting for the passphrase. This is not helpful if you are going to use
this certificate and key in an MTA, where prompting is not possible.
</p>
<p>A self-signed certificate made in this way is sufficient for testing, and
may be adequate for all your requirements if you are mainly interested in
encrypting transfers, and not in secure identification.
</p>
<p>However, many clients require that the certificate presented by the server be a
user (also called "leaf" or "site") certificate, and not a self-signed
certificate. In this situation, the self-signed certificate described above
must be installed on the client host as a trusted root <em>certification
authority</em> (CA), and the certificate used by Exim must be a user certificate
signed with that self-signed certificate.
</p>
<p>For information on creating self-signed CA certificates and using them to sign
user certificates, see the <em>General implementation overview</em> chapter of the
Open-source PKI book, available online at
<strong><a href="http://ospkibook.sourceforge.net/">http://ospkibook.sourceforge.net/</a></strong>.
<a name="IDX2476"></a>
<a name="IDX2477"></a>
</p>
<hr size="6">
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#SEC294" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="spec_40.html#SEC308" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="spec.html#SEC_Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[Contents]</td>
<td valign="middle" align="left">[<a href="spec_55.html#SEC493" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="spec_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<p>
<font size="-1">
This document was generated on <i>September, 10 2009</i> using <a href="http://www.nongnu.org/texi2html/"><i>texi2html 1.78</i></a>.
</font>
<br>
</p>
</body>
</html>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
a4080654d049ad31b216b761b9173c1f
>
files
>
142
