CA Manager

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.

This functionality now mirrors the UI.

DigiCert ONE managers now get additional information about an escrow key when using the GET /hsm/partition API endpoint.

‘Enabled’ is now the common term for active registered partitions, and status boxes all render the same.

The link now goes to the proper edit page

A bug had blocked changing default partitions, this is now fixed.

The partition designated as the default escrow partition is always available to all users.

Roots and ICAs now may be “Disabled” - which suspends any issuance, signing or CRLs and OCSP Responses or other use of the certificate until and unless it is reenabled. Disabled CA certificates show “Disabled” status in the Root or ICA table, and do not appear in dropdown menus.

To disable or reenable a CA, select the option from the 3 dot button on that certificate’s detail page.

ICAs now may be “Revoked”—this option is selected from the 3 dot button on that certificate's details page.

Revoking is a two-person effort, one admin requests the revocation, supplies the appropriate reason code and any details, and selects an approver. The approver will receive an email with the revocation request and a link. They then can approve or deny the request.

Only private trust CAs revoked with the reason “On Hold” can later be un-revoked. Otherwise the revoke is permanent.

CA services now supports the full range of qualified statements for use in end-entity certificates

[On-premises only] Additionally, end-entity templates, following ETSI requirements, exist to support issuance of Qualified Natural Persons and Qualified Legal Persons certificates. OCSP utilizes ArchiveCutoff (with the date set to the parent CA’s notBefore date), and CRLs are full-and-complete. The ExpiredCertsOnCRL extension options (see below) is also an option.

CA revocation results in all child certificates, subordinate CA and End-entities, to be revoked; after which a final CRL is published and then the CA is revoked. As noted above revoking a CA is a request and approval process.

[On-premises only] Private and Qualified trust certificate CRLs now may optionally use the CRL extension ExpiredCertonCRL, that retains the status of certificates for selected durations after they expire. Both Partition scope CRLS and full-and-complete CRLs support this extension. In this first release, the option must be selected during CA creation, from the CRL settings by selecting the checkbox “Include revoked certificates in this CA's CRL even after they expire”

This item is displayed due to initial development, but is not in general release yet. Updates to come when we deliver the general release.

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.

CA services now allows multiple HSM partitions to provide key escrow services—though you should designate one as a fallback/default. Additional improvements have been made to facilitate key escrow activities and information

HSM partitions designated for escrow also should indicate their level of relative security so that escrow requests from managers can ensure the right HSM is used for escrow needs.

The security levels run from 1 to 3, from lowest to the highest at 3.

Managers may call CA services to obtain information about an escrow key—such as it’s expiry and the security level of the partition that houses it.

When creating escrow keys, an expiry date may be set so that they are deleted to clear room.

Manager now may delete unused escrow keys directly.

Pre-work to support qualified trust certificate issuance by on-premises QTSPs, ensures CRLs created for such certificates be full and complete.

Corrected a problem where updating a request also set that date as the created date. The created date is now preserved.

Corrected an issue where the LEI certificate extension could not be set to “Optional”.

Corrected an error in the API that allowed a revoked cert to have it’s revocation date moved forward. Now only backdating is allowed for public certificates.

You can now reject or delete offline requests, which returns any allocated keypair to the public pool.

End-entity certificates may now be issued containing Qualified statements. Additional backend work has been prepared to allow issuance of ETSI-compliant certificates and lifecycle management to come in future releases.

Updated user experience to improve accessibility.

Fixed bugs that were affecting HSM connectivity.

DigiCert ONE managers, such as Trust Lifecycle Manager and IOT Trust Manager, now support custom certificate extensions using JSON-based ASN.1 templating. This removes additional steps for certain workflows.

Revocation is enabled for GlobalPlatform certificates through IOT Trust Manager.

Fixed an issued where creating a CA with pathLen configured resulted in error.

Fixed an issue where no partitions showed as available after a DPoD had been initialized.

The list of the actions available to filter is now shows all actions, instead of a random subset of all actions.

Fixed an issue where the application version in the help menu showed a mismatched application version. The help menu now shows the actual version of the application.

Fixed an issue where, when editing the responder generation settings if Auto-generate OCSP responder certificates was deselected, the other elements remained modifiable. Those options are no longer modifiable when Auto-generate OCSP responder certificates is deselected.

OCSP (Online Certificate Status Protocol) domains now can be registered as HTTPS. Such domains will display with “(HTTPs)” suffixes from the dropdown menu. Domains still must be unique, so HTTP and HTTPS versions cannot both exist. At this time, only OCSP supports HTTPs.

When reviewing offline requests for ceremony, included EKUs from the selected template are now displayed below the Policy Extension OIDs (Object Identifiers).

If an active CRL (Certificate Revocation List) with a long file path was displayed, it would overflow to page details. Now it will indicate truncation and can be viewed in full on mouseover.

The read-view of the CRLDP settings now reflects the updated setting.

The logs for Hardware Security Module (HSM) partitions are now in common language.

Corrected issue with the API that prevented the display of a list of available admins from the assignment list.

Date picker no longer overlaps icon.

Fixed an issue where the table configuration menu did not hide and overlapped a record after changing the configuration.

Added Renew option to upload the original certificate for recertification when creating an offline request.

Fixed a bug that caused errors when a CRL was changed from full and complete to a "lesser" scope. The interface now does not allow changes that will break the CRL and provides information alerting the requestor.

Breadcrumbs have been moved below the header.

A more useful error is returned when a user tries to create an identical escrowed key.

SAN dnsName now supports up to 255 characters/octets.

The country code is now optional within private SANs.

Including the IssuerAtlernativeName is no longer dependent on the SAN extension having a DirectoryName.

The dropdown should now show all available partitions no matter the quantity.

Various different minor accessibility improvements were added.

Updated icons and names to reflect current branding for DigiCert ONE® services.

CA Manager now allows importing OCSP responders in p12 format.

Corrected an issue where the list of Certificate Revocation Lists (CRLs) assigned to an account would not appear if the view had access to more than one DigiCert ONE account. They should now be visible.