1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
4
<meta name="generator" content="HTML Tidy, see www.w3.org">
5
<title>Postfix/TLS - Setting up the certificates</title>
8
<h1>Postfix/TLS - Setting up the certificates</h1>
10
This section explains what kind of certificates are needed to run
11
postfix with TLS. The certificates (and maybe keys) can be obtained
12
from a third party, that might be a commercial certification
13
authority or your internet service provider. On the long run you do
14
need certificates that are accepted by other Internet parties, so
15
you have to agree with them on certification authorities, of which
18
<h2>Server certificate</h2>
20
To run SMTP with TLS in server mode, your server <strong>
21
must</strong> have a pair of <em>private key</em> and <em>public
24
<p>As the public key must be distributed to the client somehow, it
25
is sent from the server to the client during the startup
26
negotiation. The client however cannot know from just the
27
negotiation, that the public key really belongs to the server and
28
is not faked. Therefore a third component is necessary, a <em>
29
certificate</em> from a certificate authority (CA), that is sent
30
combined with the public key. This <em>server certificate</em>
31
contains the <code>name.of.your.host</code>. The client will then
32
check the <em>signature</em> of the CA on the public key to decide,
33
whether the certificate (and public key) are authentic.</p>
35
<p>So for the server we do need:</p>
38
<li>1 <em>server private key</em></li>
40
<li>1 server public key signed by a CA, a <em>server
41
certificate</em>, certifying that the public key belongs to <code>
42
name.of.your.host</code>.</li>
44
<li>1 <em>CA certificate</em> with the public key of the CA</li>
47
For this list I definitely want point out the number of components
48
used to be <strong>1</strong>, because you must have <strong>
49
1</strong>, you cannot have less, you cannot have more!
51
<h3>Server certificate policy</h3>
53
At this point you have to decide about policy. The client which is
54
going to connect to your host will check the names in the <em>server
55
certificate</em>, the dNSName entries in the SubjectAlternativeName
56
or the CN (Common Name) if no dNSName is found, against the FQDN (Fully
57
Qualified Domain Name) of your server. If both agree, your server's
60
<p>To see, whether the certificate itself is authentic, the client
61
itself <em>must have</em> the <em>CA certificate</em>. So, if you
62
want to make it easily accessible to other, unknown parties, you
63
should have your server certificate issued by a well known and well
64
trusted CA. Remember, that your server can only have one server
65
certificate at a time.</p>
67
<p>There are commercial providers (Thawte, Verisign, just to name
68
some), the CA certificats of which are well distributed. Not
69
knowing of other countries, at least in Germany the
70
Research Network (DFN) has started a program for universities [<a
71
href="references.html#dfnpca">DFNPCA</a>].</p>
73
<p>If you do not care about that for know (you can change that
74
later), you can just become your own CA and distribute your CA cert
75
to those parties who should know it, and you are set. It is not
77
<a href="myownca.html">Lutz's very short course on being your own
80
<h3>Using the certificates with Postfix/TLS</h3>
82
To make the key and certificates available to Postfix/TLS, they
83
must be in "PEM" format. Then you have to tell postfix in main.cf
90
smtpd_tls_key_file = /etc/postfix/key.pem
93
As the public key is public including the certificate (everybody
94
can get a copy), everybody who has a copy of the private key can
95
fake your identity. It is not too easy, as he must be able to
96
redirect or intercept the IP packages sent to your server, but I
97
have seen a lot of things happening. So protect this key with:
100
chown root /etc/postfix/key.pem ; chmod 400 /etc/postfix/key.pem
103
One more possibility for protection is a passphrase. This is
104
however a problem, as you have to enter it everytime the server has
105
to be started. This has to drawbacks: firstly you would have to
106
enter it to postfix everytime you restart it, which I find quite
107
impractical for an unattended server which might restart
108
automatically after a power outage. Secondly the smtpd processes
109
are independently started from master, so that master would have to
110
pass the passphrase to the clients somehow. Alltogether I think
111
this is impractical and so I don't support by software.</li>
113
<li>The server certificate: This certificate is not secret, as it
114
will be presented to every client anyhow, so you just name it to
118
smtpd_tls_cert_file = /etc/postfix/cert.pem
121
If you like, you can put private key and cert into one file.</li>
123
<li>The CA certificate: To also have the CA certificate available,
124
you put it into a file and name it to Postfix/TLS. We will come
125
back to this file later.
128
smtpd_tls_CAfile = /etc/postfix/CAcert.pem
133
With these certificates you should already have enough to get
136
<h3>Postfix/TLS client mode</h3>
138
When connecting to a server offering TLS, postfix can present a
139
client certificate of its own. As realized by now, only one
140
certificate can be managed, so it should be issued on your own
141
hostname. No default is supplied (no certificate is presented),
142
unless you explicitly set the certificate in the configuration. You
143
can use the same certificate as for the server side:
146
smtp_tls_key_file = /etc/postfix/key.pem
147
chown root /etc/postfix/key.pem ; chmod 400 /etc/postfix/key.pem
151
smtp_tls_cert_file = /etc/postfix/cert.pem
155
smtp_tls_CAfile = /etc/postfix/CAcert.pem
158
<h2>Client certificates</h2>
160
One reason to do all of this work is that I want to do relaying
161
based on client certificates. The clients present a certificate
162
from a CA, that is unique and cannot be faked.
164
<p>Some clients can have several certificates issued by different
165
CAs. Upon connection the server will pass the client the list of
166
CAs he knows (has the CA certificates) and the client can then pass
167
back a certificate of choice. With Netscape this means, a window is
168
opened and only those client certificates compatible with the
169
server are listed for selection.</p>
171
<p>So if your clients already have certificates from trustable
172
sources, it is not necessary to create a lot of problems. You just
173
have to collect the CA certificates and make them available to
174
Postfix/TLS. If that is not enough, you can still become your own
175
CA to easily create client certificates for your users (which are
176
of course of no use outside your scope).</p>
178
<h3>Listing CA certificates</h3>
180
<p>You have two possibilities to perform this task.</p>
183
<li>You just add the CA certificates to the <code>
184
smtp[d]_tls_CAfile</code> you already have created, one after the
185
other. This file is probably not very readable, but it has the
186
advantage that it is read at smtpd before switching to chroot jail
187
and hence works in chroot mode.</li>
189
<li>You can add the CA certificates in single files with adequate
190
names to a certificate directory specified in:
193
smtpd_tls_CApath = /etc/postfix/certs
196
Please don't forget to issue a <code>$OPENSSL_HOME/bin/c_rehash
197
/etc/postfix/certs</code> after you have made changes, as the
198
hashes are use to find the right CA certificate. This method should
199
not work in chroot mode.</li>
202
<h3>Adding client certificates</h3>
204
The client certificates are issued for a DN (Distinguished Name)
205
made up of company, department, name, email... As they may contain
206
blanks, @ signs and colons, it is quite difficult to handle them
207
with standard postfix tools.
209
<p>A quite practical thing is that every client certificate has a
210
"fingerprint" that is extremely difficult to fake (read this: from
211
my knowledge, it might take years even on fast computers). I have
212
to do some more research about the security of the fingerprint, but
213
at least for relaying it should be secure enough. I will much
214
easier find a host with worse security to send out my SPAM than to
215
fake a client certificate with a matching fingerprint (which I also
216
don't know to from the outside, even from the inside you might
217
protect the fingerprint data with a <code>chmod 400</code>).</p>
added
removed
tls/doc/setup.html
