Creating a TLS encryption key and certificate

Leave a comment

(If you are unfamiliar with the abbreviation “TLS“: it is the successor to SSL.)

The internet is the best invention since sliced bread but it has become an evil place more than ever. We are dealing with script kiddies, out-of-control secret services and organized crime on a large scale. It is completely out of the question to run any unencrypted services over the internet. I consider any password immediately wasted that went through the internet unencryptedly. So let us create an encryption key and a certificate for Postfix (SMTP), Dovecot (IMAP/POP3) and Roundcube (Webmail/HTTPS).

Caveat: do not use different certificates for Postfix and Dovecot. At least the MacOS mail client will refuse your connection with confusing error messages.

There are two factors that make an encryption certificate secure:

(a) – Cryptographical security
The mathematical idea of one-way functions that make it easy to decrypt data if you know the key – but to make it virtually impossible trying to break the decryption without that knowledge. For a couple of years the SHA1 algorithm was famous but thanks to Edward Snowden’s disclosures we assume that it can be broken too easily. So everyone is advised to use at least SHA256 (which is part of the SHA2 algorithm). Also RSA signatures should not be 1024 bits long any more but rather 4096 bits. Creating secure keys and certificates is relatively easy – we have tools for that.

(b) – Trust
The idea of trusting a certificate. What’s the point if the certificate is mathematically good but you don’t know who you are communicating with. You may communicate very securely with the wrong counterpart (called man-in-the-middle). That’s not what you want. (See also my article on creating your own certificate authority.)

So you have to decide whether to buy a certificate or to create one yourself. In comparison:

Type Advantages Disadvantage Application
Self-signed No costs. Quickly created. Users will get a warning message about an untrusted certificate. They can accept the certificate manually but you should tell them the certificate’s fingerprint so they can verify it. Private mail server for yourself and friends who don’t mind ignoring the warning message about an unverified identity.
Self-signed with own PKI No costs. You can create further certificates that your users will consider trusted if they have your root certificate installed. The easy-rsa package is a good start. Takes 15 minutes longer for you. Requires that all users install your root certificate as trusted on their computers. This may make sense only if you can automatically distribute the certificate in a corporate environment. Private mail server for yourself and friends who don’t mind installing your root certificate once. Or a corporate mail server where you can automatically deploy your root certificate on all client workstations.
No-cost certificate from LetsEncrypt No costs. Users will likely not get a warning because most software trusts LetsEncrypt. Certificates are only valid for 90 days. Depending on your network it may be a hassle and cause a downtime to renew a certificate. Public mail server that does not need sugar coating called “extended validation”.
Paid certificate Users will not get a warning. Expensive (50€-200€ per year).
Probably a lengthy registration process.
You support the certificate mafia.
You don’t improve the communication security in any way.
For anyone who has too much money.

Note: Whichever method you use – always create the key on your own server. Never trust a key that has been created by anyone else. It appears simpler because you can omit one step. But the other party now knows your secret key and could in theory intercept your encrypted traffic. I will describe how to do that properly in any of the following sections. Just choose your option and follow the instructions.

Option 1: Self-signed
The simplest option. Just run this command on your server and you have a valid all-purpose certificate that is valid for the next ten years:

openssl req -newkey rsa:4096 -nodes -sha512 -x509 -days 3650 -nodes -out /etc/ssl/certs/mailserver.pem -keyout /etc/ssl/private/mailserver.pem
You will be asked for several pieces of information. Enter whatever you like. The only important field is the “Common Name” that must contain the fully-qualified host name that you want your server to be known on the internet. Fully-qualified means host + domain.

Make sure that the secret key is only accessible by the ‘root’ user:

chmod go= /etc/ssl/private/mailserver.pem
Option 2: Self-signed with own PKI
This option is a bit better than using a simple self-signed certificate. But your users or customers need to install your root certificate manually to establish a trust relationship to your PKI in both their browsers and their email programs.

I suggest you install the “easy-rsa” package and read the documentation:

zless /usr/share/doc/easy-rsa/README-2.0.gz
If there is enough interest in this topic I will elaborate on managing your own certificate authority using easy-rsa.

Option 3: No-cost certificate from StartSSL
This is almost always the best option. It doesn’t cost you money and will give you a basic trustworthy certificate that most browsers and email clients will accept.

Create a 4096 bit key file:

openssl genrsa -out /etc/ssl/private/mailserver.pem 4096
Create a certificate signing request (CSR) file from that key:

openssl req -new -key /etc/ssl/private/mailserver.pem -out /etc/ssl/certs/mailserver.csr
You will be asked for several pieces of information. Enter whatever you like. The only important field is the “Common Name” that must contain the fully-qualified host name that you want your server to be known on the internet.

Now go to StartSSL and sign up for an account. First use the “Validation Wizard” to validate your email address first. Then use the validation wizard again to validate the domain you want to use for your email server.

Next use the “Certificates Wizard” to create a “Web Server SSL/TLS certificate”. Choose your email domain, paste the contents of the CSR file (/etc/ssl/certs/mailserver.csr) you created previously and receive your certificate file. Move that file to /etc/ssl/certs/mailserver.pem and set its permissions properly:

chmod go= /etc/ssl/private/mailserver.pem
In addition to the Apache configuration described below please ensure to install the chaining certificate, too. A sample configuration section is available in the StartSSL documentation.

Option 4: Paid certificate
Are you sure you want to do it? Then just search the web for “SSL certificate” and throw your money at any certificate authority.

The key and the certificate request are created as described above in Option 3.

Use the CSR file to request a certificate from the SSL authority. Move that certificate file to /etc/ssl/certs/mailserver.pem and set its permissions properly:

chmod go= /etc/ssl/private/mailserver.pem
Increasing TLS security
By the way – you should forbid communication using potentially insecure encryption methods. There is a way to attack the encryption by pretending that you do not support modern encryption techniques and thus rather want to use SSL version 2 or 3. This is called the POODLE attack. So you better run

postconf ‘smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3’
to forbid communication using pre-Snowden protocols that may be abused to attack you. (Thanks for the hint, Guillaume.)

About Letowon Saitoti Abdi

simple person and always happy.