Setup S/MIME in Office 365 OWA

S/MIME allows to parties to trust the email that they send between each other and it’s been enabled in Office 365 but turning on Office 365 S/MIME is a little bit tricky and requires you to bring about 4 bits of documentation together. If you aren’t sure what S/MIME is or why it might be important you can read this S/MIME primer on TechNet. Lets get onto setting up S/MIME in Office 365:

S/MIME is intended to allow two people to know that they are sending and receiving mail with the right person. The flow happens a little like this: Bob wants to send an email to Mary. Bob enters Mary’s email, the email client checks that Mary has a certificate (in AD normally) and if so that we trust the certificate. Bob then signs the email with his certificate and sends the mail to Mary. When Mary opens the email her mail client checks that the cert used to sign the email matches Bob’s cert in AD and that it’s valid. If it is the message is verified. S/MIME can also be used between organizations too.


SMIME Office 365

Certificate matching is generally performed against AD when using S/MIME inside an org and it requires that the users client trusts the CA that issued the user certificate used for S/MIME, generally issued by an enterprise CA. Active Directory Certificate services has a User certificate that can be requested and can be used for this purpose. It is subsequently stored in the users AD account attributes. Before you follow these instructions for Office 365 you MUST have this setup for your organization, in fact these are the requirements, taken from this article.

Set up a Certificate Authority (CA) to issue certificates for users on-premises for S/MIME purposes.

If you have an AD CS you can just use the certificates snap in for the user you wish to request the cert for and request a USER certificate from AD CS.

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

This will happen automatically if you user the user certificate above, you can use ADSI Edit to see these attributes and you’ll find the cert in UserCertificate.

Use an appropriate version of DirSync to synchronize certificates from on-premises Active Directory to Azure Active Directory. These certificates will then get synchronized from Azure Active Directory to Exchange Online directory and will be used when encrypting a message to a recipient..

The version from AAD should work just fine.

IT  administrators need to configure their tenant in Exchange Online with certificate information, including information about the CA      who issues their signed certificates and any intermediate certificates. This information is used by OWA when validating the signature of an email and ensuring that it was signed by a trusted certificate.

This last step is where things get a little harder. The following PowerShell should help you out rather a lot.

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $UserCredential -Authentication Basic -Allow
Import-PSSession $Session

Set-SmimeConfig -OWAAllowUserChoiceOfSigningCertificate $true -OWACRLRetrievalTimeout 10000 -OWAEncryptionAlgorithms 6602:128
  • In these first two lines we connect to OWA and then enables S/MIME.
  • Now we need to export our root CA certificate to an SST file, you also need to include all intermediate certs in this file. Replace the thumbprint portion below with that of our CA cert.
Get-ChildItem –Path "Cert:\LocalMachine\CA\<cert-thumbprint>"| Export-Certificate -Type SST -FilePath C:\DemoContent\contosoca.sst
Set-SmimeConfig -SMIMECertificateIssuingCA (Get-Content filename.sst -Encoding Byte)
  • Now we need to upload the SST to OWA as above.
  • Run DirSync

Create a new mail in OWA to the other recipient. Select to encrypt and sign it. Install the control and reload OWA.


  1. Great article. Have you tried configuring this with no on-premise assets? The MS documentation isn’t exactly clear Seems like the CA could be in Azure AD, but I cannot find any guidance on how to set that up.

    • That’s kind of interesting…I can’t see any reason why you couldn’t stand up the CA in Azure, it would be almost the same as doing so on-prem.

      • percisely

        That’s what I thought was well, but apparently Microsoft disagrees.

        “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 and data published to your on-premises Active Directory Domain Service (AD DS). Your AD DS must be located on computers at a physical location that you control and not at a remote facility or cloud-based service somewhere on the internet.”

  2. Simon — we are using publicly issued s/mime certificates. I presume I should be able to just import it’s pki trust chain (root ca, and intermediate ca) into the .sst as shown above. I’ll have to test, but can’t see why that would be a problem. Additionally, is there any way to do this for a smaller O365 tenant that doesn’t use dirsync (i.e. not a windows domain)?

  3. Pingback: Your Top 5 Mobility Challenges Solved with Microsoft EMS - Enterprise Devices + Infrastructure

  4. does this work with anything other than a smartcard? When i try to select my certificate, it only finds my smartcard cert, even though I have a soft cert. Net impact, is I can only sign with a smartcard, even though I have disabled OWAOnlyUseSmartCard.

What do you think?