Whether it’s a web server, an email server (two, in fact, assuming you’re using one for SMTP and another for IMAP, as is common), or other types of applications, to have encrypted connections a TLS certificate 1 is required. It can be self-signed (say, if you’ll be the only one needing to access that server), but browsers and email clients will complain (loudly!), therefore, if you want your server to be universally accessed, a “real” certificate is needed, so let’s show how to get one.
In this tutorial, I’ll be creating an ECDSA certificate with an EC key, instead of the more usual RSA type; ECDSA is more modern and is theoretically more secure even with smaller keys. If you need an RSA certificate (which I’d recommend for Postfix, for instance, since you can’t control what other email servers around the world support, so, you should go for the most common option; for web servers, ECDSA is fine), see How to create an RSA certificate.
A few notes:
- There are alternatives (e.g. key sizes, etc.) for basically every parameter I’m using, but I’m not going into those. This is supposed to be as quick and easy as possible, after all.
- Similarly, I’m not going into Let’s Encrypt; instead, I’m assuming a “normal” certificate authority such as Comodo (which supports ECDSA certificates; if you choose another, you should make sure of that in advance). If you do use Let’s Encrypt, just use it to create the certificate instead of the “send the CSR to the certification authority” part.
- The certificate (and server) will be compatible with most browsers and applications (email clients, etc.), but that “most” won’t include any Microsoft browsers on Windows XP (Firefox or Chrome on that abomination of an OS will still work).
Generating the key and the Certificate Signing Request (CSR):
The second command will ask you for details about your server/company (location, etc.). You should fill in every field, although the only mandatory one is “Common Name” (CN), which must match your server’s public name (not necessarily the machine’s name, but the hostname people will type in the browser/email client, such as “zurgl.com” or “mail.something.com“. Note that a certificate for “domain.com” also includes “www.domain.com” (so don’t include the “www.” in the CN), but if the server is reached at “subdomain.domain.com“, then that’s what the CN needs to be.
Ordering and receiving the new certificate:
Now go to a certification authority (CA), order a new certificate, and when asked for a CSR, send them (usually you can just copy and paste it to a text entry window) that myserver.csr file.
If everything went well, then the CA should email you the new certificate in a short while. Typically they send you two files: the certificate itself, and a couple of “intermediate” certificates. Only the first is really needed, but I’ve had best results with concatenating your certificate (first) and the intermediate certs (last) into a single file, which you might call myserver-full.crt .
That file is, to all intents and purposes, your new certificate, and it’s ready to be used in application servers. You can use the same certificate for several services (e.g. an HTTPS website, an SMTP server, an IMAP server), as long as the hostname matches the certificate’s CN (so a certificate for “mail.myserver.com” won’t work for “www.myserver.com“, and vice-versa, but that’s because the names don’t match — not because they’re different services).
Adding TLS encryption (with your shiny new certificate) to internet services:
Here’s a (growing) list of tutorials:
(Note: most of this post’s content originally appeared in a previous one. The reason for its creation is that I’m planning several other TLS-related posts where a certificate will be required and, to avoid repeating the “how to create a certificate” instructions in every single one of them, I’d rather have this post to link to when needed.)
2 Replies to “How to create an ECDSA certificate”