I think that one of the coolest features of Exchange 2010 is the seamless free/busy and calendar federation between organizations. In order to get federation provisioned there are a number of steps you need to take which you can find detailed on Technet.
The first step of this setup involves creating a Federation Trust to the Microsoft Federation Gateway (MFG), but in order to create this trust you need to use a public certificate issued by one of the following Certificate Authorities (the haphazard thumbprint formatting is Technet’s, not mine):
|CA certificate friendly name||Thumbprint|
|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|
I recently was involved an Exchange deployment that involved purchasing a SAN certificate from Comodo. One of the certificate authorities Comodo uses to issue SAN certs is the USERTrust Legacy Secure Server CA, which has its own certificate issued by the Entrust.net Secure Server Certification Authority. Bottom line is the certificate you get verifies up to the Entrust certificate you can see below which the Federation Gateway supports.
After trying to create the Federation Trust we were seeing the following error:
An error occurred while attempting to provision Exchange to the Partner STS. Detailed information “An error occurred accessing Windows Live. Detailed information “The request failed with HTTP status 403: Forbidden.”.”
Basically this is the MFG’s way of saying “I don’t trust this certificate.” It turns out the MFG is geared to only accept certificates issued directly from one of the certificate authorities listed above which is not something I saw in the documentation. So if the Entrust Secure Server Certification Authority had issued our webmail certificate it would have been accepted. But like in our case, if your certificate is issued from a 3rd party intermediate certificate authority it won’t be accepted even if it technically verifies up to a support rooted authority.
The good news is a call to PSS resulted in Microsoft making a change on the MFG to accept certificates issued by this particular intermediate CA going forward for everyone. So if ran into this error previously you should be able to try again with the same certificate and see the trust succeed. As of this writing I’ve requested them to also add support for the AAA Certificate Services intermediate CA Comodo also issues certificates from.