Release Notes
Product Description
CipherTrust Manager is the center of the CipherTrust Data Security Platform. It serves as the central point for managing configuration, policy and key material for data discovery, encryption, on-premise and cloud based use cases. It is the successor to both the Thales eSecurity (formerly Vormetric) DSM and the Gemalto (formerly SafeNet) KeySecure platforms.
Product Abbreviations
Name | Abbreviation |
---|---|
CipherTrust Batch Data Transformation | BDT |
CipherTrust Manager | CM |
CipherTrust Application Data Protection | CADP |
CipherTrust Cloud Key Manager | CCKM |
CipherTrust Database Protection (formerly known as ProtectDB) | CDP |
CipherTrust Transparent Encryption | CTE |
CipherTrust Transparent Encryption UserSpace (formerly known as ProtectFile FUSE) | CTE UserSpace |
CipherTrust Teradata Protection | CTP |
CipherTrust Data Discovery and Classification | DDC |
Data Protection on Demand | DPoD |
CipherTrust Tokenization | CT |
CipherTrust Vaulted Tokenization | CT-V |
CipherTrust Vaultless Tokenization | CT-VL |
Release Description
This release is available on the Customer Support Portal in the following formats:
An upgrade file for physical k570 and k470 CipherTrust Manager devices, and existing k170v Virtual CipherTrust Manager instances.
An upgrade file for KeySecure Classic k450 and k460 devices.
An OVA image file for deploying a new Virtual CipherTrust Manager on VMWare vSphere or Nutanix AHV.
A VHDX image file for deploying a new Virtual CipherTrust Manager on Microsoft Hyper-V.
A QCOW2 image file for deploying a new Virtual CipherTrust Manager on OpenStack.
In addition, 2.4.0 Virtual CipherTrust Manager is available on the following public clouds:
Amazon Web Services: SafeNet Cloud Provisioning System
Google Cloud
Microsoft Azure: Available as a BYOL image in the Microsoft Azure Marketplace
Oracle Cloud
IBM Cloud
An OVA image file for deploying a new Virtual CipherTrust Manager on IBM Cloud VMWare.
A QCOW2 image file for deploying a new Virtual CipherTrust Manager IBM Cloud Virtual Private Cloud Gen2.
2.4.0 contains a number of new features and enhancements. Refer to Release 2.4.0 for details.
For the list of known issues, refer to Known Issues.
Features and Enhancements
Release 2.4.1
This patch fixes the issue that occurs when you perform a sequential in-place upgrade from v2.0.0 or v2.1.0 to v2.4.0, that makes the CCKM Google Workspace CSE feature unavailable.
The patch can be applied to CipherTrust Manager version 2.4.0.
Release 2.4.0
Platform
You can now migrate KMIP accessible agent keys from Data Security Manager (DSM) using ksctl or the REST API.
CTE
This release supports migration of the following CTE resources from a DSM backup file:
Clients and client GuardPoints from the same domain
Client groups and client group GuardPoints from the same domain
Clients and client group associations
User sets, resource sets, process sets, signature sets, and signatures
Standard and Cloud Object Storage (COS) policies
Note
CTE resources of IDT, LDT, Efficient Storage, and Container policies on the DSM cannot be migrated to the CipherTrust Manager 2.4 using the backup/restore method. The Container policies are supported only on the DSM. Migration of IDT, LDT, and Efficient Storage resources will be supported in a future release. However, IDT and LDT resources can be manually created on the CipherTrust Manager.
CCKM
Migration from CCKM Appliance
Export of migration data from a CCKM Appliance to CCKM on the CipherTrust Manager. This phase supports the migration of AWS and Azure clouds only with the DSM as a key source.
Google Workspace Client Side Encryption (CSE)
Integrated Google Workspace CSE to use the CipherTrust Manager as an external key manager. It allows users to encrypt/decrypt their Google Docs, Slides, and Sheets stored on Google Drive.
DDC
DDC and TDP documentation now available on the thalesdocs.com portal.
Scalable reports processing: Offloads scan processing and report generation to avoid impacting CM performance on deployments with massive amounts of data.
Intelligent Remediation with CipherTrust Transparent Encryption: Automatically protect sensitive data based on risk to improve operational efficiency and achieve compliance. Provides integration with CTE and visibility on the organization’s protection status. Requires a CTE agent supporting Intelligent Remediation.
Reports enrichment with Remediation Information: Scan reports display the Data Object remediation status and consider it when calculating the risk score.
Centralized Connection Management: TDP connection configuration moved to Connection Management brings a centralized way for configuring TDP through CipherTrust Manager’s Connection Management.
TDP HA support: Offers configuring multiple Knox proxy nodes to failover connection to TDP.
New built-in templates: Extends the regulation template list with UK-GDPR and specific built-in templates for GDPR (financial, healthcare, national ID and personal details).
New Data Stores:
SAP Hana
Office365 (Exchange Online)
Office365 (SharePoint Online)
Resolved Issues
This table lists the issue resolved in 2.4.1.
Issue | Synopsis |
---|---|
KY-31281 | [CCKM, Google Workspace CSE] Fix for Google Workspace becoming unavailable after in-place sequential upgrade from CipherTrust Manager v2.0.0 or v2.1.0 to v2.4.0. |
This table lists the issue resolved in 2.4.0.
Issue | Synopsis |
---|---|
KY-29416, 28820 | The UI displays either an error or warning popup message when the number of used licenses reaches 100% and exceeds 95% respectively. It should only display an error when the number of used licenses exceeds the allowed amount. This message does not affect any functionalities and can be safely disregarded. |
KY-28010 | Internal server error occurs when creating GuardPoints with a resource set of the type "classification". |
KY-27444 | In very rare occasions, the ECIES function of the NAE interface derives an incorrect encryption and authentication key due to incorrect padding. Encrypting data with a nonstandard derived key prevents the EC key from successfully decrypting data outside of CipherTrust Manager. If you encrypt some data with an EC key with the incorrect derived key, export the EC key from the CipherTrust Manager, and attempt to decrypt the data with the EC key, the derived key is different and cannot decrypt the data. |
KY-23751 | DDC scans re-launched after a connectivity issue with Hadoop get stuck in a Pending status. |
KY-23750 | The data allowance for the whole DDC scan target is used up although the scan previously fails with "Error connecting to PQS" |
KY-23569 | Hadoop network connectivity issues cause the DDC ongoing scans to fail. |
KY-19665 | DDC Multipath-Report: only the files from one directory are shown two or more have the same name but differs on the capitalization (uppercase / lowercase) |
KY-8526 / KY-22408 | DDC Hadoop configuration does not allow PQS schema changes. |
KY-20051 | Data objects may not be listed in reports when there is a huge number of matches. Please check DDC Known Issue KY-30760 if you are upgrading from CM 2.2. |
Advisory Notes
This section highlights important issues you should be aware of before deploying the CipherTrust Manager. There is also a full list of known issues associated with the release.
ECIES Decryption Can Fail After Upgrade in Rare Cases
If you encrypted data with ECIES prior to upgrade to 2.4, you might not be able to decrypt the data with the same EC key after upgrade. This is because, in very rare cases, the ECIES function of the NAE interface derived an encryption and authentication key due to incorrect padding. Release 2.4 fixes this rare incorrect key derivation, which means that the derived key can be different from previous releases, and decryption operations can fail. If you have trouble decrypting with an EC key after upgrade, decrypt the data with an older version of CipherTrust Manager and re-encrypt it with CipherTrust Manager version 2.4.
System Upgrade and Downgrade Supported Releases
System upgrades have been tested from releases 2.1.0, 2.2.0, and 2.3.0.
Note
Upgrades from other versions have not been tested and may not work correctly.
Caution
If you have DDC configured, you can only upgrade from 2.2.0.
CipherTrust Manager 2.4.0 can be downgraded to 2.3.0. For release-specific upgrade/downgrade information, refer to the release notes for your release.
Refer to the System Upgrade page for instructions to perform an upgrade or downgrade on a single device.
Refer to the Cluster Upgrade section for instructions to perform an upgrade on a cluster of devices.
Restoring a backup from release 1.5.0 or later is supported; however, restoring a newer backup to an older version is never supported.
SSH Key Fingerprint Change After Upgrade
Upgrading to 2.4 from version 2.2 or 2.1 introduces a new SSH server key, using the stronger ED25519 algorithm in comparison to the existing RSA key. If you upgrade the CipherTrust Manager and then SSH to the appliance as ksadmin
, you can be presented with a warning the fingerprint has changed. This warning is expected and can be safely disregarded.
If you want to verify the presented SSH key fingerprint, you can also log into the console through a serial cable (for physical appliances) or your virtual platform's console access tools. The console displays all of the SSH key fingerprints.
Default TLS Setting Can Cause Loss of KMIP/NAE/Web Connection After Upgrade
If you are upgrading from 2.1 or 2.2, the 2.4 release introduces changes to the TLS ciphersuites associated with the KMIP, NAE, and web interfaces. When you upgrade, the existing TLS ciphersuites for these connections might not be included in the 2.4 default TLS ciphersuites, which results in a loss of connection to the interface. CBC-based ciphersuites, for example, are disabled upon upgrade to 2.4.
For security reasons, we recommend that you ensure clients to your KMIP, NAE, and web interfaces use one of the 2.4 default TLS ciphersuites before upgrade.
If you cannot change the TLS ciphersuites for your clients, plan for some downtime for the interface(s) after upgrade. After upgrade, you can manually enable the previous ciphersuites to restore the connection.
Clusters with a Large Number of Transactions
Clusters that support a large number of transactions should have audit logging disabled and only syslog should be used for capturing audit logs. This significantly reduces cluster wide traffic and disk usage. This is a cluster wide setting and needs to be set on only one node in the cluster. Use the ksctl properties command to disable audit logging.
To disable local audit logging
Set the property ENABLE_RECORDS_DB_STORE
to false using the ksctl command:
$ ksctl properties modify -n ENABLE_RECORDS_DB_STORE -p false
If configured, Audit logs will be still be sent to a syslog server.
Cluster Synchronization
Correct cluster synchronization relies on all nodes in a cluster having the same time. It is strongly advised to use NTP to set the time in a new node before it joins a cluster. NTP settings are not copied between nodes - they must be set individually for each CipherTrust Manager server.
Protect the ksadmin Private SSH Key
The private SSH key for the ksadmin account is critical to system security and must be carefully protected. Failure to do so could allow an attacker to compromise the system.
TLS/SSL Must be Enabled in a Production System
As it may be useful for troubleshooting, it is possible to disable TLS/SSL for the NAE interface. This will lead to an insecure system. Therefore, TLS/SSL should always be enabled for a production system.
Data Discovery and Classification Limitations
Clustering
Only one CipherTrust Manager node in the cluster can have DDC activated. To access DDC, create a new DNS entry to point to the active CipherTrust Manager node.
DDC functionality cannot be accessed through the CipherTrust Manager FQDN. DDC requests sent to an inactive CipherTrust Manager node fail (and return the impression that DDC fails randomly).
Licensing
- Overlapping licenses are not supported (except for the trial license).
Scans
- The scans created in the DDC Scans section are stored but the executions can not be used for new reports. The user will have to run the scans to make new reports for these scans.
Reports
It is not possible to create new reports for the scan executions that were completed with previous Data Discovery and Classification version. The reports that were generated using previous DDC version are accessible and will be marked with a "L" icon meaning Legacy reports and can not be updated any more.
For the reports generation, the user will need to run new executions of the scans, since the legacy scan executions cannot be used. The user will notice that after an upgrade, when trying to generate new reports, scan executions completed with previous DDC version are not displayed in the reports wizard.
Scalable Reports Processing
Previous DDC versions needed PQS and HDFS Hadoop services, but starting from this version DDC requires HDFS and Livy. Refer to the latest Thales Data Platform Deployment Guide for information on how to install Spark, Livy and Tez and DDC Deployment Guide for configuring them in CipherTrust Manager.
As DDC no longer uses PQS to store new data, it is no longer possible to modify its configuration through the UI. Please use the API if you need to update the Knox hostname, credentials or TLS certificate. The upgrade will not delete any data stored in PQS. Please consider deleting it when you no longer need access to legacy reports.
The Hadoop settings (HDFS and Livy) must be added as if it was a fresh deployment. The HDFS settings that the user could had up to now are not kept, but the PQS settings are automatically stored to make sure the information stored for scans and reports is not lost.
For the HDFS connection, it is recommended to configure a different HDFS folder.
Compatibility
This section documents known compatibility topics to be considered before deploying the CipherTrust Manager.
TLS Compatibility
This table identifies the supported TLS versions for each of the CipherTrust Manager interfaces. The default minimum value reflects the default minimum_tls_version
setting. This setting controls the lowest acceptable TLS version allowed for connections to the interface.
Interface | Minimum TLS version | Maximum TLS version | Default Minimum TLS version |
---|---|---|---|
Web UI | TLS 1.2 | TLS 1.3 | TLS 1.2 |
NAE | TLS 1.0 | TLS 1.3 | TLS 1.2 |
KMIP | TLS 1.0 | TLS 1.3 | TLS 1.2 |
Caution
TLS 1.0 and TLS 1.1 support will be discontinued in a future release.
By default, CipherTrust Manager accepts the following ciphersuites for TLS 1.2+ connections:
TLS_AES_256_GCM_SHA384 (TLSv1.3)
TLS_CHACHA20_POLY1305_SHA256 (TLSv1.3)
TLS_AES_128_GCM_SHA256 (TLSv1.3)
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS Deprecation Notices
Use of TLS 1.0 and 1.1 protocols is deprecated. This support will be discontinued in a future release. Upgrade all applications connecting to CipherTrust Manager interfaces to TLS 1.2 or higher as soon as feasible.
Use of the following CBC-based ciphersuites is deprecated, and support will be discontinued in a future release:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
Client Platforms
The following client Platforms are supported by the CipherTrust Manager.
Caution
Older versions of most client platforms (versions earlier than the minimum versions listed below) may have incompatible TLS clients. We recommend testing older versions of client platforms in a non-production environment to ensure proper functionality.
For the purpose of transitioning from SafeNet KeySecure Classic, you can temporarily connect to CipherTrust Manager with TLS/SSL disabled on the CipherTrust Manager NAE interface; however, this is recommended only in a non-production environment.
CipherTrust Application Data Protection
ProtectApp JCE: minimum version 8.6.1
ProtectApp .NET: minimum version 8.11.0
ProtectApp ICAPI: minimum version 8.10.0
ProtectApp Oracle TDE: minimum version 8.9.0
ProtectApp SQL EKM: minimum version 8.3.2
CipherTrust Cloud Key Manager
Minimum version 1.6.3.20532
CipherTrust Database Protection
ProtectDB Oracle: minimum version 8.8.0
ProtectDB SQL: minimum version 8.9.0
ProtectDB DB2: minimum version 8.7.0
Transformation Utility: minimum version 8.4.3
CipherTrust Transparent Encryption
Minimum version 7.0.0
CipherTrust Transparent Encryption UserSpace
Minimum version 9.0.0
CipherTrust Vaulted Tokenization
Tokenization Manager: minimum version 8.7.1
Vaultless Tokenization Manager: minimum version 8.8.0
CipherTrust Batch Data Transformation
Minimum version 2.2.0.2816
CipherTrust Vaultless Tokenization
Minimum version 2.5.2.19
CipherTrust Teradata Protection
Minimum version 6.4.0.12
ProtectFile
Minimum version 8.10.11
ProtectV
Minimum version 4.7.3
Data Discovery and Classification Agents
Linux minimum kernel version is 2.6.
For details on upgrading agents please refer to Upgrading Agents.
Note
ODBC driver for Microsoft SQL: To connect to Microsoft SQL, DDC Agent requires the ODBC drivers to be installed on the host. If DDC cannot find a suitable agent, make sure that these drivers are installed. If necessary, upgrade them to the latest available version. Thus, if your MSSQL Server is configured with TLS 1.2 only, install the ODBC Driver 17 for MSSQL Server.
TDP Version Compatibility
Data Discovery and Classification requires TDP 3.1.5.1 or above.
If you have an existing TDP 3.1.5 cluster, you should apply the patch 3.1.5.1.
Following the TDP upgrade users are required to Configure TDP service HDFS again and also Configure TDP service Livy.
Known Issues
This section lists the issues known to exist in the product at the time of release.
CipherTrust Manager
Reference | Synopsis |
---|---|
KY-64204 | Problem: In NAE, the Permission tags such as <Encrypt/> and <Decrypt/> are not returned in the KeyInfoResponse when permission is assigned using LDAP group maps. |
KY-40418 | Problem: After migrating local CAs from KeySecure to CipherTrust Manager, the connection between KMIP client and CipherTrust Manager could not be established. The same issue also occurs when there is serial number conflict in external CAs. Workaround: Add the migrated local CA as an external CA on the CipherTrust Manager. |
KY-19730 | The CipherTrust Manager registers duplicate clients with KMIP auto registration enabled. |
KY-30178 | Problem: If you create a Local CA signed by an External CA, and attempt to install the signed CA certificate via the CipherTrust Manager web console GUI, the installation fails with the error NCERRInvalidParamValue . Workaround: Use the REST API endpoint /v1/ca/local-cas/{id}/install or the ksctl command ksctl ca locals install to install the signed certificate. |
KY-29408 | Problem:SNMPv1/v2c trap/inform sent to the SNMP management stations includes double-quotes to the configured community name. For example, if the management-station's community name is mycommunity, then the trap/inform is sent with the community name as "mycommunity". Workaround: Configure the trap receiver to add another community name surrounded by double quotes. The existing community name should remain untouched because this bug will be fixed in later releases of CipherTrust Manager. For example, NetSNMP snmptrapd should be configured with this additional line if the community name is mycommunity: authCommunity log,execute \"mycommunity\" . Other vendors trap receiver may or may not need to escape the double quotes when adding the workaround (for example, "mycommunity" instead of \"mycommunity\" ). |
KY-29059 | Problem: If you have configured a proxy host with a password, and you make any change to any setting in the web console GUI section Admin Settings > Proxy, the existing password is overwritten. Workaround: Use the REST API or CLI to make changes to the proxy hosts or proxy exceptions after initial configuration. |
KY-28934 | Problem: Upgrading from 2.1 or earlier causes existing LDAP group maps to no longer apply. Users lose membership in groups that are LDAP mapped. Workaround: Modify the LDAP connection by setting the user_dn_field to either dn or the empty string. Verify group mapping behavior by logging in with a user that is a member of a group that is mapped. Details: We recommend to leave the user_dn_field property empty in an LDAP connection unless the LDAP server does not use a user's distinguished name to test for user equality.Prior to CipherTrust Manager 2.2, LDAP connections ignored the user_dn_field property (user's distinguished name) and always used the dn attribute. Starting with CipherTrust Manager 2.2, when user_dn_field is set, the LDAP server uses the specified attribute to test for user equality. This primarily affects group maps between LDAP groups and CipherTrust Manager groups. For example, if a user's LDAP entry has cn:John Doe and the LDAP configuration in CipherTrust Manager has user_dn_field set to cn , then the LDAP group entry must have a member attribute that is exactly John Doe , not cn=John Doe for the LDAP server to consider the user part of the group. |
KY-28226 | A system with multiple network interfaces may swap device names and MAC addresses between boots. For example, eth0 has MAC address a8:a1:59:0a:f5:01 and eth1 has MAC address a8:a1:59:0a:f5:02. On the next boot, eth0 has MAC address a8:a1:59:0a:f5:02 and eth1 has MAC address a8:a1:59:0a:f5:01. Workaround: Create or modify a NetworkManager connection profile to remove the network interface name and specify a MAC address so the connection follows the hardware MAC address instead of the kernel's name which may change under certain circumstances. Example that creates a new connection that follows the MAC address using DHCP: ksadmin@ciphertrust:~$ nmcli conn add con-name cluster type ethernet ifname '' -- ethernet.mac-address a8:a1:59:0a:f5:02 ipv4.method auto ksadmin@ciphertrust:~$ nmcli conn up cluster Example that modifies an existing connection "cluster" so it removes the interface name and follows the MAC address instead: ksadmin@ciphertrust:~$ nmcli conn modify cluster ethernet.mac-address a8:a1:59:0a:f5:02 connection.interface-name '' ksadmin@ciphertrust:~$ nmcli conn up cluster |
KY-28221 | If CipherTrust Manager loses connection to its root of trust HSM, no alarms are raised and nothing is recorded on the syslog. The loss of connection means that if you reboot the CipherTrust Manager or restart its services, all CipherTrust Manager services become unavailable. Workaround: If you notice that CipherTrust Manager services are unavailable, examine the network connectivity to the HSM and resolve any issues. Once connectivity is restored, CipherTrust Manager detects the HSM and restarts services automatically. |
KY-27984 | The PQS Services page does not fetch resource information on the CipherTrust Manager GUI. The PQS service will be available with DDC in a future release. |
KY-27889 | If you upgrade from 2.2 to 2.3, an error is displayed: Job for ssh.service failed because a timeout was exceeded. Workaround: SSH access to the appliance is unaffected. This error can be safely ignored. |
KY-27805, KY-28689 | Problem: SNMPv3 requests fail with the error security service 3 error parsing ScopedPDU for users configured with AES-192 or AES-256 privacy protocol. This error is seen with SNMP applications, including SolarWinds Network Performance Manager, which use the nonstandard Cisco AES key extension implementation for 192 and 256 bit key length. CipherTrust Manager 2.7 and below only supports the Blumenthal implementation for these key lengths. Workaround: Set SNMP users to AES-128 privacy protocol instead. In CipherTrust Manager CLI and API, this value is called AES .CipherTrust Manager 2.8 will support Cisco implementation privacy protocols AES-192-C and AES-256-C. |
KY-27450 | Local Certificate Authorities (CAs) do not allow commas , in any of the fields. Workaround: Configure an External CA instead. Use a backslash \ in the Distinguished Name (DN) while creating a user if you are using certificate based login. For example, C=IN,ST=UP,L=Noida,O=Thales\,INC,OU=ENC,CN=test is an accepted value. All other printable characters are allowed, as per RFC 5280 definition of PrintableString. @ and & are also allowed, beyond the definitions of the RFC. |
KY-26867 | User password over NAE-XML does not accept the ampersand character, & . |
KY-25152 | You cannot pass in a custom SSH key via cloud init on Oracle Cloud instances for initial launch. You also cannot use cloud-init to auto-generate an initial password for the admin user on Oracle Cloud instances. Workaround: Login to the GUI to enter the SSH public key on initial access. You can also change the password for the admin user on this login. |
KY-22633 | When certificate authorities are migrated from KeySecure Classic, the revoked certificate fields do not update. Workaround: If an externally imported CA and its certificate are used in the NAE interface of KeySecure Classic, the CA is migrated as an External CA but the certificate is not migrated to the CipherTrust Manager. To use the same certificate for the NAE interface on the CipherTrust Manager: 1. Select the migrated external CA. 2. Upload the CA certificate manually by editing the NAE interface. |
KY-20310 | When setting up a new DPoD Luna Cloud HSM Service as root of trust, the command succeeds but sometimes returns a timeout error. Workaround: Disregard the timeout error. |
KY-17662 | In-place cluster upgrade does not enforce upgrading only one version. |
KY-17338 | KMIP: LDAP users cannot be set in the KMIP profile. Workaround: To use LDAP authentication, use the KMIP auto registration. |
KY-13617 | Domain scoped backup fails to restore on another domain when a key with the same name and version already exists. Workaround: To handle this issue, try either of the following:
|
KY-13343 | Uploading an existing backup results in error but is displayed in the list with status "Uploading". Workaround: Delete the backup using the "uploadID" as backup ID. |
KY-12602 | Manual page refresh is required to show the Pending CAs list. |
KY-11517 | [ProtectApp Application] The Invalid algorithm string error occurs when signing data with SHA384withRSA/PSSPadding. |
KY-11498 | When a CipherTrust Manager has a large number (for example, more than 10K) of local users, an ldap user cannot log on to it. |
KY-7289 | When migrating a KMIP application from KeySecure Classic to CipherTrust Manager, for encrypt/decrypt operations, the KMIP server always uses the ECB mode regardless of the provided mode. Workaround: For migration use cases, if Cryptographic Usage Mask is specified with the CBC mode on KeySecure Classic:
|
KY-7288 | When migrating from KeySecure Classic to CipherTrust Manager, AES-GCM encrypt/decrypt operations, AuthenticatedEncryptionTag is returned appended to CipherText. Workaround: For migration use cases, when using AES-GCM with KeySecure Classic:
|
KY-7258 | NAE and KMIP might not be connectable after cluster join. Workaround: Restart the newly joined node or at a minimum restart the KeySecure service. Restart the service either from the UI or by running ksctl services restart. |
KY-7193 | Sub-domain System Defined Groups do not show "Domain Admins", "ProtectApp Users", and "ProtectDB Users" groups. Workaround: Manually create missing groups in sub-domains. Policies for the groups are automatically created. |
KY-6383 | Users with a pipe in their user names (for example, user1|something ) cannot log on using NAE/KMIP. |
KY-3670 | Cluster join operation can fail, but rarely, leaving joining node in a bad state. Workaround: If a cluster join fails, verify that you can still log in to the joining node. If you cannot, restart the node before reattempting the join. If you still cannot log on to the node:
|
KY-2482 | (was NC-3480) Signing with EC keys does not work via the REST API. |
KY-2423 | (was NC-2318) KMIP: Result Reason may not be accurate or have enough detail. |
KY-2418 | (was NC-1780) NAE: Users cannot do a UserInfoRequest about themselves. |
KY-1397 | (was NC-2253) Last Login and Logins count are not updated for global user. |
KY-1396 | (was NC-2256) Group membership change for yourself does not take effect until after re-login. |
KY-1394 | (was NC-2260) Trying to mark a shared key deletable or exportable by non-admin user returns: NotFound error . The error should be: insufficient permissions. |
KY-1373 | (was NC-2391) Encrypt operation only generates a GetKey record. There's no indication the key was used. |
KY-1270 | (was NC-3567) User Admin should not have authority to manage system groups. |
KY-1199 | (was NC-3904) Trimming of audit table (at 10 million records) takes significant time and causes temporary performance issues Workaround: Disable audit table logging for a very active cluster. |
KY-1166 | (was NC-4098) NAE/KMIP multiport iptables rules are not replicated. Workaround: Perform NAE restart on each node. |
KY-504 | Integration with CloudHSM Cluster: Fail-over is not supported between different ENI IPs within an AWS CloudHSM cluster. |
NC-3573 | Migration: Active keys from KeySecure Classic will become Pre-Active on the CipherTrust Manager if the time zone is behind GMT. Workaround: Change the state of the keys in Pre-Active state to active from REST API or KMIP interface. |
NC-3572 | Migration: Keys in Pre-Active state on KeySecure Classic cannot be used for Crypto operations on the CipherTrust Manager. Workaround: Change the state of the keys in Pre-Active state to Active using KeySecure Classic's Console (UI) or KMIP interface before taking the backup for migration. Alternatively, after migration, change the state of the keys in Pre-Active state to Active from the CipherTrust Manager REST API or KMIP interface. |
NC-2063 | If a user is deleted (or LDAP connection name changes), they fail to display in the keys table. |
CipherTrust Cloud Key Manager
Issue | Synopsis |
---|---|
KY-30464 | After migration from the CCKM Appliance, incorrect "Directory ID" is displayed in the details view of the Azure Key Vaults page. Workaround: Refresh the Azure key vault. |
KY-27583 | CCKM Scheduler: A key rotation or key refresh process remains stuck, and all new scheduled processes go into the scheduled state. This happens when the scheduler expires due to some network issues or reboot of the CipherTrust Manager. The scheduled job remains in the running state. Workaround: Delete the running and scheduled jobs from the API playground, and retry. |
KY-27499 | If you update the hostname for a Google Cloud EKM endpoint, the URI format is invalid, and Google KMS cannot use the URI to perform wrap or unwrap operations. Workaround: Manually update the URI in Google Cloud KMS to the following format: https://<updated_host_name>/api/v1/cckm/ekm/endpoints/<endpoint-id> |
KY-17213 | When a CipherTrust Manager key is created using an auto rotation schedule on AWS cloud native key, its owner is set to "Global". Workaround: A CipherTrust Manager administrator can assign the ownership of the key to a desired user in the CCKM Users group. |
KY-42033 | Unable to use the key version created through CCKM for Azure SQL EKM. This issue will be resolved in CipherTrust Manager v2.8.0. |
CipherTrust Database Protection
Issue | Synopsis |
---|---|
PDB-3293 | If datatype of a column changes from char family to blob after migration, the Return replacement value option for the Error Replacement feature does not work. |
CipherTrust Data Discovery and Classification
Issue | Synopsis |
---|---|
KY-27482 | A scan fails with "Remediation could not be done" message and log contains [Scan-Launcher] Error while validating the scan name - Error timeout remediation .Workaround: If this error persists, you need to restart CipherTrust Manager services to be able to run this scan with remediation. |
KY-28125 | Scans with more than 400K Sensitive Data Objects may fail with "Internal Error". Workaround:
|
KY-27855 | "Something went wrong" message when generating a report with many scans.Report with many scans cannot be generated due to timeout in the requests between CM and the TDP servers. Workaround:
|
KY-27102 | Reports created before upgrading to CM 2.4 do not show Last run and Duration. The upgrade to CM 2.4 resets the Last run and Duration fields for the existing reports. |
KY-27095 | The PostgreSQL Agent selection fails as if there were no compatible Agent, or as if no compatible Agent could reach the Data Store. DDC does not support the scram-sha-256 authentication method.Workaround: Create the user with 'md5' password encryption by specifying the hash of the password at user creation, as in CREATE USER <user name> PASSWORD 'md5<password hash>'; For example, to create a user named 'u0' with the password 'foobar' (md5('foobar') = ac4bbe016b808c3c0b816981f240dcae ) use the following command: CREATE USER u0 PASSWORD 'md5ac4bbe016b808c3c0b816981f240dcae'; |
KY-26870 | This error on toast is displayed when accessing a report: "The report template is configured with a scan execution that can no longer be found" This happens when the scan does not find any data object with sensitive data. |
KY-26837 | Currently, all the Data Objects coming from an Exchange Online datastore are cataloged as "Other" in the extensions charts in the Scan tab. |
KY-26650 | Missing fields - Sensitivity Level and Location -in the Data Store tab of reports.This happens when the user edits a scan. For unedited scans Sensitivity Level and Location are shown properly. |
KY-24205 | The Agent selection will fail if no compatible Agent is found, or if no compatible Agent can reach the Data Store, or if the credentials provided do not grant access to the Data Store. Solution: For possible solutions, check the following:
|
KY-23454 / KY-22666 | DDC cannot scan files that are bigger than 512MB for AWS S3 and Azure Blob Data Stores Scanning large files (larger than 512 MB) on "remote (cloud)" Data Stores fails with an "error processing scan" error. Those file are marked as 'inaccessible' on the report or the scan fails with an "error processing scan". The user has no way to identify the issue from DDC. Possible Workarounds:
|
KY-22908 | All new scan executions fail with 'internal error' If all your scans finish with an "internal error", check whether your data allowance has been completely exhausted. |
KY-22407 | The user cannot launch Oracle/DB2 scan if the schema or table was created with uppercase and DDC is configured with lowercase. Workaround:Set the target path in uppercase. |
KY-21981 | Postgres tables without primary keys are not completely scanned DDC can only scan Postgres tables if they have at least one primary key defined. Workaround: Configure at least one primary key in the tables and run the scan again. |
KY-30760 | In Legacy Reports, Data Objects may not be listed in reports when there is a huge number of matchesNCERRInternalServerError: unexpected error displayed on the DataObjects report tab. This means that the Hadoop cluster has taken too long (more than 30 seconds) to retrieve the list of Data Objects in the report. Workaround:: Re-run the Scan and generate a new (non-Legacy) Report. |
KY-16274 / KY-16598 | A scan with one or more custom infotypes fails with "Internal Error" This may happen when a custom infotype contains an expression with a format too complex to interpret. Workaround:
|
KY-9098 | DDC cannot automatically assign an Agent for empty NFS shared folders. You cannot create an NFS type Data Store with an empty folder. When an empty folder is shared over NFS and scanned by DDC, the probe fails. Workaround: Introduce any document in the empty folder and manually trigger the Agent selection. Click the "Find Agent" button to relaunch the Agent selection. The button is visible when you click the ellipsis (overflow) button next to the data store. |
KY-9104 | Scan fails with “Error scanning. The target for Data Store XYZ cannot be accessed.” This happens when the Data Store is created and an Agent is selected for the Data Store but then the Agent is no longer available and there is no way to select a new Agent from the UI. Workaround: Edit the Data Store and edit any configuration parameters so the DDC Server automatically searches for a new suitable Agent. |
KY-9399 | The XVA file contains a data object that is was reported when it should not. The XVA file format is not correctly handled. After an XVA file is scanned and the report is generated, an additional data object in the Data Objects tab is displayed in the UI. You should ignore it. |
KY-8990 | Scheduled scans and those launched manually via ‘run now’ only start after X hours. If an Agent and server have the wrong time set, DDC’s ability to schedule scans or to start them immediately when they are manually launched from the UI or API will be affected and the scan start may be delayed. Workaround: Configure an NTP server for DDC and all Agent hosts. |
KY-24205 | A Data Store never transitions to a “ready” state and displays “A valid agent could not be found”. The Agent selection will fail if no compatible Agent is found, or if no compatible Agent can reach the Data Store, or if the credentials provided do not grant access to the Data Store. Solution: For possible solutions, check the following:
|
None of the clustered nodes responds to requests to DDC. DDC is only active in one of the CipherTrust Manager nodes. Requests sent to any other nodes will return this error. This will be improved in next releases. Solution:
| |
KY-13618 | Sometimes, a scan cannot be resumed after the CipherTrust Manager is restarted. When a scan is paused before restarting the CipherTrust Manager, sometimes, the scan is shown as RUNNING after the restart, when in fact, it is stalled. Workaround: Restart the scan execution after restarting the CipherTrust Manager. Note that the progress of the previous scan will be lost. |
ProtectFile
Issue | Synopsis |
---|---|
KSCH-573 | Encryption rules cannot be modified to reset values for include and exclude extension parameters. |
KSCH-568 | Encryption rules do not prevent specifying both include and exclude extension parameters simultaneously. |
KSCH-567 | Modifying a file level encryption rule to set the “isRecursive” flag does not return error. |
KSCH-564 | Non-encryptor clients cannot be removed from a Linux cluster while a cryptographic operation on an encryption rule is in progress. |