Share via

Certificate Requirements for Federation Servers

  • Article

Applies To: Active Directory Federation Services (AD FS) 2.0

In any Active Directory Federation Services (AD FS) 2.0 design, various certificates must be used to secure communication and facilitate user authentications between Internet clients and federation servers. Each federation server must have a service communication certificate and a token-signing certificate before it can participate in AD FS 2.0 communications. The following table describes the certificate types that are associated with federation server.

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

Note
The AD FS 2.0 Management snap-in refers to server authentication certificates for federation servers as service communication certificates.

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.

You can request and install a service communication certificate by requesting a service communication certificate through the Microsoft Management Console (MMC) snap-in for IIS. For more general information about using SSL certificates, see IIS 7.0: Configuring Secure Sockets Layer in IIS 7.0 (https://go.microsoft.com/fwlink/?LinkID=108544) and IIS 7.0: Configuring Server Certificates in IIS 7.0 (https://go.microsoft.com/fwlink/?LinkID=108545).

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.

Determining your CA strategy

AD FS 2.0 does not require that certificates be issued by a CA. However, the service communications certificate must be trusted by the AD FS 2.0 clients. We recommend that you not use self-signed certificates for these certificate types.

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 server (for example, the resource federation server), which can leave that server vulnerable to attack.

After you receive a token-signing certificate and service communication certificate from a CA, make sure that both certificates are imported into the personal certificate store of the local computer. You can import both certificates to the personal store with the Certificates MMC snap-in.

As an alternative to using the Certificates snap-in, you can also import the service communication certificate with the IIS Manager snap-in at the time that you assign the service communication certificate to the default Web site. For more information, see Import a Server Authentication Certificate to the Default Web Site.

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.

Depending on your security and budget requirements, carefully consider which of your certificates will be obtained by a public CA or a corporate CA. The following figure shows the recommended CA issuers for a given certificate type. This recommendation reflects a best-practice approach regarding security and cost.

Certificate revocation lists

If any certificate that you use has CRLs, the server with the configured certificate must be able to contact the server that distributes the CRLs.