Exchange 2010 Federation (well, half-way there for now)

Federation is certainly a welcome and interesting feature in Exchange 2010. Being able to share calendar information with other organizations will greatly improve collaboration efforts, especially with shops leveraging both on-premise and Exchange Online services for their information workers. There is a modest amount of information on this feature and how to set it up in the form of TechNet articles, blogs and even a webcast. I read through the available material and webcast set out to try and demo this feature for this blog but ran into a roadblock.
The roadblock I’m referring to has to do with certificates. After reading through the TechNet article you’ll find a link to the CAs you can use for Federation.

CA Certificate Friendly Name	Thumbprint
Comodo	NA
Digicert Global Root CA	083B:E056:9042:46B1:A175:6AC9:5991:C74A
Digicert High Assurance EV Root CA	91 8d a5 e4 99 c1 5f 7c 62 75 b1 24 fe de 53 35 7c 34 bd 36
Entrust.net CA (2048)	801D 62D0 7B44 9D5C 5C03 5C98 EA61 FA44 3C2A 58FE
Entrust Secure Server CA	99A6 9BE6 1AFE 886B 4D2B 8200 7CB8 54FC 317E 1539
Go Daddy Secure Certification Authority	‎7c46 56c3 061f 7f4c 0d67 b319 a855 f60e bc11 fc44

After going through the steps in the articles to get this set up I was hit with this error in the New Federation Trust wizard.

“InvalidManagementCertificate: Certificate not valid for this operation”

I was baffled by this one. Everything checked out with my certificate according to the information below. What was wrong?
Certificate Requirements for Federation
To establish a federation trust, you must procure and install an X.509 certificate on the Exchange 2010 server used to create the trust. The certificate is used only to sign and encrypt delegation tokens. The certificate must meet the following requirements:

• Trusted certification authority The certificate must be signed by a trusted certification authority (CA). For a list of trusted CAs, see Trusted Root Certification Authorities for Federation Trusts.
• Subject key identifierThe certificate must have a subject key identifier field. Most X.509 certificates issued by commercial certification authorities have a subject key identifier.
• CryptoAPI cryptographic service provider (CSP) The certificate must use a CryptoAPI CSP. Certificates that use Cryptography Next Generation (CNG) providers aren’t supported for federation. If you use Exchange to create a certificate request, a CryptoAPI provider is used. For more information, see Cryptography.
• RSA signature algorithmThe certificate must use RSA as the signature algorithm.
• Exportable private key The private key used to generate the certificate must be exportable. You can specify that the private key of a certificate be exportable when you create the certificate request using the New Certificate wizard in the EMC, or the New-ExchangeCertificatecmdlet in the Shell.
• Current certificateThe certificate must be current. You can’t use an expired or revoked certificate to create a federation trust.
• Enhanced key usage The certificate must include the enhanced key usage (EKU) type Client Authentication (1.3.6.1.5.5.7.3.2). This usage type is intended for the purpose of proving your identity to a remote computer. If you use Exchange tools to generate the certificate request, this usage type is included by default.

I tried a couple other things thinking it was something wrong with my Exchange setup, firewall, etc. Finally I started searching for similar issues on blogs and forums. There was nothing so I decided to post on the Exchange 2010 forum hoping someone has seen this. I did get a rather quick response and after a couple of exchanges I was presented with this list of CAs that can be used for federation posted on the MSDN site.

CA Certificate Friendly Name	Issued To
Entrust	Entrust.net Secure Server Certification Authority
Go Daddy	Go Daddy Class 2 Certification Authority
Network Solutions	Network Solutions Certification Authority
VeriSign	Class 3 Public Primary Certification Authority
VeriSign	VeriSign Trust Network
VeriSign	VeriSign Class 3 Public Primary Certification Authority – G5

As you can see, quite different. I decided to take a chance and purchased one of the certs from a CA on the MSDN list. This worked! Although I had to go to the time and expense of getting another cert I was at least able to establish federation with the MFG (Microsoft Federation Gateway). This is frustrating to find out this was the problem all along due to some contradictory information posted by Microsoft. My hope, however, is that more CAs will be added to the working list so customers like me don’t have to purchase new ones just to prove a point.
So now, you’ve been warned! 🙂