IoT Trust Manager

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.

A new feature has been released that enhances the administration of DigiCert Gateway access. Solution Operators can now extend DigiCert Gateway installation privileges to Server Administrators without requiring the latter to log into the DigiCert ONE portal or the Solution Operator to know the installation location in advance.

In our latest product update, we have introduced new functionality that significantly streamlines the management of enrollment profiles. You can now effortlessly clone an existing enrollment profile directly from the enrollment list page.

In our latest enhancement to the IoT API, we've made the certificate renewal process even more accommodating by allowing the certificate ID to be optional during renewal requests.

In our latest enhancement to the IoT API, we've made the certificate revocation process even more accommodating by allowing the certificate ID to be optional during revocation requests.

The batch certificate generation now includes support for the SMPB certificate format. This enhancement is part of our ongoing effort to expand the capabilities of our certificate management offerings to accommodate a wider range of industry standards.

We have addressed and resolved a scrolling issue on the Enrollment Profile Details Page when accessed via the Safari browser.

Starting November 1, 2023, at 18:00 MDT (November 2, 2023, at 00:00 UTC), we will require all DigiCert ONE accounts to use two-factor authentication (2FA).

You will use both your credentials and a one-time password to access your account. When you log in to your DigiCert ONE account on November 1, you will be prompted to set up two-factor authentication. If you have already enabled two-factor authentication in Account Manager before this date, no further action is necessary.

How to enable two-factor authentication in Account Manager.

In prior versions, a bug was identified that impeded the retry mechanism when storing a portion of a batch file. This bug resulted in an exception being triggered, leading to the incomplete saving of certificates. This exception went unnoticed by users, who would only become aware of the issue when attempting to download the batch results. This issue has been successfully resolved in this release.

In the previous version, a bug was identified in which an additional carriage return was automatically inserted at the end of the string representing the PEM certificate. This anomaly occurred infrequently and was specific to certain scenarios, primarily contingent on the size of the PEM file. To be precise, it occurred only when the number of characters was exactly divisible by 64.

This issue has been rectified in the latest release, ensuring the accurate representation of PEM certificates without the extraneous carriage return.

A new and improved batch workflow has been introduced, offering enhanced flexibility and efficiency for you. Here's what's new:

In prior versions of the IoT Trust Portal, users did not have the capability to filter credentials by enrollment profile. With this update, this functionality has been integrated into the system.

Now, within the ACME credentials section, you can easily filter credentials based on specific enrollment profiles. This improvement simplifies the management and retrieval of credentials associated with particular enrollment profiles, enhancing your overall experience and efficiency within the portal.

Previously, the digital signing of batch certificates was limited to enrollment profiles using the Digicert CA Connector exclusively. This has been expanded to include both the EJBCA and CertCentral connectors.

With this update, users leveraging the EJBCA and CertCentral connectors now have the capability to digitally sign their batch certificates. This added flexibility allows you to align your digital signing preferences with your choice of CA Connector, providing greater versatility and control over your certificate management processes.

Previously, IoT allowed users to add individual IP addresses for validation in enrollment profiles. To provide more robust functionality, we have optimized this feature to now support the addition of IP address ranges. Importantly, individual IP address validation is still fully supported.

With this update, you now have the flexibility to specify IP address ranges, offering greater convenience and efficiency in IP address management within your enrollment profiles. This enhancement not only streamlines the process but also accommodates a wider range of network configurations.

To illustrate, here are examples of supported IP address ranges:

Endpoints affected:

In the previous design, the "approve" and "reject" actions were represented by checkmark and cross symbols. While these icons are commonly used for approval and rejection, we recognized that they could be unclear to some users.

To address this, we have replaced the icons with explicit wording. Now, you will see "Approve" and "Reject" buttons instead of symbols, ensuring greater clarity and leaving no room for confusion during the approval process.

This change simplifies the user interface and aligns with best practices for usability and accessibility.

In a previous release, a bug was identified in the enrollment profile selection process when utilizing server-side key generation. Specifically, when users attempted to generate a batch using MAC address generation in conjunction with certain enrollment profiles, an error occurred, preventing the intended operation from being completed successfully.

This bug has been resolved in the current release. Users can now select enrollment profiles with server-side key generation and proceed with MAC address generation without encountering this error.

Fixed an issue where the subject directory was not being correctly extracted from CSR submissions, potentially leading to an incomplete certificate generated. This now functions as expected.

A new batch workflow offers enhanced flexibility and efficiency for our users. Here's what's new:

Opt-In banner

Users now have the option to opt in to the new batch workflow. This option will be presented to users in two sections:

New API endpoint

A new API endpoint has been exposed to enable users to switch this opt-in flag on programmatically.

Opt-out option

Users who prefer not to opt in to the new workflow will continue to use the existing workflow. However, all new enrollment profiles will automatically be opted in for the new batch workflow.

New features

The improved workflow offers several benefits:

These enhancements will streamline workflows and improve user experience with the platform.

A button at the top right corner of the Devices table will generate the API request to replicate the table's current view, including all applied filters, date settings, column headers, and data sorting.

This integration empowers users to seamlessly extract data from the table and integrate it into their workflows or applications using the provided API request.

A button at the top right corner of the Divisions table will generate the API request to replicate the table's current view, including all applied filters, date settings, column headers, and data sorting.

This integration empowers users to seamlessly extract data from the table and integrate it into their workflows or applications using the provided API request.

Support has now been added to the SEC1 private key format via the batch API. This includes updates to the following APIs (see links for details):

Added an additional parameter private_key_syntax with the following options:

Also added this option to the private_key_option parameter:

We have integrated the End Entity Certificates and Intermediate CA pages into a single, unified view. Here's what's new:

This consolidation simplifies certificate management, reduces the time spent navigating between pages, and provides a more cohesive user experience.

Starting with this release, users can now upload both zipped and unzipped CSV files for batch requests.

We have updated the user interface for the ACME credentials page. Here's what's new:

This fix applies to endpoints for unassigning divisions and retrieving batch jobs.

This page is now able to load more than 100 certificates.

On August 15, 2023, DigiCert upgraded our support plans to provide a better, more customizable experience. These improved plans are scalable and backed by our technical experts to ensure your success.

New plans:

For more details about what these plans include, see the DigiCert Support Plans and DigiCert Support: Enabling Your Success.

How does this affect me?

To show our appreciation, DigiCert has upgraded all existing customers to either Business or Premium support plans for a limited time at no additional charge. See our August 15 change log entry.

How the limited-time upgrade works:

Users now have the option to digitally sign both batch ZIP files (PEM and DER) as well as JSON files. Users may select/unselect this option upon enrollment profile creation or edit. If a user opts in to digital signing, a dropdown offers a list of DigiCert ONE CAs associated with the account from which the digital signing certificate would be issued. DigiCert creates and manages the digital signing certificate created; however, users are given the option to regenerate a digital signing certificate.

The certificate table now contains an additional column, Batch Job ID. Users may filter the certificates upon the batch job ID. The value will not be populated unless the certificate was generated via batch. Reports pertaining to certificates will now also include the Batch Job ID, if selected.

The End Entity Certificates tab and Intermediate CAs tab will be combined into a single tab labeled Certificates. A filter on the field certificate type may be used to distinguish between the Intermediate or end-entity certificates.

The Authentication CA Templates, Authentication certificates, Source fields and Manage Passcodes sections displayed in the enrollment profile details page now reflect an updated table design. The file uploader of the Source fields section has also been updated to a new, friendlier option.

The API endpoint to get certificate import details (get_import_job_details) now includes the certificate type field. The value of certificate_type would contain either:

Upon performing the following actions on the certificate profile:

When a certificate profile field is of type JSON, a JSON editor will now be rendered, allowing users to easily edit values. Similarly, for JSON fields on the Request details page, a JSON editor will now be used to display the values.

Customers are now able to encode their private key in SEC1 format, in alignment with encoding done by OpenSSL, which generates a shorter length key.

An update to the following APIs (see links for details):

Added an additional parameter private_key_syntax with the following options:

An additional option has been added to the private_key_option parameter:

Customers can now read and extract the certificate policy from the CSR. When creating a certificate template, a user should include Request as a source in their certificate policy JSON configuration. When this is included, a new checkbox will appear under the Certificate template card, allowing users to obtain the certificate policy value from the CSR.

Fixed an issue where sorting and filtering of authentication certificates (under the enrollment profile details page) were not working. Also, the new authentication certificates section now includes a link to a details page, allowing customers to manage their authentication certificates directly (not via enrollment profile details page).

A new button on the Issuing CA table lets customers execute an API call which leads to the same output as shown on the table. A new button is available in the top right corner of the the table. Selecting this button allows users to apply filters, dates, and headers, as well as sort data.

A new button on the Devices table lets customers execute an API call which leads to the same output as shown on the table. Selecting this button allows users to apply filters, dates, and headers, as well as sort data.

A new button on the audit log table lets customers execute an API call which leads to the same output as shown on the table. Selecting this button allows users to apply filters, dates, and headers as well as sort data.

A new button on the enrollment passcode table lets customers execute an API call which leads to the same output as shown on the table. Selecting this button allows users to apply filters, dates, and headers, as well as sort data.

Customers will see an improvement in batch performance. The improvements will be more evident in batch sizes of more than 20,000 records. These improvements lead to more linear growth in time as batch size increases.

The certificate profile creator now includes a JSON editor has now been included for fields of type JSON. Customers are now able to edit their JSON data.

Previously, when downloading a batch file, the download button was not greyed out causing using to click on this button multiple times. The button is now greyed out and the user sees a visual reminder that the download is in progress.

DigiCert​​®​​ IoT Trust Manager has now integrated the EJBCA APIs. This allows users of IoT Trust Manager to enjoy the same ease when using the IoT Trust Manager APIs to manage other CAs. IoT Trust Manager offers both single certificate issuance as well as batch from both API and platform.

For batch certificate enrollment jobs using server-side key generation, you have an additional download format: JSON. When your job completes, you can download a JSON formatted file that contains a list of certificates and its encrypted private key. This option is available from both API and platform.

From enrollment profile configuration, you can use the same AES key for a period of time to encrypt PKCS7 certificates. This option currently only applies to the JSON format batch download. It is available from both API and platform.

Certificates that have been renewed and revoked no longer show on alert reports for expiration.

DigiCert​​®​​ IoT Trust Manager now supports a new set of rules in a format that describes attributes of a certificate template. This defines the policies and rules that a CA uses when a request for a certificate is received. These may not necessarily be in the traditional X509 format, but do give you flexibility in the format of certificates that you receive by the Digicert Certificate Authority.

You have access to an additional authentication mechanism, which allows the option of using both a passcode and an authentication certificate. This offers an additional layer of security those those who require it.

When generating a client-side key generation batch requests, you can submit a CSV zipped file with a specified template. The template will be available for download from both API and the platform.

For users limited by divisions, we now prohibit the following functionality:

You now have the option to use the same symmetric AES key when decrypting (PKCS7) certificate responses, which is available from both API and the platform. This feature enables clients to operate more efficiently by being less reliant on HSM for decryption and you only have to decrypt one key on an HSM. Afterwards, you can work in a more high performance and cost efficient manner, while maintaining strong end-to-end data encryption.

You can now revoke GlobalPlatform certificates via API or the platform. This allows customers to now follow a similar workflow as is currently available for X509 certificates.

You now have the option to create an enrollment profile with an additional option, which allows the issuance of a certificate only with approval from a specified user. The user or list of users who can approve the issuing of this certificate are defined in the enrollment profile. By default, the the enrollment profile does not require approval, unless specified.

In the case where approval is not required, certificates will automatically move to an Auto approved state. If approval is required, the certificate request will be in Pending approval status, until approved by an entrusted approver. A user can go to the request tab to view a table of certificate requests. These will include those that have been auto-approved and those who are pending approval.

This option is available via both API and the platform.

You may now easily view the correct way to structure and execute API calls. The portal offers a friendly user interface that maps out the blueprint for APIs. The structure is comprehensible for both developers and non-developers. The API request builder generates interactive and easily testable calls.

With this improvement an API user can start a batch certificate request using a comma-separated values file (.csv) containing Certificate Signing Requests (CSRs).

Added external API endpoints to search for enrollment passwords and enrollment authentication certificates.

Users can now apply a filter on the end entity certificates table for certificate policy.

Online Certificate Status Protocol (OCSP) groups can be added, edited, and deleted through API endpoints. There is also an API endpoint for searching through OCSP groups.

Fixed an issue that truncated column names when a filter is applied. The full filter is now visible.

Fixed an issue where report status was not updating after a report was run. It now displays as expected.

Fixed an issue that allowed enrollment with an authentication certificate even after the corresponding authentication CA template was disabled or deleted in the enrollment profile. Now deleting or disabling the authentication CA template in an enrollment profile will also prevent the authentication certificates from being used for certificate enrollment.

Fixed an issue that blocked report generation when a user applied a filter to the enrollment profile table. Report generation now runs as expected.

Enterprise customers who have devices (such as routers, switches, etc.) that require certificates to be issued from a DigiCert ONE platform account, but do not have internet connectivity, can now use the DigiCert Gateway to do so. These devices and clients use SCPE/EST/CMP V2 protocols for requesting certificates. The gateway is a standalone application deployed as a JAR.

Gateway offers:

In Enrollment profiles under Authentication credentials, there was an issue that prevented CA certificates with the certificate policy extension from being uploaded to authentication CA templates.

Error Message: “Authentication CA(s) parsing was failed."

We now support CA certificates that contain the certificate policy extension.

The DigiCert Gateway helps in use cases where devices behind a firewall are not allowed direct outbound access to IoT Trust Manager in the cloud. Using the DigiCert Gateway, devices can make certificate requests using the protocols: EST, SCEP, CMPv2 and REST APIs. In this way the device need only to be granted access to make certificate requests to the DigiCert Gateway service, running within the network, the DigiCert Gateway handles passing the certificate request outside the network.

This release includes a DigiCert Gateway on-prem standalone service which can be run in Java runtime environment or Docker container. A DigiCert Gateway configuration/registration step must take place within IoT Trust Manager before an instance of the DigiCert Gateway can be started and allowed to connect to IoT Trust Manager.

Two new user permissions have been added to IoT Trust Manager: Manager DigiCert Gateway and View DigiCert Gateway.

IoT Device Manager has been renamed to IoT Trust Manager. This name change did not create any changes to processes, workflows or features and none of the APIs or page URLs were changed due to this name change.

Updated the create device page and the edit device page to a new look. There were not any functional changes to the pages.

Added Enrollment Profile to the list of additional columns to select from on the end entity certificates page.

Fixed an issue where enrollment profiles using an authentication CA were not showing in the enrollment profiles table on the authentication CA details page.