As the public key must be distributed to the client somehow, it
is sent from the server to the client during the startup
negotiation. The client however cannot know from just the
negotiation, that the public key really belongs to the server and
is not faked. Therefore a third component is necessary, a
certificate from a certificate authority (CA), that is sent
combined with the public key. This server certificate
contains the name.of.your.host
. The client will then
check the signature of the CA on the public key to decide,
whether the certificate (and public key) are authentic.
So for the server we do need:
name.of.your.host
.To see, whether the certificate itself is authentic, the client itself must have the CA certificate. So, if you want to make it easily accessible to other, unknown parties, you should have your server certificate issued by a well known and well trusted CA. Remember, that your server can only have one server certificate at a time.
There are commercial providers (Thawte, Verisign, just to name some), the CA certificats of which are well distributed. Not knowing of other countries, at least in Germany the Research Network (DFN) has started a program for universities [DFNPCA].
If you do not care about that for know (you can change that
later), you can just become your own CA and distribute your CA cert
to those parties who should know it, and you are set. It is not
difficult to do.
Lutz's very short course on being your own
CA.
smtpd_tls_key_file = /etc/postfix/key.pemAs the public key is public including the certificate (everybody can get a copy), everybody who has a copy of the private key can fake your identity. It is not too easy, as he must be able to redirect or intercept the IP packages sent to your server, but I have seen a lot of things happening. So protect this key with:
chown root /etc/postfix/key.pem ; chmod 400 /etc/postfix/key.pemOne more possibility for protection is a passphrase. This is however a problem, as you have to enter it everytime the server has to be started. This has to drawbacks: firstly you would have to enter it to postfix everytime you restart it, which I find quite impractical for an unattended server which might restart automatically after a power outage. Secondly the smtpd processes are independently started from master, so that master would have to pass the passphrase to the clients somehow. Alltogether I think this is impractical and so I don't support by software.
smtpd_tls_cert_file = /etc/postfix/cert.pemIf you like, you can put private key and cert into one file.
smtpd_tls_CAfile = /etc/postfix/CAcert.pem
smtp_tls_key_file = /etc/postfix/key.pem chown root /etc/postfix/key.pem ; chmod 400 /etc/postfix/key.pem
smtp_tls_cert_file = /etc/postfix/cert.pem
smtp_tls_CAfile = /etc/postfix/CAcert.pem
Some clients can have several certificates issued by different CAs. Upon connection the server will pass the client the list of CAs he knows (has the CA certificates) and the client can then pass back a certificate of choice. With Netscape this means, a window is opened and only those client certificates compatible with the server are listed for selection.
So if your clients already have certificates from trustable sources, it is not necessary to create a lot of problems. You just have to collect the CA certificates and make them available to Postfix/TLS. If that is not enough, you can still become your own CA to easily create client certificates for your users (which are of course of no use outside your scope).
You have two possibilities to perform this task.
smtp[d]_tls_CAfile
you already have created, one after the
other. This file is probably not very readable, but it has the
advantage that it is read at smtpd before switching to chroot jail
and hence works in chroot mode.smtpd_tls_CApath = /etc/postfix/certsPlease don't forget to issue a
$OPENSSL_HOME/bin/c_rehash
/etc/postfix/certs
after you have made changes, as the
hashes are use to find the right CA certificate. This method should
not work in chroot mode.A quite practical thing is that every client certificate has a
"fingerprint" that is extremely difficult to fake (read this: from
my knowledge, it might take years even on fast computers). I have
to do some more research about the security of the fingerprint, but
at least for relaying it should be secure enough. I will much
easier find a host with worse security to send out my SPAM than to
fake a client certificate with a matching fingerprint (which I also
don't know to from the outside, even from the inside you might
protect the fingerprint data with a chmod 400
).