The Windows OS supports 7 different types of entries in the Subject Alternate Names extension of certificates (and in the altSecurityIdentities attribute in AD).
The Exchange Powershell cmdlets on of the other hand only support the X500 format (X500DistinguishedName).
The net result of this is that a separate certificate that has the Subject Name in the X500 format may be required if you want to use it with Exchange 2010.
Error message from running Enable-Mailbox TestUser (you’ll see a similar error with the Exchange Get-User cmdlet):
Cannot calculate value of property “CertificateSubject”: “The format you provided, “X509:<RFC822>email@example.com“;, is unknown. The correct format is “X509:<I>CN=Issuer<S>CN=Subject”. Note that the issuer part or subject part, which can’t be empty, must contain an X500 distinguished name.”.
In the error message above, the ‘must contain an X500 distinguished name’ error message is only referring to the requirements that the cmdlet has (which are more stricter than what the OS has).
Ultimately, any application defines what it needs for its own purposes (as long as the underlying OS supports it).
In this case the Exchange Powershell cmdlets have only implemented a subset of the possible X509 formats that the OS supports.
Exchange 2010 Help: Get-User Powershell cmdlet
— XCN_OID_SUBJECT_ALT_NAME2 (126.96.36.199)
AltNames ::= SEQUENCE –#public– OF GeneralName
GeneralNames ::= AltNames
GeneralName ::= CHOICE
otherName  IMPLICIT OtherName, [UPN format uses the rfc822 format]
rfc822Name  IMPLICIT IA5STRING,
dNSName  IMPLICIT IA5STRING,
x400Address  IMPLICIT SeqOfAny, — Not supported
directoryName  EXPLICIT ANY, [This is the X500 format]
ediPartyName  IMPLICIT SeqOfAny,
uniformResourceLocator  IMPLICIT IA5STRING,
iPAddress  IMPLICIT OCTETSTRING,
registeredID  IMPLICIT EncodedObjectID — Not supported
OtherName ::= SEQUENCE
value  EXPLICIT NOCOPYANY
Algorithm used to locate user accounts:
If there is no UPN in the certificate and no user object is located in the previous steps, the client account is looked up based on the SAN/822name, and the KDC constructs the “X509:<RFC822>” string to look up.
When the subjectAltName extension contains an Internet mail address, the address MUST be included as an rfc822Name. The format of an rfc822Name is an “addr-spec” as defined in RFC 822 [RFC 822].
An addr-spec has the form local-part@domain. Note that an addr-spec has no phrase (such as a common name) before it, has no comment (text surrounded in parentheses) after it, and is not surrounded by “<” and “>”.
Note that while upper and lower case letters are allowed in an RFC 822 addr-spec, no significance is attached to the case.
6 Appendix A: Product Behavior