Fortanix Data Security Manager (DSM) SaaS 4.29 comes with some exciting new features, improvements, and resolved issues.
NOTE
This release is for SaaS only and is not available for on-premises installations. Updates in this release will be part of a future on-premises release.
1. New Features
- Added Filesystem encryption policy administration to Fortanix DSM security objects. (JIRA: ROFR-4866).
You can view the File Decryption Policy tab under Security Objects for the relevant security object only, not for all security objects.
Figure 1: Access File Decryption Policy Tab
For more details, refer to User’s Guide: File System Encryption for Linux.
2. Enhancements to Existing Features
- Fortanix DSM will now retrieve and authenticate Online Certificate Status Protocol (OCSP) responses to verify the revocation status of certificates used to authenticate application (app) connections (JIRA: PROD-7802).
In case both OCSP and Certificate Revocation List (CRL) verifications are present, OCSP verification will take precedence.
Figure 2: OCSP in Certificate
For more details, refer to User’s Guide: Authentication.
3. DSM-Accelerator Bug Fixes
-
DSM-Accelerator Webservice
- Fixed an issue where keys cached in Fortanix DSM-Accelerator Webservice for one application (app) could be accessible by another app within the same account (JIRA: PROD-8386).
4. Client Improvements
- Added quorum policy approval support for the Fortanix DSM PKCS#11 client (JIRA: PM-226). For more details, refer to Clients: PKCS#11 Library.
5. Bug Fixes
- Fixed an issue where users could not update the Key Access Justification policy at the cryptographic space level (JIRA: PROD-8456).
- Fixed an issue where the Key Rotation policy failed to rotate keys due to pending scheduled rotation with unrotated keys blocking the scheduler (JIRA: ES-344).
6. Known Issues
- When you create a Trusted CA Administrative (Admin) App in Fortanix DSM user interface (UI) with the Verify client certificate revocation status check box selected, the selection status is not saved after the Admin App is created. (JIRA: ROFR-4916).
Workaround: Create the Trusted CA Admin App using the Fortanix REST APIPOST /sys/v1/appsand add“check_revocation":truein the body of the request.The UI will now create the Trusted CA Admin App with the Verify client certificate revocation status check box as selected.{ "name": "checked trusted ca from postman", "description": "", "app_type": "default", "interface": "default", "oauth_config": null, "ip_address_policy": "allow_all", "role": "admin", "credential": { "trustedca": { "ca_certificate": "MII..", "check_revocation":true, "subject_general": { "directory_name": [ [ "2.5.4.6", "IN" ] ] } } } }Figure 3: “Verify client certificate revocation status” Check Box Selected
- If a wrapped security object belonging to a DSM group with a Quorum approval policy added but the Cryptographic Operations option in the policy is not selected, is imported into DSM, the UI calls the incorrect API
sys/v1/approval_requeststo import the wrapped security object. (JIRA: ROFR-4886).
Workaround: Use the API/crypto/v1/unwrapkeywith the following request body:{
"key": {
"kid": "<wrapping_key_ID>"
},
"alg": "<wrapping_key_type>",
"obj_type": "<Key_Type>",
"wrapped_key": "<wrapped_key_material>",
"name": "<Import_Key_name>",
"group_id": "<group_Id>",
"key_ops": [
"ENCRYPT",
"DECRYPT",
"WRAPKEY",
"UNWRAPKEY",
"DERIVEKEY",
"MACGENERATE",
"MACVERIFY",
"APPMANAGEABLE",
"EXPORT"
],
"mode": "<wrapping_mode>"
} - When you edit the starting time of a Key rotation policy for a security object with the value as single digit time, for example, 01:00 am, it shows an error “Invalid date/time selected. Please make sure you filled in a valid 12-hour time”(JIRA: ROFR-4786).
Workaround: Re-enter the rotate start time by removing the “0” before the single digit time and enter a new time (e.g. 01:00 am to 2:00 am). - Unable to create an LMS key with the following height combinations of 20 (JIRA: PROD-8248).
- 5, 20, and vice versa
- The hyperlink color for the field “Follow the instructions in” in the “Add Instance” form for Google Workspace Client-Side Encryption (CSE) still reflects the old link color value (JIRA: ROFR-4789).
Figure 4: Client ID of CSE Application
- The sync key API returns a “400 status code and response error” if its short-term access token expires during the synchronization of a group linked to AWS KMS (JIRA: PROD-3903). Workaround: increase the timeout of the temporary session token beyond the expected duration of the sync key operation.
-
excludedoes not work in theproxyconfiguration for operations such as attestation (JIRA: PROD-3311). - Rotating a GCP BYOK key to a pre-existing Fortanix DSM-hosted key (Rotate to DSM key) is not supported (JIRA: PROD-6722).
Workaround: You can manually copy an existing AES 256 key from a normal DSM group to a GCP-backed group. This key automatically becomes the currently active crypto key version in the GCP key ring. - The “Rotate linked key” feature fails with an error for keys in an externally backed group where the external entity is a Google Cloud Platform key ring (JIRA: PROD-6828).
Workaround: You must first manually rotate the source key in the regular DSM group and then copy the rotated key to the GCP group. - If an Azure key is rotated and then soft-deleted, only one version of the key is soft-deleted (JIRA: PROD-6947).
Workaround: Perform a key scan in DSM to synchronize the key state with Azure. - The
createoperation for security object creation does not work for the Azure Managed HSM plugin (JIRA: PROD-7078). - The retry mechanism does not work as expected in the DSM-Accelerator Webservice (JIRA: PROD-7068).
- Copying an RSA or EC key from a normal DSM group to an AWS KMS-backed DSM group does not work as expected and results in an error (JIRA: PROD-7787).
Workaround: Export the RSA or EC key from the normal DSM group and import it into the AWS KMS-backed DSM group.
Comments
Please sign in to leave a comment.