Share via

Certificate Requirements for Federation Servers

  • Article

Applies To: Windows Server 2008

In any Active Directory Federation Services (AD FS) design, various certificates must be used to secure communication and facilitate user authentications that are made between Internet clients and federation servers. Each federation server is required to have a server authentication certificate and a token-signing certificate before it can participate in AD FS communications. The trust policy requires an associated certificate, known as a verification certificate, which is the public key portion of the token-signing certificate. The following table describes each of these certificate types.

Certificate type Description

Token-signing certificate

A token-signing certificate is an X509 certificate. Its associated public/private key pair is used by federation servers to digitally sign all security tokens that they produce.

Verification certificate

A verification certificate represents the public-key portion of the token-signing certificate. It is stored in the trust policy and used by the federation server in one organization to verify that incoming security tokens have been issued by valid federation servers in this organization's farm and in other organizations.

Server authentication certificate

Federation servers use a server authentication certificate to secure Web services traffic for communication with Web clients or with federation server proxies.

Note

Client authentication certificates are not necessary for federation servers.

You can request and install server authentication certificates through the Microsoft Management Console (MMC) snap-in for Internet Information Services (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).

Determining your certification authority strategy

Because the verification certificate represents the public key portion of the token-signing certificate, only the token-signing certificate and the server authentication certificate have to be issued by either a public certification authority (CA)—for example, VeriSign—or a corporate CA.

AD FS does not require that token-signing and server authentication certificates be issued by a CA. However, we recommend that you not use self-signed certificates for server authentication certificates.

Important

Use of self-signed, Secure Sockets Layer (SSL) certificates in a production environment can allow a malicious user in an account partner 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 server authentication 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 snap-in in Microsoft Management Console (MMC).

As an alternative to using the Certificates snap-in, you can also import the server authentication certificate with the IIS Manager snap-in at the time that you assign the server authentication 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 Federation Service 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 server authentication 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: Installing 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.

Token-signing certificates

Federation servers require token-signing certificates to prevent attackers from altering or counterfeiting security tokens in an attempt to gain unauthorized access to federated resources. Every token-signing certificate contains cryptographic private keys and public keys that are used to digitally sign (by means of the private key) a security token. Later, after they are received by a partner federation server, these keys validate the authenticity (by means of the public key) of the encrypted security token.

Because each security token is digitally signed by the account partner, the resource partner can verify that the security token was in fact issued by the account partner and that it was not modified. Digital signatures are verified with verification certificates. After the signature is verified, the resource federation server generates its own security token for its organization and signs the security token with its own token-signing certificate.

The Web server in the resource partner uses the public key of the token-signing certificate to verify that the security token is signed by the resource federation server. The Web server then allows the appropriate access to the client.

Digital signatures on security tokens are also used in the account partner when there is more than one federation server (for example, in a farm deployment). In this case the digital signatures verify the origin and integrity of the security tokens that are issued by other federation servers in the account partner.

Token-signing certificates must meet the following requirements to work with AD FS:

  • The token-signing certificate must include digital signature key usage. Examples of certificate types that include this key usage are server authentication certificates or code-signing certificates. Enhanced key usage (EKU) is not required for token-signing certificates.

  • The token-signing chain must be composed of only X509 certificates, and it must chain to a client-accessible, trusted root CA.

  • For a token-signing certificate to successfully sign a security token, the token-signing certificate must contain a private key.

  • The AD FS AppPool identity must have access to the token-signing certificate’s private key in the personal store of the local computer.

Note

This is taken care of by Setup. You can also use the Active Directory Federation Services snap-in to ensure this access if you subsequently change the token-signing certificate.

  • The trust policy includes the entire token-signing certificate chain in the trustpolicy.xml file. This operation takes place automatically. You do not have to configure it manually.

Note

It is a public key infrastructure (PKI) best practice to not share the private key for multiple purposes. Therefore, do not use the server authentication certificate that you installed on the federation server as the token-signing certificate.

Deployment considerations for token-signing certificates

When you deploy the first federation server in a new AD FS installation, you must obtain a token-signing certificate and install it in the local computer personal certificate store on that federation server. You can obtain a token-signing certificate by requesting one from an enterprise CA or a public CA or by creating a self-signed certificate.

Token-signing certificates are installed differently, depending on how you create the server farm. There are two server farm options that you can consider when you obtain token-signing certificates for your deployment:

  • A private key from one token-signing certificate is shared among all the federation servers in a farm.

    In a federation server farm environment, we recommend that all federation servers share (or reuse) the same token-signing certificate. You can install a single token-signing certificate from a CA on a federation server and then export the private key, as long as the issued certificate is marked as exportable.

    As shown in the following figure, the private key from a single token-signing certificate can be shared to all the federation servers in a farm. This option—compared to the following "unique token-signing certificate" option—reduces costs if you plan to obtain a token-signing certificate from a public CA.

  • There is a unique token-signing certificate for each federation server in a farm.

    When multiple, unique certificates are used throughout your farm, each server in that farm signs tokens with its own unique private key.

    As shown in the following figure, you can obtain a separate token-signing certificate for every single federation server in the farm. This option is more expensive if you plan to obtain your token-signing certificates from a public CA.

For information about installing a certificate when you use Microsoft Certificate Services as your enterprise CA, see IIS 7.0: Create a Domain Server Certificate in IIS 7.0 (https://go.microsoft.com/fwlink/?LinkId=108548).

For information about installing a certificate from a public CA, see IIS 7.0: Request an Internet Server Certificate (https://go.microsoft.com/fwlink/?LinkId=108549).

For information about installing a self-signed certificate, see IIS 7.0: Create a Self-Signed Server Certificate in IIS 7.0 (https://go.microsoft.com/fwlink/?LinkID=108271)

Verification certificates

Verification certificates verify that a security token was issued by a valid federation server and that the token was not modified. Verification certificates are the public-key portion of your own token-signing certificate as well as the certificates of other federation servers that you trust. As shown in the following figure, verification certificates are exported (from the token-signing certificate) and added to a verification certificate list in the trust policy at the time when you first assign a federation server to an existing trust policy. This process takes place automatically during the installation of the Federation Service. You do not have to add the certificate manually.

To verify that a security token was issued by a given federation server and not modified, the federation server must have a verification certificate for the federation server that issued the security token. For example, if fs.adatum.com (a federation server in the account partner) creates and signs a security token and then sends it to fs.treyresearch.net (a federation server in the resource partner), fs.treyresearch.net must see the verification certificate for fs.adatum.com in the verification certificate list that is stored in its own trust policy.

If the certificate has been issued by a CA, ensure that:

  1. The certificate revocation lists (CRLs) of the certificate are accessible to resource partners and Web agents that trust the federation server.

  2. The root CA certificate is trusted by the resource partners and Web agents that trust the federation server.

Server authentication certificates

Federation servers require the use of server authentication certificates so that clients can establish the server's identity, because the federation server presents the client with a server authentication certificate that discloses its source. In this way, a client can verify that the data that is transmitted is usable only by the organization that is identified by the certificate.

Server authentication certificates must meet the following requirements to work with AD FS:

  • The server authentication certificate must include the server authentication EKU extension.

  • The CRLs must be accessible for all the certificates in the chain from the server authentication certificate to the root CA certificate. The root CA must also be trusted by any federation server proxies and Web agents that trust this federation server.

  • The subject name that is used in the server authentication certificate must match the Domain Name System (DNS) name of the Federation Service endpoint URL in the trust policy.

Deployment considerations for server authentication certificates

Configure server authentication certificates so that all federation servers use the same certificate. If you are deploying either of the two Federated Web SSO designs, we recommend that your server authentication certificate be issued by a public CA. You can request and install these certificates through the IIS Manager snap-in.

You can use self-signed, server authentication certificates successfully on federation servers in a test lab environment. However, for a production environment, we recommend that you obtain server authentication certificates from a public CA. The following are reasons why you should not use self-signed, server authentication certificates for a live deployment:

  • A self-signed, SSL certificate must be added to the trusted root store on each of the federation servers in the resource partner organization. While this alone does not enable an attacker to compromise a resource federation server, trusting self-signed certificates does increase the attack surface of a computer, and it can lead to security vulnerabilities if the certificate signer is not trustworthy.

  • It creates a bad user experience. Clients will receive Security Alert prompts when they try to access federated resources that display the following message: "The security certificate was issued by a company you have not chosen to trust." This is expected behavior, because the self-signed certificate is not trusted.

Note

If necessary, you can work around this condition by using Group Policy to manually push down the self-signed certificate to the trusted root store on each client computer that will attempt to access an AD FS-enabled site.

  • CAs provide additional certificate-based features, such as private key archive, renewal, and revocation, that are not provided by self-signed certificates.

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. The type of CRL determines what ports are used.