GALsync and Federation using Exchange 2010 – Part III – Provide a public certificate

5 Jul


Information workers frequently need to collaborate with external recipients such as vendors, partners, and customers, and share their availability (free/busy) information, calendar, or contacts.

In this third part I will describe the first required configuration tasks and the experiences we made with creating the federation trust using a current Exchange Comodo UC certificate.

Provide a public certificate

The certificate does not require subject alternative name because it will not be used for authentication.  Because Exchange distributes the certificate to other Exchange 2010 servers in the organization, only one certificate is required for the Federation Trust.

We already had running a COMODO UC certificate which we wanted to use for the Federation trust. So we tried to make the first step with

Get-ExchangeCertificate | where {$_.IsSelfSigned -eq $false} | New-FederationTrust -Name “NETsec Federation Trust”

But we got this error (on a German server):

Fehler beim Bereitstellen von Exchange für den Partner-STS. Detaillierte Informationen: “Fehler beim Zugriff auf Window s Live. Detailinformationen: “Fehler bei der Anforderung mit HTTP-Status 403: Forbidden.”.”. + CategoryInfo : NotSpecified: (:) [New-FederationTrust], ProvisioningFederatedExchangeException + FullyQualifiedErrorId : 6501C8A0,Microsoft.Exchange.Management.SystemConfigurationTasks.NewLiveFederationTrust

This task using EMC had the same error as result.

I am not the expert in certificates – so I followed these steps:

Googling I found the blog from Henrik Walther (MVP) reporting that this issue might be caused by the certificate (Getting an error when setting up a federation trust in Exchange 2010? … n-trust-in-exchange-2010/).

I checked the details of certificate requirements and asked COMODO for further advise.

The certificate must be signed by a trusted certification authority (CA).
Microsoft accepts only a few Certificate Authorities (See: Trusted Root Certification Authorities for Federation Trusts

My verification steps:

1. The certificate must have a Subject key Identifier (SKI) field. Most X.509 certificates issued by commercial certification authorities have a SKI.

I found this in the certificate:



 2. The certificate must use a CryptoAPI cryptography service provider (CSP). Certificates that use CryptoAPI Next Generation (CNG) providers are not supported for Federation. If you use Exchange to create a new certificate request, a CryptoAPI provider is used.

I didn’t know how to evaluate this and asked COMODO for advise.

3. The certificate must use RSA as the signature algorithm.

I found this in the certificate:



4. The private key used to generate the certificate must be exportable.

We genereated the request with the parameter for privatekey, but I did not know how to evaluate this and asked COMODO for advise.

5. The certificate must be current.

I found this in the certificate:


5. The certificate must include the Enhanced Key Usage type Client Authentication ( This usage type is inteded for the purpose of proving your identity to a remote computer. 

I found this in the certificate:


So after all I sent a support call to COMODO and to different newsgroups asking for advise.

But after 1 hour I tried the command again – and it worked without having modified something! So be patient and take time for a coffee . . .

What I did a second time?

Get-ExchangeCertificate | where {$_.IsSelfSigned -eq $false} | New-FederationTrust -Name “NETsec Federation Trust”

with this result: 

I only wanted to validate in this last step that the certificate we are using is accepted. But in the same time we created a Federation trust. For demonstration purposes we delete this trust with:

Remove-FederationTrust “NETsec Federation Trust

The next step you have to validate is:

Publish your Exchange to Internet

The domain used for establishing a federation trust should be resolvable from the Internet.
This requires that the domain be registered with a domain registrar, and the DNS zone for the domain be hosted on a DNS server accessible from the Internet. If the organization receives Internet e-mail for the domain, these requirements are already met.


Federated sharing features require

1. outbound access (port 443 for TCP)  of all CAS Servers to the Internet by using HTTPS

2. inbound access (port 443 for TCP)  to one of the CAS Servers in your organization   


The future:
Certificates for Federation services with Exchange 2010 SP1: you might use a Self signed certificate created by a Windows CA in your own organization. 

Further information

Public Certificates for Exchange 2010 Federation

Getting an error when setting up a federation trust in Exchange 2010? 

Free/Busy Federation Troubleshooting

. . . Let’s go on with this in the next blog article . . .


Leave a Reply

Your email address will not be published. Required fields are marked *