Chapter 2. Red Hat Certificate System 10.8 on Red Hat Enterprise Linux 8.10
This section describes significant changes in Red Hat Certificate System 10.8, such as highlighted updates and new features, important bug fixes, and current known issues users should be aware of.
Downgrading Red Hat Certificate System to a previous minor version is not supported.
2.1. Updates and new features in CS 10.8 Copy linkLink copied to clipboard!
This section documents new features and important updates in Red Hat Certificate System 10.8:
Certificate System packages have been rebased to version 11.6.
Certificate System now defaults to Random Serial Numbers
If you are migrating from Certificate System 10.6 to Certificate System 10.8, note that Certificate System 10.8 now defaults to Random Serial Numbers v3 (RSNv3).
If the Certificate System 10.6 instance was using SSN or RSNv1, it will continue to work as is after migrating to Certificate System 10.8. You can switch to RSNv3 if required.
If you install a new Certificate System 10.8 instance, RSNv3 will be used by default unless you explicitly configure it to use Sequential Serial Numbers (SSN) or RSNv1.
Note: After migrating to RSNv3, switching back to SSN RSNv1 is not supported.
Certificate System now supports Sequential Serial Numbers v2
Sequential Serial Numbers v2 (SSNv2) works the same as SSNv1 with serial numbers but requires a different configuration and solves the issues with contiguous range allocation for the certificate serial numbers.
Notes:
SSNv2 is only supported for requests and certificates in CA.
SSNv2 is not supported for random serial numbers using dbs.enableRandomSerialNumbers=true
. Use RSNv3 instead.
SSNv2 is not supported for requests and keys in KRA. Use RSNv3 instead.
Certificate System now supports Enrollment over Secure Transport protocol
Support for the Enrollment over Secure Transport (EST) protocol has been added to RHCS. EST is a cryptographic protocol designed to provide secure certificate enrollment for devices. EST is designed for automated enrollment and certificate management. For more information on EST, see RFC7030.
For more details on installation, refer to the Planning, Installation, and Deployment Guide and for more details on configuring EST, refer to the Administration Guide.
Certificate System now supports OAEP key wrapping algorithm support
Support for Optimal Asymmetric Encryption Padding (OAEP) key wrapping algorithm has been added to RHCS in favor of the older PKCS#1 algorithm. Newer HSM devices and later FIPS-enabled versions of NSS often require this algorithm for use.
There are two scenarios where OAEP is most often used:
- Within our RHCS subsystems such as the KRA, TPS, and TKS.
- Used through various command line tools that interact with one of the RHCS subsystems.
For more details on installation, refer to the Planning, Installation, and Deployment Guide and for information on configuring OAEP, refer to the Administration Guide.
Certificate System supports purging of expired certificates
You can now configure CA database pruning, which allows you purge expired certificates and certificate request records from the CA database. Previously, there was no method for doing this and the database continued to grow and it had the potential to causes issues with stored, performance degradation and increased costs.
Note: In order to remove the records safely, the CA needs to use the RSNv3 to generate the certificate serial numbers and enrollment/renewal request IDs.
The CA in RHCS provides a pruning job that removes:
- Certificates that have expired for some time
- Completed requests corresponding to the expired certificates
- Incomplete requests that have been idle for some time
You should schedule the job to run regularly to remove a certain number of records each time it is run. The remaining records will be removed in the subsequent runs. In large deployments it will be possible to distribute the job among the servers in the cluster.
Added password policy to enforce configured password complexity
A new password policy option has been provided to enforce the password quality defined by the user during the enrollment with server-sde key generation. This enables customers to increase the security of exchanged PKCS #12 files with generated certificates and keys.
The policy allows you to set:
-
password.minSize
: The minimum size for the password. -
password.minUpperLetter
: The minimum number of uppercase letters. -
password.minLowerLetter
: The minimum number of lowercase letters. -
password.minNumber
: The minimum number of digits. -
password.minSpecialChar
: The minimum number of punctuation characters. -
password.seqLength
: The size of substring sequence which cannot be repeated. -
password.maxRepeatedChar
: Maximum number of times a character can be repeated.
You can configure password complexity for each profile but default values can be configured in CS.cfg
.
ACME is now fully supported in RHCS
Server certificate issuance via an Automated Certificate Management Environment (ACME) responder is now fully supported in Red Hat Certificate System (RHCS). The ACME responder supports the ACME v2 protocol (RFC 8555).
Previously, users had to use the Certificate Authority (CA)'s proprietary certificate signing request (CSR) submission routines. The routines sometimes required certificate authority (CA) agents to manually review the requests and issue the certificates.
The RHCS ACME responder now provides a standard mechanism for automatic server certificate issuance and life cycle management without involving CA agents. The feature allows the RHCS CA to integrate with existing certificate issuance infrastructure to target public CAs for deployment and internal CAs for development.
For more information, see the IETF definition of ACME.
2.2. Technology Previews Copy linkLink copied to clipboard!
There are no Technology Previews in this release.
2.3. Bug fixes in CS 10.8 Copy linkLink copied to clipboard!
The Pretty Print Certificate utility now displays the Inhibit Any-Policy extension correctly in a certificate
Previously, if you used the Pretty Print Certificate utility to view a certificate, the Inhibit Any-Policy
extension displayed incorrectly, only displaying the OID value and not the extension name.
This has been fixed and the information is now displayed correctly as follows:
Identifier: Inhibit Any-Policy - 2.5.29.54 Critical: no
Identifier: Inhibit Any-Policy - 2.5.29.54
Critical: no
2.4. Known issues in CS 10.8 Copy linkLink copied to clipboard!
This part describes known problems you should be aware of in Red Hat Certificate System 10.8, and, if applicable, workarounds.
TPS requires adding anonymous bind ACI access
In previous versions, the anonymous bind ACI was allowed by default, but it is now disabled in LDAP. Consequently, this prevents enrolling or formatting TPS smart cards.
To work around this problem, you need to add the anonymous bind ACI in Directory Server manually:
Issues reinstalling after removing instances using pkidestroy
or pki-server remove
If you install a CA instance and remove it using either the pkidestroy
or pki-server remove
commands, if you try to install the CA instance again, an installation error is returned:
Installation failed: [Errno 2] No such file or directory: '/lib/systemd/system/pki-tomcatd@.service' -> '/etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd@topology-02-CA.service'
Installation failed: [Errno 2] No such file or directory: '/lib/systemd/system/pki-tomcatd@.service' -> '/etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd@topology-02-CA.service'
To workaround this problem, after removing the instance using the pkidestroy
or pki-server remove
commands, remove and reinstall the redhat-pki-packages
.
Known issues in the pki-core
package:
Cloning KRA with HSM fails due to missing attribute in auditSigningCert
When cloning a Key Recovery Authority (KRA) with Hardware Security Module (HSM), the auditSigningCert
trust attribute u,u,Pu
should get synced implicitly in the alias DB between the master and the clone. However, it now fails to replicate in the clone’s alias DB. As a consequence, cloning a KRA with HSM fails with the error auditSigningCert cert-topology-02-KRA KRA is invalid: Invalid certificate: (-8101) Certificate type not approved for application
.
To work around this problem, you must add the u,u,Pu
trust attribute for auditSigningCert
explicitly in the alias DB of the clone KRA and restart the instance. For example:
Before the workaround:
certutil -vv -V -d /var/lib/pki/clone-KRA/alias/ -h nfast -n 'token:auditSigningCert cert-topology-02-KRA KRA' -u J
# certutil -vv -V -d /var/lib/pki/clone-KRA/alias/ -h nfast -n 'token:auditSigningCert cert-topology-02-KRA KRA' -u J Enter Password or Pin for "token": certutil: certificate is invalid: Certificate type not approved for application.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow After the workaround:
certutil -M -d /var/lib/pki/clone-KRA/alias/ -n 'token:auditSigningCert cert-topology-02-KRA KRA' -t u,u,Pu certutil -vv -V -d /var/lib/pki/clone-KRA/alias/ -h nfast -n 'token:auditSigningCert cert-topology-02-KRA KRA' -u J
# certutil -M -d /var/lib/pki/clone-KRA/alias/ -n 'token:auditSigningCert cert-topology-02-KRA KRA' -t u,u,Pu # certutil -vv -V -d /var/lib/pki/clone-KRA/alias/ -h nfast -n 'token:auditSigningCert cert-topology-02-KRA KRA' -u J Enter Password or Pin for "token": certutil: certificate is valid
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Using the cert-fix
utility with the --agent-uid pkidbuser
option breaks Certificate System
Using the cert-fix
utility with the --agent-uid pkidbuser
option corrupts the LDAP configuration of Certificate System. As a consequence, Certificate System might become unstable and manual steps are required to recover the system.