Public Certificates for Exchange 2010 Federation

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
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

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.

image

After trying to create the Federation Trust we were seeing the following error:

image

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.

Here

Recent content I've written for you—just for you!— to enjoy while you're here.

There

Quick commentary and links to other sources you'll find interesting. I promise.

Everywhere

Some personal background, links to related projects, and other ways to connect.

Hi there. My name is Tom Pacyk and this is my small home on the web. I love the intersection of design, technology, and communication, which is a combination that led me to a career in sales and marketing roles at places like Zoom and ServiceNow. They're a bit old now, but I also had the opportunity to publish a couple of books along the way.

Portland, Oregon is home for me, my wife Beth, and our three kids, but I'm actually a Midwestern transplant—I grew up in the Chicago suburbs and went to school at Purdue and Illinois. When I find some free time I'm probably going to concerts, rooting for the Portland Timbers, or working on my Sunshine Burn Photography project.