Release notes

Issue

In the Provider.loadPartition function, partition loading failed when the API Key name and Actor name did not match due to incorrect logic enforcing a name match.

Fix

The logic has been updated to correctly load partitions regardless of API Key and Actor name alignment, ensuring consistent partition access as supported by Crypto4A HSM.

Issue

When creating an Intermediate CA (ICA) with a PQC CSR (SLH-DSA or ML-DSA) using the Provide a CSR signed by your own CA option, the system previously populated the Allowed signature algorithms field with all available algorithms.

Fix

This has been fixed so that, for PQC ICAs, the Allowed signature algorithms field now contains only the single algorithm that matches the ICA key size, ensuring correct configuration.

This release adds improved scalability for CRL management by allowing automatic generation of sequenced CRL partitions for an Issuing Certificate Authority. New partitions are created based on user-defined thresholds, such as the number of issued certificates or the estimated size of the CRL file.

This release enhances traceability and operational visibility in CA Manager by adding previously missing actions. It closes existing gaps, enabling users to monitor and validate activities more effectively for compliance and audit needs.

This release addresses an issue where, after re-certifying the issuing root of an Intermediate CA (ICA) and subsequently re-certifying the ICA itself, the re-certified ICA incorrectly retained the issuer serial number from the original root certificate. With this fix, the re-certified ICA now correctly reflects the serial number of the updated (re-certified) root, ensuring accurate certificate chaining and improved trust path integrity.

Issue

Following the upgrade to Luna client version 10.9, CRL generation for Ed25519 keys started failing. This was due to a change in the key type identifier—Ed25519 now uses key type value 64 instead of the previous identifier (CKK_EC_EDWARDS).

Fix

Code has been updated to recognize and use key type 64 for Ed25519, restoring CRL generation functionality.

The on-premise DigiCert® Private CA now enforces license limits for the creation of Root and Intermediate CAs (ICAs), aligning with the enforcement model used in DigiCert DC1/CA Manager. License limits are embedded in the license payload and are validated during installation, updates, and CA creation. If a user attempts to create a CA beyond the licensed limit, the system blocks the operation and displays a clear, actionable error message.

The on-premise DigiCert® Private CA now extends HSM support to include:

A new certificate preview feature has been added to allow users to verify certificate content prior to signing. This preview certificate is returned for display, enabling users to review the final output before executing a real signing operation. The same preview capability remains available after signing as well.

With this release, On-Prem Private CA now allows OCSP responses to be served and the latest published CRL to remain accessible even after the license expires, enhancing the reliability of certificate validation. This implementation aligns On-Prem CA functionality with CA Manager, ensuring that validation services continue to operate for already issued certificates.

This implementation aligns On-Prem CA functionality with CA Manager, ensuring that validation services continue to operate for certificates that have already been issued.

The system now enforces automatic revocation of all prior CAs when a renewed (recertified) Private CA is revoked to strengthen certificate lifecycle consistency. This ensures that the entire CA chain is properly invalidated, reducing the risk of trust misconfiguration or misuse of older CA certificates.

This release introduces support for delegated OCSP responders to enhance flexibility in signing OCSP responses, particularly in environments where root and intermediate certificate authorities (ICA) are offline or where key protection requirements mandate delegation.

Resolved an issue that prevented recertification of CAs created using MLDSA and SLHDSA root templates. Users can now successfully recertify root and intermediate CAs based on these Post-Quantum algorithms using the Recertify option on the CA details page.

Resolved an issue where the Number of ICAs column in the Root CA list incorrectly displayed 0 for all Root CAs, despite each having associated Intermediate CAs. The correct ICA count now loads immediately without requiring the user to click into each Root CA.

With this release, the on-premise DigiCert® Private CA now supports Linux operating systems with 64-bit binaries on AMD64 architecture, in addition to traditional Kubernetes-based deployments. This offers greater flexibility for customers standardizing on Linux-based infrastructure. The core features and deployment models remain the same.

For more information, see On-premise DigiCert® Private CA.

When issuing private trust certificates, DigiCert® Private CA now supports Subject Alternative Name (SAN) entries of type dNSName that begin with an underscore (_).

Fixed an issue where the custom template editor failed to load in air-gapped on-premises environments due to external resource dependencies. All required files (for example, Monaco Editor) are now bundled locally, ensuring full offline functionality.

Private CA now allows you to issue Elliptical Curve Cryptography (ECC) certificates with the KeyEncipherment and DataEncipherment key usages (KUs), enabling compatibility with third-party tools require the key usages.

"key_usage": {
  "critical": true,
  "skip_validation": true,
  "required_usages": {
    "ECC": [
      "digital_signature",
      "non_repudiation",
      "key_encipherment",
      "data_encipherment"
  }
}

The "signature algorithm" selection for template-based CRL creation under offline root or intermediate certificate authorities (CAs) is now restricted to match the issuer’s key algorithm to ensure cryptographic consistency. This change prevents misconfiguration by disallowing incompatible combinations, such as using a different ML-DSA variant than the CA’s key for CRL signing.

We updated the Multi-use AATL Signing ICA profile in Ceremony Manager to align with the latest specifications effective after May 1, 2025. Key changes include the following:

These updates ensure the profile adheres to revised compliance and usage requirements across AATL, Microsoft, and general signing use cases.

The audit log now captures CRL scope changes by recording both the previous and updated scope values (for example, “Partition” to “Complete”). This enhancement improves traceability and accountability, ensuring that any scope changes impacting certificate revocation visibility can be accurately audited and attributed.

Fixed an issue where the Organization Name field was not populated in the database when generating an Intermediate CA certificate CSR (certificate signing request) for offline signing. This bug caused sorting and display inconsistencies after the signed certificate was imported back. The Organization Name field is now correctly stored during CSR creation, ensuring consistent behavior across offline ICA workflows.

このリリースでは、DigiCert® Private CA 内で Crypto4A 製 HSM （ハードウェアセキュリティモジュール）が新たにサポートされ、ML-DSA アルゴリズム（最終版）を使用したハードウェアベースの耐量子コンピューター暗号（PQC）をサポートできるようになりました。この統合により、PQC のユースケースに対して本番対応が可能となり、将来的なアルゴリズム拡張にも備えられます。また、Crypto4A によって発行された PQC 証明書に対して CRL （証明書失効リスト）のサポートも追加され、標準規格に準拠したセキュアな証明書ライフサイクル管理の取り組みがさらに強化されました。

主な機能:

このリリースでは、CA Manager の UI （ユーザーインターフェース）を更新し、CA 証明書のサブジェクトに含まれる組織名を表示することで、認証局の視認性と管理性を向上させました。

強化機能:

CA Manager で、未管理 CA の SubjectDN の順序の設定がサポートされました。

強化機能:

この SubjectDN の変更が重要な理由

特定の業界仕様やプロトコルでは、SubjectDN の属性を特定の順序でエンコードする必要があります。このアップデートにより、そうしたシナリオにも確実に準拠し、利用システムと相互互換性の問題が発生するリスクを軽減できます。

CA Manager で、ルート CA 証明書および ICA （中間 CA）証明書に対する設定可能な AKI （認証局の鍵識別子）拡張がサポートされました。

強化機能:

このリリースでは、MariaDB を管理対象の依存関係として含む Helm チャートを使用し、DigiCert On-premises Private CA を Kubernetes にデプロイできるようになりました。これにより、外部データベースの設定を要することなく、合理的な自己完結型のデプロイが可能となり、複雑さが軽減され、移植性が向上します。

主な機能:

ルート CA 証明書または中間 CA 証明書を発行する際に、カスタムの鍵使用方法を使用できないという制限を解消しました。これまでは、証明書テンプレートが既定の鍵使用方法の値を上書きできず、CA のロールを柔軟に設定できませんでした。

強化機能:

このリリースでは、耐量子コンピューター暗号アルゴリズムを使用する CA に対する検証とエラー処理が改善されました。このリリースには、メッセージング機能の強化、未サポートの設定のより適切な処理、ならびに CA 作成時の無効な設定を防ぐための保護機能が含まれています。

Private CA で、ルート証明書、ICA （中間 CA）証明書、およびエンドエンティティ証明書に対して、証明書ポリシーや設定を定義、管理、再利用できる、カスタムの JSON ベース証明書テンプレートがサポートされました。

カスタムテンプレートの機能:

このリリースでは、認証局（ICA またはルート CA）の有効期限が近づいた際に、証明書の発行を継続できるようにする CA の再認証機能を導入しました。この機能は、以前のバージョンでは「更新」と呼ばれる場合もありましたが、今回からシステム全体で「再認証」という呼び名に統一されました。

再認証の機能:

再認証後の機能:

制限事項:

CRL （証明書失効リスト）が ML-DSA （Multi-Lattice Digital Signature Algorithm）証明書に対応しました。これにより、耐量子コンピュータ暗号証明書に対して標準規格に準拠した失効処理が可能になりました。ML-DSA 証明書を CRL に追加できるようになりました。ML-DSA 証明書は、承認済みの ML-DSA アルゴリズムで正しく署名されるとともに、RFC 5280 （適切な DER エンコーディングと構造を含む）に完全に準拠します。すべての ML-DSA 証明書に crlDistributionPoints 拡張が正しく入力されるため、標準的な失効確認メカニズムと互換性も確保されています。

Ceremony Manager （CM）が、デジサートのタイムスタンプサービス向けに、新しいエンドエンティティ（EE）証明書をオフラインで発行できるようになりました。これは、発行者の秘密鍵をオフラインで保管することを求める最新のベースライン要件（BRS）に準拠するための変更です。Ceremony Manager には タイムスタンプユニット（TSU）という名前の EE プロファイルが新たに追加され、テンプレートに依存せずにオフラインの EE 要求を作成できるようになりました。

その他の強化機能:

証明書管理の簡素化と自動化を目的として、フィルタリングおよびスケジューリング機能が強化された新しい証明書一覧取得用エンドポイントを DigiCert® Private CA に追加しました。

証明書一覧取得エンドポイントの機能:

このアップデートにより、DigiCert® Private CA 環境における DigiCert ONE Trust Lifecycle Manager を通じたポリシーベースの検出および管理がシームレスに行えるようになります。

暗号標準の進化に対する継続的な取り組みの一環として、Private CA に以下のポスト量子暗号に関するアップデートを導入しました。

これらの変更は、すべての DigiCert CA プラットフォームにおいて、セキュアで標準規格に準拠した暗号運用を推進するというデジサートの積極的な取り組みの一環です。

このリリースでは、Private CA システムに、ライセンスに指定された end_date を検証することによるライセンス有効期限の強制適用が追加されました。ライセンスの有効期限が切れると、アプリケーションはアクセスを制限し、自動的にシャットダウンして、再起動の試みをすべてブロックします。タイムゾーン間での一貫した動作を維持するため、ライセンスの検証は協定世界時（UTC）に基づいて行われます。ライセンスの内容を改ざんしようとした場合、そのライセンスは拒否されます。このアップデートにより、システムは期限付きの、有効なライセンスでのみアクセスおよび操作できるようになります。

CA Manager で、専用の鍵管理のためにクライアントが独自に所有する HSM （ハードウェアセキュリティモジュール）を使用することがサポートされました。この機能の導入により、クライアントは、他の認証局（たとえばコード署名用）で管理されていた鍵を、鍵の再生成や移行による遅延なしに引き続き使用できるようになります。

主な機能:

現在の制限事項:

Swagger API 文書が DigiCert® Private CA に統合され、可視性、使いやすさ、開発者エクスペリエンスが向上しました。

鍵に関するアップデート:

外部にホストされている ICA について、セレモニー作成エクスペリエンスを簡素化するため、複数の UI （ユーザーインターフェース）改善を行いました。これらの変更により、使いやすさが向上し、ワークフローを視覚的に把握しやすくなります。

Private CA で、［ルート認証局］ページと［中間認証局（ICA）］ページにアクセスすると、証明書の組織名（O=）を［Subject Distinguished Name (SubjectDN)］から確認できるようになります。この更新以前は、ルート CA 証明書または中間 CA 証明書の詳細ページに移動しなければ、この情報を確認することはできませんでした。

詳細ページから関連する CA インスタンス間を移動する際（たとえば、ICA（中間 CA）証明書から親のルート CA に移動する、または ルート CA から子の ICA 証明書に移動するなど）、OCSP（オンライン証明書ステータスプロトコル）レスポンダのフェッチ要求が正しく発生しない問題を修正しました。この問題により、以前に開いた CA インスタンスの OCSP レスポンダーが誤って表示されていました。

この修正により、別の CA インスタンスを開いたときには、アプリケーションが正しく要求を送信して関連付けられた OCSP レスポンダを取得し、選択された CA に対して適切なレスポンダが存在する場合、それが表示されるようになりました。

Digicert On-Prem CA は、最新の共通 UI バージョン 9 および ANTD バージョン 5 利用するようにアップグレードされました。これは、アプリケーション全体にわたって更新が必要な重大な変更です。

すべての OCSP レスポンダ生成パスにおいて、［署名アルゴリズム］フィールドでデフォルトの署名アルゴリズムがあらかじめ選択されるようになりました。

変更点の概要

問題

［失効チェックのみ］オプションでオフラインの ICA （中間 CA）を正常にインポートしたとき、アプリケーションに本来表示すべき「中間 CA がインポートされました。」ではなく、誤って「ルート CA がインポートされました。」という成功メッセージが表示されていました。

修正

成功メッセージがインポートされた CA の種別に合わせて正しく表示されるようになり、分かりやすくなって誤解を防ぐことができるようになりました。

まとめ

運用の可視性を向上させ、HSM パーティションが満杯になることによる予期せぬ障害を防止するため、CA Manager GUI に新しくパーティション監視機能が追加されました。

強化の詳細

パーティションの使用状況を先回りして監視するため、CA Manager GUI に SafeNet HSM 用の新機能が追加されました。

この機能により、ストレージの問題を早期に検出してダウンタイムを防止できるとともに、PKI OPS チームによるパーティション容量の管理が容易になります。

背景

Chrome と Mozilla は、現在、パブリックトラスト TLS 証明書を、サーバ認証のみに目的が限定された中間 CA からのみ発行することを義務付けています。このポリシーの変更をサポートするため、デフォルトの証明書プロファイルに以下の調整を加えました。

まとめ

Chrome と Mozilla のルートストアポリシーの更新に合わせて、デフォルト値の TLS 証明書プロファイルを更新し、新しい要件に準拠するようにしました: TLS 証明書は、TLS 専用の階層構造のチェーンに属している必要があります。これらの変更は、2025 年 3 月 15 日以降に発行される証明書から適用されます。

外部システム向けに、外部委任された OCSP レスポンダ証明書を発行できるようになりました。これらの証明書は DigiCert ONE 外部にホストされ、OCSP 要求のルーティングと応答はクライアントが管理します。

新しい要求フォーム、CSR アップロードオプション、API 文書の強化など、UI （ユーザーインターフェース）と API サポートを追加しました。

サンドボックス環境の New Relic メトリクスに、SQL ステートメントと接続タイプが追加され、観測可能性とパフォーマンス分析が向上しました。New Relic のラップされたデータベースドライバは、New Relic が明示的に構成された場合にのみ条件付きでロードされるようになり、不必要な依存関係やオーバーヘッドの可能性を防ぐことができるようになりました。

問題: registeredID SAN（Subject Alternative Names）が、CA Manager によって DER エンコードされた OBJECT IDENTIFIER（OID）ではなく、ASCII 文字列として誤ってエンコードされていました。

修正: registeredID SAN を DER 形式の OID として正しくエンコードするよう、エンコードロジックを修正しました。これにより、RFC 5280 に準拠し、標準に準拠したクライアントおよびアプリケーションとの相互運用性が確保されます。

これまで、フロントエンド（FE）を介してハードウェアセキュリティモジュール（HSM）パーティションを［選択したアカウント］に割り当てる際、少なくとも 1 つの［許可された使用］（［新しい CA 鍵］、［新しい OCSP レスポンダの鍵］、または［鍵預託］）を選択する必要がありました。一方、バックエンド（BE） API を介してパーティションを登録または編集する場合は、この制限が適用されていませんでした。

変更

API を介して HSM パーティションを［選択したアカウント］に割り当てる際も［許可された使用］の制限を適用し、バックエンドの動作がフロントエンドと一致するようにしました。この変更により、両方のインターフェースで一貫した認証が行われ、設定ミスを防ぐことができます。

影響:

今後、API ユーザーが［選択したアカウント］に HSM パーティションを割り当てる際、［許可された使用］を少なくとも 1 つ指定する必要があります。

Digicert On-Prem CA は、企業のセキュリティ要件に準拠した、証明書の発行、ライフサイクル管理、セキュリティポリシーを完全に制御可能な、セキュアかつ自動化された X.509 証明書管理を提供するプライベート認証局（CA）です。

プライベート証明書において、SAN:dnsName フィールドでアンダースコアが使用可能になりました。

今後、プライベート証明書において、RSA 公開指数として 2¹⁶  < e < 2²⁵⁶ の範囲がサポートされます。

継続的なセキュリティおよびコンプライアンス対策の一環として、OCSP no-check 拡張（RFC 6960 のセクション 4.2.2.2 で定義された id-pkix-ocsp-nocheck）がクリティカルな拡張としてマークされている OCSP レスポンダをブロックする変更を導入します。OCSP no-check 拡張は、OCSP レスポンダ証明書の失効チェックを免除するためのものです。これは長寿命の OCSP レスポンダには必要かもしれませんが、この拡張をクリティカルとしてマークすると、失効のバイパスが強制され、セキュリティリスクが生じる可能性があります。特に、この拡張がクリティカルとしてマークされているレスポンダは、たとえ侵害されても、無期限に信頼され続けるため、証明書の検証メカニズムの効果が損なわれる場合があります。

影響:

パフォーマンスと効率性を高めるため、証明書発行時のデータベースおよび HSM への呼び出し回数を削減する新しいキャッシュモジュールが導入されました。

預託鍵で署名する機能のパフォーマンス分析により、公開鍵の取得時に HSM のルックアップが頻繁に発生し、効率が低下していることが判明しました。パフォーマンスを最適化するため、署名鍵と併せて公開鍵もキャッシュされるようにしました。

更新ジョブのポーリングサイクルが設定可能となり、テスト自動化が容易になりました。また、必要に応じてユーザーがキャッシュを無効化できるようになりました。

OCSP レスポンダ証明書の valid_to が CA 証明書の valid_to の 10 秒以内である場合、不要な新しい OCSP 応答者証明書を生成しないよう最適化されました。

これまでの動作

新しい動作

OCSP レスポンダ証明書に含まれる ocsp no check 拡張を非クリティカルに設定

この修正により、新しいプロキシアプリを追加する際に Authcode を表示してアクセスできるようになりました。Authcode は、CA Manager とリモートプロキシアプリの接続を設定するために必要です。

登録済みの HSM パーティションから RSA、ECC、または EdDSA のキーペアを CA Manager のキーペアレコードへインポートし、LUNA Safenet システムの Software Trust Manager ワークフロー内での署名プロセスに利用できるようになりました。

パブリック TLS 向けのプレ証明書を作成し、CT ログに送信して署名されたバージョンを取得し、証明書として発行できる機能を追加しました。

証明書作成時の PathLen 変更フローに関する軽微な修正を行いました。

ECDSA 鍵および SHA3 を用いた発行と預託をサポートしました。

適格エンドエンティティテンプレートに BasicConstraints を再度追加しました。

HSM リモートプロキシバンドルのダウンロードオプションを複数追加し、Thales G5 USB HSM にも対応しました。

選択したルート CA のファミリーツリーを視覚的に表示できる新しい機能を追加し、階層間の移動を容易にしました。

サブジェクトの Surname と GivenName の各フィールドで最大 64 文字まで入力できるようにしました。

HSM 機能管理の基盤となるプロセスにさまざまな調整を加えました。

AIA のアクティブ化と非アクティブ化の機能を修正しました。

証明書有効期限を表示すると、テーブルの読み込み中にハングアップする問題を修正しました。

作成された複数の AIA が証明書に含まれるようになりました。

サードパーティ機能がルート CA 証明書だけでなく中間 CA 証明書にも対応しました。

最初に署名 OID を確認して PureEd448 または PreHashedED448 のどちらを使用しているかを判断し、適切な関数を使用して検証するようになりました。

バックエンドのロジックを修正して表示テーブルのロジックを簡素化し、オーバーヘッドを削減しました。

ログでキャプチャされるイベントを拡充しました。

さまざまなメール検証ポイント間で一貫したロジックが使用されるように調整しました。

幅広い部分のアクセシビリティに手を加え、改善しました。

幅広い部分のアクセシビリティに手を加え、改善しました。

様々な箇所におけるアクセシビリティやインターフェイスの使い勝手に手を加え、改善しました。

いくつかのセキュリティ上の改善を実施しました。

タイムゾーンや SCEP 登録に関する特有の問題に対処するため、マネージャは、notBefore の有効期間が過去の日付になっているエンドエンティティを提出できるようになりました。

DPoD の適切なリージョンの選択をわかりやすくするため、リージョンをメニューから選択できるようになりました。

アクセシビリティおよびユーザーエクスペリエンスの向上を目的として、さまざまな改善を実施しました。

NIST は PQC アルゴリズムの最終バージョンをまだ確定しておらず、PKI 標準団体も規格を定めていません。Dilithium （ML-DSA）、SPHINCS+ （SLH-DSA）、Falcon （FN-DSA）などの PQC アルゴリズムは、いずれもテスト目的でのみ使用され、後方互換性のないアップデートが行われる可能性があり、機能もまだ不完全です。

また、パフォーマンスを確保するために、PQC のサポートは SoftHSM 経由でのみ提供されます。ハードウェア HSM （Safenet）でのサポートは、ベンダーがネイティブな PQC サポートを提供次第に対応予定です。

共通 UI を更新し、電話およびローカライズオプションにおける国旗アイコンの表示不具合を修正しました。

PathLen の適用方法を変更し、オペレーション担当者がオフラインリクエストを柔軟に作成できるようにしました。

同名アカウントの識別性を向上するため、アカウントのフレンドリ識別子を表示するようにしました。

エバーグリーン証明書を発行可能な CA によって署名される 別の CA が、長い有効期間を設定できなかった問題を修正しました。

NIST は PQC アルゴリズムの最終バージョンをまだ確定しておらず、PKI 標準団体も規格を定めていません。Dilithium （ML-DSA）、SPHINCS+ （SLH-DSA）、Falcon （FN-DSA）などの PQC アルゴリズムは、いずれもテスト目的でのみ使用され、後方互換性のないアップデートが行われる可能性があり、機能もまだ不完全です。

また、パフォーマンスを確保するために、PQC のサポートは SoftHSM 経由でのみ提供されます。ハードウェア HSM （Safenet）でのサポートは、ベンダーがネイティブな PQC サポートを提供次第に対応予定です。

EU および北米の DigiCert ONE プラットフォームとの互換性を確保するために、HSM 登録時に Thales DPoD のリージョンコードが必要になりました。

メール機能を再設計し、ローカライズに対応しました。翻訳が完了すると、受信者は希望の言語を選択できます。

コードベースを定期的にスキャンし、新たに発見された問題や脆弱性を修正して、セキュリティを最新状態に保っています。

外部 CSR を介して CA を作成した際、デフォルトでエクスポート可能とされてしまう問題を修正しました。現在、CA をエクスポート可能としてマークするには、明示的に選択する必要があります。

NIST は PQC アルゴリズムの最終バージョンをまだ確定しておらず、PKI 標準団体も規格を定めていません。Dilithium （ML-DSA）、SPHINCS+ （SLH-DSA）、Falcon （FN-DSA）などの PQC アルゴリズムは、いずれもテスト目的でのみ使用され、後方互換性のないアップデートが行われる可能性があり、機能もまだ不完全です。

また、パフォーマンスを確保するために、PQC のサポートは SoftHSM 経由でのみ提供されます。ハードウェア HSM （Safenet）でのサポートは、ベンダーがネイティブな PQC サポートを提供次第に対応予定です。

MGF パラメータおよび 2048、3072、4096、8192 のソルト長に対応しました。

CRL 配布ポイントの作成で、ファイルディレクトリパスをスキーマとして指定できるようになりました。また、"somedomain.com/subdir1/subdir2/" のようなトップレベルドメイン以下の Web URL をサポートするオプションも CA サービスに追加しました。

また、新しい作成プロセスのフローをサポートするために、CRL 作成フォームも更新しました。

各 DigiCert ONE Manager で、デフォルトでエンドエンティティ証明書に含まれる SKI または AKI 拡張を省略できるようになりました。

内部的な処理をいくつか調整しました。

削除された［すべてのアカウント］オプションは不明瞭でした。現在は、特定のアカウントと、［なし］のみが表示されます。［なし］を選択すると、アカウントを持たないシステムスコープユーザーを含むすべてのユーザーが HSM パーティションにアクセスできます。

現在は修正されており、期待通りに動作します。

OCSP レスポンダの有効期間が、親 CA の有効期間を超えることがないように制限されました。

NIST は PQC アルゴリズムの最終バージョンをまだ確定しておらず、PKI 標準団体も規格を定めていません。Dilithium （ML-DSA）、SPHINCS+ （SLH-DSA）、Falcon （FN-DSA）などの PQC アルゴリズムは、いずれもテスト目的でのみ使用され、後方互換性のないアップデートが行われる可能性があり、機能もまだ不完全です。

また、パフォーマンスを確保するために、PQC のサポートは SoftHSM 経由でのみ提供されます。ハードウェア HSM （Safenet）でのサポートは、ベンダーがネイティブな PQC サポートを提供次第に対応予定です。

ルートおよび ICA の情報の横に表示されるアイコンに脈絡がなく、混乱を招いていました。購入済みのルートまたは ICA をアカウントが消費済みの場合、緑色のチェックマークが表示されるようになりました。さらに、ロールオーバー時に、コンテキストを提供するツールチップが表示されるようになりました。

オフライン要求で PathLen を変更できないバグを修正しました。

［無効］でフィルタリングしても、失効済みの証明書が一覧に表示されていた問題を修正しました。

サブジェクトのコモンネームを持たない CA をインポートできなかった問題を修正しました。

nil ポインタに関する軽微な問題を修正しました。

一意でないアカウント名もサポートするようになりました。

内部セレモニーツールで、デジサート外部でホストされているルートに対するクロス署名をサポートしました。

キーペアが削除された場合や存在しない場合、400 "not found" エラーが返されるようになりました。

エラーが修正され、オフライン CA 要求のパス長を変更できるようになりました。

NIST は PQC アルゴリズムの最終バージョンをまだ確定しておらず、PKI 標準団体も規格を定めていません。Dilithium （ML-DSA）、SPHINCS+ （SLH-DSA）、Falcon （FN-DSA）などの PQC アルゴリズムは、いずれもテスト目的でのみ使用され、後方互換性のないアップデートが行われる可能性があり、機能もまだ不完全です。

また、パフォーマンスを確保するために、PQC のサポートは SoftHSM 経由でのみ提供されます。ハードウェア HSM （Safenet）でのサポートは、ベンダーがネイティブな PQC サポートを提供次第に対応予定です。

一貫性を高めるため、ユーザーインターフェースを微調整しました。

オフラインルートを無効化しようとすると、その操作が許可されていないことを明確に示すエラーメッセージが表示されるようになりました。

その他、軽微な内部的バグを修正しました。

NIST は PQC アルゴリズムの最終バージョンをまだ確定しておらず、PKI 標準団体も規格を定めていません。Dilithium （ML-DSA）、SPHINCS+ （SLH-DSA）、Falcon （FN-DSA）などの PQC アルゴリズムは、いずれもテスト目的でのみ使用され、後方互換性のないアップデートが行われる可能性があり、機能もまだ不完全です。

また、パフォーマンスを確保するために、PQC のサポートは SoftHSM 経由でのみ提供されます。ハードウェア HSM （Safenet）でのサポートは、ベンダーがネイティブな PQC サポートを提供次第に対応予定です。

SoftHSM オプションで、最新バージョンの Dilithium （ML-DSA）、SPHINCS+ （SLH-DSA）、Falcon （FN-DSA）がサポートされるようになりました。

PQC は、パフォーマンスおよびバージョンサポートの観点から、ハードウェア HSM ではサポートされなくなりました。  CA サービスでのハードウェア HSM サポートは、NIST が最終仕様を策定し、ネイティブサポートが提供された後、2024 年後半に提供予定です。

［Define a path length over 0］オプションを選択した際、数値入力フィールドにデフォルトで「-1」という誤った値が表示されてしまっていた問題を修正しました。

NIST は PQC アルゴリズムの最終バージョンをまだ確定しておらず、PKI 標準団体も規格を定めていません。Dilithium （ML-DSA）、SPHINCS+ （SLH-DSA）、Falcon （FN-DSA）などの PQC アルゴリズムは、いずれもテスト目的でのみ使用され、後方互換性のないアップデートが行われる可能性があり、機能もまだ不完全です。

ルートまたは CA の作成時にフォームの後半のページを表示している状態で前のページに戻っても、以前入力したデータが保持および表示されるようになり、再入力の必要がなくなりました。

機能を先にデプロイしておき、後からリモートで有効化/無効化できるサービスを導入しました。これにより、デプロイやロールバックによる影響を抑えることができ、テストも簡素化されます。この変更はお客様からは見えませんが、全体的なユーザーエクスペリエンスの向上が期待されます。

ICA およびルート CA のレコードテーブルで、複数のフィルタオプションによる絞り込みが可能になりました。

お好みの言語を選択するドロップダウンでオランダ語およびポルトガル語を選択しても、対象言語で表示されない不具合を修正しました。

インポートしたサードパーティのルートが、アプリケーションによって自動的かつサイレントに無効化されるバグを修正しました。

海外のユーザー向けに、言語ローカライズのカバー範囲を拡大しました。ポルトガル語が正しく適用されない問題については、現在修正中です。

登録するパーティションの選択を容易にするため、HSM パーティションテーブルレコードにアクションメニューを追加しました。

この問題は修正され、現在は、新しく選択した内容に応じてアカウントフィールドが自動で入力されるようになりました。

実装は変更される可能性があります。

NIST は PQC アルゴリズムの最終バージョンをまだ確定しておらず、PKI 標準団体も規格を定めていません。Dilithium、SPHINCS+、Falcon などの PQC アルゴリズムは、いずれもテスト目的でのみ使用され、機能もまだ不完全です。

アカウントフィルタ設定後にテーブルが正しく更新されて表示されるようになりました。

CA Manager は、HSM リモートプロキシアプリケーション用に入力された URL がすでに存在するかどうかをチェックするようになりました。

Dilithium （MLDSA）ベースのエンドエンティティ証明書を SoftHSM から発行できるようになりました。

SPHINCS+ （SLHDSA）耐量子コンピューターアルゴリズムによるダイジェスト署名が可能になりました。

PQC に対応した SoftHSM とハードウェア HSM の両方で、SPHINCS+ ベースの預託クライアント鍵の作成が可能になりました。

テーブルレコード表示が共通 UI に準拠するようになりました。

インポートされたサードパーティのルートがオフラインになる問題を修正しました。現在は、オンライン状態が維持されます。

一連のサブジェクトフィールドを含む送信に対する応答において、全体が処理されたにもかかわらず、一部のサブジェクトフィールドしか API 応答に表示されていませんでした。現在は応答内容が送信内容と一致し、より分かりやくなりました。

HSM の URL を追加または編集しようとすると、CA サービスは、重複が存在しないことを検証してから、操作を受け付けるようになりました。

実装は変更される可能性があります。

NIST は PQC アルゴリズムの最終バージョンをまだ確定しておらず、PKI 標準団体も規格を定めていません。Dilithium、SPHINCS+、Falcon などの PQC アルゴリズムは、いずれもテスト目的でのみ使用され、機能もまだ不完全です。

管理者は、［登録された ID］に単一値または複数値を送信できるようになりました。

ページ数が 2 ページ未満の場合でも、追加ページが表示される問題を修正しました。

実装は変更される可能性があります。

NIST は PQC アルゴリズムの最終バージョンをまだ確定しておらず、PKI 標準団体も規格を定めていません。Dilithium、SPHINCS+、Falcon などの PQC アルゴリズムは、いずれもテスト目的でのみ使用され、機能もまだ不完全です。

PQC 対応のハードウェア HSM パーティション上で、SPHINCS+ アルゴリズムを使用してルート CA および中間 CA を作成できるようになりました。SoftHSM は将来のリリースでサポートされる予定です。

既知の問題: 鍵サイズが大きいため、作成時にタイムアウトが発生することがあります。作成して 10～15 分後に、ルートまたは ICA 一覧に CA が追加されているかを確認してください（通常、SLDHSA-SHA2-128f、SLDHSA-SHA2-128fs、SLDHSA-SHA2-192f は高速です）。非同期処理のサポートを今後のリリースで追加予定です。

PQC 対応のハードウェア HSM パーティション上で、ルート CA、中間 CA、エンドエンティティ証明書を作成できるようになりました。SoftHSM は将来のリリースでサポートされる予定です。

操作性向上のため、これらのページのレイアウト、フィルタ、オプションが統一されました。

実装は変更される可能性があります。

NIST は最終バージョンをまだ確定しておらず、PKI 標準団体も規格を定めていません。Dilithium、SPHINCS+、Falcon などの PQC アルゴリズムは、いずれもテスト目的でのみ使用され、機能もまだ不完全です。

適格自然人テンプレートで、サブジェクトの組織単位および組織 ID フィールドがサポートされるようになりました。

CRLDP の破損を防止するため、「CRL」という使用方法を持つドメインは、発行済み証明書がある場合、CRL 用の使用設定を削除できないようになりました。

Dilithium は MLDSA と表記されるようになりました。

ワイルドカード証明書が再び作成可能になりました。

SoftHSM を使用してテスト用の PQC 証明書を発行できるようになりました。

ユーザーには表示されない内部的な問題を修正しました。

ETSI 仕様に準拠するため、適格エンドエンティティ証明書に EKU が不要になりました。

CRL や OCSP の破損を防ぐため、証明書に割り当てられているドメインは編集できなくなりました。編集するには、新しいバージョンを作成するか、すべての証明書から割り当てを解除する必要があります。

この脆弱性は修正されています。

クライアントが誤ってルートをアップロードできてしまう問題がありました。現在は、アップロードをブロックしてエラーを返すようになりました。

設定を修正し、issue end-entities が再びデフォルトで有効になりました。

API でもユーザーインターフェース（UI）と同様の能力や要件が適用されるようになりました。

CA およびエンドエンティティ発行に限り、CRYSTALS-Dilithium アルゴリズムのテスト使用が可能になりました。OCSP および CRL の作成にはまだ対応していません（作成しようとするとエラーになります）。

ロギング機能が強化され、CA の有効化/無効化イベントやエンドエンティティの署名などの操作がログに記録されるようになりました。

API 経由で設定された CRL スコープが適用されていなかった問題を修正しました。

1) PQC 非対応の HSM で Dilithium キーを使用しようとした場合、2) Dilithium キーを使って発行された証明書に対して、CRL または OCSP を作成しようとした場合に表示されます。

鍵使用方法のグループ化に関する制限を取り除き、クライアントがより柔軟に対応できるようにしました。