Known issues

This section contains information about potential issues that you may encounter while using Tungsten Token Vault 3.8.0. Workarounds are included, as applicable.

Title Description Workaround
Potential security warning when opening Token Vault from Mozilla Firefox

Even if Token Vault is configured properly with https protocol and a certificate which is added to the Trusted Root Certificates in the Windows certificate store, a potential security risk warning might appear when opening Token Vault from a Mozilla Firefox browser. By default, the Mozilla Firefox browser does not trust Root authorities in the Windows certificate store.

Enable the Firefox security.enterprise_roots.enabled feature to allow Firefox to trust Root authorities in the Windows certificate store by performing the following steps:

  1. Type about:config into the address bar of the Firefox browser and accept any warnings if prompted.
  2. Search for the security.enterprise_roots.enabled setting and modify its value to true.

    If this setting does not exist, create a new setting with this name and boolean value and set its value to true.

  3. Restart the Firefox browser.
Token Vault configuration migration limitation note

From Token Vault 3.5, the Token Vault client configuration has been discontinued, and the role of Token Vault client ID has been taken by the authorization provider ID. This means that instead of a Token Vault client ID, the authorization provider ID must be configured in the client applications (such as eCopy ShareScan connectors) for a client application to be able to request authentication tokens from Token Vault.

During the upgrade from Token Vault 3.0 or lower to this version, Token Vault connector configurations are migrated as authorization provider configurations, and Token Vault client IDs are preserved as authorization provider IDs to avoid reconfiguring client applications. This is only possible for those Token Vault clients where only one Token Vault connector is associated on the client page of the earlier version of Token Vault because the authorization provider IDs must be unique. Otherwise, a new authorization provider ID is generated for the migrated configuration.

This means that the authorization provider IDs must be checked in the Token Vault and in the client applications (such as eCopy ShareScan connectors) after upgrading an earlier version of Token Vault, and the Token Vault authorization provider IDs must be configured in the client applications accordingly.