Update 6/6/2017: We updated this post to reflect availability for China plans.
Update 7/28/2017: Updated with links for support with Outlook for iOS and Android.
On-premises Exchange environment...
Updated Jul 01, 2019
Version 2.0
Blog Post
To be clear, should the SAN in the cert be the UPN or the email address? I'd be careful to not make assumptions that they are the same.
Alex F,
If i may clarify to save wading through documentation and IETF RFC's,
The Subject Alt Name is a complete field which is an extension of the X.509 certificate definition. Their are multiple options for the values in this field which comply with the X.509 specifications.
In this instance Microsoft are stating that when using EAS, the RFC822 value or the Principal Name value should be the email address of the specific user (ergo their client certificate) wishing to authenticate using this mechanism.
You are correct - the UPN of a user and their email address may certainly differ and in many cases most certainly will be different as the Active Directory domain a user logs into (locally defined) will definitely not match the email address containing an externally resolvable domain name (necessary for Office 365 operation with DNS queries etc,)
In the case of authentication against an Exchange based public facing system using EAS, the identifier Microsoft are using in this instance (using a digital certificate containing multiple system identifiers and unique user identifiers) is the SAN field and specific values they have chosen to use that match the rest of their architecture based on extensions (the SAN field) the X.509 specification allows.
It would not be correct to use a UPN, as it would not be within an externally resolvable domain (wouldn't necessarily match the email address) and therefore not be able to matched against a similar value in the Certificate Revocation List, published by the CA that created the client certificate in the first place, which has to be public (internet) facing for the Office 365 revocation checking routine to operate. Coupled with the fact that the SAN field has to comply in parts with the RFC822 spec which would negate some variations of the UPN format.
In other words, to place a non public identifier (UPN) on a public facing system that requires public facing mechanisms to check its validity against a public facing Office 365 would not work (or be a good idea.)
Hope that helps.
Or lookup the RFC3280 spec from the IETF for the SAN extension if you are wanting some specialist X.509 knowledge.
- Mark is correct, this requirement is intended to indicate that in the EAS case, the user's email address must be in the Principal Name value or the RFC822 Name value of the SAN field of the certificate. In some cases, the UPN is the user's email address but this is not necessarily always the case. Admittedly, this requirement is rather tricky so please do feel free to let us know if you do encounter issues configuring this item.