I may have mentioned this before - I do run my own virtual servers for important services (basically email and my web presence). I do this mostly for historic reasons and also because I’m not a huge fan of using centralised services for all of the above. The downside is that you pretty much have to learn at least about basic security. Over the 20+ years I’ve been doing this, the Internet hasn’t exactly become a less hostile place. Anyway, Elliptic Curve Certificates, what about them?

I’m not a cryptographer and nor do I play one on the Internet, so I’ll direct you to this particular link over on the PKI Consortium’s website that explains why ECC cryptography is A Good Thing. TL;DR - the keys are smaller, yet offer the same or better strength, and ECC tends to be faster. Let’s Encrypt has supported ECDSA certificates for a while and now that the EFF’s certbot supports requesting ECC certificates, I figured it was time to experiment with them.

Not all clients support ECDSA yet, so I still need to support existing RSA certificates as well. Fortunately the software I use for these servers allows me to configure multiple certificates to address this issue.

How do I get an ECDSA certificate?

As mentioned, I use EFF’s Certbot to manage my certificates, at least on the FreeBSD boxes - my OpenBSD boxes use the native client, and I haven’t looked into using ECDSA certificates with it.

Certbot allows you to specify the key type via the command line parameter --key-type, so requesting an ECDSA key is a matter of running certbot certonly --key-type ecdsa with the appropriate parameters. In most cases, you want to use the ECDSA certificate as an additional certificate instead of a substitute for an existing RSA certificate, so you would want to specify the certificate name using the --cert-name option as well. For more details, have a look a the Certbot documentation.

Once you have the certificates in place, it is time to update the configuration for the various servers. As mention, I want to set up the new ECDSA certificates as additional certificates, not as replacements.

Postfix

I’m still using the older style Postfix configuration that uses a separate certificate and private key configuration setting instead of the newer smtpd_tls_chain_files configuration option. For the old style configuration, the relevant lines for the RSA key and certificate look like this:

smtpd_tls_cert_file = <path to certificate file>
smtpd_tls_key_file = <path to private key file>

To add the ECDSA certificate and key file, we need to add the following two lines and reload the configuration:

smtpd_tls_eccert_file = <path to certificate file>
smtpd_tls_eckey_file = <path to private key file>

Once I convert to using smtpd_tls_chain_files, this configuration gets simplified because all combined key/certificate files for the various key types will all be listed in the single configuration list parameter.

Dovecot

Dovecot’s configuration is similar inasmuch as Dovecot supports configuring multiple certificates and keys for a server. So in addition to the ssl_cert and ssl_key parameters that I already had configured pointing to the existing RSA certificates, I had to add the following two entries:

ssl_alt_cert = <"path to ECDSA certificate file"
ssl_alt_key = <"path to ECDSA private key file"

After that, restarting the dovecot server pulls in the new configuration and enables the support for the ECDSA certificates.

nginx

Out of the three servers, nginx is probably the easiest to configure to add support for ECDSA certificates. To add a different certificate type, you repeat the ssl_certificate and ssl_certificate_key lines in the (virtual) server configuration and add the new certificate and key file. So basically, you go from this:

ssl_certificate <path to TLS certificate>
ssl_certificate_key <path to corresponding private key file>

to this:

ssl_certificate <path to RSA TLS certificate>
ssl_certificate_key <path to corresponding RSA private key>
ssl_certificate <path to ECDSA TLS certificate>
ssl_certificate_key <path to corresponding ECDSA private key>

And like with Postfix and Dovecot, you need to reload the configuration or restart the process for the new certificates to become usable.

While I was in there - yes, I know, dangerous words - I also took the time to tweak the configuration a little more. Qualys SSL Labs’ checks had shown that I hadn’t enabled TLS 1.3 and generally gave the site a B grade, so I took this opportunity to rectify this and also tweaked the list of acceptable ciphers somewhat. To generate a suitable nginx configuration, I used Mozilla’s SSL Configuration Generator set to ‘Intermediate’. This should give me a pretty well rounded setup that should be both reasonably secure and reasonably performant.

For those on outdated browsers or links that generally work better without TLS, the blog is also accessible via HTTP, so disabling outdated and/or weak ciphers shouldn’t do much harm.

Summary

Adding ECDSA certificates is generally simple with the server processes I use, and it should lead to slightly better performance, at least for those clients who are able to take advantage of the more modern certificate types.

Is it worth it? The main server I have statistics for - my primary email server - suggests that about 1/3 to 1/2 of the connections are using ECDSA. It hasn’t made a noticeable difference to the server load, but I didn’t expect that either as the server is fairly overprovisioned for the load it is under these days. For nginx, I simply haven’t got the connection type statistics at the moment, and I haven’t looked at where I could find them. Again, the server running this blog and a couple of other sites isn’t exactly suffering from massive load, so I didn’t expect the certificate changes to make a big difference. But either way it was worth it to me to satisfy my tech curiosity.