Certificate-based authentication with Office 365

Secure Mail supports certificate-based authentication (also known as client-based authentication) with Office 365. Secure Mail users with iOS and Android devices can take advantage of certificate-based authentication when connecting to Office 365. When they sign on to Secure Mail, users authenticate by using a client certificate, instead of typing their credentials. This article discusses how to configure certificate-based authentication for Office 365.

Support for certificate-based authentication in Secure Mail exists for on-premises Exchange configurations. If you had already set up certificate-based authentication in Endpoint Management, you now configure Exchange Online, Azure Active Directory, and Active Directory Federation Services (ADFS) on Windows Server. Then, users with Secure Mail versions 10 and later can take advantage of certificate-based authentication to connect to their Office 365 accounts.

If you have not configured certificate-based authentication, you first enable the feature in the Endpoint Management console. For details, see Client certificate or certificate plus domain authentication. Then, you enable certificate-based authentication for Exchange online, Azure (AD), and ADFS on Windows Server.

The procedures in this article assume that you have enabled certificate-based authentication in Endpoint Management.

The following figure shows how the components involved in certificate-based authentication integrate.

Image of certificate-based authentication components


  • A copy of the certificate (X.509) generated from the Certificate Authority (CA) when you configured PKI Entities in the Endpoint Management console.
  • The CA must have a certificate revocation list (CRL) that can be referenced via a URL.
  • In the certificate Subject Alternative Name field, include the user email address in the RFC822 Name or the Principal Name value. For example, see the following figure.

Image of the Certificate Subject Alternative Name field

The following steps show how you configure certificate-based authentication for Exchange Online, Azure AD, and ADFS on Windows Server.

This article summarizes configuration guidance from Microsoft. If you have trouble with the steps for configuring the Microsoft components, we recommend that you see the Microsoft documentation for more information.

To enable Exchange Online

Microsoft Exchange Online uses modern authentication features of the Office 365 tenant. These features enable authentication features like multifactor authentication (MFA) by using smart cards, certificate-based authentication, and third-party SAML identity providers. By default, modern authentication isn’t enabled in Exchange Online. To enable modern authentication, do the following.

  1. Connect to Exchange Online PowerShell. For details, see the Microsoft documentation.
  2. Run the following command.

    Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

  3. To verify that the change was successful, run the following command.

    Get-OrganizationConfig | Format-Table -Auto Name,OAuth*

To configure Azure AD

Exchange Online sends a prompt=login command to Azure AD in a request. By default, Azure AD translates this command in the request to ADFS as wauth=usernamepassworduri.

By default, Azure AD prompts ADFS to do U/P authentication. Azure AD also sends the command 'wfresh=0' which prompts Azure ADD to ignore the single sign-on (SSO) state and to do a fresh authentication.

  1. Change the default Azure AD Set PromptLoginBehavior behavior.

    • Connect to Office 365 PowerShell. For details, see the Microsoft documentation.
    • Run the following command in Office 365 PowerShell.


      The domain is the same as the mail server domain.

    Set-MSOLDomainFederationSettings -domainname <domain> -PromptLoginBehavior Disabled

  2. Configure the certificate authorities in Azure AD. Upload the public portion of the root certificate, as discussed in the preceding list of prerequisites.

    • Connect to Azure AD PowerShell. For details, see the Microsoft documentation.
    • Run the following set of commands in Azure AD PowerShell. The .cer file is available locally on the machine.

    $cert=Get-Content -Encoding byte "[LOCATION OF THE CER FILE]" $new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation $new_ca.AuthorityType=0 $new_ca.TrustedCertificate=$cert New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca

  3. Configure revocation in Azure AD.

    To revoke a client certificate, Azure AD fetches and caches the certificate revocation list (CRL) from the URLs, which were uploaded as part of the CA information. The last publish timestamp (Effective Dateproperty) in the CRL is used to ensure that the CRL is still valid. The CRL is periodically referenced to revoke access to certificates that are a part of the list. To ensure that the revocation persists, you must set the Effective Date of the CRL to a date after the value set by StsRefreshTokenValidFrom.

    Ensure also that the certificate in question is in the CRL. The following steps outline the process for updating and invalidating the authorization token by setting the StsRefreshTokenValidFrom field.

    • Connect to the MSOL service. For details, see the Microsoft documentation.
    • Retrieve the current StsRefreshTokensValidFrom value for a valid user by running the following commands.

      $user = Get-MsolUser -UserPrincipalName test@yourdomain.com $user.StsRefreshTokensValidFrom

    • Configure a new StsRefreshTokensValidFrom value for the user equal to the current timestamp by running the following command.

      Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/15/2017")

The date you set must be in the future. If the date is not in the future, the StsRefreshTokensValidFrom property is not set. If the date is in the future, StsRefreshTokensValidFrom is set to the current time (not the date indicated by the Set-MsolUser command).

To configure ADFS

You complete two main steps to configure ADFS.

  • Enable certificates as an authentication method.
  • Configure claims in an ADFS token.
  1. Enable certificates as an authentication method.

    • Open the ADFS management console and then navigate to Service > Authentication Methods > Edit Primary Authentication Methods.

      Image of the Authentication Methods screen

    • Under Extranet, select the Certificate Authentication check box.

    • Under Intranet, optionally select the Certificate Authentication check box.

    Most of your devices that use certificate authentication are likely to come only from the extranet. For that reason, the Intranet selection is optional.

    Image of the Extranet options

  2. Configure claims in the ADFS token.

    Azure AD sends the issuer and serial number to ADFS so that ADFS can revoke or deny authentication in different access scenarios. If a device is lost or stolen, for example, the administrator can update the CRL. Then, Azure AD revokes access by using certificate authentication. To configure claims, do the following.

    • Navigate to Service > Claim Descriptions > Add Claim Description.

      Image of the Add Claim Description screen

    • In the Active Directory Claims Provider trust, add the following two rules. These rules indicate to ADFS to allow an Active Directory user to pass through when authenticating.

      Serial Number of the Client Certificate - http://schemas.microsoft.com/ws/2008/06/identity/claims/<serialnumber>

      Issuer of the client certificate - http://schemas.microsoft.com/2012/12/certificatecontext/field/<issuer>

The following figures are examples of the completed fields.

Image of the Serial Number Properties

Image of the Issuer Properties

Certificate-based authentication with Office 365