Replacing the SSL and Service Communications certificate with ADFS 2.0
Replacing the SSL and Service Communications certificate
|*Note - Replacing the SSL and Service Communications certificates go hand-in-hand. Any time you are replacing one of these certificates, you must also replace the other. SSL certificates exist on all Federation Servers and Federation Server Proxy servers. Service Communications certificates only exist on Federation Servers.|
1. Obtain a new certificate with the following requirements
- Enhanced Key Usage is at least Server Authentication. If you are obtaining this from an internal MS Exterprise CA, the Web Server template will work fine.
- Subject or Subject Alternative Name (SAN) must contain the DNS name of your Federation Service or an appropriate Wildcard name
Example: sso.contoso.com or *.contoso.com
- You may wish to generate the certificate request and mark the private key exportable so that you can move the certificate from one server to others in the case when you have a Federation Server farm or at least one Federation Server Proxy.
- Take note of which server was used to generate the certificate request. The private key is generated and stored here. When you receive the certificate from the issuing CA, you will need to bring that file back to the server where the request was initiated so that you can create a private/public key pair.
- The issuing CA that you choose is important because your Federation Server(s), Federation Server Proxy(ies), and all clients accessing your Federation Service must be able to chain to a trusted root certification authority when validating the SSL certificate. Customers will typically use a 3rd party, public CA for the SSL and Service Communications certificate.
2. ACL the SSL and Service Communications certificate to allow Read access for the AD FS 2.0 service account
*Note - This step must be completed on all Federation Servers only.
- Click Start, Run, type MMC.exe, and press Enter
- Click File, Add/Remove Snap-in
- Double-click Certificates
- Select Computer account and click Next
- Select Local computer and click Finish
- Expand Certificates (Local Computer), expand Personal, and select Certificates
- Right-click your new SSL and Service Communications certificate, select All Tasks, and select Manage Private Keys
- Add Read access for your AD FS 2.0 service account and click OK
- Close the Certificates MMC
3. Bind the new SSL and Service Communications certificate to the web site in IIS which hosts the Federation Service
*Note - This step must be completed on all Federation Servers and Federation Server Proxy servers.
In IIS7 on Windows Server 2008 and Windows Server 2008 R2, you will select the web site, right-click, Edit Bindings, and select the SSL port, Edit, and use the drop-down menu to select the new SSL certificate:
*Note - Be careful when making your certificate selection. Your old SSL certificate and new SSL certificate will likely have the same subject name and/or friendly name, and this may make it difficult to differentiate between the two certificates.
4. Set a new Service Communications certificate in the AD FS 2.0 Management console
*Note - This step needs to be completed just one time on a single Federation Server in the farm. Proxies are not involved here, and other Federation Servers in a farm will pick up this change automatically.
- Launch AD FS 2.0 Management from the Administrative Tools menu
- Expand Service and select Certificates
- In the Actions panel, click Set Service Communications Certificate...
- You will be presented with a list of certificates that are valid for Service Communications. If you find that your new certificate is not being presented in the list, you need to go back and make sure that a. the certificate is in the local computer Personal store with private key associated, and b. the certificate has the Server Authentication EKU.
- Select your new Service Communications certificate and click OK
* Note: Be careful when making your certificate selection. Your old Service Communications certificate and new Service Communications certificate might have the same subject name and/or friendly name, and this may make it difficult to differentiate between the two certificates.
5. Test SSL functionality for internal and external users to ensure that SSL is working as expected on the Federation Servers and the Federation Server Proxy servers.
See our troubleshooting section if needed.