Chapter 5. Red Hat Certificate System 10.1 on Red Hat Enterprise Linux 8.3
This section describes significant changes in Red Hat Certificate System 10.1 on RHEL 8.3, 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.
5.1. Updates and new features in CS 10.1
This section documents new features and important updates in Red Hat Certificate System 10.1:
Certificate System packages rebased to version 10.9.0
The pki-core, redhat-pki, redhat-pki-theme, and pki-console packages have been upgraded to upstream version 10.9.0, which provides a number of bug fixes and enhancements over the previous version.
JSS now provides a FIPS-compliant SSLContext
Previously, Tomcat used the SSLEngine directive from the Java Cryptography Architecture (JCA) SSLContext class. The default SunJSSE implementation is not compliant with the Federal Information Processing Standard (FIPS), therefore PKI now provides a FIPS-compliant implementation via JSS.
Server-Side keygen Enrollment
Many newer versions of browsers have removed the functionality to generate PKI keys and CRMF support for key archival. To resolve this deficiency, Red Hat Certificate System 10.1 introduces a Server-Side Keygen enrollment mechanism: keys are generated on the KRA server and then transferred securely back to the client in PKCS#12.
It is highly recommended to employ the Server-Side Keygen mechanism only for encryption certificates.
Functionality Highlights:
- Certificate request keys are generated on the KRA (Note: a KRA must be installed to work with the CA)
-
The profile default plugin, serverKeygenUserKeyDefaultImpl, provides selection to enable or disable key archival (i.e. the
enableArchival) - Support for both RSA and EC keys
- Support for both manual (agent) approval and automatic approval (e.g. directory password-based)
CA Certificate Transparency with Embedded Signed Certificate Time stamp
Red Hat Certificate System now offers a basic version of Certificate Transparency (CT) V1 support (rfc 6962). It has the capability of issuing certificates with embedded Signed Certificate Time stamps (SCTs) from any trusted log where each deployment site chooses to have its root CA certificate included. The system can be configured to support multiple CT logs. For this feature to work, a minimum of one trusted CT log is required.
It is the responsibility of the deployment site to establish its trust relationship with a trusted CT log server.
Updates and new features in the pki-core package:
Checking the overall health of your public key infrastructure is now available
The pki-healthcheck tool provides several checks that help you find and report error conditions that may impact the health of your public key infrastructure (PKI) environment.
PKI now supports the RSA PSS (Probabilistic Signature Scheme) signing algorithm
With this enhancement, PKI now supports the RSA PSS (Probabilistic Signature Scheme) signing algorithm. To enable this feature, set the following line in the pkispawn script file for a given subsystem: pki_use_pss_rsa_signing_algorithm=True
5.2. Technology Previews
ACME support in RHCS available as Technology Preview
Server certificate issuance via an Automated Certificate Management Environment (ACME) responder is available for 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.
Note that this Technology Preview only includes an ACME server support. No ACME client is shipped as part of this release. Additionally, this ACME preview does not retain issuance data or handle user registration.
Be aware that future Red Hat Enterprise Linux updates can potentially break ACME installations.
For more information, see the IETF definition of ACME.
Note that this feature is offered as a technology preview, provides early access to upcoming product functionality, and is not yet fully supported under subscription agreements.
5.3. Bug fixes in CS 10.1
This part describes bugs fixed in Red Hat Certificate System 10.1 that have a significant impact on users.
Bug fixes in the pki-core package:
Auditors group now available for TPS installations
Previously, LDAP lacked a group entry for TPS-specific Auditors. New installations now feature a default TPS Auditors group. Existing instances require a manual LDAP procedure in order to use this group.
To correct this, run the
ldapmodifyutility to connect to the LDAP server in question and add the missing object:$ ldapmodify -x -D "cn=Directory Manager" -w $PASSWORD << EOF dn: cn=Auditors,ou=Groups,{rootSuffix} changeType: add objectClass: top objectClass: groupOfUniqueNames cn: Auditors description: People who can read the signed audit logs for TPS EOFReplace
{rootSuffix}with the base DN (pki_ds_base_dn) from the TPS configuration file. For exampledc=tks,dc=pki,dc={DOMAIN…},dc={TLD}.
As a result, existing TPS installations can use the Auditors group along with new TPS installations.
5.4. Known issues in CS 10.1
This part describes known problems users should be aware of in Red Hat Certificate System 10.1, 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 until a fix, 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";)
EOFKnown issues in the pki-core package:
Certificates issued by PKI ACME Responder connected to PKI CA may fail OCSP validation
The default ACME certificate profile provided by PKI CA contains a sample OCSP URL that does notpoint to an actual OCSP service. As a consequence, if PKI ACME Responder is configured to use a PKI CA issuer, the certificates issued by the responder may fail OCSP validation
To work around this problem, you need to set the policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0 property to a blank value in the /usr/share/pki/ca/profiles/ca/acmeServerCert.cfg configuration file:
-
In the ACME Responder configuration file, change the line
policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ocsp.example.comtopolicyset.serverCertSet.5.default.params.authInfoAccessADLocation_0= - Restart the service and regenerate the certificate
As a result, PKI CA will generate ACME certificates with an autogenerated OCSP URL that points to an actual OCSP service.
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.
