AD FS token-signing certificate rollover issue

Neha Gupta 25 Reputation points
2026-09-01T07:14:52.9+00:00

I'm trying to keep our AD FS sign-in working with our federated SaaS applications. AD FS automatically rolls over the token-signing certificate, but after the rollover the applications start rejecting user logins because they still have the old certificate information.

This is what it comes back as when users try to sign in: error: token-signing certificate not trusted Description: failed%20to%20validate%20federation%20metadata

I'm trying to figure out how to force the relying party trusts or SaaS applications to pick up the new federation metadata, or how to manage the certificate rollover without causing users to lose access.

Windows for business | Windows 365 Business
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Harry Phan 30,960 Reputation points Independent Advisor
    2026-09-01T08:30:03.81+00:00

    Hello Neha,

    The problem is that AD FS rolls over its token-signing certificate automatically, but your SaaS applications are still bound to the old one. When that happens, tokens signed with the new certificate are rejected. The quickest way to fix this is to update the relying party trusts with the new certificate. If the SaaS app supports automatic federation metadata refresh, enable it in AD FS by opening the relying party trust properties, going to the Monitoring tab, and checking “Automatically update relying party.” If the app doesn’t support that, you’ll need to manually provide the new federation metadata XML from AD FS at https://<your-adfs-domain>/FederationMetadata/2007-06/FederationMetadata.xml.

    For environments where downtime is unacceptable, many admins disable automatic rollover with Set-ADFSProperties -AutoCertificateRollover $false and manage certificate changes manually, so they can coordinate with SaaS vendors before switching. If you’re already broken, export the new token-signing certificate from AD FS and import it into the SaaS application’s trust configuration. Once the SaaS side trusts the new cert, logins will resume. Long term, the best practice is either to configure automatic metadata consumption or to plan certificate updates in advance with vendors.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    HP.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-09-01T07:15:20.2866667+00:00

    When AD FS rolls over the token-signing certificate, the new certificate must also be trusted by each federation partner. If the partner or SaaS app still has the old certificate, sign-ins fail because the token signed by AD FS is no longer trusted.

    Use this approach:

    1. Verify whether partners can consume federation metadata.
      • If they can consume federation metadata, ensure they refresh and pick up the new token-signing certificate.
      • If they cannot consume federation metadata, send them the public key of the new certificate as a .cer file, or .p7b if the full chain is needed. They must update trust on their side.
    2. Check whether AD FS is using automatic rollover.
      • Run: 
             Get-ADFSProperties | FL AutoCertificateRollover
      • If AutoCertificateRollover = TRUE, AD FS automatically generates new certificates before expiration and later promotes them to primary.
      • If AutoCertificateRollover = FALSE, certificate replacement and promotion must be done manually.
    3. If rollover is manual, promote the new secondary certificate only after partners have had time to consume it.
      • In the AD FS Management MMC, select the secondary token-signing certificate and choose Set As Primary.
      • This reduces disruption because federation metadata can publish the secondary certificate before it becomes active.
    4. For Microsoft Entra ID or Office 365 federated domains, confirm the cloud-side signing certificate matches AD FS.
      • Compare the token-signing certificate thumbprint between AD FS and the federated domain configuration.
      • Use: 
             Get-MgDomainFederationConfiguration -DomainId <domain_id>
      • If the thumbprints do not match, update the federated domain configuration: 
             Connect-MgGraph -scopes Domain.ReadWrite.All, Directory.ReadWrite.All
     $tdo= Get-MgDomainFederationConfiguration -DomainID <domain_id>
     Update-MgDomainFederationConfiguration -DomainId <domain_id> -InternalDomainFederationId $tdo.Id -SigningCertificate <certificate_token>
     Disconnect-MgGraph
    5. If sign-in failures continue after rollover, also check these common causes:
      • Stale or cached credentials in Windows Credential Manager.
      • The Secure Hash Algorithm on the Office 365 relying party trust is set to SHA1.
    6. If the certificate is already expired and an immediate rotation is required, use emergency rotation carefully.
      • This revokes the old certificate immediately.
      • It can cause a service outage until all federation partners update to the new certificate.

    Operationally, the safest rollover pattern is:

    • Let AD FS publish the new secondary certificate.
    • Allow metadata-consuming partners time to refresh.
    • Manually notify non-metadata-consuming partners and provide the new public certificate.
    • Promote the new certificate to primary only after partners are ready.
    • For Microsoft Entra ID, verify and update the federated domain signing certificate if needed.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.