Sign your emails and save your certificate on a Yubikey.
The eM Client email program has been updated since original publication (I’m now using version 7.1.31849). It’s support for S/MIME has improved (supporting SHA256 and AES), but it now manages its own certificate store. Which means my Yubikey isn’t required to sign emails; eM Client does everything itself - which isn’t as secure as using the Yubikey to protect the certificate.
I’ve updated the client side support: Google’s apps now support S/MIME.
I got a pair of Yubikey’s for Christmas. I’d quickly used the Universal 2 Factor “security token” part to add a second factor to my Google and DropBox accounts. But I was looking for some way I could use them beyond that “security token” style.
The Yubikey 4 is a PIV compatible smart card, which means it can store X.509 certificates and use them to encrypt, sign and authenticate.
(My work is currently evaluating using the smart-card feature as an alternative to Windows logins, so I had some idea of this feature before hand).
My personal computers are not part of a Windows domain, so I couldn’t use smart-card based logins. But I found you can encrypt / sign emails using S/MIME, which struck me as a way to make use of the Yubikey.
I read a couple of recent articles from Ars Technica about PGP and email. One somewhat negative, the other a bit of a rebuttal to the first. But the overall impression was that encrypting email was a recipe for disaster, there were too many things which could go wrong and render emails unreadable. However, signing emails looked like a helpful “value add” which would degrade nicely for people who’s email client didn’t support S/MIME. If people could see the mail was signed then that’s nice, but otherwise they’re no worse off than before.
S/MIME is supposedly well supported and “just works” (because it uses the same X.509 certificate authority hierarchy used by SSL/TLS, as opposed to the more labour intensive PGP). However, I quickly found that not all email clients support it. So I’d be looking for a new Windows email app.
I’d also need to obtain a (preferably free) X.509 certificate which could be used for signing emails.
Finally, I’d load the cert into my Yubikey such that it is only accessible when it is plugged in.
I have been using two email clients: Windows Mail (the new client which I’d been using since Windows 10) which I found nicer to compose emails, and Windows Live Mail (and older client which shipped as part of the Windows Essentials suite) which I used to manage emails (mostly for the ability to copy emails between different email accounts).
Windows Mail only supports S/MIME with an Exchange server, so that wouldn’t work.
I found eM Client, which promised S/MIME support. It has a free license version which is restricted to two email accounts, which is enough for my purposes. Installation and configuration was straight forward enough. And it felt more modern than the aging Windows Live Mail.
I haven’t yet found an appropriate app for Android devices.
X.509 certificates are a complicated beast. I’ve used StartSSL and Lets Encrypt in the past to obtain SSL/TLS certificates, but their purpose is to identify a server. For S/MIME I needed a certificate to identify me as the owner of an email address.
(Although, as an important aside, no free S/MIME certificate that I’m aware of connects a real person to the email address. All validation is done by magic links in emails. So all the certificate is asserting is that Murray Grant can receive emails at his email address. No attempt is made to check that Murray Grant is real, or has anything to do with the ligos.net domain, or any particular email address under that domain. All of that requires money for real people to check real documents, and I wasn’t going to spend real money on this exercise just yet.)
Lets Encrypt only offers server certs, not personal ones, so it was out of the question.
I’ve migrated all my websites to use Lets Encrypt instead of StartSSL, but remembered the later offer more certificate options. I noticed they offered free 3 year S/MIME Client certificates, which looked promising. So I dusted off a neglected StartSSL account and re-validated my email address in preparation for a shiny new certificate.
Until I noticed this:
When certificate authorities get distrusted by browsers, that usually is game over for them. Further research lead me to the document the Mozilla Foundation issued as to why they’ve come to this decision. The short version is that StartCom (the company behind StartSSL) got bought by WoSign. WoSign broke some of the rules certificate authorities must abide by when they issue certificates. And StartCom were using the same systems and processes as WoSign.
So no StartSSL certificate. (At least for the next 12 months).
I found that Comodo will issue free certificates for email. And embarked on their validation process.
The important thing, which doesn’t seem to be well advertised, is you need to use Internet Explorer. Chrome wouldn’t generate the private key.
As soon as you visit the site, Internet Explorer pops up a message about digital certificates. You need to say Yes to this. On pretty much every page in the process.
Start by filling in your name, email to validate and country. (Just to remind people, the email address is validated, but I could enter any name and county I felt like).
After you enter a revocation password and agree to the terms and conditions, click submit.
You now have a certificate request pending. Which means you have a private key on your computer, and you’ve submitted the public part of the key to Comodo for their stamp of approval.
(If you dig into the Windows Certificate MMC Snap-in.aspx), you’ll see your half complete cert).
You then get an email, with a magic link to validate that you do indeed control the email you just entered. Click the big red button (or, because Internet Explorer is not my default browser, I copied the link and pasted into IE).
Comodo then trusts your email and signs your private key as being valid. Which means the rest of the world now trusts your certificate.
And if you look in the Windows Certificate MMC Snap-in again, you’ll find your certificate all ready to go, issued to the email you entered and with a private key.
The last step is to create a backup of your certificate, and especially its private key. Because if your computer dies, your certificate dies with it. In the Certificate Snap-in, you can right click and export a certificate. Just remember to include the private key and stick a password on it.
(Also, if you’re going to load the cert into your Yubikey, you’ll need that backup file).
Now we have a certificate, we need to tell eM Client to use it. (Obviously, this step will be different for other email clients, but the overall process of choosing a certificate to use for an email account will be similar).
In the Menu -> Tools -> Settings -> Mail -> Certificates. You create a new Security Profile.
Create a profile for the email account, and select the certificate which was just created. I wanted to sign all emails, so I ticked that box. But left the encrypt by default box unticked. (After I took the screenshot, I removed the Encrypt By certificate, so I can’t accidentally encrypt emails).
Unfortunately, eM Client only supports 3DES and SHA1 (rather than the more modern AES and SHA2 functions) at the time of writing (UPDATE version 7.1 of eM Client supports AES and SHA2). Which is OK for my purposes, and it appears they are planning to support other algorithms.
Then I wrote a test email, and sent it to my other email account. As I wanted to see what it looks like in other mail clients.
I soon found that S/MIME support
isn’t that wide spread in 2017 is pretty good, as at August 2018.
eM Client supports S/MIME, and indicates it via a badge icon and signed by email@example.com.
I’ve actually once or twice received signed emails in Windows Live Mail, so I know it’s supported. Again, you get a little badge, but no email address next to it (in fairness, the email is a few lines above).
The new Windows Mail client doesn’t seem to support S/MIME signed by public certificates (even in 2018). I’m guessing it only works for internal Exchange Server certificates. Instead, you see an unusual attachment, which I presume are attached certificates required to verify the email. Fortunately, the content of the email is still readable.
Since at least August 2018, GMail shows the certificate details. You have to dig into a little “extra details” icons to find it though, there’s nothing to indicate a signature in the default view. And click Sender info and you’ll see the certificate details.
Again, since August 2018, the Android GMail app gives a green tick once you tab Show details. Nothing in the default view. And a Sender info for certificate details as well.
I didn’t show MS Outlook in the original article (because I only use it at work), but I remember S/MIME was supported back then. For completeness, here’s a signed email in whatever version of Outlook my work computer has.
Update August 2018: S/MIME support seems considerably better in 2018, and my original goal is still valid as well. Everyone can still read my email, and now more people can see it’s been signed by me.
It’s possible that the email clients which don’t show the message as signed are doing that because of the obsolete SHA1 hash algorithm. Although, if that was the case, I’d expect nasty red banners saying the signature isn’t valid.
Overall, this is the outcome I was aiming for: people with the right email client will see the signature and get a nice badge, and if your email client doesn’t support S/MIME, you’re no worse off.
So far, the certificate is stored in the Windows Certificate Store (which I happen to know is a bunch of files buried deep in your user folder).
That’s nice, but it doesn’t make any use of the shiny new Yubikey I just got. (Note: if you don’t have a Yubikey, you can quite safely stop here and get all the benefits of S/MIME signatures).
UPDATE: version 7.1 of eM Client uses its own certificate store, so it doesn’t use my YubiKey any more.
To copy the certificate to your Yubikey, download and install the Yubikey PIV Manager. This will let you control your Yubikey’s smart-card functionality (PIN and loading certificates).
Start the PIV Manager and insert your Yubikey. You may be prompted to enter a PIN as part of the setup process. Then click Certificates.
smart-cards let you install certificates in “slots”. For our purposes of signing emails, we use the Digital Signature slot. (I’m not sure if there’s any special significance to which slot you use).
Click Import from File and select the
pfx file you exported as a backup at the end of step 3.
You’ll be required to enter the password you set on the
Then the certificate and private key will be loaded into your Yubikey.
If all goes well, you’ll see the following:
The PIV Manager asked me to remove and then insert the Yubikey before the certificate is usable. Which I did.
After this, step 7 just magically worked.
I was slightly concerned that my private key was still stored with the certificate. The Certificate Snap-in certainly said it was.
I was also puzzled about how Windows suddenly knew that it needed my Yubikey to use the certificate (and no other certificate in my system).
After adding and removing the certificate from both the Windows certificate store and my Yubikey, I worked out the following:
- The private key may or may not be stored in the normal certificate store, I can’t really tell. But Windows knows the private key is available.
- The act of loading a certificate into your Yubikey via PIV Manager tags it in some way in your certificate store; Windows knows it needs to use a smart-card to use the private key for that cert.
- There’s no obvious indicator in the certificate store that the certificate requires a smart-card. It looks identical to every other certificate with a private key.
- I think / hope (and this is pure speculation on my part) that loading the certificate into a Yubikey destroys the private key on disk such that Window must go to the smart-card to make use of the private key.
- You must not remove the certificate from the certificate store; doing so means eM Client can’t find the cert and cannot sign email.
- You cannot just have the public key part of the certificate in your certificate store; eM Client is not able to sign because no private key is available.
- Removing the certificate from your Yubikey does not change what Windows knows about the cert; it will still prompt you for a smart-card (you just won’t have one that works any more).
- Removing the certificate from the certificate store makes Windows forget it needs a smart-card; in effect, this resets the requirement for the Yubikey.
With eM Client 7.1, none of the below applies any more. The certificate is managed entirely by eM Client, and the Yubikey doesn’t come into play.
Signing emails using S/MIME works nicely, if you have the right email client.
The main benefit is to prove that you really did write what you said you wrote.
That is, to assure your recipients that your emails don’t have a forged
from field (which usually indicates its spam or contains a malicious attachment / link).