Full Mail Server Solution w/ Virtual Domains & Users - Page 10 (Secure Email + Certificates)
VII. Secure Email
In an ideal world, our users would be able to send/receive email whenever they were on the net, from any place in the world. Unfortunately, that's incredibly insecure... passwords are being tossed back and forth in plain text via the SMTP and IMAP protocols, and that means anyone who wanted to could just 'snoop' the password.
If your users don't need direct access to the mail solution, then don't give it to them! There's no point in stressing over a secure email setup if all your users need is Webmail! Just make their connection to the webmail server secure, and make sure that the webmail server uses a secure network connection when talking to your mail servers. Problem solved! If, on the other hand, your users do require the ability to send/receive mail via the internet without using webmail, well then, that just makes things more difficult. Not impossible, just difficult.
So, here's your problem: SMTP and IMAP send passwords over clear text. You can have them send passwords using MD5, but basic MD5 can be hacked. You can have them send passwords using MD5CRYPT, but then you're dealing with multiple implementations (not to mention the fact that not all email clients support MD5 passwords). The solution? TLS (Transport Layer Security). We're going to set up our solution to support an encrypted connection over the internet. While we could modify some of our existing servers to handle this, there's no point in over-complicating their setups. We're just going to run a seperate server to handle all of this: secure-mail.example.com
NOTE: In the original scenario, the small business had multiple static IP addresses. Since this is the case, we were able to run SMTP+TLS on port 25, if you don't have multiple IP addresses, then that is not possible. The reason is simple enough: While IMAPS(secure IMAP) runs a different port (993) than standard IMAP (143), SMTP+TLS runs on the SAME port as SMTP (25). So, using a firewall to route based on ports allows you to run seperate IMAP and IMAPS servers, but no firewall in the world can route port 25 to two different machines. Even with all of that though, you could always just run SMTP+TLS on a non-standard port... heck, it would even be more secure.
So, with all of that in mind, we're going to setup a secure mail server, which uses SMTP+TLS for sending mail, and IMAPS for receiving it.
A. SSL Certificates
The simplest form of encryption is having a simple self-signed certificate on the server. This will generate a warning message when the clients first connect, but they should be able to save it for further use. It is not really secure, since anyone can execute a man-in-the-middle attack if you don’t save the certificate.
The next level is using a server certificate signed by a Certificate Authority (CA), either a commercial one, or perhaps the company internal CA. This way, the server certificate will be trusted, and if you now receive a warning, there is potentially something bad going on.
Last but definitely not least is using client certificates for logging in to the server, and using a server certificate to authenticate the server to the clients. This is quite secure, but it is not supported in all mail clients. Thunderbird among others do have support for it.
1. Self-signed server certificate
First create the directories, create the private key, and lastly create the certificate.
# mkdir -p /etc/ssl/example.com/mailserver/
Note that “Common Name (eg, YOUR name)” MUST match the name of the server, which in this case is secure-mail.example.com
2. CA-Signed Certificate
Using a real CA-signed certificate is no different from using a self-signed one. It’s just another step in the key-pair creation. If your company has its own CA, then they should issue a certificate for the mail server. A Google search for be your own ca will give you enough answers to create one yourself, if you have the need.