AD FS uses Token-Signing certificates to digitally sign security tokens generated by the service. This signature provides evidence that a security token has not been modified during transit. The public key of the Token-Signing certificate is provided during establishment of federation trusts so that the application or service receiving a signed security token can verify the signature.

Recently a Kloud client raised a query about the use of self-signed certificates versus use of a commercial certificate from a public certificate authority for the AD FS Token Signing certificate. What is recommended and why? In answering the query, I noticed contradictory opinions from various sites – but not much in the way of explanation of why one type is better than the other in respect to token-signing.

Generally the use of self-signed certificates is limited to non-production environments, where the use of certificates from a certificate authority is impractical or costly. The reasons for restricting their use are:

  1. Self-signed certificates are not generated by a trusted certificate authority which validates their authenticity, and therefore the authenticity of the resource presenting them.
  2. Self-signed certificates must be manually distributed and imported into the certificate store on computers that must validate it as a trusted certificate.

Due to the above, many people out-of-hand recommend against the use of self-signed certificates for Token-Signing in AD FS. However, doing so without taking into consideration the use and future maintenance of this certificate in AD FS is a mistake.

The AD FS service has been designed to use a self-signed certificate for Token-Signing. A self–signed certificate has a default validity of one year, after which it must be renewed or service failures will occur. AD FS incorporates the capability for automatic renewal for self-signed Token-Signing certificates. It can automatically renew self-signed certificates before expiry, and if a relying party trust is configured for automatic federation metadata updates, automatically provide the new public key to the relying party. This automation makes for a resilient, low maintenance federation service in that a key certificate used by the service does not require periodic attention.

To verify that automatic certificate renewal (rollover) of the Token-Signing certificate is enabled, fire up PowerShell and enter Get-AdfsProperties. Verify that AutoCertificateRollover is set to True.

If you have systems that do not process automatic federation metadata updates it may be beneficial to increase the default expiry for the Token-Signing certificate. This will reduce the frequency that manual update to these systems is required. The following PowerShell command will increase the certificate expiry to 3 years (1095 days).

Set-AdfsProperties -CertificateDuration 1095

For Office 365, consider automating the update of federation metadata. Microsoft has provided a PowerShell script for this task.

The other argument I’ve seen against self-signed Token-Signing certificates is that it reduces the overall security of the AD FS solution as the certificate cannot be validated back to a trusted certificate authority. This would be true for the majority of services, however not with AD FS Token-Signing.

The Service Communication certificate validates the authenticity of a federation service as a whole and not the Token-Signing certificate. Recall that the Token-Signing certificate’s use is to only ensure that security tokens are not modified in transit – important as the use of SSL bridging and offloading increases. The Service Communication certificate is verified during establishment of SSL communication to the federation service, before security tokens are exchanged.

Token-Signing certificates are exchanged at establishment of a federation trust through configuration of an identity provider and relying party. This is a deliberate act performed by both the administrator of the identity provider and the relying party. At this time the validation of the Service Communication certificate to a trusted certificate authority ensures that the federation service which is being configured to participate in a federation trust is authentic. Secondary validation of the Token-Signing certificate to a trusted certificate authority is not required.

To reduce operational overheads and the potential for service failure, the use of self-signed Token-Signing certificates should be considered a highly effective option – outweighing the perceived security benefits of using of a certificate authority issued Token-Signing certificate.

Category:
ADFS

Join the conversation! 3 Comments

  1. Nice article, Mark.

    We ran into this comparison of self-signed cert vs. commercial cert in regards of token signing half a year ago, and we finally ended up using self-signed certs in our production. So far so good.

    However, we did it a bit different. For ADFS which might need to federate with external identity providers, we use commercial cert. While for our custom Security Token Services, we use self-signed certs for token signing.

    Regards,
    Duy.

  2. Hi,
    Thanks for the great article. I am a little confused in an ADFS 2012 R2 infrastructure if O365 still needs to be updated when the self signed certs changed. The script in your article is for ADFS 2.0. I read at the bottom of this article http://blogs.technet.com/b/tfg/archive/2014/04/21/token-signing-and-token-decrypt-certificates-expiration-process-and-dates.aspx The following…..
    “To have single sign on with ADFS the federation certificates need to be updated with the online platform. O365 is now automatically pulling the certificates from the AD FS server via the public metadata endpoint on a regular basis.
    You may need to manually update the federation metadata using the PowerShell in complement to the Microsoft pull mechanism, as this will not pull the certificates on all scenarios.”

    Seems to suggest there is a pull from O365 for the metadata?

    • >> Seems to suggest there is a pull from O365 for the metadata?

      Affirmative. First, start Powershell as an admin and “Import-Module MsOnline” if you don’t have it pre-loading. The run the following command:

      Get-MsolFederationProperty -DomainName yourdomname.com

      It will display the current certs from ADFS, and also from the federated Office365 tenant domain. If they don’t show the same thumbprint, but the “ADFS Server” TokenSigningCertificate looks reasonable (not expired), run this command:

      Update-MSOLFederatedDomain –DomainName yourdomname.com

      HOWEVER, Note that if you have multiple local AD domains federated with a single AzureAD tenant, be sure you study this article FIRST:

      https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-multiple-domains

      …which discusses additional considerations, and the use of the additional command option -SupportMultipleDomain for multi-domain tenant.

Comments are closed.