AD FS and self-signed Token-Signing certificates

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.