Postfix/TLS - Setting up the certificates

This section explains what kind of certificates are needed to run postfix with TLS. The certificates (and maybe keys) can be obtained from a third party, that might be a commercial certification authority or your internet service provider. On the long run you do need certificates that are accepted by other Internet parties, so you have to agree with them on certification authorities, of which type they might be.

Server certificate

To run SMTP with TLS in server mode, your server must have a pair of private key and public key.

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:

1 server private key
1 server public key signed by a CA, a server certificate, certifying that the public key belongs to name.of.your.host.
1 CA certificate with the public key of the CA

For this list I definitely want point out the number of components used to be 1, because you must have 1, you cannot have less, you cannot have more!

Server certificate policy

At this point you have to decide about policy. The client which is going to connect to your host will check the name in the server certificate, the CN (Common Name), against the FQDN (Fully Qualified Domain Name) of your server. If both agree, your server's identity is proved.

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 CERT of the Research Network (DFN) has started a program for universities [DFNCERT].

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.

Using the certificates with Postfix/TLS

To make the key and certificates available to Postfix/TLS, they must be in "PEM" format. Then you have to tell postfix in main.cf where to find them:

The private key:
```
smtp_tls_key_file = /etc/postfix/key.pem
```
As 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.pem
```
One 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.
The server certificate: This certificate is not secret, as it will be presented to every client anyhow, so you just name it to postfix:
```
smtp_tls_cert_file = /etc/postfix/cert.pem
```
If you like, you can put private key and cert into one file.
The CA certificate: To also have the CA certificate available, you put it into a file and name it to Postfix/TLS. We will come back to this file later.
```
smtp_tls_CAfile = /etc/postfix/CAcert.pem
```

With these certificates you should already have enough to get Postfix/TLS running.

Postfix/TLS client mode

When connecting to a server offering TLS, postfix can present a client certificate of its own. As realized by now, only one certificate can be managed, so it should be issued on your own hostname. No default is supplied (no certificate is presented), unless you explicitly set the certificate in the configuration. You can use the same certificate as for the server side:

smtpd_tls_key_file = /etc/postfix/key.pem
chown root /etc/postfix/key.pem ; chmod 400 /etc/postfix/key.pem

smtpd_tls_cert_file = /etc/postfix/cert.pem

smtpd_tls_CAfile = /etc/postfix/CAcert.pem

Client certificates

One reason to do all of this work is that I want to do relaying based on client certificates. The clients present a certificate from a CA, that is unique and cannot be faked.

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).

Listing CA certificates

You have two possibilities to perform this task.

You just add the CA certificates to the 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.
You can add the CA certificates in single files with adequate names to a certificate directory specified in:
```
smtpd_tls_CApath = /etc/postfix/certs
```
Please 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.

Adding client certificates

The client certificates are issued for a DN (Distinguished Name) made up of company, department, name, email... As they may contain blanks, @ signs and colons, it is quite difficult to handle them with standard postfix tools.

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).