Encryption in Exchange Online Part 6

In the first five parts of this series, I cover encryption, BitLocker, TLS, Office 365 Message Encryption, and Information Rights Management.  In part 6 we turn our attention to the final encryption option, S/MIME.

What is S/MIME, and what does it do?

S/MIME is “client to client” encryption.  S/MIME is the only client-side option available in Exchange Online to allow Outlook or OWA clients to encrypt messages from creation to delivery.  That’s not to say that email normally leaves your PC in plain text. Depending on what client you use, and how you connect to Exchange, in-transit encryption mechanisms such as TLS protect messages en route to Exchange. However, that protection is removed once messages reaches Exchange and other protection is then used, like BitLocker to protect data at rest in the database.  

Exchange has access to email when it is protected by all the other types of encryption discussed in this series. The server needs this ability to be able to perform functions like virus protection, discovery searches, DLP, transport rules, and so on. The downside in Exchange being able to decrypt and process your email traffic is that a highly permissioned Exchange administrator might be able to read your email.  In the case of Exchange Online, Microsoft goes to some pretty extreme lengths to ensure that there is no unauthorized access to your information.  You can read all about those measures at the Office 365 Trust Center website.  That being said, I’ve had customers ask me “…but what if someone, on the Office 365 team, decides that it's worth getting fired and is willing to break into my Exchange server to read my email?  Is there anything I can do to protect my email from that?” S/MIME is the technology that allows you to encrypt your email, so that even a crazed Office 365 admin cannot read your email.

But wait, there’s more! Not only does S/MIME provide “client to client” encryption, it also provides the ability to digitally sign email.  A digital signature is a way to prove that an email is from who it purports to be from, and that email has not been altered since it was signed.  In technical terms, digital signatures provide authentication (proof that email came from who it says it does), nonrepudiation (prevents the sender from disavowing the email), and data integrity (the recipient is assured that the content of the email has not been altered since that email was signed).  It is important to note that a digital signature does not provide confidentiality, that is to say anyone who intercepts a signed email in transit will still be able to read that email.

Furthermore, digital signatures and message encryption are not mutually exclusive.  A single email message can be both signed and encrypted to provide the benefits of both services.  It is even possible to “triple wrap” a single email message.  This process includes signing the message, then encrypting the message, and finally signing the message again.  When a message is signed and encrypted using OWA that message is automatically triple wrapped.  Outlook does not currently provide the ability to triple wrap a message, but Outlook can read triple wrapped messages.

How do I deploy S/MIME for Exchange Online?

In this article I'll walk through the process of setting up S/MIME for my Exchange Online account.  It is important to note that my mailbox is 100% cloud only. I do not have a hybrid Exchange org setup, nor do I have AD FS or DirSync configured.

The first thing we’re going to need is a certificate. There are a lot of vendors who will sell you a certificate, but I used https://www.startssl.com/ because they will give you one for free.

Once you have installed a certificate on your workstation, you are ready to begin the S/MIME setup for your Exchange Online account. The first step is to create a .sst file.

$sst = Get-Content .sst -Encoding Byte

Set-SmimeConfig -SMIMECertificateIssuingCA $sst

Get-Mailbox | FT *user*

After the certificate is published to the GAL, you’ll be able to send signed S/MIME messages to other users. [A certificate needs to be in the GAL to be able to encrypt messages for other users?] In the screenshot below I sent a signed message to a test account on my tenant.

It is important to note that to send S/MIME encrypted messages between organizations, including different Office 365 tenants, the sender needs to have a contact object for the recipient that includes the recipient’s trusted certificate. Remember, from Part 1 of this series, the way public key encryption works is that the encryption is done with one key (the public key), and the decryption is done with a separate key (the private key). For someone to send you an S/MIME encrypted message, they need access to your public key. For you to read that message, you need to have your own associated private key.

Below is a screen shot of a message sent from a test account to my account using S/MIME encryption. Notice the lock icon showing the message was encrypted. That test account does not have a certificate configured, so I am unable to send encrypted messages to it (though I can send signed messages to it as shown above.)

The setup for S/MIME certificates, in a hybrid Exchange organization, is going to require an on-premises certificate authority. I’m not going to cover setting that up in this article, but once the on-premises CA is up and functional, the steps to publish the S/MIME certificates are much the same.

That’s all I have for S/MIME configuration. In the next, and final, article in this series we’ll review each of the encryption types available in Exchange Online and in which situations it is best to use them.