Configuring S/MIME for Exchange Online Dedicated

Dedicated and ITAR-support Plans

Applies to: Office 365 Dedicated – Legacy 2013 Platform Release Topic Last Modified: 8-May-2015

Topic Last Modified: Modifications Applied: 6-May-2015 Initial Release 7-May-2015 Updated doc title, clarified opening description, updated mobile device example 9-May-2015 Added certificate renewal reminder

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a widely accepted method for sending digitally signed and encrypted messages. S/MIME assures the recipient that the message received is the original and untampered message initiated by the sender and that the message was sent by a verified sender. To do this, S/MIME provides cryptographic security services such as authentication, message integrity, and non-repudiation of origin (using digital signatures). It also helps enhance privacy and data security (using encryption) for electronic messaging. For an expanded description regarding the history and architecture of S/MIME in the context of email, see Understanding S/MIME.

S/MIME requires a certificate and publishing infrastructure that is often used in business-to-business and business-to- consumer situations. The user controls applying the cryptographic keys for each message sent. When S/MIME encryption has been applied to a message, email applications such as Outlook will search a trusted root certificate authority location to perform digital signing or verification of a signature.

As an administrator, you can enable S/MIME-based security for your organization if you have mailboxes in either Exchange 2013 SP1 or Exchange Online. The content in this topic summary can be used to configure S/MIME and to provide end user guidance.

Important

1. Not all generally available documentation produced by Microsoft to describe the features and functionality of Exchange 2013 is applicable to the dedicated and ITAR-support plan offerings of Office 365 for enterprises. Content accessible via links provided in this content are reliable sources.

2. Unless otherwise stated, all references to “dedicated plans” or “Exchange Online Dedicated” also apply to the International Traffic in Arms Regulations (ITAR-support) version of Exchange Online.

Related message encryption technologies

As message security becomes more important, administrators need to understand the principles and concepts of secure messaging. This understanding is especially important because of the growing variety of protection-related technologies, such as S/MIME, that have become available. A variety of encryption technologies work together to provide protection for messages at rest and in-transit. S/MIME can work simultaneously with the following technologies but is not dependent on them:

Transport Layer Security (TLS) encrypts the tunnel or the route between email servers in order to help prevent snooping and eavesdropping.

Secure Sockets Layer (SSL) encrypts the connection between email clients and Office 365 Dedicated servers (TLS soon will replace SSL for these communication channels within Office 365 Dedicated).

BitLocker encrypts the data on a hard drive in a datacenter. If unauthorized access to the data occurs, the data cannot be read.

Office 365 Message Encryption is a policy-based encryption service that can be configured by an administrator (not an individual user) to encrypt mail sent to anyone inside or outside of the organization. It’s an online service that’s built on Windows Azure Rights Management and does not rely on a public key infrastructure. Office 365 Message Encryption also provides additional capabilities, such as the ability to customize the mail with the brand of an organization. For more information, see Office 365 Message Encryption.

Supported scenarios

If your organization uses either Exchange 2013 SP1 or Exchange Online, you can set up S/MIME to work with any of the following end points:  Outlook 2007  Outlook 2010  Outlook 2013  Outlook Web App  Exchange ActiveSync (EAS) devices

Note:

S/MIME support is not provided for Outlook Web App when using the Firefox, Opera, or Chrome browsers.

To use S/MIME in supported versions of Outlook or ActiveSync with either Exchange 2013 SP1 or Exchange Online, the users in your organization must have certificates issued for signing and encryption purposes that are published to your on-premises Active Directory (AD). Your AD infrastructure must be implemented on computers at a physical location that you control and not at a remote facility or cloud-based service somewhere on the internet. For more information, see Active Directory Domain Services.

Configuring an S/MIME implementation

The following steps are required to configure S/MIME for use in your on-premises Exchange environment and Exchange Online Dedicated: 1. Install a Windows-based Certification Authority and set up a public key infrastructure to issue S/MIME certificates. Certificates issued by third-party certificate providers aren’t supported. For details, see Active Directory Certificate Services Overview.

2. Publish the user certificate to the UserCertificate attribute and/or the UserSMIMECertificate attribute in an on- premises Active Directory account.

3. Synchronize the user certificates from your on-premises Active Directory to the Office 365 Dedicated Active Directory. Allow the Microsoft Managed Solutions Service Provisioning Provider (MMSSPP) provisioning tool to synchronize the certificates. These certificates then will be synchronized from Office 365 Dedicated Active Directory to the Exchange Online Dedicated directory and will be used when a message is encrypted. To establish the flow of the user certificates from on-premises to Office 365 Dedicated, contact your Microsoft Service Delivery Manager to complete a Configuration Request.

4. Set up a virtual certificate collection. The information is used by Outlook Web App when validating the signature of an email message and when ensuring that the message was signed by a trusted certificate. This virtual certificate collection is set up as a Serialized Certificate Store File (.sst) filename extension. The SST file contains all the root and intermediate certificates that are used when validating an S/MIME certificate. The SST file must be created in the on-premises environment and published to the Exchange Online Dedicated environment. As an administrator, you can create this SST file by exporting the certificates from the certificate store of a trusted machine using the Export-Certificate cmdlet. Specify SST as the file type at the time of export. See the Export-Certificate reference topic for more information. Once the SST file is generated, use the Set-SmimeConfig cmdlet to save it in the virtual certificate store to the Exchange Online Dedicated environment by using the -SMIMECertificateIssuingCA parameter. An example is the following:

Set-SmimeConfig -SMIMECertificateIssuingCA (Get-Content filename.sst -Encoding Byte)

Exchange 2013 SP1 first checks for the SST file and validates the certificate. If the validation fails, it will look at the local machine certificate store to validate the certificate. This behavior is new for Exchange 2013 SP1 and different from prior versions of Exchange. In Exchange Online Dedicated, only the SST will be used for validation.

5. Set up Outlook, Outlook Web App, and EAS end points to use S/MIME. The following articles provide additional information including user interaction to send, or reply to, an S/MIME message:

Outlook 2007: Secure messages with a digital signature Outlook 2010: Get a digital ID Outlook 2013: Send an email message with an S/MIME receipt request Outlook Web App: Encrypt messages by using S/MIME in Outlook Web App

For an EAS device, a Personal Information Exchange (.pfx) file must be generated and placed within the device. See Installing digital certificates for an example of how to load the .pfx file into a Windows Phone device. For devices used within your organization, obtain and execute the procedures provided by the manufacturer of the device.

Note:

1. S/MIME encrypted messages cannot be decrypted by an eDiscovery search. 2. Each of the user, root, and intermediate certificates associated with your S/MIME implementation have an expiration date. You must take action to renew the certificates prior to their expiration. Following the renewal, you must re-execute the publishing steps for user certificates and/or generate and upload the Serialized Certificate Store File per the steps described above.