Exchange Powershell get-user cmdlet only recognizes certificates using the X500 format

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>testuser@contoso.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
http://technet.microsoft.com/en-us/library/aa996896.aspx

IX509ExtensionAlternativeNames Interface
http://msdn.microsoft.com/en-us/library/aa378081(VS.85).aspx

----------------------------------------------------------------------

-- AlternativeNames

-- XCN_OID_SUBJECT_ALT_NAME2 (2.5.29.17)

----------------------------------------------------------------------

AltNames ::= SEQUENCE --#public-- OF GeneralName

GeneralNames ::= AltNames

GeneralName ::= CHOICE

{

   otherName [0] IMPLICIT OtherName, [UPN format uses the rfc822 format]

   rfc822Name [1] IMPLICIT IA5STRING,

   dNSName [2] IMPLICIT IA5STRING,

   x400Address [3] IMPLICIT SeqOfAny, -- Not supported

   directoryName [4] EXPLICIT ANY, [This is the X500 format]

   ediPartyName [5] IMPLICIT SeqOfAny,

   uniformResourceLocator [6] IMPLICIT IA5STRING,

   iPAddress [7] IMPLICIT OCTETSTRING,

   registeredID [8] IMPLICIT EncodedObjectID -- Not supported

}

OtherName ::= SEQUENCE

{

   type EncodedObjectID,

   value [0] EXPLICIT NOCOPYANY

}

Algorithm used to locate user accounts:

http://msdn.microsoft.com/en-us/library/cc246114(PROT.10).aspx

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.

 

http://www.ietf.org/rfc/rfc2459.txt

   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
http://msdn.microsoft.com/en-us/library/cc240443(PROT.13).aspx