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.

Note

Downgrading Red Hat Certificate System to a previous minor version is not supported.

2.1. Updates and new features in CS 10.8

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

There are no Technology Previews in this release.

2.3. Bug fixes in CS 10.8

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
Copy to Clipboard Toggle word wrap

2.4. Known issues in CS 10.8

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:

$ ldapmodify -D "cn=Directory Manager" -W -x -p 3389 -h hostname -x <<EOF
dn: dc=example,dc=org
changetype: modify
add: aci
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
EOF
Copy to Clipboard Toggle word wrap

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'
Copy to Clipboard Toggle word wrap

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
      Enter Password or Pin for "token":
      certutil: certificate is invalid: Certificate type not approved for application.
    Copy to Clipboard Toggle word wrap
  • 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
      Enter Password or Pin for "token":
      certutil: certificate is valid
    Copy to Clipboard Toggle word wrap

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.

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat