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