Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2013-05-15) Replacing ADFS Certificates

Posted by Jorge on 2013-05-15


You have an ADFS infrastructure up-and-running smoothly, but your certificates are about to expire. It is very important you start renewing your current certificates as needed and in time way before your current certificates expire. In addition, you may need to notify upstream application owners, upstream federation services and downstream federation services.

As mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x, in ADFS v2.x the following certificates can be used:

  1. For Security Token Service (STS) servers only:
    1. Service Communications certificate (CA issued certificate)
    2. Token Signing Certificate (CA issued certificate or ADFS managed self-signed)
    3. Token Decryption Certificate (CA issued certificate or ADFS managed self-signed)
  2. Proxy Service (PRX) servers
    1. Service Communications certificate (CA issued certificate)

[AD.1.1 – Service Communications Certificate For ADFS STS servers]

Get a certificate that fulfills the requirements as mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x and then:

  • Import CA issued certificate into the personal store of each ADFS STS server;
  • On each ADFS STS server, permission the private key (only if new) with the ADFS Service Account to have Allow:Read
  • On each ADFS STS server, bind the CA issued certificate to the default website in IIS
  • Using the ADFS MMC on any ADFS STS server (when using SQL) or the primary ADFS STS server (when using WID), configure the certificate as the “Service Communications” certificate

[AD.1.2 – Token Signing Certificate For ADFS STS servers]

First you need to determine and understand if you are using a CA issued certificate or an ADFS managed self-signed certificate.

If you are using an ADFS managed self-signed certificate, then ADFS will perform the rollover (add, promote and remove) automatically.

If you are using CA issued certificate you must replace (add, publish, remove)  the certificate manually by performing the following actions:

  • Get a certificate that fulfills the requirements as mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x
  • Import CA issued certificate into the personal store of each ADFS STS server;
  • On each ADFS STS server, permission the private key (only if new) with the ADFS Service Account to have Allow:Read
  • Using the ADFS MMC on any ADFS STS server (when using SQL) or the primary ADFS STS server (when using WID), configure the certificate as the secondary “Token Signing” certificate

After that publish/communicate [*] the new ADFS Token Signing Certificate to every upstream application and/or upstream federation service that is represented as an Relying Party Trust in your ADFS based federation service and every downstream federation service that is represented as an Relying Party Trust in your ADFS based federation service [**] . The owner of the upstream application and/or upstream federation service must add the new ADFS Token Signing Certificate of your federation service to the Claims Provider Trust or Identity Provider Trust (whatever it is called) that represents your federation service. The owner of the downstream federation service must add the new ADFS Token Signing Certificate of your federation service to the Relying Party Trust or Service Provider Trust (whatever it is called) that represents your federation service [**].

After publishing/communicating [*] the new ADFS Token Signing Certificate to every upstream application and/or upstream federation service that is represented as an Relying Party Trust in your ADFS based federation service and every downstream federation service that is represented as a Claims Provider Trust in your ADFS based federation service, promote the secondary “Token Signing” certificate to become the primary “Token Signing” certificate.

[*] Publishing/Communicating New Token Signing Certificates To Upstream Applications And/Or Upstream Federation Services

If the federation metadata is published through an URL AND it is also consumed automatically by those upstream applications and/or upstream federation services, then instruct the owners of those upstream upstream applications and/or upstream federation services to import/read the updated federation metadata through the URL, if not already done automatically. Those owners may also need to add the ADFS managed self-signed certificates, if used, to the trusted root stores as needed in addition!

If the federation metadata is NOT published through an URL OR it is NOT consumed automatically by those upstream applications and/or upstream federation services, then export the Token Signing Certificate from ADFS and send that certificate with the public key to the owners of those upstream upstream applications and/or upstream federation services and instruct them to import the new Token Signing Certificate into the Claims Provider Trust or Identity Provider Trust (whatever it is called) that represents your federation service. Those owners may also need to add the ADFS managed self-signed certificates, if used, to the trusted root stores as needed in addition!

[**] Token Signing Certificates Also Used By Downstream Federation Services

Some relying parties require that signature certificates are applied to the relying party for SAML requests, as signature certificates provide a critical security validation function and are defined in the SAML 2.0 specification.

TIP: Know which entity consumes your federation metadata automatically and also know which ones do not! You can for example use the NOTES property of each trust to specify if your metadata URL is being used by the entity and if you are using the entity’s metadata URL! That way you would be able to easily query through PowerShell who you would need to contact!

[AD.1.3 – Token Decryption Certificate For ADFS STS servers]

First you need to determine and understand if you are using a CA issued certificate or an ADFS managed self-signed certificate.

If you are using an ADFS managed self-signed certificate, then ADFS will perform the rollover (add, promote and remove) automatically.

If you are using CA issued certificate you must replace (add, publish, remove)  the certificate manually by performing the following actions:

  • Get a certificate that fulfills the requirements as mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x
  • Import CA issued certificate into the personal store of each ADFS STS server;
  • On each ADFS STS server, permission the private key (only if new) with the ADFS Service Account to have Allow:Read
  • Using the ADFS MMC on any ADFS STS server (when using SQL) or the primary ADFS STS server (when using WID), configure the certificate as the secondary “Token Decrypting” certificate

After that publish/communicate [***] the new ADFS Token Decrypting Certificate to every downstream federation service that is represented as an Claims Provider Trust in your ADFS based federation service. The owner of the downstream federation service must add the new ADFS Token Decryption Certificate of your federation service to the Relying Party Trust or Service Provider Trust (whatever it is called) that represents your federation service.

After publishing/communicating [***] the new ADFS Token Decrypting Certificate to every downstream federation service that is represented as an Claims Provider Trust in your ADFS based federation service, promote the secondary “Token Decrypting” certificate to become the primary “Token Decrypting” certificate.

[**] Publishing/Communicating New Token Decrypting Certificates To Downstream Federation Services

If the federation metadata is published through an URL AND it is also consumed automatically by those downstream federation services, then instruct the owners of those downstream federation services to import/read the updated federation metadata through the URL, if not already done automatically. Those owners may also need to add the ADFS managed self-signed certificates, if used, to the trusted root stores as needed in addition!

If the federation metadata is NOT published through an URL OR it is NOT consumed automatically by those downstream federation services, then export the Token Decrypting Certificate from ADFS and send that certificate with the public key to the owners of those downstream federation services and instruct them to import the new Token Decrypting Certificate into the Relying Party Trust or Service Provider Trust (whatever it is called) that represents your federation service. Those owners may also need to add the ADFS managed self-signed certificates, if used, to the trusted root stores as needed in addition!

TIP: Know which entity consumes your federation metadata automatically and also know which ones do not! You can for example use the NOTES property of each trust to specify if your metadata URL is being used by the entity and if you are using the entity’s metadata URL! That way you would be able to easily query through PowerShell who you would need to contact!

[AD.2.1 – SSL Communications Certificate For ADFS PRX servers]

Get a certificate that fulfills the requirements as mentioned in the blog post Certificates Used In Active Directory Federation Services (ADFS) v2.x and then:

  • Import CA issued certificate into the personal store of each ADFS PRX server;
  • On each ADFS PRX server, bind the CA issued certificate to the default website in IIS

For additional details also see:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

3 Responses to “(2013-05-15) Replacing ADFS Certificates”

  1. […] ADFS I have explained in this blog post, from a process perspective, what you need to do when you need to replace any of the certificates […]

  2. […] Replacing ADFS certificates: https://jorgequestforknowledge.wordpress.com/2013/05/15/replacing-adfs-certificates/ […]

  3. […] Replacing ADFS certificates: https://jorgequestforknowledge.wordpress.com/2013/05/15/replacing-adfs-certificates/ […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: