Serving Email Part 3: Encryption and SSL Certificates

This is part three of a six part series on setting up an email server and covers encryption and SSL Certificates*. This post is also useful for someone who just wants https support for their website.

This series:

Part 1: The Pieces of the Puzzle
Part 2: Subdomains and DNS
Part 3: Encryption and SSL Certificates <- You are here
Part 4: The Email Server(s)
Part 5: Autoconfiguration
Part 6: Debugging Email Servers

* Technically a TLS Certificate, a type of Public Key Certificate, but it is still normally referred to by the old name, "SSL Certificate".

Paper SSL certificate with question mark

What the Heck is an SSL Certificate?

An SSL certificate is used to verify that your browser, email program, or other program is communicating securely with the address in the certificate. It does this by combining the address, a public key and a little bit of other info, then having a trusted entity digitally sign that combination.

Your web-browser, email program or other program has a list of self-signed "root certificates" that it trusts. If a certificate from a website is signed by one of these, then it will trust that certificate. Not only that, it will also trust any chain (certificate signed by certificate signed by ... signed by root certificate) that end in a trusted root certificate. An important proviso, is that any parent certificates needs to be a certificate authority certificate - thus you can't sign someone else's certificate, just because you have a website certificate. There are other important provisos, but that's the basics.

Validation

Certificate Authorities are required to verify that the certificates they sign are who they purport to be. There are three levels of validation: domain validation, organizational validation, and extended validation.

Domain Validation

This lowest level of validation simply verifies that you have control of the site. There are 3 ways this is usually done:

Respond to an email to the registered webmaster or postmaster of the site
Place a file in a specific location on the site
Make a DNS record (see previous post in this series)

You may need to do these in combination: e.g. place a file sent to the webmaster on your website, or make a DNS record specified in an email to the postmaster.

SEAL OF APPROVAL, with a circus seal animal

Organization Validation (or Business Validation)

Certificates with organizational validation fill in the "organization" field in the certificate. They usually cost significantly more than just domain validation certificates.

Proving that you are the organizational or business entity that you say you are usually involves sending copies of your letter of incorporation, organizational charter or other business documents and may take days for the review.

Extended Validation

Then there's "Extended Validation" (EV) that will turn the address bar or text green and may place the organization's name in the address bar. In this case, the business validation is more extensive and should ensure the customer that your business entity is "above board". Note that wildcard certificates are not possible with EV. EV certificates are very expensive.

I find it telling, that neither Amazon, nor ebay have adopted EV, though PayPal has.

What Certificate(s) will you need?

You can and should use the same certificate(s) for https and for your MTA (Mail Transfer Agent). You will need certificate support for each subdomain the MTA is using, whether that is the single domain solution (example.com), the single extra subdomain solution (mail.example.com), or a multi-subdomain solution (imap.example.com, pop3.example.com, smtp.example.com).

Note that because of inherent limitations in the mail protocols, your MTA has only one domain per protocol / IP-Address. This means only one SSL Certificate per protocol / IP-Address. This does not mean that it cannot handle emails from all your domains: it merely requires that the domain be explicit in the email username. For instance: if you have the domains example.com and example2.com on the same server / IP address, the email client setup for me@example2.com might set the server to mail.example.com and the user for login to me@example2.com. One could not set the user to just me, because it would not be able to differentiate between me@example.com and me@example2.com.

A wildcard certificate should work, be careful however: I ran into a hitch with a wildcard certificate I bought: "*.softwareschmiede-herndon.de" is not a valid certificate for "softwareschmiede-herndon.de" (it's missing the ".") - this was not an email specific problem. This can be solved by either always redirecting to "www." or by getting a certificate that explicitly covers the main domain as well.

You will not need certificates for autoconfiguration (autoconfig.example.com, autodiscover.example.com), though they don't hurt either.

If you already have the certificate(s) you need and they are installed for https, then you should continue with Part 4 when that is posted.

If you have certificate(s), but they are not installed for https, you can skip to installation.

Obtaining Certificates

If you don't have the certificate(s) you need yet, there are the following options:

Self-signed certificates.
Obtain from Let's Encrypt. These are free, but only good for three months at a time.
Obtain from your webhoster: this is often the easiest (sometimes Let's Encrypt is actually easier).
Obtain from a third party.

Escher work 'Drawing Hands' - two hands each drawing the other

Self-signed Certificates

One can generate a certificate for oneself and there are several guides in the internet to generating them. I tried it, and I no longer consider this an option: your users will get nasty warnings when they visit your website or try to use your mail server. On some clients, I found no in-program way to circumvent the lack of trust, meaning that the user has to figure out how to install a trusted certificate on their platform.

If you choose this option, you are on your own.

Let's Encrypt!

Let's Encrypt (letsencrypt.org) is a "free, open, and automated Certificate Authority." These certificates only have domain validation and are only good for three months, but they are free.

How that works in specifics is different based on which panel you're using or if you're using a panel at all.

Verification Difficulties

If your Let's Encrypt verification does not work, then you probably have some sort of redirect going on, such that the verification files placed on the website are not found. For instance this blog uses ProxyPass to serve from ghost blogging software, which is on port 2368. Let's Encrypt! uses the subdirectory ".well-known" (which is also used for other purposes), so I added "ProxyPass /.well-known !" to my "Apache & Nginx Settings" in Plesk which now looks like this:

HTTP:

RewriteEngine On
ProxyPass /.well-known !
ProxyPass / http://localhost:2368/
ProxyPassReverse / http://localhost:2368/

HTTPS:

RewriteEngine On
ProxyPass /.well-known !
ProxyPass / http://localhost:2368/
ProxyPassReverse / http://localhost:2368/
RequestHeader set X-Forwarded-Proto "https"

If you are using a different panel or a different webserver, you will need to adjust according to that software.

Plesk Let's Encrypt! Plugin

Here is the Plesk extension for Let's Encrypt!. It is free. Login to Plesk, click on "Extensions", click the button "Add Extension" and upload the extension. Then start the extension by clicking on it. You will see a list of your domains. For most domains, simply click on the domain to install a "Let's Encrypt!" certificate.

cPanel Let's Encrypt! Plugin

I do not currently use cPanel, but here is the cPanel plugin. It is probably worth the $30: doing a hand verification yourself every couple months will get old real quick.

Do it yourself Let's Encrypt! Certificates

Go to "Getting Started" at letsencrypt.org and follow the instructions. Currently, this mostly mean using certbot. Certbot can be setup on the webserver (if you have command line access) to do automatic renewals. Or it can be run in manual mode if you don't have command line access.

SSL Certificate from your Webhoster?

If Let's Encrypt! is not for you - you need organizational validation, a wildcard certificate, or certificates that are valid for years - then the easiest route is almost certainly your webhoster: your webhoster will already have domain validation, may already have organizational validation through your business relationship with them and the process may or may not be integrated into your panel. They may also allow you to pay for the certificate monthly: be careful not to compare monthly prices to yearly prices!

A certificate from your webhoster will almost certainly be more expensive than from a 3rd party: the margins are thin and competition fierce in webhosting, so ISPs try to cash in on their "captive audience" once they have you. Fortunately, webhosters generally allow 3rd party certificates - they would lose many transfer customers if they didn't. So unless money is no object, I recommend shopping around.

blue speaker on left, red speaker on right, question mark in middle

SSL Certificate from a 3rd Party

If you buy from a reputable 3rd party, you will have to do the validation from scratch.

A note of caution: I started with a commercial certificate from StartSSL. They had the cheapest commercial plan for my purposes. Unfortunately, StartSSL was bought by WoSign, another certificate provider, without revealing this - meaning they had two votes in the CAB forum where they should have only had one. Due to this and other irregularities, Firefox and Chrome will no longer trust their certificates starting in January 2017. I have since moved all my websites to Let's Encrypt! So, research the trustworthiness of your certificate seller.

Here are some popular SSL certificate sellers with their current (December, 2016) price for a single domain / year with domain validation only. This list is not exhaustive - it is only intended to give you an idea of the range and a place to start. Note also that you can usually get a cheaper cost/year by buying a three year certificate.

DigiCert - $175
GeoTrust - $149
GlobalSign - $179
GoDaddy - $50.99
InstantSSL - $79.95
RapidSSL - $59
SSLs.com - $8.95

Installing Certificates for HTTPS

How you install a certificate will, once again, depend on which panel / platform you have. MTA specific installation will be covered in the next part of the series.

Plesk (https/mail)
cPanel (https/mail)
Apache (https)
Windows/IIS (https)

Installing Certificates in Plesk

If you're using the Let's Encrypt! extension, congratulations! You're done for now.

Otherwise, as per the instructions:

go to the "Hosting Settings" of the domain
enable "SSL Support"
go to the "SSL Certificates" of the domain
select "Add SSL Certificate" (I've never gotten the "Upload certificate button here to work correctly)
enter a name you will remember for that certificate
if you received your certificate in file form (the most common case), upload the three files you need. Otherwise copy and paste what you need, then click on the appropriate "Upload Certificate" button.

Installing Certificates in cPanel

Here is the cPanel guide to installing certificates. Unlike Plesk, cPanel will let you choose which domain / certificate to use for the MTA.

Installing Certificates in Apache

If you're running under Linux, you are almost certainly using Apache. If you're not using a panel, then this is the right place.
Here is Apache's documentation on setting up SSL/TLS.

Installing Certificates in Microsoft IIS

If you're running Windows through a panel, it should handle configuring your webserver for you. If you're not using a panel, and you're using IIS, not Apache, then:

Here is the guide for configuring certificates in IIS 7.0.

In Closing

I highly recommend using certificates and HTTPS for your websites, even if you don't technically need them or only need them for your mail server:

Too many ISPs are doing deep-packet inspection and some even do ad injection. Encryption prevents that.
HTTPS, though theoretically slower than HTTP, is actually faster in practice.

I also highly recommend getting your certificates from Let's Encrypt! and, if you can, supporting them in their good work.

Thank you for reading my blog post!