horok/postfix
1
0
Fork 0
Code Activity
postfix/proto/FORWARD_SECRECY_README.html
Daniel Baumann 75cf244379
Adding upstream version 3.10.2. 
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
2025-06-21 14:19:32 +02:00

614 lines
26 KiB
HTML
Raw Permalink Blame History

<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
"https://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>TLS Forward Secrecy in Postfix</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link rel='stylesheet' type='text/css' href='postfix-doc.css'>
</head>
<body>
<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">
TLS Forward Secrecy in Postfix
</h1>
<hr>
<h2> Warning </h2>
<p> Forward secrecy does not protect against active attacks such
as forged DNS replies or forged TLS server certificates. If such
attacks are a concern, then the SMTP client will need to authenticate
the remote SMTP server in a sufficiently-secure manner. For example,
by the fingerprint of a (CA or leaf) public key or certificate.
Conventional PKI relies on many trusted parties and is easily
subverted by a state-funded adversary. </p>
<h2> Overview </h2>
<p> Postfix supports forward secrecy of TLS network communication
since version 2.2. This support was adopted from Lutz J&auml;nicke's
"Postfix TLS patch" for earlier Postfix versions. This document
will focus on TLS Forward Secrecy in the Postfix SMTP client and
server. See <a href="TLS_README.html">TLS_README</a> for a general
description of Postfix TLS support. </p>
<p> Topics covered in this document: </p>
<ul>
<li> <p> Give me some background on forward secrecy in Postfix </p>
<ul>
<li><a href="#dfn_fs">What is Forward Secrecy</a>
<li><a href="#tls_fs">Forward Secrecy in TLS</a>
<li><a href="#server_fs">Forward Secrecy in the Postfix SMTP Server</a>
<li><a href="#client_fs">Forward Secrecy in the Postfix SMTP Client</a>
</ul>
<li> <p> Never mind, just show me what it takes to get forward
secrecy </p>
<ul>
<li><a href="#quick-start">Getting started, quick and dirty</a>
<li><a href="#test">How can I see that a connection has forward secrecy?</a>
<li><a href="#ciphers"> What ciphers provide forward secrecy? </a>
<li><a href="#status"> What do "Anonymous", "Untrusted", etc. in
Postfix logging mean? </a>
</ul>
<li> <p> <a href="#credits"> Credits </a> </p>
</ul>
<h2><a name="dfn_fs">What is Forward Secrecy</a></h2>
<p> The term "Forward Secrecy" (or sometimes "Perfect Forward Secrecy")
is used to describe security protocols in which the confidentiality
of past traffic is not compromised when long-term keys used by either
or both sides are later disclosed. </p>
<p> Forward secrecy is accomplished by negotiating session keys
using per-session cryptographically-strong random numbers that are
not saved, and signing the exchange with long-term authentication
keys. Later disclosure of the long-term keys allows impersonation
of the key holder from that point on, but not recovery of prior
traffic, since with forward secrecy, the discarded random key
agreement inputs are not available to the attacker. </p>
<p> Forward secrecy is only "perfect" when brute-force attacks on
the key agreement algorithm are impractical even for the best-funded
adversary and the random-number generators used by both parties are
sufficiently strong. Otherwise, forward secrecy leaves the attacker
with the challenge of cracking the key-agreement protocol, which
is likely quite computationally intensive, but may be feasible for
sessions of sufficiently high value. Thus forward secrecy places
cost constraints on the efficacy of bulk surveillance, recovering
all past traffic is generally infeasible, and even recovery of
individual sessions may be infeasible given a sufficiently-strong
key agreement method. </p>
<h2><a name="tls_fs">Forward Secrecy in TLS</a></h2>
<p> Early implementations of the SSL protocol do not provide forward
secrecy (some provide it only with artificially-weakened "export"
cipher suites, but we will ignore those here). The client
sends a random "pre-master secret" to the server encrypted with the
server's RSA public key. The server decrypts this with its private
key, and uses it together with other data exchanged in the clear
to generate the session key. An attacker with access to the server's
private key can perform the same computation at any later time. </p>
<p> Later revisions to the TLS protocol introduced forward-secrecy
cipher suites in which the client and server implement a key exchange
protocol based on ephemeral secrets. Sessions encrypted with one
of these newer cipher suites are not compromised by future disclosure
of long-term authentication keys. </p>
<p> The key-exchange algorithms used for forward secrecy require
the TLS server to designate appropriate "parameters" consisting of a
mathematical "group" and an element of that group called a "generator".
Presently, there are two flavors of "groups" that work with PFS: </p>
<ul>
<li> <p> <b>FFDHE:</b> Finite-field Diffie-Hellman ephemeral key
exchange groups (also EDH or DHE). The server needs to be configured
with a suitably-large prime and a corresponding "generator". Standard
choices of the prime and generator are specified in RFC7919, and can be
used in the TLS 1.3 protocol with the server and client negotiating a
mutually supported choice. In earlier versions of TLS (1.0 through
1.2), when FFDHE key exchange is performed, the server chooses the prime
and generator unilaterally. </p>
<li> <p> <b>EECDH:</b> This is short for Ephemeral Elliptic Curve
Diffie-Hellman (also abbreviated as ECDHE). EECDH offers better
security at lower computational cost than FFDHE. Elliptic curves used
in cryptography are typically identified by a "name" that stands for a
set of well-known parameter values, and it is these "named curves" (or,
in certificates, associated ASN.1 object identifiers) that are used in
the TLS protocol. When EECDH key exchange is used, a mutually supported
named curve is negotiated as part of the TLS handshake. </p>
</ul>
<h2><a name="server_fs">Forward Secrecy in the Postfix SMTP Server</a></h2>
<p> The Postfix &ge; 2.2 SMTP server supports forward secrecy in
its default configuration. If the remote SMTP client prefers cipher
suites with forward secrecy, then the traffic between the server
and client will resist decryption even if the server's long-term
authentication keys are <i>later</i> compromised. </p>
<p> Most remote SMTP clients now support forward secrecy (the only
choice as of TLS 1.3), but some may prefer cipher suites <i>without</i>
forward secrecy. Postfix &ge; 2.8 servers can be configured to override
the client's preference by setting "tls_preempt_cipherlist = yes". </p>
<h3> FFDHE Server support </h3>
<p> Postfix &ge; 3.1 supports 2048-bit-prime FFDHE out of the box, with
no additional configuration. You can also generate your own FFDHE
parameters, but this is not necessary and no longer recommended. See
the <a href="#quick-start">quick-start</a> section for details. </p>
<p> Postfix &ge; 3.8 supports the finite-field Diffie-Hellman ephemeral
(FFDHE) key exchange group negotiation API of OpenSSL &ge; 3.0. FFDHE
groups are explicitly negotiated between client and server starting with
TLS 1.3. In earlier TLS versions, the server chooses the group
unilaterally. The list of candidate FFDHE groups can be configured via
"tls_ffdhe_auto_groups", which can be used to select a prioritized list
of supported groups (most preferred first) on both the server and
client. The default list is suitable for most users. Either, but not
both of "tls_eecdh_auto_curves" and "tls_ffdhe_auto_groups" may be set
empty, disabling either EC or FFDHE key exchange in OpenSSL 3.0 with TLS
1.3. That said, interoperability will be poor if the EC curves are
all disabled or don't include the most widely used curves. </p>
<h3> EECDH Server support </h3>
<p> As of Postfix 3.2 and OpenSSL 1.0.2, a range of supported EECDH
curves is enabled in the server and client, and a suitable mutually
supported curve is negotiated as part of the TLS handshake. The list of
supported curves is configurable via the "tls_eecdh_auto_curves"
parameter. With TLS 1.2 the server needs to leave its setting of
"smtpd_tls_eecdh_grade" at the default value of "auto" (earlier choices
of an explicit single curve grade are deprecated). With TLS 1.3, the
"smtpd_tls_eecdh_grade" parameter is not used, and curve selection is
unconditionally negotiated. </p>
<h2> <a name="client_fs">Forward Secrecy in the Postfix SMTP Client</a> </h2>
<p> The Postfix &ge; 2.2 SMTP client supports forward secrecy in its
default configuration. All supported OpenSSL releases support both
FFDHE and EECDH key exchange. If the remote SMTP server supports cipher
suites with forward secrecy (and does not override the SMTP client's
cipher preference), then the traffic between the server and client will
resist decryption even if the server's long-term authentication keys are
<i>later</i> compromised. Forward secrecy is always on in TLS 1.3. </p>
<p> Postfix &ge; 3.2 supports the curve negotiation API of OpenSSL
&ge; 1.0.2. The list of candidate curves can be changed via the
"tls_eecdh_auto_curves" configuration parameter, which can be used
to select a prioritized list of supported curves (most preferred
first) on both the Postfix SMTP server and SMTP client. The default
list is suitable for most users. </p>
<p> Postfix &ge; 3.8 supports the finite-field Diffie-Hellman ephemeral
(FFDHE) key exchange group negotiation API of OpenSSL &ge; 3.0.
The list of candidate FFDHE groups can be configured via
"tls_ffdhe_auto_groups", which can be used to select a prioritized list
of supported groups (most preferred first) on both the server and
client. The default list is suitable for most users. </p>
<p> The default Postfix SMTP client cipher lists are correctly ordered
to prefer EECDH and FFDHE cipher suites ahead of similar cipher suites
that don't implement forward secrecy. Administrators are strongly
discouraged from changing the cipher list definitions. </p>
<h2><a name="quick-start">Getting started, quick and dirty</a></h2>
<h3> EECDH Client support (Postfix &ge; 3.2 with OpenSSL &ge; 1.1.1) </h3>
<p> This works "out of the box" with no need for additional
configuration. </p>
<p> Postfix &ge; 3.2 supports the curve negotiation API of OpenSSL
&ge; 1.0.2. The list of candidate curves can be changed via the
"tls_eecdh_auto_curves" configuration parameter, which can be used
to select a prioritized list of supported curves (most preferred
first) on both the Postfix SMTP server and SMTP client. The default
list is suitable for most users. </p>
<h3> EECDH Server support (Postfix &ge; 3.2 with OpenSSL &ge; 1.1.1) </h3>
<p> This works "out of the box" with no need for additional
configuration. </p>
<p> Postfix &ge; 3.2 supports the curve negotiation API of OpenSSL
&ge; 1.0.2. The list of candidate curves can be changed via the
"tls_eecdh_auto_curves" configuration parameter, which can be used
to select a prioritized list of supported curves (most preferred
first) on both the Postfix SMTP server and SMTP client. The default
list is suitable for most users. </p>
<h3> FFDHE Client support (Postfix &ge; 3.2, OpenSSL &ge; 1.1.1) </h3>
<p> In Postfix &lt; 3.8, or OpenSSL prior to 3.0, FFDHE for TLS 1.2 or
below works "out of the box", no additional configuration is necessary.
The most one can do is (not advisable) disable all "kDHE" ciphers, which
would then disable FFDHE key exchange in TLS 1.2 and below. </p>
<p> With OpenSSL 1.1.1, FFDHE is not supported for TLS 1.3, which uses
only EECDH key exchange. Support for FFDHE with TLS 1.3 was added in
OpenSSL 3.0. With OpenSSL 3.0 and Postfix 3.8 the list of supported TLS
1.3 FFDHE groups becomes configurable via the "tls_ffdhe_auto_groups"
parameter, which can be set empty to disable FFDHE in TLS 1.3, or
conversely expanded to support more groups. The default should work
well for most users. </p>
<h3> FFDHE Server support (Postfix &ge; 2.2, all supported OpenSSL
versions) </h3>
<p> In Postfix &lt; 3.8, or OpenSSL prior to 3.0, FFDHE for TLS 1.2 or
below works "out of the box", no additional configuration is necessary.
One can of course (not advisable) disable all "kDHE" ciphers, which
would then disable FFDHE key exchange in TLS 1.2 and below. </p>
<p> The built-in default Postfix FFDHE group is a 2048-bit group as of
Postfix 3.1. You can optionally generate non-default Postfix SMTP
server FFDHE parameters for possibly improved security against
pre-computation attacks, but this is not necessary or recommended. Just
leave "smtpd_tls_dh1024_param_file" at its default empty value. </p>
<p> The set of FFDHE groups enabled for use with TLS 1.3 becomes
configurable with Postfix &ge; 3.8 and OpenSSL &ge; 3.0. The default
setting of "tls_ffdhe_auto_groups" enables the RFC7919 2048 and 3072-bit
groups. If you need more security, you should probably be using EECDH.
</p>
<h2><a name="test">How can I see that a connection has forward
secrecy? </a> </h2>
<p> Postfix can be configured to report information about the
negotiated cipher, the corresponding key lengths, and the remote
peer certificate or public-key verification status. </p>
<ul>
<li> <p> With "smtp_tls_loglevel = 1" and "smtpd_tls_loglevel = 1",
the Postfix SMTP client and server will log TLS connection information
to the maillog file. The general logfile format is shown below.
With TLS 1.3 there may be additional properties logged after the
cipher name and bits. </p>
<blockquote>
<pre>
postfix/smtp[<i>process-id</i>]: Untrusted TLS connection established
to host.example.com[192.168.0.2]:25: TLSv1 with cipher <i>cipher-name</i>
(<i>actual-key-size</i>/<i>raw-key-size</i> bits)
postfix/smtpd[<i>process-id</i>]: Anonymous TLS connection established
from host.example.com[192.168.0.2]: TLSv1 with cipher <i>cipher-name</i>
(<i>actual-key-size</i>/<i>raw-key-size</i> bits)
</pre>
</blockquote>
<li> <p> With "smtpd_tls_received_header = yes", the Postfix SMTP
server will record TLS connection information in the Received:
header in the form of comments (text inside parentheses). The general
format depends on the smtpd_tls_ask_ccert setting. With TLS 1.3 there
may be additional properties logged after the cipher name and bits. </p>
<blockquote>
<pre>
Received: from host.example.com (host.example.com [192.168.0.2])
(using TLSv1 with cipher <i>cipher-name</i>
(<i>actual-key-size</i>/<i>raw-key-size</i> bits))
(Client CN "host.example.com", Issuer "John Doe" (not verified))
Received: from host.example.com (host.example.com [192.168.0.2])
(using TLSv1 with cipher <i>cipher-name</i>
(<i>actual-key-size</i>/<i>raw-key-size</i> bits))
(No client certificate requested)
</pre>
</blockquote>
<p> TLS 1.3 examples. Some of the new attributes may not appear when not
applicable or not available in older versions of the OpenSSL library. </p>
<blockquote>
<pre>
Received: from localhost (localhost [127.0.0.1])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(No client certificate requested)
Received: from localhost (localhost [127.0.0.1])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature ECDSA (P-256) client-digest SHA256)
(Client CN "example.org", Issuer "example.org" (not verified))
</pre>
</blockquote>
<ul>
<li> <p> The "key-exchange" attribute records the type of "Diffie-Hellman"
group used for key agreement. Possible values include "DHE", "ECDHE", "X25519"
and "X448". With "DHE", the bit size of the prime will be reported in
parentheses after the algorithm name, with "ECDHE", the curve name. </p>
<li> <p> The "server-signature" attribute shows the public key signature
algorithm used by the server. With "RSA-PSS", the bit size of the modulus will
be reported in parentheses. With "ECDSA", the curve name. If, for example,
the server has both an RSA and an ECDSA private key and certificate, it will be
possible to track which one was used for a given connection. </p>
<li> <p> The new "server-digest" attribute records the digest algorithm used by
the server to prepare handshake messages for signing. The Ed25519 and Ed448
signature algorithms do not make use of such a digest, so no "server-digest"
will be shown for these signature algorithms. </p>
<li> <p> When a client certificate is requested with "smtpd_tls_ask_ccert" and
the client uses a TLS client-certificate, the "client-signature" and
"client-digest" attributes will record the corresponding properties of the
client's TLS handshake signature. </p> </ul>
</ul>
<p> The next sections will explain what <i>cipher-name</i>,
<i>key-size</i>, and peer verification status information to expect.
</p>
<h2><a name="ciphers"> What ciphers provide forward secrecy? </a> </h2>
<p> There are dozens of ciphers that support forward secrecy. What
follows is the beginning of a list of 51 ciphers available with
OpenSSL 1.0.1e. The list is sorted in the default Postfix preference
order. It excludes null ciphers that only authenticate and don't
encrypt, together with export and low-grade ciphers whose encryption
is too weak to offer meaningful secrecy. The first column shows the
cipher name, and the second shows the key exchange method. </p>
<blockquote>
<pre>
$ openssl ciphers -v \
'aNULL:-aNULL:kEECDH:kEDH:+RC4:!eNULL:!EXPORT:!LOW:@STRENGTH' |
awk '{printf "%-32s %s\n", $1, $3}'
AECDH-AES256-SHA Kx=ECDH
ECDHE-RSA-AES256-GCM-SHA384 Kx=ECDH
ECDHE-ECDSA-AES256-GCM-SHA384 Kx=ECDH
ECDHE-RSA-AES256-SHA384 Kx=ECDH
ECDHE-ECDSA-AES256-SHA384 Kx=ECDH
ECDHE-RSA-AES256-SHA Kx=ECDH
ECDHE-ECDSA-AES256-SHA Kx=ECDH
ADH-AES256-GCM-SHA384 Kx=DH
ADH-AES256-SHA256 Kx=DH
ADH-AES256-SHA Kx=DH
ADH-CAMELLIA256-SHA Kx=DH
DHE-DSS-AES256-GCM-SHA384 Kx=DH
DHE-RSA-AES256-GCM-SHA384 Kx=DH
DHE-RSA-AES256-SHA256 Kx=DH
...
</pre>
</blockquote>
<p> To date, all ciphers that support forward secrecy have one of
five values for the first component of their OpenSSL name: "AECDH",
"ECDHE", "ADH", "EDH" or "DHE". Ciphers that don't implement forward
secrecy have names that don't start with one of these prefixes.
This pattern is likely to persist until some new key-exchange
mechanism is invented that also supports forward secrecy. </p>
<p> The actual key length and raw algorithm key length
are generally the same with non-export ciphers, but they may
differ for the legacy export ciphers where the actual key
is artificially shortened. </p>
<p> Starting with TLS 1.3 the cipher name no longer contains enough
information to determine which forward-secrecy scheme was employed,
but TLS 1.3 <b>always</b> uses forward-secrecy. On the client side,
up-to-date Postfix releases log additional information for TLS 1.3
connections, reporting the signature and key exchange algorithms.
Two examples below (the long single line messages are folded across
multiple lines for readability): </p>
<blockquote>
<pre>
postfix/smtp[<i>process-id</i>]:
Untrusted TLS connection established to 127.0.0.1[127.0.0.1]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature ECDSA (P-256) client-digest SHA256
postfix/smtp[<i>process-id</i>]:
Untrusted TLS connection established to 127.0.0.1[127.0.0.1]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256
</pre>
</blockquote>
<p> In the above connections, the "key-exchange" value records the
"Diffie-Hellman" algorithm used for key agreement. The "server-signature" value
records the public key algorithm used by the server to sign the key exchange.
The "server-digest" value records any hash algorithm used to prepare the data
for signing. With "ED25519" and "ED448", no separate hash algorithm is used.
</p>
<p> Examples of Postfix SMTP server logging: </p>
<blockquote>
<pre>
postfix/smtpd[<i>process-id</i>]:
Untrusted TLS connection established from localhost[127.0.0.1]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature ECDSA (P-256) client-digest SHA256
postfix/smtpd[<i>process-id</i>]:
Anonymous TLS connection established from localhost[127.0.0.1]:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
server-signature RSA-PSS (2048 bits) server-digest SHA256
postfix/smtpd[<i>process-id</i>]:
Anonymous TLS connection established from localhost[127.0.0.1]:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
server-signature ED25519
</pre>
</blockquote>
<p> Note that Postfix &ge; 3.4 server logging may also include a
"to <i>sni-name</i>" element to record the use of an alternate
server certificate chain for the connection in question. This happens
when the client uses the TLS SNI extension, and the server selects
a non-default certificate chain based on the client's SNI value:
</p>
<blockquote>
<pre>
postfix/smtpd[<i>process-id</i>]:
Untrusted TLS connection established from client.example[192.0.2.1]
to server.example: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature ECDSA (P-256) client-digest SHA256
</pre>
</blockquote>
<h2><a name="status"> What do "Anonymous", "Untrusted", etc. in
Postfix logging mean? </a> </h2>
<p> The verification levels below are subject to man-in-the-middle
attacks to different degrees. If such attacks are a concern, then
the SMTP client will need to authenticate the remote SMTP server
in a sufficiently-secure manner. For example, by the fingerprint
of a (CA or leaf) public key or certificate. Remember that
conventional PKI relies on many trusted parties and is easily
subverted by a state-funded adversary. </p>
<dl>
<dt><b>Anonymous</b> (no peer certificate)</dt>
<dd> <p> <b> Postfix SMTP client:</b> With opportunistic TLS (the "may" security level) the Postfix
SMTP client does not verify any information in the peer certificate.
In this case it enables and prefers anonymous cipher suites in which
the remote SMTP server does not present a certificate (these ciphers
offer forward secrecy of necessity). When the remote SMTP server
also supports anonymous TLS, and agrees to such a cipher suite, the
verification status will be logged as "Anonymous". </p> </dd>
<dd> <p> <b> Postfix SMTP server:</b> This is by far most common,
as client certificates are optional, and the Postfix SMTP server
does not request client certificates by default (see smtpd_tls_ask_ccert).
Even when client certificates are requested, the remote SMTP client
might not send a certificate. Unlike the Postfix SMTP client, the
Postfix SMTP server "anonymous" verification status does not imply
that the cipher suite is anonymous, which corresponds to the
<i>server</i> not sending a certificate. </p> </dd>
<dt><b>Untrusted</b> (peer certificate not signed by trusted CA)</dt>
<dd>
<p> <b> Postfix SMTP client:</b> The remote SMTP server presented
a certificate, but the Postfix SMTP client was unable to check the
issuing CA signature. With opportunistic TLS this is common with
remote SMTP servers that don't support anonymous cipher suites.
</p>
<p> <b> Postfix SMTP server:</b> The remote SMTP client presented
a certificate, but the Postfix SMTP server was unable to check the
issuing CA signature. This can happen when the server is configured
to request client certificates (see smtpd_tls_ask_ccert). </p>
</dd>
<dt><b>Trusted</b> (peer certificate signed by trusted CA, unverified
peer name)</dt>
<dd>
<p> <b> Postfix SMTP client:</b> The remote SMTP server's certificate
was signed by a CA that the Postfix SMTP client trusts, but either
the client was not configured to verify the destination server name
against the certificate, or the server certificate did not contain
any matching names. This is common with opportunistic TLS
(smtp_tls_security_level is "may" or else "dane" with no usable
TLSA DNS records) when the Postfix SMTP client's trusted CAs can
verify the authenticity of the remote SMTP server's certificate,
but the client is not configured or unable to verify the server
name. </p>
<p> <b> Postfix SMTP server:</b> The remote SMTP client certificate
was signed by a CA that the Postfix SMTP server trusts. The Postfix
SMTP server never verifies the remote SMTP client name against the
names in the client certificate. Since the client chooses to connect
to the server, the Postfix SMTP server has no expectation of a
particular client hostname. </p>
</dd>
<dt><b>Verified</b> (peer certificate signed by trusted CA and
verified peer name; or: peer certificate with expected public-key
or certificate fingerprint)</dt>
<dd>
<p> <b> Postfix SMTP client:</b> The remote SMTP server's certificate
was signed by a CA that the Postfix SMTP client trusts, and the
certificate name matches the destination or server name(s). The
Postfix SMTP client was configured to require a verified name,
otherwise the verification status would have been just "Trusted".
</p>
<p> <b> Postfix SMTP client:</b> The "Verified" status may also
mean that the Postfix SMTP client successfully matched the expected
fingerprint against the remote SMTP server public key or certificate.
The expected fingerprint may come from smtp_tls_policy_maps or from
TLSA (secure) DNS records. The Postfix SMTP client ignores the CA
signature. </p>
<p> <b> Postfix SMTP server:</b> The status is never "Verified",
because the Postfix SMTP server never verifies the remote SMTP
client name against the names in the client certificate, and because
the Postfix SMTP server does not expect a specific fingerprint in
the client public key or certificate. </p>
</dd>
</dl>
<h2><a name="credits">Credits </a> </h2>
<ul>
<li> TLS support for Postfix was originally developed by Lutz
J&auml;nicke at Cottbus Technical University.
<li> Wietse Venema adopted and restructured the code and documentation.
<li> Viktor Dukhovni implemented support for many subsequent TLS
features, including EECDH, and authored the initial version of this
document.
</ul>
</body>
</html>
View git blame Copy permalink