Setup S/MIME in Office 365 OWA

11

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.

 

Setup S/MIME in Office 365 OWA

SMIME Sign

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. tweet

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. tweet

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.. tweet

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. tweet

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 https://outlook.office365.com/powershell-liveid/ -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.

Share with your network so they know you're THE mobility expert
Setup S/MIME in Office 365 OWA10Setup S/MIME in Office 365 OWA1Setup S/MIME in Office 365 OWA12Setup S/MIME in Office 365 OWA1Setup S/MIME in Office 365 OWASetup S/MIME in Office 365 OWASetup S/MIME in Office 365 OWA0Setup S/MIME in Office 365 OWA0Setup S/MIME in Office 365 OWA

11 comments

  1. percisely - June 20, 2014 6:29 am

    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.

    Reply
    • Simon May - June 23, 2014 4:24 pm

      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.

      Reply
      • percisely - June 24, 2014 11:00 pm

        That’s what I thought was well, but apparently Microsoft disagrees. http://community.office365.com/en-us/f/158/t/245348.aspx

        “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.”

        Reply
        • Simon May - August 14, 2014 10:58 pm

          I dug into this a little more. This boils down to load balancing the service in Azure, for now PKI should probably stay on-prem as a result.

          Reply
          • Chris - August 14, 2014 11:00 pm

            That makes some sense. Thanks again for the article and followup.

          • Simon May - August 14, 2014 11:04 pm

            Sure, sorry it took me so long to come back

  2. msb2014 - July 29, 2014 2:15 pm

    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)?

    Reply
    • msb2014 - July 29, 2014 3:07 pm

      Also, how could I export multiple CA’s (and their intermediate CA’s) into that .sst file?

      Reply
      • Simon May - August 14, 2014 10:54 pm

        It’s not that easy (or that hard). Basically you’ll need to get the child items into an array first.

        Reply
    • Simon May - August 14, 2014 10:54 pm

      Yes and Yes even if it’s a smaller domain you’ve still got Azure AD.

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

What do you think?

Simon May is an Infrastructure Technology Evangelist at Microsoft concentrating on Devices and Services but with special interests in deployment and device management. Simon is a professional public speaker and the author of several books on Windows.
x
Get the exclusive inside track on enterprise mobility:

No spam. Just the latest EMM news