Skip to content

Ulysses Neves

Microsoft Entra ID, authentication, and hybrid identity troubleshooting.

Menu
  • Home
  • Microsoft Azure
  • Microsoft AD FS
  • Microsoft 365
  • Contact
  • Troubleshooting Index
Menu

AD FS – Updating the Token-signing and Token-decrypting certificates in AD FS

Posted on August 26, 2020

Update notice — September 2026: This article contains commands from the Azure AD or MSOnline PowerShell modules maintained since its original publication. Microsoft has deprecated these modules and recommends Microsoft Graph PowerShell for current automations. Do not use the legacy commands in new implementations.

Source: Guidance for migrating to Microsoft Graph: “Azure AD, Azure AD Preview and MSOnline PowerShell modules are deprecated.”

Hello everyone. Are you one of those administrators who shudders just seeing that the time is coming to update the AD FS certificates? 😱

In today’s article I’ll explain how to update the AD FS Token-signing and Token-decrypting certificates automatically and manually, while keeping the AD FS environment functional.

What is the Token-signing Certificate used for?

AD FS servers use the token-signing type certificate to prevent hackers from making changes to authorization tokens and gaining access to federated services. Private and public keys are used to ensure that the security token is not generated by anything other than a trusted source and is not altered by third parties.

What is the Token-decrypting Certificate used for?

The token-decrypting type certificate is used to decrypt tokens that were encrypted by other federated resources. All certificates have a private key.

Changing the Token-signing and Token-decrypting certificates automatically

By default, the TS (Token-signing) and TD (Token-Decrypting) certificates are configured to be updated automatically through the feature called AutoCertificateRollover.

This setting can be observed by running the command below on a primary AD FS server:

Get-AdfsProperties

The available parameters are:

AutoCertificateRollover: If active, allows the AD FS service to manage the issuance and replacement of certificates automatically by generating a secondary certificate and then promoting it.
CertificateCriticalThreshold: Contains the number of days before the expiration of the primary TS or TD certificate. When the value set in this parameter is reached, the certificate replacement process starts by generating a new certificate and promoting it to primary.
CertificateDuration: Contains the number of days that certificates in the AD FS service can remain valid.
CertificateGenerationThreshold: Contains the number of days before the AD FS service generates a new certificate. When the number of days specified in this parameter is reached, the service starts creating the new certificate, naming it as secondary. At this point, applications that consume the AD FS settings through the metadata file can already access information about the new certificate before it replaces the current one, avoiding unavailability resulting from the change.
CertificatePromotionThreshold: Contains the number of days the new certificate remains as secondary before being promoted to primary.
CertificateRolloverInterval: Contains the time in minutes at which AD FS checks whether any new certificate needs to be generated.
CertificateThresholdMultiplier: Contains the time multiplier. By default, this parameter has the number of minutes in a day (1440). It is changed only in specific cases where you want to set a certificate expiration time shorter than one day.

If you keep the default with AutoCertificateRollover active, the TS and TD certificates will be generated automatically and consumed by the Relying Parties through the AD FS metadata file available through the URL https://server.domain.com/FederationMetadata/2007-06/FederationMetadata.xml.

For applications that do not support automatic updating, you must export the certificate generated by AD FS and schedule the change with the service provider responsible for the application.

When the certificate is generated, you can observe the certificates identified as secondary, being promoted automatically when CertificatePromotionThreshold is reached.

Changing the Token-signing and Token-decrypting certificates manually

To manually run the certificate creation, we’ll need to activate the Auto Certificate Rollover parameter with the command below:

Set-ADFSProperties -AutoCertificateRollover $true

To identify the active TS certificate on the AD FS server, let’s run the command below:

Get-ADFSCertificate –CertificateType token-signing

To generate a new secondary TS certificate on the AD FS server, let’s run the command below:

Update-ADFSCertificate –CertificateType token-signing

We can observe the new certificate identified as secondary in the AD FS console:

If you need to generate a new certificate and immediately replace the primary one, you can use the -urgent attribute as shown below:

Update-ADFSCertificate –CertificateType token-signing -urgent

Note: When using the -urgent parameter, the RPs need to be updated immediately. As shown below, we can see that only the new certificate appears as primary.

With the command below we can see that the new certificate is configured in AD FS.

Get-ADFSCertificate –CertificateType token-signing

Let’s now run the command below to identify the TD certificate in AD FS.

Get-ADFSCertificate –CertificateType token-decrypting

Let’s run the command below to generate a new TD certificate in AD FS.

Update-ADFSCertificate –CertificateType token-decrypting

We can see that the new certificate was generated and is identified in the AD FS console as secondary.

Just as with the TS certificate change, let’s run the command below to replace the current certificate immediately in AD FS.

Update-ADFSCertificate –CertificateType token-decrypting -urgent

We can see below that the new certificate is now configured as primary and in use in the AD FS console.

Updating the new TS certificate in Azure

To ensure access to applications hosted in Azure, it is necessary to update the certificates generated by AD FS in Microsoft Entra ID. Let’s start this update by running the commands below in case you don’t have the MSOnline module installed

Install-Module MSOnline
Import-Module MSOnline

Run the command below to connect to the MSOnline service.

Connect-MsolService

Sign in with a credential that has global administrator permission in Azure.

By running the command below, we can see that the certificate generated by AD FS does not match the certificate configured in Office 365.

Get-MsolFederationProperty -DomainName <domain> | FL Source, TokenSigningCertificate

Let’s now run the command below to update the certificate generated by AD FS in Azure.

Update-MSOLFederatedDomain –DomainName <domain> -SupportMultipleDomain

Let’s run the command below to validate the certificate update in Office 365.

Get-MsolFederationProperty -DomainName <domain> | FL Source, TokenSigningCertificate

With the command below, we can observe the TS certificates configured in Office 365.

Get-MsolDomainFederationSettings -domain <domain>

Summary

In today’s article, we talked about the ways to update the token-signing and token-decrypting certificates used by AD FS.

I hope this content has contributed to enriching your knowledge of AD FS.

Did you like the post? Like and share it. 🙂

If you have any suggestions or comments, let us know.

[ ]’s

Ulysses Neves

Related guides: Browse the Microsoft Identity Troubleshooting Index or the Microsoft AD FS topic archive.

4 thoughts on “AD FS – Updating the Token-signing and Token-decrypting certificates in AD FS”

  1. Marcelo Lima says:
    August 26, 2020 at 19:25

    Parabéns pelo conteúdo, Ulysses.

    Reply
    1. Uneves says:
      September 5, 2020 at 20:47

      Obrigado brother!

      Reply
  2. Diego Machado Ferreira says:
    February 17, 2022 at 14:28

    Obrigado!! Consegui atualizar os certificados graças ao seu tutorial.

    Reply
    1. Uneves says:
      February 18, 2022 at 14:46

      Obrigado pela opinião Diego! Fico feliz que este artigo o tenha ajudado.

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent Posts

  • Microsoft Defender for Identity domain investigation: six questions to ask first September 10, 2026
  • Microsoft Entra Kerberos key rotation: what changes—and what administrators should check September 6, 2026
  • Microsoft Authenticator Will Block Jailbroken Devices in 2026 — What You Need to Know March 17, 2026
  • Enhancing Azure role activation security with FIDO2/Passkeys September 23, 2024
  • Microsoft Entra ID CAP | Enforcing WHfB using Authentication Strength April 21, 2024

Archives

  • September 2026
  • March 2026
  • September 2024
  • April 2024
  • February 2024
  • December 2023
  • September 2023
  • July 2023
  • June 2023
  • May 2023
  • April 2023
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019

Tags

#aaddownleveldevice #adfs #adfscertificate #adfscertificates #adfsmfaadapter #azureauth #azureCA #azuredevice #capolicy #cloudsummit2021 #conditionalaccess #conditionalaccesspolicy #deviceregistration #farmbehavior #gopasswordless #mfaserver #msidentity #namedlocation #securingazure #securingazuread #sslprivatekey #troubleshootingadfs #troubleshootingwaptrust #tshootadfs #waptrust #webapplicationproxy #WHFBcerttrust #whfbdeployment #WHfBhybridsetup #WHfBprovisioning #widdatabase adconnect AD FS authenticationstrength az500 azurepim Azure security cloudsecurity microsoft365 Microsoft Azure Microsoft Entra hybrid join Microsoft Entra ID Microsoft Entra MFA PowerShell WHfB
©2026 Ulysses Neves | Design: Newspaperly WordPress Theme
Ulysses Neves
Gerenciar Consentimento de Cookies
Para fornecer as melhores experiências, usamos tecnologias como cookies para armazenar e/ou acessar informações do dispositivo. O consentimento para essas tecnologias nos permitirá processar dados como comportamento de navegação ou IDs exclusivos neste site. Não consentir ou retirar o consentimento pode afetar negativamente certos recursos e funções.
Funcional Always active
O armazenamento ou acesso técnico é estritamente necessário para a finalidade legítima de permitir a utilização de um serviço específico explicitamente solicitado pelo assinante ou utilizador, ou com a finalidade exclusiva de efetuar a transmissão de uma comunicação através de uma rede de comunicações eletrónicas.
Preferências
O armazenamento ou acesso técnico é necessário para o propósito legítimo de armazenar preferências que não são solicitadas pelo assinante ou usuário.
Estatísticas
O armazenamento ou acesso técnico que é usado exclusivamente para fins estatísticos. O armazenamento técnico ou acesso que é usado exclusivamente para fins estatísticos anônimos. Sem uma intimação, conformidade voluntária por parte de seu provedor de serviços de Internet ou registros adicionais de terceiros, as informações armazenadas ou recuperadas apenas para esse fim geralmente não podem ser usadas para identificá-lo.
Marketing
O armazenamento ou acesso técnico é necessário para criar perfis de usuário para enviar publicidade ou para rastrear o usuário em um site ou em vários sites para fins de marketing semelhantes.
  • Manage options
  • Manage services
  • Manage {vendor_count} vendors
  • Read more about these purposes
Ver preferências
  • {title}
  • {title}
  • {title}