Certificate Requirements for Federation Servers

Certificate type

Description

Token-signing certificate

A token-signing certificate is an X509 certificate. Federation servers use associated public/private key pairs to digitally sign all security tokens that they produce. This includes the signing of published federation metadata and artifact resolution requests.

You can have multiple token-signing certificates configured in the AD FS 2.0 Management snap-in to allow for certificate rollover when one certificate is close to expiring. By default, all the certificates in the list are published, but only the primary token-signing certificate is used by AD FS 2.0 to actually sign tokens. All certificates that you select must have a corresponding private key.

For more information, see Token-Signing Certificates and Add a Token-Signing Certificate.

Service communication certificate

Federation servers use a server authentication certificate, also known as a service communication certificate, to secure Web services traffic for Secure Sockets Layer (SSL) communication with Web clients and with federation server proxies and for Windows Communication Foundation (WCF) Message Security. This is the same certificate that a federation server uses as the SSL certificate in Internet Information Services (IIS).

For more information, see Service Communications Certificates and Set a Service Communications Certificate.

Because the service communication certificate must be trusted by client computers, we recommend that you use a certificate that is signed by a trusted certification authority (CA). All certificates that you select must have a corresponding private key.

Token-decryption certificate

This certificate is used to decrypt tokens that are received by this federation server. AD FS 2.0 uses the SSL certificate for IIS as the default decryption certificate.

You can have multiple decryption certificates. This makes it possible for a resource federation server to be able to decrypt tokens that are issued with an older certificate after a new certificate is set as the primary decryption certificate. All certificates can be used for decryption, but only the primary token-decrypting certificate is actually published in federation metadata. All certificates that you select must have a corresponding private key.

For more information, see Add a Token-Decrypting Certificate.

Note

In AD FS 2.0 you can change the Secure Hash Algorithm (SHA) level that is used for digital signatures to either SHA-1 or SHA-256 (more secure). AD FS 2.0does not support the use of certificates with other hash methods, such as MD5 (the default hash algorithm that is used with the Makecert.exe command-line tool). As a security best practice, we recommend that you use SHA-256 (which is set by default) for all signatures. SHA-1 is recommended for use only in scenarios in which you must interoperate with a product that does not support communications using SHA-256, such as a non-Microsoft product or AD FS 1. x.

Important

Use of self-signed, SSL certificates in a production environment can allow a malicious user in an account partner organization to take control of federation servers in a resource partner organization. This security risk exists because self-signed certificates are root certificates. They must be added to the trusted root store of another federation ser
ver (for example, the resource federation server), which can leave that server vulnerable to attack.

Note

Before you install the AD FS 2.0 software on the computer that will become the federation server, make sure that both certificates are in the Local Computer personal certificate store and that the service communication certificate is assigned to the Default Web Site. For more information about the order of the tasks that are required to set up a federation server, see Checklist: Setting Up a Federation Server.