Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

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
Copiar enlace

This section documents new features and important updates in Red Hat Certificate System 10.8:

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
Copiar enlace

There are no Technology Previews in this release.

2.3. Bug fixes in CS 10.8
Copiar enlace

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

CRL generation performs an unindexed search and times out CA

Due to timing, when pki_ds_setup_vlv=True is set in the pkispawn config file, VLV database reindexing might occasionally fail to complete. To reindex, manually run: 

# pki-server ca-db-vlv-reindex -i <instance_name>

2.4. Known issues in CS 10.8
Copiar enlace

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

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'

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.

  • 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

Using the pki-server cert-fix utility with the --agent-uid pkidbuser option breaks Certificate System

Using the pki-server 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.

Audit signing certificate is no longer created by default

In this release, an audit signing certificate is no longer created during pkispawn by default, since it is only needed when signed audit logging is enabled. The default signedAuditCertNickname is now blank.

If you enable signed audit logging (logSigning=True) without first configuring an audit signing certificate, the CA will fail to start with a Property log.instance.SignedAudit.signedAuditCertNickname missing value error.

To create an audit signing certificate, use one of the following approaches:

  • During installation, specify the pki_audit_signing_nickname parameter in the pkispawn configuration file.
  • For an existing instance, manually create the certificate and set the signedAuditCertNickname parameter in the CS.cfg file.

Manual configuration required for TLS mutual authentication in non-IdM RHCS installations

In this version of Red Hat Certificate System (RHCS), two changes affect TLS mutual authentication (SslClientAuth) setup for KRA, TKS, and OCSP subsystems in non-Identity Management (non-IdM) RHCS installations. This does not affect CA subsystems.

First, the pkidbuser is no longer automatically created for KRA, TKS, and OCSP subsystems. Without this user, TLS mutual authentication between these subsystems and their LDAP directory servers cannot be established.

Second, the pki-server upgrade command, which runs during instance startup, now queries the "Enterprise EST Administrators" group in LDAP. When TLS mutual authentication is enabled, the authenticated subsystem user requires read access to LDAP entries. Without an explicit Access Control List (ACL), the instance fails to start with GroupNotFoundException: Group Enterprise EST Administrators not found.

To complete the TLS mutual authentication setup, perform the following steps for each affected subsystem:

  1. Create the pkidbuser: 

    # pki-server <subsystem>-user-add pkidbuser --full-name "pkidbuser" --type agentType -i <instance>

  2. Export the subsystem certificate: 

    # pki-server cert-export subsystem -i <instance> --cert-file subsystem.crt

  3. Add the subsystem certificate to pkidbuser: 

    # pki-server <subsystem>-user-cert-add --cert subsystem.crt pkidbuser -i <instance>

  4. Grant database access to pkidbuser: 

    # pki-server <subsystem>-db-access-grant UID=pkidbuser,ou=people,<base_DN> -i <instance>

  5. Add the Subsystem Group read access ACL to the base DN using ldapmodify: 

    dn: <base_DN>
changetype: modify
add: aci
aci: (targetattr="*")(version 3.0; acl "Subsystem Group Read Access"; allow (read, search, compare) groupdn="ldap:///cn=Subsystem Group,ou=groups,<base_DN>";)
    Note

    If CmapLdapAttr seeAlso is configured in the Directory Server’s certmap.conf file, the seeAlso attribute containing the subsystem certificate’s Subject DN must also be manually added to the pkidbuser entry.

As a result, the TLS mutual authentication setup functions correctly.

VLV search logic disregards the maxResults parameter

The Virtual List View (VLV) search logic in CMSRequestDAO failed to respect the maxResults parameter.

To work around this problem, use the --size parameter to specify an exact page size for the results. As a result, users can manage the data output volume, although this does not function as a direct maximum result limit.

Missing logger declarations in logging.properties prevents CLI verbose mode from working

The logging.properties file used by pki-server for Java commands is missing logger declarations for com.netscape, org.dogtagpki, and netscape.

As a result, running pki-server commands with -v does not show Java-side INFO messages.

To work around this problem, manually add the following lines to the /usr/share/pki/etc/logging.properties file: 

org.mozilla.jss.level = WARNING
org.dogtagpki.level = WARNING
com.netscape.level = WARNING
netscape.level = WARNING

As a result, when the -v flag is enabled, it correctly controls the output verbosity for pki-server commands.

pki-server status might not reflect critical subsystem failures

The pki-server status command occasionally fails to correctly report the health of specific subsystems. Because the status check does not always account for failures in the internal diagnostic tests (self-tests), the command might report a "running" status even when a critical failure has occurred.

As a result of this known issue, users might continue to use a Certificate Authority (CA) that is not functioning correctly, leading to potential certificate issuance or validation errors.

To work around this problem, do not rely solely on the pki-server status output. Instead, manually monitor the self-test logs located in /var/log/pki/<instance>/ca/selftests.log (or the equivalent path for your subsystem) for any critical failure messages. Manually verifying these logs ensures that the CA and its subsystems are operating as expected.

Intermittent segmentation fault crashes in native NSS and JSS libraries

Intermittent segmentation fault crashes can occur during PKI operations that rely on TLS and native cryptographic libraries, such as pki ca-sd-join, causing the command to fail with a non-zero exit code.

As a result, operations such as pkispawn may fail as a result.

To work around this issue, retry the failed command. Because the crashes are intermittent, re-running the operation typically succeeds.

KRATool fails to recognize the securityDataEnrollment request type

The KRATool utility does not include the securityDataEnrollment record type in its recognized LDIF (LDAP Data Interchange Format) schemas. As a consequence, during Key Recovery Authority (KRA) data migration, the tool skips these specific records and fails with an Unknown LDIF record type=securityDataEnrollment error.

There is currently no workaround for this issue.

The pki-server est-create command fails if the EST directory already exists

The utility does not check for or manage pre-existing Enrollment over Secure Transport (EST) configuration files. This causes the pki-server est-create command to fail with a FileExistsError if the destination directory is not empty.

To work around this problem, run the pki-server est-remove -i <instance> command or manually delete the /var/lib/pki/<instance>/conf/est directory before re-running the creation command.

The pki tps-token-find command may hang after token enrollment

After enrolling a token, the pki tps-token-find command may hang indefinitely when listing all tokens. The tps-token-find <CUID> command to find a specific token may also hang until the TPS server is restarted.

As a partial workaround, restart the TPS server. After restarting, the tps-token-find <CUID> command will return results for a specific token. However, tps-token-find without a CUID may still hang.

Missing instance validation in Java CLI subcommands causes stack trace errors

Several pki-server subcommands throw a stack trace error instead of a user-friendly error message when the specified instance does not exist, or when no instance is specified and the default, such as pki-tomcat, does not exist on the system.

As a workaround, always specify a valid instance name with the -i flag. For example: 

# pki-server ca-cert-find -i <instance_name>

The JAVA_HOME reference in tomcat.conf must be manually updated to Java 17

When upgrading to Red Hat Certificate System (RHCS) 10.8, the` tomcat.conf` file may still reference the Java 8 JDK path instead of the compatible Java 17 JDK. As a consequence, pki-server commands fail with an UnsupportedClassVersionError because newer components require Java 17.

To work around this problem, you must manually update the JAVA_HOME path in the /etc/pki/<pki_instance>/tomcat.conf file. Change the value from /usr/lib/jvm/jre-1.8.0-openjdk to /usr/lib/jvm/jre-17-openjdk.

As a result, the pki-server utility correctly utilizes the Java 17 environment and commands execute successfully.

The pki-healthcheck utility fails on resource-limited systems

The 'pki-healthcheck' utility appears to fail on resource-limited systems.

There is currently no workaround for this problem

pki nss-cert-request fails with a Java exception if the password is omitted

The pki nss-cert-request command does not automatically trigger an interactive password prompt for the NSS database when credentials are missing. As a consequence, omitting the password argument results in a TokenException stack trace instead of a prompt, preventing certificate generation.

To work around this problem, explicitly provide the NSS database password using the -c <password> option. As a result, the utility bypasses the missing interactive prompt and processes the certificate request successfully.

Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2026 Red HatVolver arriba