SupportConsoleDevelopersStart a trialContact

8.4. Known Issues

These are known issues in the 9.0 release of Red Hat Certificate System. When available, workarounds are included.
BZ#1041414
Due to a bug, Certificate System sets an incorrect CA profile ID when you install a TPS. To work around the problem, manually set the op.enroll.delegateISEtoken.keyGen.encryption.ca.profileId parameter in the /var/lib/pki/instance_name/tps/conf/CS.cfg file to caTokenUserDelegateAuthKeyEnrollment: 
op.enroll.delegateISEtoken.keyGen.encryption.ca.profileId=caTokenUserDelegateAuthKeyEnrollment
BZ#1256901
When certain HSMs are used while TLS_ECDHE_RSA_* ciphers are enabled, subsystems experience communication problems. The issue occurs in the following scenarios:
  • When a CA has been installed and a second subsystem is being installed and tries to contact the CA as a security domain, thus preventing the installation from succeeding.
  • While performing a certificate enrollment on the CA, when archival is required, the CA encounters the same communication problem with the KRA. This scenario can only occur if the offending ciphers were temporarily disabled for the installation.
To work around this problem, keep the TLS_ECDHE_RSA_* ciphers turned off if possible. Note that while the Perfect Forward Secrecy provides added security by using the TLS_ECDHE_RSA_* ciphers, each SSL session takes about three times longer to establish. Also, the default TLS_RSA_* ciphers are adequate for the Certificate System operations.
issue tracked upstream
Red Hat Certificate System 9 provides SCEP enrollment using RSA transport certificates only. If ECC certificates are required to be issued using SCEP, the administrator should set up an RSA system certificate to be used for transporting purposes, instead of the CA signing certificate.
BZ#1202527
If a CUID provided by a client is not properly converted in format, the tokenType and keySet mapping resolver framework sometimes fails to evaluate properly the mapping filter for the CUID range (tokenCUID.start / tokenCUID.end).
BZ#1256984
Currently, the External Registration Recovery does not calculate the size of each key to recover individually and only works properly for 1024-bit keys by default. For example, at attempt to recover a certificate with a 2048-bit private key will fail.
To work around this problem, add the following setting to the externalRegAddToToken profile in the CS.cfg file: 
op.enroll.externalRegAddToToken.keyGen.encryption.keySize=2048
This configuration will work if all the requiredcertificates to add have keys of the same size.
BZ#1255963
When using the latest TPS applet version that supports scp01 smart cards, format operations fail on the SafeNet 330 Java (330J) smart card.
Note that the TPS server is currently offered as a Technology Preview and is not yet fully supported under subscription agreements.
BZ#1202526
Token terminations force revocation of all certificates on the token and previously, there was little ability to customize that process. Red Hat Certificate System adds granular control over operations performed on certificates. However, in order to work properly, this feature requires the following list of parameters to be added to the TPS CS.cfg file for all token types: 
op.enroll.tokenType.keyGen.keyType.recovery.terminated.revokeCert
		op.enroll.tokenType.keyGen.keyType.recovery.terminated.revokeCert.reason
		op.enroll.tokenType.keyGen.keyType.recovery.terminated.scheme
The above parameters ensure that the terminated and keyCompromise states can be configured to have different revocation reasons. 
op.enroll.tokenType.keyGen.keyType.recovery.endState.holdRevocationUntilLastCredential = true/false
The above set of new parameters for each token allows to set behavior so that if a certificate is shared by multiple tokens, then that certificate is not revoked until the last token containing that certificate is terminated or lost. If the certificate is finally revoked on the last token, then the status of all the other tokens is set to revoked as well. 
op.enroll.tokenType.keyGen.keyType.recovery.state.revokeExpiredCerts = true/false
The above set of new parameters for each token type allows to set behavior so that expired certificates do not get revoked.
BZ#1255192
In Certificate Manager - Certificate Profiles, if you select a Profile instance that is disabled and click Edit/View to get the Certificate Profile Rule Editor window, changes to the inputs are not applied as they should.
BZ#1253502
When a caDirUserCert certificate is issued, the job notification email is not sent when the job notification for issued certificates is enabled.
BZ#1252952
When using a SCP02 token with the gp211 Coolkey applet, which is currently offered as a technology preview, attempting a re-enroll operation results in a failure near the end of the process.
To work around this problem, perform a format operation before re-enrolling.
BZ#1254804
CRMF key generation request types are no longer supported in Firefox 33, 35 or later. As a consequence, it is no longer possible to perform browser-based enrollments, particularly in the key archival functionality. Note that limited support for simple keygen-based enrollments now exists for the profiles not performing key archival.
To work around this problem, perform enrollments through the pki CLI utility. In Red Hat Certificate System 9, the client-cert-request command supports both PKCS #10 and CRMF certificate requests. To generate and submit a CRMF certificate request with key archival, first download the transport certificate: 
# pki cert-find --name "<KRA Transport certificate's subject common name>"
			# pki cert-show serial_number --output transport.pem
Then, submit the certificate request: 
# pki -c password client-init
			# pki -c password client-cert-request subject_DN --profile caDualCert --type crmf --transport transport.pem
BZ#1257670
When a CA with KRA is installed and an archival attempt through archival-enabled CA profile is made, if the connection between CA and KRA was attempted with the user pkidbuser instead of the subsystem user, the archival attempt fails.
To work around this problem, add the pkidbuser user to the Trusted Managers group.
BZ#1244965
The synchronous key recovery mechanism has been deprecated in Red Hat Certificate System 9. Red Hat recommends to use asynchronous key recovery instead.
BZ#1250741
When cloning a CA and the master CA having serialCloneTransferNumber=0 set, the pkispawn utility currently does not return a proper error message as it should.
BZ#1255431
An incompatibility with the authentication plug-in interface protocol has resulted in the UdnPwdDirAuth plug-in not working properly in Red Hat Certificate System 9.0, so that this plug-in cannot be placed in any profile at this time.
BZ#1250734
When cloning a CA, if the serial number range is less than the value of serialCloneTransferNumber, the pkispawn utility terminates with an exception rather than returning a proper error message.
BZ#1252621
The pkispawn utility uses the following default ports as defined in /etc/pki/default.cfg: 
pki_https_port=8443
				pki_http_port=8080
While pkispawn allows for highly flexible customizations, any attempt to override the default port values using ports that have been pre-allocated for other uses may cause installation or configuration to fail with error messages similar to the following: 
pkispawn    : DEBUG    ....... Error Type: Exception
					pkispawn    : DEBUG    ....... Error Message: port 9180 has invalid selinux context pki_ca_port_t
The availability of a given port can be checked by running the following commands: 
# semanage port -l | grep 9180
						pki_ca_port_t      tcp      829, 9180, 9701, 9443-9447
						# semanage port -l | grep 18443
						(if the port is unused, nothing will be displayed)

Note

Red Hat Certificate System 9 primarily uses the http_port_t SELinux context, even though the default HTTP port 8080 uses http_cache_port_t. The following ports and their SELinux contexts were added to the system policy for previous versions of Red Hat Certificate System, and as such, cannot be used for Red Hat Certificate System 9: 
# semanage port -l | grep pki
								pki_ca_port_t        tcp      829, 9180, 9701, 9443-9447
								pki_kra_port_t       tcp      10180, 10701, 10443-10446
								pki_ocsp_port_t      tcp      11180, 11701, 11443-11446
								pki_ra_port_t        tcp      12888-12889
								pki_tks_port_t       tcp      13180, 13701, 13443-13446
								pki_tps_port_t       tcp      7888-7889
BZ#1246635
The pki user-cert-add command provides an option to import the user certificate directly from CA. However, this option does not work properly if the command is executed over SSL port due to incorrect client library initialization. Consequently, the command fails with the following error message: 
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated.
To work around this problem, download the certificate from CA into a file using the pki cert-show command, then upload the certificate from a file using the pki user-cert-add command.
BZ#1247410
Currently, the ocspResponderURL configuration parameter does not work when it uses a HTTPS secure port. Consequently, trying to enable OCSP checking from the KRA (Key Recovery Authority) subsystem using CA's secure port causes self tests to fail during KRA restart.
To work around this problem, you can safely use an insecure HTTP port because the response is signed and time-stamped.
BZ#1251581
When an enrollment request is submitted using the End-Entity page using the Manual User Signing & Encryption Certificates Enrollment profile, the CA will generate both encryption and signing certificates. However, when the request is submitted using the CRMFPopClient or pki utilities, the CA only generates the encryption certificate.
To work around this problem, the signing certificate can be requested separately.
BZ#1231261
The pkispawn utility has an interactive mode to primarily help users deploy the most straightforward configurations, and become familiar with Red Hat Certificate System. Therefore, pkispawn does not currently provide an interactive session for HSM, cloning subsystems, sub-CA, and externally signed CA.
As a temporary relief, the user is properly informed during the interactive pkispawn session as to which functionality is not yet supported, to prevent any confusion from other related error messages.
BZ#753311
When restarting the CA, SELinux returns AVC denied error messages.
The CA ultimately restarts properly, so these errors can be ignored.
BZ#699456
If an administrator creates a custom log type, any modifications made to the file or to the log file configuration is not recorded in the audit log. This means that the log file is not secure .
BZ#693412
Using the KRA agent's page to search for pending recovery requests does not return the list of pending requests.
Search for the specific recovery request by using the reference number given when the recovery request was submitted. Searching by the reference number successfully returns the recovery request record. From there, the request can be approved by clicking the Grant button.
BZ#678320
Resetting the password on a token with an applet upgrade operation does not work properly. Both the password reset operation and the applet upgrade operation fail.
To work around this problem, disable applet upgrade in the PIN reset profile.
BZ#673182
ECC keys are not supported for signing audit logs. Neither the servers nor the AuditVerify utility support ECC keys for signed audit log files.
To work around this problem, use RSA keys for signing audit logs.
BZ#664594
After a key recovery request is approved and complete, the recovery request page should display a list of which KRA agents approved the recovery. Instead, the Recovery Approving Agents field remains blank.
The recovering page used by agents to approve the request is updated with the list of approving agents. That page can be referenced.
BZ#616532
When attempting to recover keys, if you search for pending requests based on the key identifier and click the Recover button, it returns an error that it had a problem processing the request. The form used to submit the search request sends a malformed request, which results in an invalid X.509 certificate error.
To work around this problem, search for the recovery certificate by pasting in the full certificate blob in the search criteria form.
BZ#512029
If the same HSM partition is used to multiple Red Hat Certificate System subsystem instances, the instance names cannot be used more than once, even if the instances are on different hosts. If the user tries to configure a new instance with the same name (including the default options) as an existing instance, then configuration process stops at the key generation step with an error that the certificate subject name already exists.
To work around this problem, when using an HSM, always specify a distinct pki_XYZ_subject_dn individually.
BZ#226823
An error in the <Connector> entry in the server.xml file causes the server to start and listen on that connector port, but does not provide any services. This problem occurs if the system is configured to use an HSM, not the internal token, and can be recognized by the following JSS configuration error returned by the Tomcat server: 
Failed to create jss service: java.lang.SecurityException: Unable to initialize security library
BZ#454559
Attempting to connect to the Online Certificate Status Manager using the wget utility or HTTP POST to send OCSP requests times out.
To work around this problem, use the OCSPClient utility to send status requests.
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.

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.

© 2024 Red Hat, Inc.