Software Trust Manager

We have enhanced the frontend of DigiCert ONE to ensure the latest account settings are consistently loaded across all pages upon loading. This update pertains to the following features:

In this release, we have increased the synchronization window from 7 days to 14 days for Cert certificate orders.

This update reduces synchronization failures and better aligns with business timelines.

In DigiCert ONE, all Software Trust Manager pages (with the exception of Account settings and Certificate details) have been updated with improved chevron functionality.

We resolved an issue in the Certificate list page. Previously, when a user applied a start date filter, and then refreshed the page, the filter was not retained. Instead, all available certificates were displayed, ignoring the selected filter criterion.

With this release, the system now retains and applies the start date filter correctly after a page is refreshed.

In this release, we have:

We resolved an issue for users who attempted to re-upload an SBOM file. Previously, users would encounter a name validation error when attempting to re-upload an SBOM file, even when the file name was valid.

This update ensures the correct workflow to re-upload an SBOM file with a valid file name.

We resolved a permission issue with uploading SBOMs. Previously, the Upload SBOM button would activate for users who simply had the Manage threat detection permission. However, to fully upload and analyze an SBOM file, users also need to have the Run threat detection permission.

With this update, the Upload SBOM button will only activate for users who have both the Manage threat detection permission and the Run threat detection permission.

We have updated the workflow for deleting users. Previously, the automated job that would de-provision users would only remove users from user groups.

With this update, the automated job will fully remove users from all associated resources, including keypairs, certificates, teams, and release windows. This job will run every 6 hours.

This update provides a more robust de-provisioning process for deleted users.

We added Start date and End date columns to the table views in the Certificates and CertCentral orders sections.

This update allows users to view certificate expiry details directly from the table without having to select individual certificates or log into CertCentral.

To complement the Resolved timeout issues bug fix, we have introduced a new API endpoint, api/v2/signatures.

The V2 version of this API offers limited filters (accountId, signatureType, signatureStatus), a sorter (createdOn), and attributes aligned with DigiCert ONE.

This updated functionality prevents performance impacts on the database due to large volumes of signature data. The V1 APIs will remain available to ensure backward compatibility.

We resolved intermittent HTTP 408 timeout issues for the /signingmanager/api/v1/signatures endpoint, which affected certain accounts since October 23, 2024.

The timeout issues were caused by database connection management problems, causing queries to fail under specific conditions.

This bug fix relates to the New API endpoint enhancement.

We detected an issue with updating release windows, including the release duration.

This issue has been resolved, ensuring the correct workflow to update release windows.

On the Create GPG keypair page, the Create button would incorrectly activate, even if the user had not entered the required information.

With this update, users must first enter the required information before the Create button activates.

On the Request to delete keypair page, spacing has been adjusted between the Approvers label and the selected users.

On the Create release page, there was an issue with properly displaying keypair IDs after the user selected a different team.

This issue has been resolved, ensuring the correct workflow to create a release.

In the Import keypair page, the Click or drag a file to upload field would not behave as expected in regards to the browse files window.

This issue has been resolved, ensuring the correct workflow to upload a keypair via the browse files window.

This release includes enhanced SBOM management features to help users monitor and address software vulnerabilities and license issues, including:

To learn more, see Upload and analyze an SBOM file.

We’ve added support for keypair rekey automation to streamline certificate replacement workflows and enhance crypto-agility for users.

This update includes:

We’ve introduced audit logging for automatic certificate renewal failures in CertCentral.

Automatic cert renewal failures will now be recorded in the audit log, including the reason for the failure. This information will help users to quickly identify and troubleshoot issues without needing to contact DigiCert Support.

We have updated the certificate template for private code signing certificates by adding a new field. The "include": "no" field has been added to the Extended Key Usage (EKU) section. Adding this field ensures that certificates issued from a private trust can exclude the Extended Key Usage field.

By retaining only the Digital Signature (80) value in the Key Usage field and removing other values, the certificates will now have a more streamlined Key Usage with just the Digital Signature (80) included.

This update allows code signing certificates to be issued without the Extended key usage field.

The List team resources API endpoint has been updated to only list resource types that are associated with teams.

Previously, this endpoint would display all resource types, regardless if those resources were associated with teams. This issue would cause inconsistencies with the List available resources endpoint.

This issue has been resolved, ensuring the correct workflow to display only resources associated with a specified team.

We resolved an issue in the List available resources API endpoint where users would encounter an invalid_input_field error for RELEASE_WINDOW, KEY_ROTATION, and USER resource types.

This issue has been resolved, ensuring the correct workflow to manage these resource types in the API.

We resolved an issue regarding key pair restrictions. Previously, users in a specified group could neither view nor use keypairs, even if the keypair was correctly restricted to that group.

This issue has been resolved, ensuring the correct workflow to restrict and use keypairs.

We are introducing enhanced control over user / member capabilities for teams, allowing team and account leads to better manage user / member permissions.

This change enables more access control, ensuring that users / members only perform specific critical operations, based on their configured roles and team settings.

This release contains the following high-level updates:

To learn more, see:

We resolved an issue involving adding users to a keypair rotation.

This issue has been resolved, ensuring the correct workflow to add users to a keypair rotation.

We resolved an issue involving selecting an expire date while creating or updating a keypair, a GPG keypair, or a team.

This issue has been resolved, ensuring the correct workflow to select an expiry date.

In an upcoming release, we will be updating the team management process by focusing solely on individual user assignments.

To support this update, we will be making the following changes in this release:

A manual database patch is now available to support the upload of an Apple public certificate to replace a keypair.

This update allows users to map and replace an existing keypair certificate with a newly uploaded Apple public cert by manually inserting the certificate into the database.

For setting up private trust anchors, we have removed the requirement for CA and ICA certificates to have the Digital Signature key usage.

This update allows for more flexibility in certificate hierarchies, particularly for users who use the IMX8 NXP hierarchy.

This update resolves an issue where users were blocked from importing CA and ICA certificates that do not include "Digital Signature" in their private trust hierarchy.

Note: For public trust hierarchy setups, this requirement does not change.

We have made several minor DigiCert One enhancements to improve the overall user experience across all DigiCert products.

To address reported vulnerabilities, we have upgraded certain client tools and software.

We resolved an issue involving incorrect sizes / curves being displayed.

In the Account settings page, under Keypairs the Ed25519 size / curve would incorrectly display, even though EDdsa was not listed as a selected algorithm.

This issue has been resolved, ensuring the correct workflow to display valid sizes / curves for selected algorithms.

We resolved an issue regarding unnecessary pop-up messages.

When creating a test keypair without generating a certificate, a pop-up message would display describing expiry dates. For test keypairs, there is no corresponding expiry flow, rendering the pop-up message as unnecessary.

This issue has been resolved, ensuring the correct workflow to create test keypairs.

We resolved an issue regarding notifications not being sent for revoked API keys.

Without receiving these notifications, users attempting to fetch authorizations would encounter a 403 error in Software Trust Manager logs.

This issue has been resolved, ensuring the correct workflow to receive notifications on blocked renewals.

We resolved an issue where deleted keypairs would inaccurately display in error messages and logs. Instead of displaying the deleted keypairs' alias, the error message and log would display the keypair ID.

This issue has been resolved, ensuring the correct information is displayed in error messages and logs.

We have introduced different service tiers that enable users to select the tier that best meets their threat detection needs.

Currently, there are two types of service tiers, a free service (named Software Assurance Service) and a paid service (named Supply Chain Compromise Risk Assessment Service).

To learn more, see Software binary analysis (SBA) features.

Version 1.53.0 of SMCTL introduces support for both the Software Assurance Service and Supply Chain Compromise Risk Assessment Service service tiers. This version of SMCTL provides a new --threat-summary flag for the smctl scan rl-scan command.

We resolved an issue involving the creation of test keypairs with HSM storage. In this scenario, users were able to select HSM as the key storage for test keypair types. This was an issue because test keypairs should only be stored on disk, not on HSM storage.

This issue has been resolved, ensuring the correct workflow to create test keypairs.

We resolved an issue involving deleting keypairs assigned to a team. In this scenario, after a keypair was deleted, the keypair would still be associated with the team.

This issue has been resolved, ensuring the correct workflow to delete a keypair assigned to a team.

We have introduced support for RSAPSS with SHA-256 for HSM signing.

With this enhanced cryptographic signature scheme, users will benefit from stronger security and improved protection against signature forgery.

Note: Software Trust Manager supports NoneWithRSAPSS on Disk, but not on HSM.

We resolved an issue where users who attempted to extend an expired GPG keypair would receive an error message (“GPG Keypair is in status EXPIRED and cannot be updated”).

This issue has been resolved, ensuring the correct workflow to extended expired GPG keypairs.

As part of a larger effort to update the rekey workflow, in this release, we are introducing automated workflows for GPG keypair expiry management.

To enhance security and efficiency in key manager, this update includes:

To learn more, see GPG keypairs.

The updated SMCTL supports the creation and editing of GPG keypairs with expiry flags.

The following new fields have been added:

We resolved an issue relating to updating GPG keypairs via SMCTL. While there was no issue when updating via DigiCert ONE, in SMCTL users would receive a 400 error.

This issue has been resolved, ensuring the correct workflow to update a GPG keypair via SMCTL.

We have implemented a new integration method for DigiCert single login users. This method will automatically pull your CertCentral API key, provided that your CertCentral account is already linked to your single login account. This method is easier than existing methods that require you to provide your username and password or API key for your CertCentral account.

We resolved an issue affecting users with multiple accounts.

Previously, if a user was on the Keypair list page, then switched accounts, and then selected the Create keypair button, the user would receive an error message.

This issue has been fixed, ensuring the accurate workflow to create a keypair when switching accounts.

We resolved an issue affecting users with multiple accounts.

Previously, if a user was on the Account settings page, and then switched accounts, the page would display a fixed set of settings, which would throw an error if a user attempted to edit the page.

This issue has been fixed, ensuring the accurate workflow to view and edit data when switching accounts.

We resolved an issue relating to creating a release for threat detection purposes.

Previously, if a user was creating a release and teams were disabled, then the Create button would be faded out and unclickable.

This issue has been fixed, ensuring the accurate workflow to create a release, despite having teams disabled.

We have identified and corrected an issue affecting keypair generation via DigiCert ONE when teams are disabled and a user has the Create keypair permission, but not the Manage keypair permission. Previously, keypairs created in this scenario were automatically restricted to the user who created them.

With this update, keypairs generated under these conditions will now be categorized as Open, making them accessible to all users within the account. To restrict access, users can utilize the --restricted flag during keypair creation.

We have identified and corrected an issue affecting keypair access via DigiCert ONE.

Previously, when creating a keypair, if a user selected a team first, followed by selecting Open access, then the keypair would be restricted to the team.

This issue has been fixed, ensuring the accurate workflow to create an open keypair.

We have identified and corrected an issue affecting keypair creation via DigiCert ONE.

Previously, if a user enabled Teams and Keypair profiles, then created a keypair using the keypair profile, and then selected Open access, the Team dropdown would still display, but the Create keypair button would be disabled, forcing the user to create a restricted keypair.

This issue has been fixed, ensuring the accurate workflow to create open keypairs.

We have identified and corrected an issue relating to the description of restricted keypairs.

Previously, there were discrepancies in the information displayed relating to teams, users, and user groups in the Keypairs detailed page, specifically the Access section. In this section, users and user groups (which were mapped from disabled teams) were inaccurately displayed in the Keypairs detailed page.

With this update, only the team associated with the keypair will display in the Keypair detailed page.

We enhanced our delete keypair workflow. This enhancement enables you to delete keypairs from the keypair details page, in addition to the keypair list page.

We enhanced our keypair profile and create keypair workflows to allow for the selection of an alternative quantum-safe algorithm, Secure Lightweight Hash-based Digital Signature Algorithm (SLHDSA). SLHDSA is an innovative approach to cryptographic security, designed to offer robust protection with minimal computational overhead. It leverages lightweight hash-based techniques to ensure security while optimizing performance, making it ideal for resource-constrained environments. With SLHDSA, you can achieve efficient and secure digital signatures that are resistant to both classical and quantum attacks.

We resolved an issue where keypair actions for deleted standard and GPG keypairs were still accessible to users. Previously, various keypair actions remained visible and clickable for deleted keys, leading to backend errors. With this release, keypair-related actions are removed for deleted GPG and standard keypairs.

We fixed an issue where the GPG smart card daemon (SCD) showed version 1.3 in Software Trust Manager, but users were downloading version 1.4. The Client tool repository now correctly displays version 1.4.

We have enhanced the team management functionality to allow users to see and modify how projects are associated with teams. Teams can now be mapped to one or multiple projects, provided the projects have a status of In progress or Paused. You can change project-team associations via Software Trust Manager or the API via Create and Edit team workflows provided that you have the Manage all teams or Manage my team permission.

We released version 1.50.0 of SMCTL. This version of SMCTL contains enhancements for handling the new team to project management workflows mentioned above.

Users can now download the GPG keyring associated with a subkey that is used for signing and is assigned to their team, even when the master key is not assigned to their team

We identified issue where attempting to download the Software Trust Manager AIX Clients (portable tar.gz) resulted in an error: File wasn't available and Release smtools-aix-ppc64.tar.gz not found. We resolved this issue by releasing version 1.50.0 of Software Trust Manager AIX Clients (portable tar.gz).

Multi-Factor Authentication (MFA) is no longer required to access the GET Teams APIs. This change ensures easier access to these endpoints while maintaining security protocols. The affected endpoints are:

We identified an issue where Disk option was showing undefined while creating a keypair with keypair profile. This issue has been fixed and works as expected.

We identified an issue where users were blocked from changing the keypair storage method when updating keypair profiles. This issue has been fixed and works as expected.

Account users with Manage keypair permission can now delete standard and GPG keypairs stored on HSM devices. Deleting a keypair frees up an HSM slot, allowing you to store a new keypair in its place.

We have released version 1.49.0 of SMCTL. This version of SMCTL contains enhancements for handling special characters in sign commands, but it still does not support all characters. To avoid errors, remove unsupported characters from file paths before attempting to sign:

We fixed an issue where clicking on any page number in the Trust Anchors list page, redirected users backto Page 1. Pagination now works correctly, allowing you to navigate through all pages as expected.

We have fixed an issue where the expiry information for dynamic keypairs was not preserved when these keys were refreshed via API or manually refreshed. Expiry information is now maintained correctly after refreshing dynamic keypairs.

You now have the option to perform ECDSA signatures without ASN1 decoration. From SMCTL version 1.48.0 onward, the smctl sign sign-hash command will support a new flag --non-decorate-signature. Previously, all ECDSA signatures included ASN1 decoration. This enhancement is crucial for supporting COSE signatures in the SCITT framework and other platforms and can be used. This change marks the first step towards fully enabling signatures tailored for SCITT.

We identified a bug that was introduced when keypair expiry was released earlier this year. The bug occurred when a dynamic test keypair was updated, this action resulted in the following error: Expiry type NO_EXPIRY is not allowed for test keypairs. This issue has been resolved.

We added a new feature to allow users with Manage all teams permission to delete any team in the account. When deleting a team, users and any resources such as keypairs, keypair profiles, projects, releases, and threat detection scans associated with the team will be disassociated with the team and become available to assign to an existing team.

We identified an issue where when teams were enabled on the account, users with Manage all teams and Generate keypair permission were able to generate keypairs and assign it to any team in the account. This issue has been resolved and only users with Manage all teams and Manage keypair permission can generate keypairs for any team within the account.

We identified an issue where GPG test key generation was incorrectly throwing an expiry error, preventing the creation of test keypairs. This has been resolved, and test keypairs can now be generated without encountering expiry restrictions.

We identified an issue where users who were assigned to a user group, and then deleted in Account Manager were still displaying in the user group. We have fixed this issue, and the deleted users will no longer be displayed in user groups that they previously belonged to.

We have improved our email notification system. Now, only the users who need to know will receive specific updates about keypairs and certificates. Review the changes below:

Keypair expiry email notifications will be sent to the following recipients:

Certificate expiry email notifications will be sent to the following recipients:

Certificate auto-renewal email notifications will be sent to the following recipients:

Certificate auto-renewal blocked email notifications will be sent to the following recipients:

We identified an issue where users were incorrectly shown the Close release option in Software Trust Manager, which resulted in an error: <User ID> does not have permission to close release. This issue has been fixed:

We fixed an issue where users with the Developer user role, or with Create keypair permission but without Manage keypair permission were directed to a Page not found error after creating a keypair. Now, these users will be correctly returned to the keypair list page.

We have added a fallback mechanism for OCSP requests to ensure that users can import ICA certificates in the Trust anchor tab in Software Trust Manager. Now we will check the certificate status with SHA256 and if it fails, our system will retry using SHA1 to ensure compatibility with OCSP services that still use SHA1. This update helps maintain secure certificate validation and ensures smooth importing of Root and Intermediate certificates.

We identified an issue where users who were assigned to a user group, and then deleted in Account Manager were still displaying in the user group. We have fixed this issue, and the deleted users will no longer be displayed in user groups that they previously belonged to.

On February 7, 2024, we enhanced our keypair creation workflows to support quantum-safe Machine Learning-based Digital Signature Algorithm (MLDSA), however generating a code signing certificate with an MLDSA keypair was not possible. As of this release, MLDSA certificates can now be generated.

We have enabled expiry for standard keypairs to enhance crypto agility and improve security. Standard keypairs can now be set to expire on a specific date, upon certificate expiration, or remain non-expiring as before. Setting expiry dates help maintain security, ensures compliance with industry standards, and preserves trust in your code's integrity. This update provides more flexibility in managing keypair lifecycles.

The initial implementation of the smctl sign command was designed to support signing multiple files from an input folder. At that time, we chose not to make the command fail immediately if signing one of the files failed, anticipating this requirement in future updates. We have now introduced three flags to improve the bulk signing procedure, these flags are: --exit-non-zero-on-fail and --fail-fast.

Previously, team names in drop-down menus were listed in order of creation. As of this release, team names will be listed alphabetically to enhance the user experience.

We resolved an issue affecting users with multiple accounts.

We resolved an issue affecting users with multiple accounts.

We resolved an issue relating to creating a release for threat detection purposes.

We have identified and corrected an issue affecting keypair generation via DigiCert ONE when teams are disabled and a user has the Create keypair permission, but not the Manage keypair permission. Previously, keypairs created in this scenario were automatically restricted to the user who created them.

We fixed an issue where dynamic keypairs were incorrectly expiring after 30 days. Dynamic keypairs are periodically refreshed and should not expire. This issue has now been resolved for all active dynamic keypairs. However, previously expired dynamic keypairs cannot be restored.

We fixed an issue where keypairs not associated with a team were still appearing in the team field when updating key rotations. Now, you will only see and be able to select keypairs that are associated with the team to which the key rotation belongs.

We have identified and corrected an issue affecting keypair access via DigiCert ONE.

We have identified and corrected an issue affecting keypair creation via DigiCert ONE.

We have identified and corrected an issue relating to the description of restricted keypairs.

Previously system users had limited visibility into account information. To better assist the accounts they support, we have extended their permissions to allow them to view:

For simplified resource management and ease of reference, the following user flows have been implemented based on whether teams are enabled or not.

When teams are disabled on the account, users with:

When teams are enabled on the account, users with:

We have updated keypair download format to conform to RFC 7468 standards.

Previous format:

-----BEGIN EC PUBLIC KEY-----
<content>
-----END EC PUBLIC KEY-----

New format:

-----BEGIN PUBLIC KEY-----
<content>
-----END PUBLIC KEY-----

We identified that the PKCS11 library was unintentionally excluded in version 1.46.0 of the Windows Clients Installer. We have rectified this issue without altering the version number. If you've already installed this version, download it again to ensure you have access to all required client tools.

We added a JCE library to our Client tool repository. JCE is part of the Java Development Kit (JDK) that facilitates digital signing of Java Archive (JAR) files and related artifacts. Using JCE for signing is preferred over PKCS11 and KSP library options due to its compatibility with various operating systems (Windows, Linux, macOS, Solaris, and AIX) and Java architectures, including 64-bit, 32-bit, and ARM processors.

Our client tool packages were updated with the latest version of ReversingLabs' scanning tool called rl-deploy to improve accuracy and consistency between Software Trust Manager and ReversingLabs' portal.

In the release creation workflow, we've updated the default setting to display only keypairs with associated certificates, enhancing user experience. Users retain the flexibility to view all keypairs by deselecting the filter box if needed, ensuring seamless navigation. This change aims to streamline selection processes while providing greater clarity and efficiency.

We have rectified an error in the import certificate workflow where the "Certificate alias" field was incorrectly labeled as "Keypair alias"; it now displays accurately. This fix ensures clarity and accuracy in the workflow for all users.

We updated translation files to enhance multilingual support across the platform, excluding Japanese. These updates ensure improved clarity and consistency for users worldwide. We remain committed to delivering a seamless experience for our diverse user base.

We became aware that user's were receiving the following error: "Attempt to create duplicate resource. Please check data provided." when attempting to create or update a user group in Software Trust Manager and the API. We have resolved this issue and users should be able to create and update user groups as expected.

Our client tool packages were updated with version 1.3.0.0 of ReversingLabs' scanning tool called rl-deploy to improve accuracy and consistency between Software Trust Manager and ReversingLabs' portal.

When teams are enabled, and a member of the team generated a keypair via SMCTL, the keypair was generated with open access instead of restricted to the team. This has been corrected and when teams are enabled and a user generates a keypair via SMCTL, the user will be required to provide the Team ID so that the keypair's use is restricted to that specific team.

We identified that the excel report generated after downloading via the Most recent 10,000 signature logs method did not include relevant metadata. We fixed this issue and relevant metadata should show in these reports.

When a user ran the smctl healthcheck command and no signing tools were found in their system, the log files listed the following error message: "Error Tools cannot be null." We updated the error message to: "Unable to detect compatible signing tools." to improve the clarity that the user needs to install third-party signing tools.

When a user runs the smctl windows certsync command without providing environment variables first, the log files listed a long string of information. We updated the error messages to be more concise: "Error occurred while trying to connect to service. No Host provided in request URL."

You may have been notified about an new version of Software Trust Manager client tools; however, if you have already downloaded version 1.44.0 of the Software Trust Manager tools, there is no need to update your client tools to the latest version as the changes made do not affect Software Trust Manager users.

As an ongoing effort, we have improved the scalability and reliability of Software Trust Manager. These updates ensures seamless operations even during peak usage and provides our users with a more efficient and robust user experience.

We have addressed the issue of slow downloading for signature logs via the latest 10,000 option as well as the archived signature logs workflows. This change optimizes the download speed and prevents timeout errors.

Previously when users downloaded an SBOM report, Software Trust Manager showed no indicator that the download was in progress. We have enhanced this workflow by disabling the "Download" button after it is clicked and display a spinner to assure users that the download is in progress. This enhancement also prevents users from unnecessarily clicking the download button multiple time and duplicating the SBOM reports.

Deleted certificates were still listed in Windows certificate store even after running the smctl windows certsync command. We have fixed this issue and deleted certificates should no longer display in the certificate store after running the smctl windows certsync command.

The 32-bit and 64-bit CSP library had an issue preventing users from using SHA1 digest signature algorithm. This has been resolved and users should now be abled to use SHA1 digest signature algorithm via the CSP library. This change was made on the server side and does not require you to upgrade to a newer version of the CSP library.

We have developed a 32-bit version of our PKCS11 library. This version allows users to utilize our PKCS11 tool on 32-bit Windows and Linux systems, enabling them to sign Java applications in a 32-bit environment. This new version is available for download from Software Trust Manager client tool repository.

It is mandatory to select a certificate profile when generating a certificate. Previously, users needed both Generate certificate and View certificate profile permissions to successfully generate a certificate. We have streamlined the workflow by removing the requirement for the View certificate profile permission when generating a certificate. Users can now generate certificates and select certificate profiles if they only have the Generate certificate permission, this change reduces errors for users with custom roles, seeing as it is not intuitive that the 'view certificate profile' permission was required for certificate generation.

Previously, SBOM signing commands only supported keypair IDs. Now, we've expanded support to include keypair aliases as well. Keypair aliases offer users a more intuitive and user-friendly option, making SBOM signing commands easier to remember and use.

Previously, users encountered errors when adding any characters other than letters, numbers, ., _, or - in Release names. This error blocked users from creating a release but did not advise which characters were allowed. In response, we have introduced a tooltip within the Create release workflow, providing users with guidance on the allowed characters and format.

We have resolved an issue where attempting to view keypairs assigned to your team during the Release creation process which resulted in an error. Now, users can seamlessly select keypairs associated with a team without encountering errors. This improvement ensures a smoother experience when creating Releases, with all relevant keypairs readily available for selection.

We identified an issue where users were unable to enable specific key algorithms in Account settings. This problem has been resolved, and the workflow should now function as expected. Users can once again seamlessly choose their preferred key algorithms in the Account settings.

We enhanced our keypair profile workflows to allow for selection of the quantum-safe algorithm, Machine Learning-based Digital Signature Algorithm (MLDSA). MLDSA is a cutting-edge approach to cryptographic security. It utilizes advanced machine learning techniques to continuously adapt and enhance security measures, providing adaptive protection against emerging threats.

We have addressed delays in loading on the archived signature logs page by removing the Total number of signature logs field as well as the Number of records column. Each report consistently contains 10,000 unfiltered signature events. However, the most recent report reflects the delta of events since the last archival, potentially deviating from the standard 10,000 events. This change ensures a smoother user experience while maintaining transparency and accuracy in reporting.

We identified an issue with the smctl windows ksp list command, which resulted in the output only showing the first letter of the storage providers. We have fixed this issue and the command output should display with the full names, as expected.

CertCentral now issues certificates off SHA-384 signature algorithm ICAs. While previously limited to SHA-256, this update enables users to utilize SHA-384 signatures based on their CA and ICA settings within CertCentral. Users can seamlessly leverage this feature to further strengthen their certificate management workflows.

We have identified that system scope keypair profiles that should be shown be visible in all Software Trust Manager accounts, were hidden. We have fixed this issue and should be accessible in all accounts.

During keypair generation, the security level associated with the keypair profile selected was hidden. We have resolved this issue and the security level should display as expected.

We identified an issue preventing the download of Software Trust Manager client tools via the no authentication API endpoint: /signingmanager/api-ui/v1/releases/noauth/{releaseName}/download and CI/CD plugins. We have fixed this issue and users should be able to successfully download our client tools using the endpoint referred to above and Software Trust Manager plugins.

We enhanced our keypair creation workflows to allow for the selection of the quantum-safe algorithms, Machine Learning-based Digital Signature Algorithm (MLDSA). MLDSA is a cutting-edge approach to cryptographic security. It utilizes advanced machine learning techniques to continuously adapt and enhance security measures, providing adaptive protection against emerging threats.

We enhanced our command line interface (CLI), Signing Manager Controller (SMCTL) to support CycloneDX and SPDX SBOM signing and verification using in-toto. SBOM signing enables users to securely sign their SBOMs, providing assurance of their authenticity and integrity throughout the software supply chain. Additionally, SBOM verification ensures that received SBOMs have not been tampered with, enhancing trust and mitigating the risk of supply chain attacks.

Building on existing binary signing workflows, we enhanced our command line interface (CLI), Signing Manager Controller (SMCTL) to support hash signing. Hash signing ensures data integrity by generating unique cryptographic signatures for files, offering an extra layer of security against tampering and unauthorized modifications throughout the software distribution process.

We identified and fixed two issues relating to our Projects feature. Previously, system users encountered difficulties loading the projects page; we have resolved this, and it should now load as expected. Additionally, the "Create project" button was displayed in the UI for users who did not have the required permissions assigned. We have rectified this by removing the button for users who do not have the necessary permissions to perform this action.

We have improved our API for system users. As of this release, it is mandatory for system users to provide an account ID when retrieving signature logs. This change ensures that users can access logs for a specified account rather than receiving data for all accessible accounts. This enhancement allows for more efficient workflow management.

We have enhanced the drop-down menus in existing workflows to include a search functionality to speed up the selection process. The search functionality has been applied to the following workflows:

We made changes to how keypair profiles are organized. Previously, when you created a new keypair profile, it appeared at the bottom of the list, potentially causing inconvenience. Now, to streamline your experience, newly created keypair profiles will automatically populate at the top of the list for easier access and better visibility.

We enhanced input validation for hashes provided at time of signing related to keypairs stored on disk via Software Trust Manager Rest API.

We have enhanced the user interface (UI) pages for archived signature logs in Software Trust Manager, significantly improving their load time.

Previously, users with large log volumes experienced timeouts when accessing archived logs. This release should eliminate timeouts. Additional optimizations are in progress to enhance other aspects of the signature logs workflow to further enhance user experience.