How to Configure S/MIME in Office 365

S/MIME in Office 365

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and digital signingof MIME data. Configuring S/MIME in Office 365 is a slightly different procedure than configuring S/MIME on-premises. This blog is for people who want to move from on-premises to Exchange Online and want to continue to use S/MIME. This article will also apply to any Office 365 customers who want to use S/MIME for sending digitally signed and encrypted mails. Configuring S/MIME will allow users to encrypt and/or digitally sign an email. S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity, non-repudiation of origin (using digital signatures), privacy, and data security (using encryption). Further, Office 365 also provides the capability for end users to compose, encrypt, decrypt, read, and digitally sign emails between two users in an organization using Outlook, Outlook Web App (OWA) or Exchange ActiveSync (EAS) clients. Below, we will take you through the configuration steps that you will need to follow to configure S/MIME for Exchange Online Only (Scenario 1), and for Exchange Hybrid(Scenario 2).

Scenario 1: Exchange Online

In this scenario, all the users are hosted on cloud and there is no on-premises Exchange organization.

Requirements

1. .SST File (Serialized store): The SST file contains all the root and intermediate certificates that are used when validating the S/MIME message in Office 365. The .SST file is created from certificate store explained below.
2. End user’s certificate for signing and encrypting the message issued from Certificate Authorities(CA) either Windows based CA or Third party CA.

Configuration

Remember that in Exchange Online, only the SST will be used for S/MIME certificate validation. 1. Create a .SST file for the Trusted Root CA / Intermediate CA of the certificate issued to the users: You can use either Certificate MMC or PowerShellcmdlets to export SST file. I am using Certificate console to export the .SST here: Open certmgr.msc snap-in, expand Trusted Root Certificate Authorities > Certificates > select the CA Certificates which issued the certificates to end users for S/MIME and right click > All Tasks > Export…

Note: There may be some Intermediate CA’s. You can move them to Trust Root CA folder and select them (including the Trusted CA certificates) and export it all in one .SST file.

2. Select Microsoft Serialized Certificate Store(.SST) > Click Next and save the SST file: 3. Upload .SST to office 365 server: Update the SST on office 365 exchange server by executing the following commands using remote PowerShell.

$sst = Get-Content <sst file copied from the box>.sst -Encoding Byte

(Example: $sst = Get-Content TenantRoot.sst -Encoding Byte)

Set-SmimeConfig -SMIMECertificateIssuingCA $sst

4. Publish user’s certificate to the Exchange Online GAL (Global Address List) using Outlook. If not published, users will not be able to exchange S/MIME encrypted messages.

Note: To publish the certificate, the user must first have the certificate installed on their local machine.

• On the File menu in Outlook 2013, click Options.
• On the Outlook Options window, click Trust Center, click Trust Center Settings..., and then click Email Security.
• In the Trust Center window, click Settings… (Here, you need to choose certificate issued by the CA you are going to use for S/MIME).
• In the Change Security Settings window, type the Security Settings Name (you can name it anything) and choose Signing and Encryption certificate. Select the appropriate certificate assigned in previous steps, leave the Algorithm default and click OK.

• Once the information is selected, you will notice the Default Setting is populated with Security Settings Name. Now you can click the Publish to GAL button. To publish the certificate to the GAL, click OK.

5. To confirm the certificate is published in AAD (Azure Active Directory), connect to Exchange Online using remote PowerShelland run following command. Check to make sure that the UserSMimeCertificate attribute is populated with the certificate information. If not, return to step 4.

Get-Mailbox <user> | FL or FT *user*

6. Once you confirm the end user has the certificate on their machine under certificates > personal store and also published in AAD, the users can use Outlook, OWA, or EASto send and receive S/MIME messages.

Note: Make sure you check S/MIME Supported Clients section below before exchanging S/MIME messages.

Scenario 2: Exchange Hybrid

In Exchange Hybrid topology, some mailboxes are homed on-premises and some mailboxes are homed online, and users share the same e-mail address space.

Requirements:

1. Public Key Infrastructure (PKI). You can use Active Directory Certificate Services to issue certificates to the end users.
2. SST File (Microsoft serialized certificate store). Tenant admins will have to configure their tenant in O365 with signing certificates issuing CA & Intermediate certs information. They will have to produce a SST file, which is a collection of certificates, and then later import it into O365 to validate S/MIME.
3. DirSync. You will need version 6593.0012 or higher of the DirSync tool. DirSync is used to synchronize the Active Directory user object to the Azure AD, so that cloud users can also see the certificate information of recipients when performing S/MIME (encrypt) operation.

You can verify the DirSync version following these steps:

• Open Control Panel.
• Click Programs.
• Click Programs and Features.
• Click Windows Azure Active Directory Sync tool.
• Check the version as the screenshot below:

Configuration:

1. Public Key Infrastructure (PKI) The users in your organization must have certificates issued for digitally signing and encryption purposes. You can either install Certificate Authority On-premises to issue certificates to the end users or have third party certificates issued to them. There are two attributes in a user object where certificate information stored: 1) UserCertificate and 2) UserSMimeCertificate. UserCertificateis populated automatically in on-premises deployment with a Windows root CA. This is populated at the time the user enrolls for a user certificate. This could be done manually for each user, or an administrator can set a GPO to automatically enroll all users. Certificates are stored in the userSMimeCertificate attribute when an Outlook client publishes a certificate to GAL. Outlook 2010 and above will populate both attributes with the same certificate http://support.microsoft.com/kb/2840546. But Outlook 2007 and below will not. http://support.microsoft.com/kb/822504 2.When setting a SST file, remember in Exchange online, only the SST will be used for S/MIME certificate validation. Create a SST file for the Trusted Root CA / Intermediate CA of the certificate issued to the users: You can use either Certificate MMC or PowerShellcmdlets to export the SST file. I am using the Certificate console to export the SST here: Open certmgr.msc snap-in, Expand Trusted Root Certificate Authorities > Certificates > select the CA Certificates which issued the certificates to end users for S/MIME, and right click > All Tasks > Export…

Note: There may be some Intermediate CA. If there are, move them to Trust Root CA folder and select them, including the Trusted CA certificates, and export them all in one .SST file.

Select SST > Click Next and save the SST file: Upload .SST to Office 365 server: Update the SST on Office 365 Exchange server by running the commands below using remote PowerShell:

$sst = Get-Content <sst file copied from the box>.sst -Encoding Byte

(Example: $sst = Get-Content TenantRoot.sst -Encoding Byte)

Set-SmimeConfig -SMIMECertificateIssuingCA $sst

3.If end users are issued third party certificates, they can publish the certificate information to the GAL by following these steps:

Note: To publish the certificate, the users must first have the certificate installed on their local machine.

• On the File menu in Outlook 2013, click Options.
• On the Outlook Options window, click Trust Center, click Trust Center Settings..., then Email Security.
• On Trust Center window, click Settings… (Here, you need to choose which certificate you are going to use for S/MIME).
• In the Change Security Settings window, type the Security Settings Name (you can name it anything), Choose Signing and Encryption certificate, select the appropriate certificate assigned in previous steps, leave the Algorithm default, and click OK.

• Once the information is selected, you will notice the Default Setting is populated with Security Settings Name. Now you can click the Publish to GAL button. To publish the certificate to the GAL, click OK.

• To confirm that the certificate is published in AAD (Azure Active Directory), connect to Exchange Online using remote PowerShell and run the following command. Check to see if the UserSMimeCertificate attribute is populated with the certificate information. If not, return to step 4.

Get-Mailbox <user> | FL or FT *user*

If Windows Certificate Authority is used, then the CA will publish the certificate information into the user object. In both cases, you need to use DirSync to replicate the on-premises Active Directory information to the cloud so that cloud users can exchange S/MIME messages. 4. After the above steps, your end users can use Outlook, OWA, or EASto send and receive S/MIME messages.

Note: Make sure you check S/MIME Supported Clients section below before exchanging S/MIME messages.

S/MIME Supported Clients

All the client machines should have the PKI issued user certificate installed under (whichever is applicable) Certificates - Current User - Personal - Certificates ­­­­- Trusted Root Certification Authorities - Certificates - Intermediate Certification Authorities - Certificates If the PKI issued certificate is not available, users will not be able to send digitally signed messages or decrypt the S/MIME encrypted messages. Outlook Web App:

• OWA for S/MIME - Supported only on Windows Vista or greater with browser IE9 and above. Not supported on other browsers or on MOWA (Mobile for Outlook Web Access).
• Third party certificates aren’t supported for OWA S/MIME; only Windows Certificate Authority issued certificates are supported.
• To use Outlook Web Access with the S/MIME control, the client system on which the user is running Internet Explorer must have Outlook Web Access with the S/MIME control installed. S/MIME functionality in Outlook Web Access cannot be used on a system that does not have Outlook Web Access with the S/MIME control installed.

SMIME control in OWA requires .Net 4.5. All users accessing their mailboxes using OWA should install this on their machine. .Net 4.5 can be installed from Microsoft Downloads page.

Outlook

• Outlook 2010 and above are supported.

EAS Clients

• Windows phone 8.1 is a supported EAS client for S/MIME. To learn how to install a certificate on Windows Phone 8.1, see Installing digital certificates.
• For any other devices, you need to check with the device vendors.

FAQ

1. Do both of these user object attributes (UserSMIMECertificate and UserCertificate) need to be populated with certificate information? Either, or both. 2. Do we support S/MIME for Cross Org/Cross Tenant? Cross Org/Cross Tenant S/MIME is not supported in Outlook Web App and EAS (Exchange Active Sync) With Outlook, it is a supported scenario. A tenant administrator may create contact objects with associated S/MIME public certificates, for users external to their organization that’d synchronize to Office 365 directory. Also, when we are looking for certificates for recipients, we check in all the Address Books.  This includes the Global Address Book (GAL), the Contact Address Book (contacts folder), as well as any other address books (which includes LDAP address books). As long as we can find an entry in an address book for the recipient and it contains a certificate that we trust, then we can use it and send S/MIME mail.

Note: Certificate in Exchange online GAL (for contact) is supported, however OWA client doesn’t support this scenario at present..

3. When I select Encrypt mail and click on Send button in Outlook/OWA, I get error saying that the sender does not have a certificate. Why? In the example below, David is a sender. He was trying to send an S/MIME encrypted email message to a couple of recipients who have certificates published in the Active Directory, but David himself doesn’t have a certificate. When he clicks Send, he gets the below error. So, when sending an S/MIME encrypted message, we always check the sender’s certificate so that the message is encrypted such that the sender himself can see it from his Outlook ‘sent items’ folder.

References

Understanding S/MIME Special thanks to Frank Brown, Mike Brown, Timothy Heeney, Tariq Sharif, Vikas Malhotra and Eduardo Melo for reviewing this post! Suresh Kumar