Action Required: TeamDynamix Single Sign-On Certificate Rollover (USA Only)

Target Audience

  1. Are you a customer in TeamDynamix US SaaS Cloud?
    1. Does your organization utilize Single Sign-On (versus TeamDynamix native authentication or traditional LDAP/Active Directory authentication)?
      1.  Yes. This article applies to you. Please proceed with the steps outlined in this article.
        Please note that some historical Canadian clients are located in the original US region, so this article may apply to you. If a ping yourTeamDynamixDomainHere command in a command prompt/terminal resolves to or one of the US-based IP addresses in the TeamDynamix IP Addresses article in the Related Articles Section, this applies to you as well!
      2.  No. This article does not pertain to you. No action is required.
  2. Are you a customer in TeamDynamix Canada SaaS Cloud? 
     This article does not pertain to you. No action is required.


The certificate used by the USA TeamDynamix Shibboleth Service Provider for Single Sign-On (SSO) login interactions will expire on November 1st, 2022. While the SAML specification does not require certificate expiration to be checked because trust is handled through metadata or out-of-band, some software products check it anyway, requiring an update to maintain maximum compatibility.

To best protect user privacy, TeamDynamix has generated a new keypair and issued a replacement certificate that will be valid for another 20 years. Both keys will be considered acceptable for encrypted messages until the beginning of November, but the old certificate will still be used in rare instances where TeamDynamix signs messages.

Steps to Take

If you dynamically pull Service Provider (SP) metadata from TeamDynamix, either directly or through a federation, you likely do not need to take further action. TeamDynamix is part of InCommon, and metadata is exported to eduGAIN for international customers. Verify that the TeamDynamix SP metadata in your systems contains the new certificate below (expiring in 2042). If it does not for some reason, please proceed on with this article.

You should check to ensure that fresh metadata is being used. If you have statically configured metadata or a trust/IdP app for TeamDynamix, to ensure continuity of service, you will need to take three steps at appropriate points in time:

  1. Verify that the TeamDynamix SP metadata in your systems contains the new certificate below (expiring in 2042). If for some reason it does not, please proceed to steps 2-4.
  2. Acquire the new certificate for encryption. This is done preferably through pulling new metadata available from the Obtaining the TeamDynamix SP Metadata article in the Related Articles section. Alternatively, the certificate itself may be downloaded in various formats in the Attachments section, and is available in text below.
  3. Begin using the new certificate to encrypt messages for TeamDynamix. This may be done immediately, but it must be done before November 1st, 2022.
  4. Remove the old certificate (if necessary) and pull it from your trust configuration.
  5. After completing steps 1-4 above, confirm back to TeamDynamix that you have completed the certificate rollover process using the survey link below. Please complete the survey even if your organization already had the new certificate.

New Certificate Text


Identity System-Specific Instructions

We have also compiled specific instructions for the most commonly used identity providers amongst our clients for your convenience.

Shibboleth IdP

Shibboleth is capable of pulling service provider metadata dynamically. It is recommended that you obtain metadata using the MDQ protocol. If you prefer, you can also acquire metadata directly from TeamDynamix. 

Shibboleth can also use static metadata. If you have a saved copy of the TeamDynamix metadata on disk, please replace it and then reload the metadata service in the IdP.

Azure Active Directory (Azure AD / AAD)

To replace a certificate in Azure AD, you must import the new certificate manually using the Azure Portal and then activate it for use. TeamDynamix can support multiple certificates at one time, so you may do this at any time. It is requested that you perform a test login to ensure that the new key is being used.

To upload a new signing certificate:

  1. Log into Azure Portal.
  2. Locate the AAD Enterprise Application you configured for TeamDynamix SSO.
  3. Click the Security > Token encryption tab in the left nav bar.
  4. Import the new certificate file (use one of the files from the Attachments section of this article).
  5. Click the three dots ... to the far right of the newly uploaded certificate in the grid and choose to Activate token encryption certificate.
  6. Repeat step #5 for any old certificates located here but instead choose Deactivate token encryption certificate.

Active Directory Federation Services (ADFS)

Early ADFS versions require that service provider certificates be manually replaced. The easiest way to do this is by opening the ADFS management console and importing the new certificate manually in the Relying Party Trust > Encryption and Signing tabs, but PowerShell may also be used. Please consult the ADFS documentation for your version for instructions. Remove all old service provider certificates for TeamDynamix and replace them with the new one from the Attachments section.

ADFS 3.0 and later supports service provider metadata with multiple certificates. After pulling the latest metadata from the URL you are already monitoring for metadata, you can then designate the new certificate as the primary encryption certificate using PowerShell. If you are not monitoring a URL for metadata, or your ADFS for some reason will not accept multiple certificates, use the previous steps to import the certificate manually.

For hybrid ADFS/Azure AD deployments, please refer to Microsoft’s documentation.

For older ADFS 2.0 (and possibly early ADFS 3.0) Deployments
It appears that ADFS 2.0, and certain subsets of old/unpatched (TDX cannot determine the trigger for this) ADFS 3.0 deployments, are unable to dynamically monitor our Shibboleth metadata URLs (which return multiple certificates). For ADFS 3.0, sometimes patching to the latest Windows patch levels fixes this, but not always. For ADFS 2.0, there seem to be no resolutions at all for which dynamically monitored metadata will work.

If your ADFS 2.0/3.0 deployment will not let you dynamically monitor our metadata in the Monitoring tab of the Relying Party Trust:

  1. Turn off monitoring in the Monitoring tab, then click OK/Apply/Save.
  2. Go to the Encryption tab.
  3. Manually remove our old certificate (expiring in 2022).
  4. Manually add our new certificate from this KB (expiring in 2042).
  5. Ensure that login sessions still work.
  6. Wait for an in-app system message that TeamDynamix has completely removed the old 2022 encryption/signing certificates. This will likely be sometime in Q1 2023. Only resume monitoring in the Monitoring tab after receiving this confirmation or upgrading your ADFS deployment to ADFS 4.0.


Okta requires that a custom application be created for TeamDynamix because your environment is unique to you as a client. Note that Okta only allows you to specify a single public key to use for encryption per service. Fortunately, the software used by TeamDynamix is capable of attempting decryption with multiple keys, making up for this deficiency and allowing you to perform the key rollover at your leisure.

To perform the key rollover, browse to Okta’s documentation page on custom SAML integrations. Click Show Advanced Settings and remove the existing encryption key. Supply Okta with the new encryption key by downloading the new certificate above, ensuring that it is saved on disk with a .cer suffix, and uploading it using the GUI.

Central Authentication Service (CAS)

CAS is capable of using MDQ, REST, flat files, and more for SP metadata. The documentation does not include any precise guidance regarding key rollovers, but there is an overview of how it works. Simply import the new metadata containing both certificates, or just the new certificate if possible. If you would like, you may remove the old certificate after verifying that the new one is functioning, but dynamically pulled metadata will eventually be updated to include only the new certificate anyway.


SimpleSAML PHP is capable of pulling service provider metadata dynamically. It is recommended that you obtain metadata using MDQ. If you prefer, you can also acquire metadata directly from TeamDynamix as mentioned earlier.

SimpleSAML PHP can also use static metadata. If you have a saved copy of the TeamDynamix metadata on disk, please replace it.

Google IdP

From the information we can find, it does not seem that Google IdP even supports performing assertion encryption. This article will not apply to you. Simply fill out the completion survey above.

DUO SSO SAML / Access Gateway

From the documentation presented by DUO, the platform as a whole does not support assertion encryption. TeamDynamix does not require assertion encryption, so this article will not apply to you. Simply fill out the completion survey above.

Other IdPs

We will try to add guidance for other IdPs, such as Ellucian Ethos Identity / WSO2 / PortalGuard / OneLogin / SecureAuth / etc., as we are able to research it or receive feedback from customer.

100% helpful - 1 review


Article ID: 142682
Wed 4/13/22 2:30 PM
Fri 10/7/22 10:59 AM

Related Articles (1)

TeamDynamix SAML Metadata