Signing Mail, 2024 Edition

I have been using S/MIME to sign e-mail for well over a decade now. Because certificates don’t last for ever, I need to renew mine every couple of years. This gives me an opportunity to experience the current state of that market and of client software.

This has seldom been a pleasant experience, and it has sometimes been downright awful (see 2019, 2022). This iteration wasn’t great, but there are some small signs of improvement.

I should make clear a couple of important qualifications which may mean that my experience isn’t applicable to your situation:

• I’m looking at this from the point of view of an individual without access to some sort of corporate-level certificate provision.
• I no longer even consider the PGP/GPG ecosystem for mail authentication, although I do still use it for artifact signing. There are enough systems in between myself and recipients these days that it is next to impossible to get even clear-signed text blocks through the system sufficiently unscathed for the signature to be verifiable. Broken signatures are not useful.

I mentioned last time that the process then depended on the long-standing capability of certain browsers to create an RSA keypair and use that in requesting an S/MIME certificate from a certification authority through the CA’s web site. This approach caused a large share of the problems in previous years because collecting the certificate, linking it to the private key in the browser and then exporting it to other clients was just full of flakiness, bugs and bad user interface design.

The browsers that had that ability are, I think, now fully extinct. The good news is that this means that all those problems went away. The bad news is that the alteratives aren’t great:

• The option that I suspect most people will use is to allow the CA’s web site to create your RSA keypair and let you download it from them. I find it surprising that this is offered without any mention of the fact that the CA therefore knows your private key. In the world of TLS certificates, the key being at any time out of your sole control would be grounds to revoke your certificate immediately. Somehow, that rule apparently doesn’t apply here. Needless to say, I don’t feel that I can take this route with a straight face.
• The second option, by analogy with the TLS certificate market, is for the customer to create their own keypair, construct an appropriate Certificate Signing Request (CSR) and submit that for signing. This obviously requires more technical knowledge and is probably something most individuals looking for S/MIME certificates won’t feel capable of doing. It is nevertheless the route I took.

Unfortunately, at least on the site of the CA I was working with, there seemed to be no documentation at all of what an appropriate CSR should look like. In the end, this is what I did:

touch smime.key
chmod 600 smime.key
openssl genrsa 3072 >>smime.key
openssl req -new -config smime.cnf -key smime.key -out smime.csr

The critical part of this is smime.cnf:

[req]
default_bits = 3072
distinguished_name = dn
prompt = no

[dn]
C=GB
ST=Scotland
L=Edinburgh
O=Ian A. Young
CN=ian@iay.org.uk
emailAddress=ian@iay.org.uk

As it turned out, the certificate product I was purchasing discarded all of the components of the distinguished name other than the emailAddress, so that could probably have been simplified.

Once I uploaded the CSR to the certification authority’s web site, I was able to download the new certificate in one of two ways:

• I could get a PKCS#12 file (sometimes called a PFX file, particularly in Microsoft environments). This would be ideal for configuring client software, but there’s a catch: this requires you to upload your private key. Yes, again, there’s an option that asks you to lose control of your private key without mentioning that in many situations this would be an unacceptable security risk. As with the “easy” option for key generation, I didn’t feel that I could do this.
• The second option is to have a PKCS#7 file generated, and that’s of course what I selected.

A PKCS#7 file is just a bag of certificates (i.e., public data). The end entity certificate (for ian@iay.org.uk in this case) is usually first, followed by the other certificates required to build a verification chain up to a trust root. This will be a familiar concept to anyone who has worked with X.509 certificates for transport layer security, as will the inevitable format conversion dance that followed on from downloading the file.

I had expected the download to be either:

• A PEM-encoded PKCS#7 bundle with the usual textual BEGIN and END lines, or
• A DER-encoded (binary) PKCS#7 bundle.

What I actually got was a text file containing a single very long line. You could think of this as the PEM variant with the header and trailer lines stripped off, or as a Base64-encoded form of the DER variant. I chose the latter viewpoint and converted it to something useful like this:

base64 --decode <smime.p7b >certs.der
openssl pkcs7 -in certs.der -inform der -print_certs -out certs.pem

Now I had a series of certificates in the textual PEM format in certs.pem, but to conifgure my mail clients I needed to further convert that to a PKCS#12 file so that I could incorporate the private (still private) key:

openssl pkcs12 -export -in certs.pem -inkey smime.key \
    -out smime.p12 -chain -untrusted certs.pem -legacy

The -legacy option changes the default encryption algorithm and was necessary to make the resulting PKCS#12 file acceptable to the Apple mail clients I use.

Once you have a PKCS#12 file, of course your troubles are over! I jest, of course: in practice, mail clients hide the configuration of signing certificates in the weirdest places. For Apple’s Mail under macOS, for example, you register the certificate in the separate Keychain Access utility and then hope that Mail notices when you enable signing in the main application.

One place things have improved a little since my previous iteration is in Apple’s mobile operating systems. Under both iOS and iPadOS, installing a new signing certificate was a bit of a pain: now, if you can locate your .p12 file in the Files application, you can just tap it and get an instruction to install the new “profile” in Settings.

In conclusion: on one hand, the bad news is that signing your e-mail is still quite problematic, sufficiently so that I wouldn’t expect most people to bother even if they knew it was possible. On the other hand, some of the old cruft has been stripped away in the last couple of years, and someone who is capable of understanding TLS certificates should be able to apply that knowledge to S/MIME certificates directly, and that’s good.

On the gripping hand, if you go through this process you get more than one opportunity to commit the cardinal sin of compromising your private key material by handing it over to a supplier. This is bad.