Microsoft Active Directory Federation Services implementations, typically, use three certificates for its functionality:

1. Service communication certificate
2. Token-signing certificate
3. Token-decrypting certificate

In the past three parts of this series, I’ve discussed the best practices I use when choosing the settings for my service communication certificate (request).

Today, I’ll share my best practices for the token-signing certificate and the token-decryption certificate lifetime.

Relying Party Trusts can be set up using several methods:

• Import data about the relying party published online or on a local network
• Import data about the relying party from a file
• Enter data about the relying party manually

When using the first method, the federationmetadata.xml file can be polled automatically by both Relying Party Trust endpoints. For some Relying Party Trusts, the option to Automatically update relying party on the Monitoring tab of the Relying Party Trust’s Properties is enabled, by default:

This allows for both Relying Party Trust endpoints to automatically pick up on changes, including changes in certificates.

When using the other methods, the information for the Relying Party Trust is exchanged manually. During initial setup the certificate thumbprints are exchanged and not automatically monitored. Whenever a change is made, the change needs to be communicated to the person managing the other endpoint. When a Token-signing or Token-decrypting certificate changes for an Active Directory Federation Services 9AD FS) implementation acting as an Identity Provider, these changes need to be communicated to the person managing the Relying Party.

Of course, we want to keep communication to a minimum.
Therefore, in organizations with a lot of manually created Relying Party Trusts, I typically recommend to configure the Token-signing and token-decrypting certificate with a longer lifetime.

Default token-signing and decrypting settings

By default the self-signed token-signing and token-decrypting certificates have a lifetime of 365 days.

You can see the properties of these certificates (and your service communications certificate) in the Certificates node under the Service node in the AD FS Management console snap-in (Microsoft.IdentityServer.msc):

Alternatively, using Windows PowerShell you can query the certificateduration property for the AD FS Service, using the following PowerShell one-liner:

Get-AdfsProperties | ft certificateduration

By default, its value is 365, equal to a non-leap year in days.

Additionally, by default, the token-signing and token-decrypting certificates are configured for automatic roll-over.

Configuring token-signing and decrypting cert lifetime settings

To avoid communication with persons managing Relying Parties, set-up using manually configured Relying Party Trusts, I typically extend the lifetime of the AD FS token-signing and token-decrypting certificates with a lifetime of 5 years.

Now, being a bit of a perfectionist, I want to see the dates in the AD FS Management console snap-in (Microsoft.IdentityServer.msc) match. This means I take into account leap year dates. TimeandDate.com has a nice calculator for this purpose, meaning I’m specifiying 1827 days for the certificateduration property for the AD FS service, to achieve a 5 year certificate lifetime (both 2016 and 2020 are leap years apparently).

Using the PowerShell one-liner below from an elevated PowerShell session achieves this goal:

Set-AdfsProperties -Certificateduration 1827

Renewing the token-signing and decrypting certs

Now, nothing happens to the token-signing and token-decrypting certificates after you issue that last one-liner, since both certificates have no issues in their current state. Eventually, near the end of their lifetime, they would automatically roll-over, but we want it to happen now (and ideally before we manually configure the first Relying Party Trust).

We have to tell the certificates to roll over to their new settings. The following two PowerShell one-liners can be used to this purpose:

Update-AdfsCertificate -CertificateType Token-Signing -Urgent

Update-AdfsCertificate -CertificateType Token-Decrypting -Urgent

Concluding

The default Active Directory Federation Services (AD FS) token-signing and token-decrypting certificate duration settings can be changed to accommodate manually configured Relying Party Trusts (RPTs).

For AD FS implementations with a lot of manually configured Relying Party Trusts (RPTs) I recommend 3 year to 5 year certificate durations for the token-signing and token-decrypting certificates (depending on the economic lifetime of the AD FS implementation).

Related blogposts

AD FS Certificates Best Practices, Part 1: Hashing Algorithms
AD FS Certificates Best Practices, Part 2: Key size
AD FS Certificates Best Practices, Part 3: Cryptographic Next Generation (CNG)-generated Private Keys

Further reading

Set-ADFSProperties
AD FS 2.0: Understanding AutoCertificateRollover Threshold Properties
ADFS AutoCertificateRollover
AD FS and self-signed Token-Signing certificates
Guide to renew the security certificate for ADFS 2.0 and Claims Provider in SharePoint