IoT Trust Manager

We have updated the certificate renewal process with stricter rules to ensure the Subject Distinguished Name (DN) remains consistent with the original certificate. Any changes to the Subject DN, such as common name or organizational details, are now rejected to maintain certificate integrity. This change applies to both UI and API certificate renewals.

The character limit for regular expressions in registered value containers has been increased to allow for more complex configurations.

The List assignable ICAs endpoint for returning assignable Certificate Authorities (CAs) now supports more than 1,000 CAs. This provides better management capabilities for customers with large environments.

Fixed an issue where the Registered values details page would not load if an associated enrollment profile was disabled. The page now loads correctly regardless of the profile status.

Resolved a problem where certificate requests were rejected if the SAN DNS field met specific ends with conditions. Requests now process correctly, ensuring accurate validation.

Fixed an issue that prevented trust bundle downloads where multiple certificates shared the same common name. Trust bundles can now be downloaded without errors.

The trust bundle download URL now allows direct access without needing to sign in. This simplifies the download process.

The term Certificate policy in the notification banner has been updated to Certificate management policy to align with our adoption of new industry standard terminology.

Added the ability to exclude Authority Key Identifier (AKI) and Subject Key Identifier (SKI) extensions in certificates based on template settings. This allows for more precise control over certificate attributes.

Now when you add AKI/SKI extensions to a template with the include parameter set to no, these extensions will be excluded from the generated certificates.

Example

 {
  "extensions": {
    "ski_extension": {
      "include": "no"
    },
    "aki_extension": {
      "include": "no"
    }
  }
}

Resolved an issue where reports generated successfully but failed to download due to recent memory patch fixes. This fix ensures that reports can now be downloaded successfully.

We have improved our reporting functionality to use memory more efficiently, especially for larger reports, ensuring smoother and more reliable performance.

A Learn more link has been added to the name changes banner on the dashboard, providing users with detailed information about upcoming product name changes.

Following updates to CMPv2 protocol logging, we have enhanced logging for the EST protocol:

Key changes:

These enhancements improve transparency and traceability for better auditing and troubleshooting.

Fixed an issue where decrypted files incorrectly contained the PGP public key instead of the generated private key in batch jobs using server-side key generation and JSON output format.

Resolved an issue where certificate requests using the MLDSA key type failed with an unsupported_public_key_algorithm error. Certificate requests using MLDSA key type will now be processed successfully.

Introduced an advanced feature allowing solution operators to set specific conditions for certificate fields within enrollment profiles. This ensures certificate requests meet predefined criteria and provides detailed logs for rejected requests.

Improved clarity and organization of batch reports and output files by including the batch job name and its UUID in their names.

Introduced the ASN1_Algorithm field in the certificate issuance API, allowing users to specify the ASN.1 algorithm directly.

Enhanced system defenses to ensure accurate license counts, especially during device and certificate failures.

Users with the appropriate permissions now have the ability not only to create and edit, but also to disable and delete custom certificate templates directly from their account.

Upgraded CMPv2 with additional logging capabilities to provide more in-depth insights into its operations and interactions.

Implemented code changes in IoT Trust Manager to unify the naming conventions for Post Quantum Crypto Dilithium across CA Manager and the server-side key generation for Dilithium keys. This adjustment ensures IoT Trust Manager continues to support certificate requests for Dilithium type keys and algorithms, alongside introducing server-side Dilithium key generation capabilities.

Addressed an issue where mismatches between the signature algorithms of authentication certificates and their issuing CA, designated as the “authentication CA” in IoT Trust Manager, led to authentication failures. This correction prevents failed certificate requests stemming from the rejection of authentication certificates due to algorithm mismatches.

Users now have the ability to easily remove the association between a registered values object and an enrollment profile, offering greater flexibility in managing the configuration and lifecycle of enrollment profiles.

Addressed a bug in the CSV template download functionality within the Registered values details page. The fix ensures that the downloaded CSV template accurately mirrors the certificate values specific to the dataset being managed, fixing an issue where a generic template was received, leading to inconsistencies.

Resolved an issue where email notifications for batch downloads incorrectly displayed 'null null' for the Service User. Notifications now include the Service User's email (friendly name), providing clear identification.

Fixed a problem where batch job reports erroneously indicated no successful records, even when jobs were completed successfully. Reports now accurately reflect the success of job executions and document any issues or errors, enhancing trust in the system's reporting capabilities.

Implemented a correction for a misrepresentation issue where batch enrollments marked as 'Rejected' inaccurately showed records as having been processed successfully. The system now correctly reflects the actual status of each record in rejected batches.

In this update, we're introducing a significant enhancement to our container management system: the pre-termination hook. This new feature is designed to give you more control and predictability over how your containers shut down—ensuring a smoother, more reliable system operation.

Key features

Implemented registered values in IoT Trust Manager to enhancing certificate issuance control. Registered values ensure that certificate request values adhere to predefined criteria, including lists of allowed values and conditions. This enhancement enables stricter validation of certificate fields according to specific requirements.

Registered values can also be managed and viewed by all divisions within an account or restricted to specific divisions only. This allows for the assignment of a registered values container to specific divisions.

To start using registered values, sign in to your DigiCert ONE IoT Trust Manager account and go to Certificates > Registered values.

Adding the entire IP range, specifically from 0.0.0.0 to 255.255.255.255, to the list of allowed IP addresses is no longer possible. This change addresses potential security risks by preventing these broad ranges from being used.

A new toggle switch feature allows you to easily control the limitations on IP address entries. This provides flexibility between restricted and unrestricted IP address entries.

Resolved a bug that prevented sending batch external emails via API.

Resolved an issue that prevented zipped files from uploading correctly, allowing users to upload zipped trust bundles without errors.

Fixed an issue to enable successful uploading of P7B files.

Addressed an issue that caused files with whitespaces in their names to fail during upload.

Fixed an issue where the signature algorithm was not correctly applied when creating a certificate profile for CMPv2.

Introduced trust bundle division access feature to enhance security and access control, allowing trust bundles to be limited by divisions for granular access control.

Initiated integration of Post-Quantum Cryptography (PQC) support with the incorporation of the Dilithium algorithm, marking a step towards enhanced security.

Enhanced gateway installation process to allow for unlimited downloads and introduced a predefined expiration period of 3 days (72 hours) for the download link.

Introduced enhancements to CMPv2 functionality, enabling users to specify certificate validity duration and signature algorithm selection directly in CMPv2 requests.

Added a configuration option to enable or disable MAC address verification for DigiCert Gateway, catering to deployments in environments with dynamic MAC addresses, like Kubernetes containers.

A trust bundle is an essential collection of certificates used to establish trust within digital environments. A trust bundle can include various types of certificates such as root CAs, intermediate CAs, code signing certificates, and others required for distribution into trust stores. Our system supports adding up to 100 certificates in a single trust bundle.

You can easily manage these trust bundles in the IoT Trust Manager console, where you can perform the action listed below. These actions enhance your ability to manage trust bundles effectively, ensuring that you can maintain the necessary digital trust and security for your operations. For detailed instructions or additional support, please refer to our documentation or contact our support team

These CMPv2 updates address the CMPv2 directory value limitation and enhance the enrollment profile interface for EST/SCEP/CMPv2 methods.

We now support Post-Quantum Cryptography (PQC) Dilithium keys as a part of our commitment to providing advanced security features and keeping up with evolving industry standards.

By integrating PQC Dilithium keys, we are enhancing our platform's security and preparing for the quantum-resistant future of cybersecurity. This update empowers our users to adopt stronger cryptographic standards, ensuring the longevity and integrity of their security measures.

New features

Customers have expressed the need for clearer visibility into potential exceptions that may occur during the batch generation processes. The lack of detailed feedback when batch generation fails leaves customers uncertain about the nature and stage of the failure.

Therefore, we enhanced our exception-handling protocols to provide more informative and specific error feedback during batch-generation failures. Customers will now receive detailed error messages indicating the stage at which the batch process failed.

Examples of updated messages:

Possible error codes

To further assist in troubleshooting, the following error codes will be provided, detailing the nature of the exception:

Issue: CSV template missing the CSR column

The downloaded CSV template does not include a CSR column.

Fix: Updated the logic in the create batch page to handle the template request correctly

Now, when the client-side key generation is selected and the user requests a template download, the system will send the option “client_side” in the request. In all other cases, the system will default to the “server_side” option.

This change ensures the correct template, including the CSR column, is provided, aligning with the user's selection.