CA Manager

You can now issue external delegated OCSP responder certificates for use on external systems. These certificates are hosted outside DigiCert ONE, with clients responsible for routing and responding to OCSP requests.

We added user interface (UI) and API support, including a new request form, CSR upload option, and enhanced API documentation.

New Relic metrics in the sandbox environment now include SQL statements and connection types for better observability and performance analysis. The New Relic wrapped database driver is now conditionally loaded only when New Relic is specifically configured, preventing unnecessary dependencies and potential overhead.

Issue: The registeredID Subject Alternative Name (SAN) was encoded incorrectly as an ASCII string by CA Manager instead of a DER-encoded OBJECT IDENTIFIER (OID).

Fix: The encoding logic has been corrected to properly encode registeredID SANs as DER-encoded OIDs, ensuring compliance with RFC 5280 and interoperability with standards-compliant clients and applications.

Previously, when assigning a hardware security module (HSM) partition to a "Selected Account" via the frontend (FE), users were required to select at least one "Allowed Use" (New CA Keys, New OCSP Responder Keys, or Key Escrow). However, this restriction was not enforced when registering or editing a partition via the backend (BE) API.

Change

We aligned the backend behavior with the frontend by enforcing the "Allowed Uses" restriction when assigning an HSM partition to a "Selected Account" via the API. This change ensures consistent validation across both interfaces and prevents misconfigurations.

Impact

Now, API users must specify at least one "Allowed Use" when assigning an HSM partition to a "Selected Account."

The Digicert’s On-Prem CA will be a private Certificate Authority (CA) for secure and automated X.509 certificate management that provides full control over certificate issuance, lifecycle management, and security policies, ensuring compliance with enterprise security requirements.

Underscores are now supported in the SAN:dnsName files for private certificates.

RSA public exponents will support keys for the range 2¹⁶  < e < 2²⁵⁶ for private certificates.

As part of our ongoing security and compliance measures, we are going to push this change blocking OCSP responders that include the OCSP No-Check extension (id-pkix-ocsp-nocheck as defined in RFC 6960, Section 4.2.2.2) when marked as a critical extension. The OCSP No-Checkextension is designed to exempt OCSP responder certificates from revocation checking. While this may be necessary for long-lived OCSP responders, marking this extension as critical enforces the revocation bypass, potentially introducing security risks. Specifically, a compromised responder with this extension marked as critical could remain trusted indefinitely, undermining certificate validation mechanisms.

Impact:

To enhance performance and efficiency, a new caching module has been introduced to reduce database and HSM calls during certificate issuance.

A performance analysis of signing functionality with an escrowed key revealed frequent HSM lookups for the public key, causing inefficiencies. To optimize performance, the public key will now be cached alongside the signing key.

The update job polling cycle is now configurable, improving test automation and allowing users to disable caching if needed.

This release introduces an optimization to prevent the unnecessary generation of OCSP responder certificates when the OCSP responder’s valid_to is within 10 seconds of the CA certificate's valid_to.

Previous behavior

New Behavior

Set the criticality of the ocsp no check extension in the OCSP responder cert to false.

The fix allows users to view and access the Authcode when adding a new proxy app. The Authcode is required to set up a connection between the CA manager and the remote proxy app.

Ability to import RSA, ECC, or EdDSA keypairs from a registered HSM partition into CA Manager keypair records for use in signing processes within Software Trust Manager workflows for LUNA Safenet systems.

Capability to create a pre-certificate for PUBLIC TLS that can be submitted to CT logs for signing, and subsequently retrieve the signed version for issuance.

Minor fixes to PathLen modification flows during certifcate creation.

Issuance and escrow is now supported for ECDSA keys and SHA3.

BasicConstraints have been added back to Qualified end-entity templates.

Allow multiple options for downloading the HSM Remote Proxy bundle and support has been added for Thales G5 USB HSM’s.

We added a new graphical view of a selected root CA’s family tree to make navigating the hierarchy easier.

The Subject Surname and GivenName fields now accept up to 64 characters.

Made various tweaks to the processes underpinning management of the HSM functionalities.

Fixed the ability to activate and deactivate AIAs.

We corrected an issue where displaying expired certificates cased the table to hang while loading.

Multiple AIAs will now be included in the certificate when created.

Third-party functionality is no longer restricted to just root CA certificates.

Verification first interrogates the signature OID to see if PureEd448 or PreHashedED448 are used and then uses the correct function.

We corrected some backend logic to simplify and reduce overhead to the display table logic.

Expanded the events captured in logging.

Made logic consistent across different email validation points.

Tweaked and improved accessibility in various areas.

Tweaked and improved accessibility in various areas.

We tweaked and improved accessibility and interface usability in various spots.

Mades some security improvements.

To address quirks with time zones and SCEP enrollments, managers may submit end-entities with notBefore validities in the past.

To make selecting the appropriate region for a DPoD more sensible, regions can now be selected from the menu.

We made various improvements to improve accessibility and the user experience.

NIST has not yet codified the final versions of the PQC algorithms, nor have PKI standards bodies defined standards. PQC algorithms - Dilithium (ML-DSA), SPHINCS+ (SLH-DSA), and Falcon (FN-DSA) - are for testing purposes only, subject to backward-incompatible updates, and features are still rough around the edges.

Additionally, to ensure performance, PQC support is only provided via the SoftHSM. Hardware HSMs (Safenet) will be delivered once the vendor provides native PQC support.

The updates to Common UI address failure to display flag icons in the phone and localization options.

The changed PathLen enforcement provides Operations members more flexibility in creating offline requests.

Account-friendly identifiers provide for better identification of similarly named accounts.

We corrected an issue where a CA being signed by another enabled to issue evergreen certificates could not set a longer validity period.

NIST has not yet codified the final versions of the PQC algorithms, nor have PKI standards bodies defined standards. PQC algorithms - Dilithium (ML-DSA), SPHINCS+ (SLH-DSA), and Falcon (FN-DSA) - are for testing purposes only, subject to backward-incompatible updates, and features are still rough around the edges.

Additionally, to ensure performance, PQC support is only provided via the SoftHSM. Hardware HSMs (Safenet) will be delivered once the vendor provides native PQC support.

Thales DPoD region codes are now required when registering the HSMs to ensure compatibility with DigiCert ONE platforms in the EU and North America.

We refactored the email functionality to allow for email localization. Once translations are complete, recipients can select the language of their choice.

We regularly scan our codebase for newly discovered issues and vulnerabilities to fix, ensuring security is up to date.

We corrected an issue where creating a CA via an external CSR defaulted the CA as exportable. Flagging a CA as exportable is now an opt-in selection.

NIST has not yet codified the final versions of the PQC algorithms, nor have PKI standards bodies defined standards. PQC algorithms - Dilithium (ML-DSA), SPHINCS+ (SLH-DSA), and Falcon (FN-DSA) - are for testing purposes only, subject to backward-incompatible updates, and features are still rough around the edges.

Additionally, to ensure performance, PQC support is only provided via the SoftHSM. Hardware HSMs (Safenet) will be delivered once the vendor provides native PQC support.

We also include support for the MGF parameter and salt lengths of 2048, 3072, 4096, and 8192.

CRL distribution point creation now supports file directory paths as a schema. Additionally, CA services now provide the option to support web URLs below the top-level domain, such as "somedomain.com/subdir1/subdir2/".

We also tweaked the CRL creation form to support the updated creation process flow better.

DigiCert ONE managers may omit the SKI or AKI extensions included by default in an end-entity certificate.ement copy

We made a few behind-the-scenes tweaks.

The remove all accounts option was confusing. Now, the choices are between specific accounts and "none," which allows any user, irrespective of account, including system-scope users who have no accounts, to access an HSM partition.

This is corrected and now behaves as expected.

OCSP responder validity is now limited to no later than the parent CA's valid to date.

NIST has not yet codified the final versions of the PQC algorithms, nor have PKI standards bodies defined standards. PQC algorithms - Dilithium (ML-DSA), SPHINCS+ (SLH-DSA), and Falcon (FN-DSA) - are for testing purposes only, subject to backward-incompatible updates, and features are still rough around the edges.

Additionally, to ensure performance, PQC support is only provided via the SoftHSM. Hardware HSMs (Safenet) will be delivered once the vendor provides native PQC support.

The lack of context for the icons shown next to Root and ICA info was confusing. Once accounts have consumed the amount of Roots or ICAs purchased, a green checkmark is now shown. Additionally, tooltips that provide context now display on rollover.

Corrected a bug preventing offline requests from modifying the PathLen.

Corrected an issue where revoked certificates were included in lists that had the filter “Disabled.”

Resolved an issue preventing CAs without a Subject Common Name from being imported.

A minor nil pointer problem was nullified.

The service now supports account names that are not unique.

The internal ceremony tool now supports cross-signing for roots hosted outside of DigiCert.

A 400 “not found” error will now be returned when a keypair has been deleted or not present.

An error has been corrected to allow modification of PathLen for offline CA requests.

NIST has not yet codified the final versions of the PQC algorithms, nor have PKI standards bodies defined standards. PQC algorithms - Dilithium (ML-DSA), SPHINCS+ (SLH-DSA), and Falcon (FN-DSA) - are for testing purposes only, subject to backward-incompatible updates, and features are still rough around the edges.

Additionally, to ensure performance, PQC support is only provided via the SoftHSM. Hardware HSMs (Safenet) will be delivered once the vendor provides native PQC support.

Minor user interface updates to improve consistency.

Attempting to disable offline roots now returns a clearer error message letting you know this is not permitted.

Miscellaneous behind-the-scenes bug fixes.

NIST has not yet codified the final versions of the PQC algorithms, nor have PKI standards bodies defined standards. PQC algorithms - Dilithium (ML-DSA), SPHINCS+ (SLH-DSA), and Falcon (FN-DSA) - are for testing purposes only, subject to backward-incompatible updates, and features are still rough around the edges.

Additionally, to ensure performance, PQC support is only provided via the SoftHSM. Hardware HSMs (Safenet) will be delivered once the vendor provides native PQC support.

The softHSM option now supports the most recent versions of Dilithium (ML-DSA), SPHINCS+ (SLH-DSA), and Falcon (FN-DSA).

PQC no longer supports hardware HSMs because of performance and version support issues.  CA services will provide support for hardware HSMs later in 2024, after NIST finalization and once native support is provided.

We corrected an issue in which the number entry field displayed an incorrect default value of -1 when selecting the "Define a path length over 0" option.

NIST has not yet codified the final versions of the PQC algorithms, nor have PKI standards bodies defined standards. PQC algorithms - Dilithium (ML-DSA), SPHINCS+ (SLH-DSA), and Falcon (FN-DSA) - are for testing purposes only, subject to backward-incompatible updates, and features are still rough around the edges.

When a person creating a Root or CA is on a later page in the form, returning to a prior page will now retain and display the previously entered data, no longer requiring reentry.

We deployed a service that allows features to be deployed and then remotely enabled and disabled. This will allow less disruptive deployments or rollbacks, as well as simplified testing. It will be transparent to customers but should improve the overall experience.

Table filtering on the ICA and Root CA records table now supports filtering by multiple options.

We corrected an issue preventing Dutch and Portuguese languages from displaying when selected from the preferred language dropdown

We corrected a bug where the application was automatically and silently disabling imported third-party roots.

International users should see improved coverage for language localization. We are having an issue with Portuguese refusing to apply properly and are working to fix.

To simplify selecting partitions for registration, an action menu is now available on HSM partition table records.

This has been corrected so that the newly selected account is autofilled.

Implementations are subject to change.

NIST has not yet codified the final versions of the PQC algorithms, nor have PKI standards bodies defined standards. PQC algorithms (Dilithium, SPHINCS+, Falcon) are for testing purposes only, and features are still rough around the edges.

When the account filter is set, the table now updates and displays correctly.

CA Manager now checks to ensure an entered URL for an HSM Remote Proxy application does not already exist.

Dilithium (MLDSA)-based End-entities can be issued from softHSM now.

Digest signing with SPHINCS+ (SLHDSA) post-quantum algorithm is now avaialble.

SPHINCS+-based escrow client key creation is enabled on both softhsm and hardware HSMs that are PQC enabled.

Table record display now conforms to our common user interface.

Corrected an issue where imported third-party roots were turned offline. They now remain online.

The response to a submission containing a set of Subject fields, only displayed a subset of those fields in response, despite processing the full set. The response now matches the submission for improved clarity.

When adding or editing a HSM URL, CA Services now verifies that no duplicate exists before accepting.

Implementations are subject to change.

NIST has not yet codified the final versions of the PQC algorithms, nor have PKI standards bodies defined standards. PQC algorithms (Dilithium, SPHINCS+, Falcon) are for testing purposes only, and features are still rough around the edges.

Managers are now able to submit single or multiple values for Registered ID.

Additional pages are no longer indicated when the list is less than 2 pages.

Implementations are subject to change.

NIST has not yet codified the final versions of the PQC algorithms, nor have PKI standards bodies defined standards. PQC algorithms (Dilithium, SPHINCS+, Falcon) are for testing purposes only, and features are still rough around the edges.

Roots and CAs may now be generated using the SPHINCS+ algorithms - on the PQC-enabled hardware HSM partitions. SoftHSM will be supported in a future release.

Known issues: Given the size of the keys, timeouts may be experienced during creation. Check back after 10-15 minutes to verify the CA has been added to the root or ICA listings (SLDHSA-SHA2-128f, SLDHSA-SHA2-128fs, and SLDHSA-SHA2-192f are generally the fastest). We will be adding asynchronous support in future releases.

Roots, ICAs, and End-entity certificates may now be generated on the PQC-enabled hardware HSM partition. SoftHSM will be supported in a future release.

These pages now share consistent layouts, filtering, and options to improve usability.

Implementations are subject to change.

NIST has not codified final versions yet, nor have PKI standards bodies defined standards. The use of PQC algorithms (Dilithium, SPHINCS+, Falcon) is for testing purposes only, and features are still rough around the edges.

Qualified Natural Persons templates now support Organizational Unit and Organization ID fields in the Subject.

To prevent breaking CRLDPs, a domain with the usage “CRL” may not have that usage removed if certificates have been issued using that domain.

Dilithium is now referred to as MLDSA.

Wildcard certificates can be created once again.

The SoftHSM can now be used to issue test PQC certificates.

Corrections to non-user-facing issues.

To conform with ETSI specs, qualified end-entities no longer require an EKU.

To prevent the breaking of CRLs and OCSPs, if a domain has been assigned to certificates, then it may not be edited. A new version must be created, or the domain unassigned to each certificate.

This vulnerability has been corrected.

Clients could mistakenly upload a root. The feature now blocks upload and returns an error.

These settings have been corrected, and issue end-entities is again enabled by default.

The API now enforces the same requirements and capabilities as the user interface (UI).

For CA and end-entity issuance only, CRYSTALS-Dilithium algorithm use is now offered for testing. OCSP and CRL creation are not yet supported (errors will be returned on creation attempts).

Improved logging to include CA disable/enable events, end-entity signing, and other activities.

Corrected an issue where the CRL scope set via API was not being honored.

Will be displayed if 1) a non PQC-Capable HSM is selected to use Dilithium keys and 2) CRL or OCSP are attempted to be created for certificates using Dilithium keys.

Removed restrictions on grouping of required Key Usages to allow clients more flexibility.