Certificate requirements for federation servers

Applies To: Windows Server 2003 R2

In any Active Directory Federation Services (ADFS) 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 ADFS 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.

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.

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

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). For more information, see Import a certificate (https://go.microsoft.com/fwlink/?linkid=20040).

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.

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 the use of 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 ADFS:

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

1. The ADFSAppPool 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.

Deployment considerations for token-signing certificates

When you deploy the first federation server in a new ADFS 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 token-signing certificates when you use Microsoft Certificate Services as your enterprise CA, see Submit an advanced certificate request via the Web to a Windows Server 2003 CA (https://go.microsoft.com/fwlink/?linkid=64020). For information about installing a token-signing certificate from a public CA, contact your public CA. For information about creating self-signed certificates, see Create a self-signed, code-signing certificate (https://go.microsoft.com/fwlink/?linkid=68171).

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, we require that:

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

2. The root CA certificate be 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 ADFS:

• 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 Uniform Resource Locator (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 Internet Information Services (IIS) 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 list provides reasons why you should not use self-signed server authentication certificates for a live deployment:

• A self-signed Secure Sockets Layer (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 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 ADFS-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.