Chapter 2. Red Hat Certificate System 11.0 on Red Hat Enterprise Linux 10.2
This section describes significant changes in Red Hat Certificate System 11.0 on RHEL 10.2, such as highlighted updates and new features, important bug fixes, and current known issues users should be aware of.
2.1. Updates and new features in CS 11.0
This section documents new features and important updates in Red Hat Certificate System 11.0:
New tools added for HSM compatibility verification
This update introduces two simulation tools to verify basic Hardware Security Module (HSM) compatibility with the Dogtag Certificate System without requiring a full installation:
-
hsmCompatVerifyServ- A server-side simulator for Certificate Authority (CA) and Key Recovery Authority (KRA) operations. -
hsmCompatVerifyClnt- A client-side simulator for certificate enrollment.
Both tools support RSA and ECC key operations, key archival and recovery workflows, and PKCS#12 export. As a result, you can validate HSM integration and functionality before deploying a complete Certificate System environment.
The Certificate System now supports ML-DSA keys and signatures
With this enhancement, the Certificate System supports the Module-Lattice-based Digital Signature Algorithm (ML-DSA) for both keys and signatures. Because ML-DSA is standardized by NIST to withstand potential quantum computing threats, the Certificate System can now generate and manage quantum-resistant certificates.
This release supports ML-DSA at three NIST-defined security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87.
2.2. Technology Previews
There are no technology previews in this release.
2.3. Bug fixes in CS 11.0
This part describes bugs fixed in Red Hat Certificate System 11.0 that have a significant impact on users.
Two-step KRA installation with an HSM no longer fails during certificate validation
Before this update, a two-step Key Recovery Authority (KRA) installation using a Hardware Security Module (HSM) failed due to a certificate validation error.
With this release, the validation logic has been updated to verify the certificates correctly during the deployment process.
As a result, the two-step KRA installation with an HSM now completes successfully.
OCSP responder now returns standard error codes for internal errors
Before this update, if the Online Certificate Status Protocol (OCSP) responder encountered an internal error, such as missing Certificate Revocation List (CRL) data, it threw an exception. OCSP clients then interpreted this exception as an invalid response.
With this release, the OCSP responder has been updated to return a proper internal error code as defined in RFC 6960.
As a result, clients can now correctly identify when an internal error occurs on the responder side instead of treating the response as invalid.
pkispawn no longer fails due to invalid Tomcat paths in systemd service files
Before this update, systemd service files referenced incorrect paths for the Tomcat executable and startup scripts, pointing to /usr/bin instead of /usr/sbin. Additionally, an invalid inline comment was present in the service configuration. As a consequence, the pkispawn utility failed during deployment.
With this release, the executable and script paths have been corrected to /usr/sbin, and the invalid comment has been removed from the service files.
As a result, pkispawn now successfully starts the Tomcat service and completes the installation without encountering path-related errors.
2.4. Known issues in CS 11.0
This part describes known problems users should be aware of in Red Hat Certificate System 11.0, and, if applicable, workarounds.
KRATool now supports cross-scheme migration for archived keys
KRATool command now supports a preliminary implementation of cross-scheme migration, allowing migration of archived keys between different key wrapping schemes, for example DES3 to AES, or RSA to RSA-OAEP. This preliminary implementation currently contain a few unresolved issues:
- When the source and target payload wrap algorithm names are identical but the key sizes differ (e.g., AES-128 to AES-256 using "AES KeyWrap/Padding" for both), KRATool generates a session key with the source key size instead of the target key size.
- Cross-scheme migration from DES3 source keys fails because the session key unwrap is hardcoded to use AES. DES3 source keys require DES3 key type with 168-bit strength for the unwrap operation.
- When migrating to an HSM target (e.g., Luna), the target payload wrap algorithm must be set to "AES KeyWrap/Wrapped" instead of the default "AES KeyWrap/Padding". The default maps to an NSS-proprietary PKCS#11 mechanism that HSMs cannot process.
Upgrading without NSS 3.124 causes installation error
To successfully perform an upgrade to Red Hat Certificate System 11, you must have Network Security Services (NSS) version 3.124 or later installed on your system. Otherwise, the upgrade process fails.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}