backstory
In December 2019, DHL, the German logistics group, notified me via email of an upcoming package delivery. I was using apple’s mail app at the time, which was displaying a checkmark similar to “twitter verified” next to the sender’s email address:
What does the check mark mean?
Upon further inspection, I discovered that gmail also tags this email with a checkmark and even provides additional information:
Once again we find a check mark, this time in green, alongside the label “Verified email address.”
even more information is presented to us when we click on “sender information”:
The keywords here are “Download certificates,” which saves a certificates.pem file to your computer. When you connect the dots you will find that this must be a S/MIME certificate that is used to encrypt & decrypt emails between recipients.
what’s in the certificate?
thanks to openssl, we can take a closer look at the content of this certificate via openssl x509 -in certificates.pem -noout -text:
and we can learn a lot from this data!
For example, this certificate was issued on May 9, 2018 and expired on May 8, 2020. It was issued by Deutsche Post in Bonn, Nordrhein-Westfalen, and refers to [email protected] as its email address. subject, which, unsurprisingly, matches the email address from the package notification email.
More importantly, if you pay attention to the x509v3 extensions, you’ll find that “email protection” was added as an extended key usage. additionally, “s/mime capabilities” are attached in extensions.
how do i get a checkmark myself?
In a nutshell:
- get an s/mime-enabled certificate
- add your certificate to all your email clients
- your email clients will start attaching your public certificate to every outgoing email
However, I found myself facing many obstacles throughout this process. Since 2016, I’ve been using Google Workspace for all my mail, calendar, and cloud storage needs.
For those of you who are interested in enabling hosted s/mime with google workspace, please read on to make sure this process goes smoothly and isn’t as time consuming as it was for me.
s/mime hosted on google workspace
Before you begin, I recommend that you read the entire post first to make sure you’re up for the challenge and the financial burden. all steps are listed in chronological order and must be completed in succession.
upgrade your google workspace plan
To get started, you’ll need to be an active subscriber to the enterprise plus plan, as it’s the only google workspace plan that supports s/mime encryption. this plan will cost you around us$30/month/user at the time of writing.
enable s/mime encryption in google workspace
Once you’ve upgraded your google workspace plan to business plus, you’ll need to manually enable s/mime in google admin.
you can do this by navigating to applications -> google workspace -> gmail settings -> user settings in google admin.
then you should be greeted by this screen:
All you’ll have to do is tick these two boxes:
- “enable s/mime encryption for sending and receiving email”
- “allow users to upload their own certificates”
press the “save” button to apply your changes!
generate a csr
The first step in your s/mime journey will be to generate a certificate signing request. to do this you will need an rsa key; you can use an existing key if you already have one.
To generate a new rsa key, run this command:
and now you can generate the csr using your rsa key:
You will be prompted to enter some details about your csr, but you can leave the fields blank using a . in the corresponding fields. however, you will want to enter your email address at the email address prompt. make sure you use the email address you want to create the s/mime certificate for!
Finally, you will be offered to enter a challenge password. you can leave this blank if you wish, but I recommend entering a passphrase for added security.
your end result should look like this:
Purchase a S/MIME enabled certificate
Next is possibly the most important step: buying an s/mime certificate! google maintains a list of trusted ca certificates that you can use to make your certificate authority decision.
I chose the silver swisssign email id certificate valid for 1 year for 25 chf, which is equivalent to about 27 US dollars at the time of writing.
We will use swisssign for the purposes of this step-by-step guide, but you can use any certificate authority of your choice. Please note that your certificate must not be valid for more than 27 months, otherwise it will be rejected by Google Workspace.
shortly after you’ve been billed by swisssign, you should be able to activate the code for your new s/mime certificate in my account -> certificates -> activate code.
because you will be prompted for it later, be sure to copy the 18 character long “certificate proof key” on this page.
once you’ve done that, click the “activate code” button to continue:
Activate your S/MIME certificate
This process is quite long and can be tedious, so make sure you have some time to follow the steps below very precisely. errors can be irreversible once the certificate is issued.
Clicking “activate code” will bring up a login page. you can ignore this login page entirely and just click the “continue without account (for quick single certificate request)” button on the left side.
You’ll be redirected to a search page. You can ignore this as well and just click the “New” button on the right-hand side.
Now you’re on the right track.
on this “certificate voucher” page, you will need to paste the 18 character long “certificate voucher key” that you previously copied from the swisssign website with the red “activate code” button.
You’ll be asked to accept the “Subscriber Agreement” which I recommend you review before clicking the checkbox.
Once you are ready, you can continue by clicking the “I accept the above conditions” button.
It’s time to paste the CSR you generated earlier. To do that, open the CSR file in a text editor of your choice, or print it with cat:
your csr will look like this:
Paste your csr in the pkcs#10 field and click “continue” to continue.
SwissSign now needs to know the email address to which the S/MIME certificate should be registered. You’re going to want to enter your email address here—make sure to double-check your input!
This next step is intended for larger organizations where e.g. an IT department would issue a S/MIME certificate on behalf of someone else. Since you’re issuing the S/MIME certificate for yourself you may leave all of these fields as they are and click “Proceed”.
To wrap up the initial activation phase, you’re presented with a final “Submission” page to make sure you entered all details correctly. Take a good minute to review all the entries. Use the “Back” button if you have to make any adjustments.
once you’re ready, hit the “request certificate” button on the right hand side.
Check your inbox! 📫
You should have received an email from swisssign. click the underlined “approve” link in the email to continue. this step is necessary to verify that you are the owner of the email address where the s/mime certificate will be registered.
The link will redirect you back to SwissSign where you’ll be given a last glance at what your certificate will look like. I recommend that you once again review the information. If there are any issues with the entries you can use the “withdrawing” link in the email to withdraw the certificate request and start anew.
click “confirm approval” to continue.
Back to your inbox! 📫
You should have received a new email from swisssign confirming that your certificate request has been approved. In the email, you will also find a “download certificate” link that you can go ahead and click to retrieve your certificate files.
On the download page, you’ll be offered several format options. You will need the .pem (certificate chain) format for the next steps, so make sure that’s selected before clicking the “Download” button.
The downloaded file will have a name like [email protected] where [email protected] is your email address.
upload your certificate in gmail
let’s add your new s/mime certificate to gmail.
To get started, you’ll need to convert your certificate to pkcs#12 format. To do this, run the following command:
you will be prompted to enter an “export password” which you will need to enter each time this pkcs#12 is imported into an email client like gmail, so make sure you write it down somewhere, preferably in a password manager . of your choice.
once you have entered a passphrase, a .p12 file will be saved in your current directory.
then open or reload your gmail tab, go to the settings tab and select the accounts tab.
Find your email address in the “Send mail as” list, and click on “edit info” on the right-hand side. A yellow pop-up window will open.
Click on the “Upload a personal certificate” link. You will be prompted with a file select dialogue. Select the .p12 file you generated earlier and confirm.
You will be prompted to enter a passphrase, which is the “export password” you selected earlier in the pkcs#12 conversion process.
Finally, hit “Add certificate” to complete the process. Your certificate should show up in the list as expected. Make sure its radio button is selected and close the pop-up window.
Using hosted S/MIME in Gmail
Congratulations, your new s/mime certificate is ready to use! 🥳
test your digital signature in gmail
I have tested my own s/mime certificate by sending a test email to my work email address:
And… there it is! The green check mark. Let’s inspect the “Sender info” link once again:
Perfect! Looks like we have a match.
send emails without digital signature
Because of the way s/mime works, every time you send an email, gmail will inject an attachment that is usually hidden in modern email clients.
Unfortunately for us, sometimes that hidden s/mime attachment isn’t actually hidden. for example, if you respond to a support ticket, help desk platforms like zendesk will add your digital signature as an attachment to the support ticket, which could confuse customer support agents.
Google must have considered this to be a problem and configured it so that you can temporarily disable the ability to attach your digital signature, if necessary.
To access these settings, start by composing an email. add a recipient and you will get a little lock icon on the right hand side, next to the “cc” and “bcc” buttons:
Clicking the lock icon will present you with a pop-up summary of the message security methods used:
To change the message security settings, click “View details”:
From here, all you have to do is click “Standard encryption” and you should be good to go. This will prevent Gmail from injecting your S/MIME certificate and force it to fall back to the default encryption method—most likely TLS.
You probably won’t need to do this often, but it’s handy to have it ready when you need it.
“this message could not be decrypted”
Under very certain circumstances, you may receive an encrypted email from a contact that gmail “couldn’t decrypt”. the content will be attached as smime.p7m instead.
the displayed message gives some clues as to why this is so:
As you can tell from the very short and to-the-point error message, the sender did not supply their digital signature, which is why Gmail refuses to decrypt the email. It’s not that it can’t—Apple Mail does it without complaining—Gmail just doesn’t want to.
I contacted google workspace support in April 2021 and was given this information:
The last paragraph might be the solution for you, but I discovered that one of my contacts just didn’t attach his digital signature to any outgoing emails.
However, this does not prevent us from seeing the email! you can use this command to decrypt the smime.p7m attachment:
publishing your smimea dns logs
It is recommended to publish the smimea (type 53) dns records of your certificate. this has two main advantages:
- allows recipients to check the validity of your signed email against the dns record
- if someone wants to send you an encrypted email, they can use the smimea dns record to get your public key without need your certificate file
enable dnssec
The smimea dns record is only valid if your domain has dnssec enabled to verify that the tlsa record has not been tampered with.
You can refer to this table to find out if your tld offers dnssec. if so, you may want to contact your carrier for setup instructions.
If your tld or provider doesn’t offer dnssec, you won’t be able to use smimea dns registration, but your certificates will still work fine.
get your name prefix
first things first, you will need the name of the smimea dns record. consists of two parts:
- your email prefix
- the ._smimecert suffix
for example, if your email address is [email protected], your command would look like this:
Note that only the string eric is used in the echo command instead of the full email address. it is very important that you only include something before the @ symbol, otherwise your name prefix will be incorrect.
Your output should look similar to this:
But that’s only half the story. you’ll need to add ._smimecert right after your encrypted email prefix, like so:
and that’s a change in your name prefix! ✨
download your pem certificates
To use the following set of commands, you will need your pem certificates. Go back to the swisssign download page and check the .pem radio button in the “format” section:
Generate the hashes
Below are the values.
there are two selectors:
- 0 for full certificate
- 1 for subjectpublickeyinfo
and three matching types:
- 0 for no hashing
- 1 for sha-256
- 2 for sha-512
Lastly, we will use usage 3 for the domain-issued certificate because it is the only one that applies to our use case.
Each of the usages, selectors, and match types play a different role, so you’ll want to post as many combinations as possible to ensure maximum compatibility.
To get the necessary values for your smimea dns records, run these commands:
publish your logs
and lastly, you can publish your logs through your provider, which in my case is cloudflare:
Test your records
I highly recommend tobias bauer’s smimea test website to check the validity of your smimea dns records:
The website is published in German, but the results are color coded and you can use google translate for more information if needed. the green check mark usually means that your smimea dns records have been implemented correctly:
Final thoughts
As you can see from this elaborate tutorial, the s/mime setup process can be very confusing and overwhelming for non-tech-savvy users who want to benefit from the extra layer of security and the newness of the checkmark in email clients, which can make s/mime quite undesirable for a large portion of potential users. additional costs for google workspace enterprise plus and periodic renewal of your s/mime certificate can also be an issue.
In my opinion, s/mime is a niche feature that isn’t going anywhere right now, after all, it is and will continue to be the standardized method of sending and receiving encrypted email. but in its current form, s/mime’s target audience probably won’t expand beyond high-profile companies and interested individuals.
Do you want to test your new s/mime certificate? feel free to email me and I’ll try to get back to you in a timely manner. 😊
Enjoy your new check mark!