Chapter 23. Authentication and Interoperability

yum no longer reports package conflicts after installing ipa-client

After the user installed the ipa-client package, the yum utility unexpectedly reported package conflicts between the ipa and freeipa packages. These errors occurred after failed transactions or after using the yum check command. With this update, yum no longer reports errors about self-conflicting packages because such conflicts are allowed by RPM. As a result, yum no longer displays the described errors after installing ipa-client. (BZ#1370134)

In FIPS mode, the slapd_pk11_getInternalKeySlot() function is now used to retrieve the key slot for a token

The Red Hat Directory Server previously tried to retrieve the key slot from a fixed token name, when FIPS mode was enabled on the security database. However, the token name can change. If the key slot is not found, Directory Server is unable to decode the replication manager's password and replication sessions fail. To fix the problem, the slapd_pk11_getInternalKeySlot() function now uses FIPS mode to retrieve the current key slot. As a result, replication sessions using SSL or STTARTTLS no longer fail in the described situation. (BZ#1378209)

Certificate System no longer fails to install with a Thales HSM on systems in FIPS mode

After installing with the Certificate System (CS) with a Thales hardware security module (HSM), the SSL protocol did not work correctly if you generated all system keys on the HSM. Consequently, CS failed to install on systems with FIPS mode enabled, requiring you to manually modify the sslRangeCiphers parameter in the server.xml file. This bug has been fixed, and installation FIPS-enabled systems with Thales HSM works as expected. (BZ#1382066)

The dependency list for pkispawn now correctly includes openssl

Previously, when the openssl package was not installed, using the pkispawn utility failed with the following error:
Installation failed: [Errno 2] No such file or directory
This problem occured because the openssl package was not included as a runtime dependency of the pki-server package contained within the pki-core package. This bug has been fixed by adding the missing dependency, and pkispawn installations no longer fail due to missing openssl. (BZ#1376488)

Error messages from the PKI Server profile framework are now passed through to the client

Previously, PKI Server did not pass through certain error messages generated by the profile framework for certificate requests to the client. Consequently, the error messages displayed on the web UI or in the output of the pki command did not describe why a request failed. The code has been fixed and now passes through error messages. Now users can see the reason why an enrollment failed or was rejected. (BZ#1249400)

Certificate System does not start a Lightweight CA key replication during installation

Previously, Certificate System incorrectly started a Lightweight CA key replication during a two-step installation. As a consequence, the installation failed and an error was displayed. With this update, the two-step installation does not start the Lightweight CA key replication and the installation completes successfully. (BZ#1378275)

PKI Server now correctly compares subject DNs during startup

Due to a bug in the routine that adds a Lightweight CA entry for the primary CA, PKI Server previously failed to compare subject distinguished names (DN) if it contained attributes using encodings other than UTF8String. As a consequence, every time the primary CA started, an additional Lightweight CA entry was added. PKI Server now compares the subject DNs in canonical form. As a result, PKI server no longer adds additional Lightweight CA entries in the mentioned scenario. (BZ#1378277)

KRA installation no longer fails when connecting to an intermediate CA with an incomplete certificate chain

Previously, installing a Key Recovery Authority (KRA) subsystem failed with an UNKNOWN_ISSUER error if the KRA attempted to connect to an intermediate CA that had a trusted CA certificate but did not have the root CA certificate. With this update, KRA installation ignores the error and completes successfully. (BZ#1381084)

The startTime field in certificate profiles now uses long integer format

Previously, Certificate System stored the value in the startTime field of a certificate profile as integer. If you entered a larger number, Certificate System interpreted the value as a negative number. Consequently, the certificate authority issued certificates that contained a start date located in the past. With this update, the input format of the startTime field has been changed to a long integer. As a result, the issued certificates now have a correct start date. (BZ#1385208)

Subordinate CA installation no longer fails due with a PKCS#11 token is not logged in error

Previously, subordinate Certificate Authority (sub-CA) installation failed due to a bug in the Network Security Services (NSS) library, which generated the SEC_ERROR_TOKEN_NOT_LOGGED_IN error. This update adds a workaround to the installer which allows the installation to proceed. If the error is still displayed, it can now be ignored. (BZ#1395817)

The pkispawn script now correctly sets the ECC key sizes

Previously, when a user ran the pkispawn script with an Elliptic Curve Cryptography (ECC) key size parameter set to a different value than the default, which is nistp256, the setting was ignored. Consequently, the created PKI Server instance issued system certificates, which incorrectly used the default ECC key curve. With this update, PKI Server uses the value set in the pkispawn configuration for the ECC key curve name. As a result, the PKI Server instance now uses the ECC key size set when setting up the instance. (BZ#1397200)

CA clone installation in FIPS mode no longer fails

Previously, installing a CA clone or a Key Recovery Authority (KRA) failed in FIPS mode due to an inconsistency in handling internal NSS token names. With this update, the code that handles the token name has been consolidated to ensure that all token names are handled consistently. T allows the KRA and CA clone installation to complete properly in FIPS mode. (BZ#1411428)

PKI Server no longer fails to start when an entryUSN attribute contains a value larger than 32-bit

Previously, the *LDAP Profile Monitor" and the Lightweight CA Monitor parsed values in entryUSN attributes as a 32-bit integer. As a consequence, when the attribute contained a value larger than that, a NumberFormatException error was logged and the server failed to start. The problem has been fixed, and the server no longer fails to start in the mentioned scenario. (BZ#1412681)

Tomcat now works with IPv6 by default

The IPv4-specific 127.0.0.1 loopback address was previously used in the default server configuration file as the default AJP host name. This caused connections to fail on servers which run in IPv6-only environments. With this update, the default value is changed to localhost, which works with both IPv4 and IPv6 protocols. Additionally, an upgrade script is available to automatically change the AJP host name on existing server instances. (BZ#1413136)

pkispawn no longer generates invalid NSS database passwords

Prior to this update, pkispawn generated a random password for the NSS database which in some cases contained a backslash (\) character. This caused problems when NSS established SSL connections, which in turn caused the installation to fail with a ACCESS_SESSION_ESTABLISH_FAILURE error.
This update ensures that the randomly generated password can not contain the backslash character and a connection can always be established, allowing the installation to finish successfully. (BZ#1447762)

Certificate retrieval no longer fails when adding a user certificate with the --serial option

Using the pki user-cert-add command with the --serial parameter previously used an improperly set up SSL connection to the certificate authority (CA), causing certificate retrieval to fail. With this update, the command uses a properly configured SSL connection to the CA, and the operation now completes successfully. (BZ#1246635)

CA web interface no longer shows a blank certificate request page if there is only one entry

Previously, when the certificate request page in the CA web user interface only contained one entry, it displayed an empty page instead of showing the single entry. This update fixes the web user interface, and the certificate request page now correctly shows entries in all circumstances. (BZ#1372052)

Installing PKI Server in a container environment no longer displays a warning

Previously, when installing the pki-server RPM package in a container environment, the systemd daemon was reloaded. As a consequence, a warning was displayed. A patch has been applied to reload the daemon only during an RPM upgrade. As a result, the warning is no longer displayed in the mentioned scenario. (BZ#1282504)

Re-enrolling a token using a G&D smart card no longer fails

Previously, when re-enrolling a token using a Giesecke & Devrient (G&D) smart card, the enrollment of the token could fail in certain situations. The problem has been fixed, and as a result, re-enrolling a token works as expected. (BZ#1404881)

PKI Server provides more detailed information about certificate validation errors on startup

Previously, PKI Server did not provide sufficient information if a certificate validation error occurred when the server was started. Consequently, troubleshooting the problem was difficult. PKI Server now uses the new Java security services (JSS) API which provides more detailed information about the cause of the error in the mentioned scenario. (BZ#1330800)

PKI Server no longer fails to re-initialize the LDAPProfileSubsystem profile

Due to a race condition during re-initializing the LDAPProfileSubsystem profile, PKI Server previously could incorrectly reported that the requested profile does not exist. Consequently, requests to use the profile could fail. The problem has been fixed, and requests to use the profile no longer fail. (BZ#1376226)

Extracting private keys generated on an HSM no longer fails

Previously, when generating asymmetric keys on a Lunasa or Thales hardware security module (HSM) using the new Asymmetric Key Generation REST service on the key recovery agent (KRA), PKI Server set incorrect flags. As a consequence, users were unable to retrieve the generated private keys. The code has been updated to set the correct flags for keys generated on these HSMs. As a result, users can now retrieve private keys in the mentioned scenario. (BZ#1386303)

pkispawn no longer generates passwords consisting only of digits

Previously, pkispawn could generate a random password for NSS database consisting only digits. Such passwords are not FIPS-compliant. With this update, the installer has been modified to generate FIPS-compliant random passwords which consist of a mix of digits, lowercase letters, uppercase letters, and certain punctuation marks. (BZ#1400149)

CA certificates are now imported with correct trust flags

Previously, the pki client-cert-import command imported CA certificates with CT,c, trust flags, which was insufficient and inconsistent with other PKI tools. With this update, the command has been fixed and now sets the trust flags for CA certificates to CT,C,C. (BZ#1458429)

Generating a symmetric key no longer fails when using the --usage verify option

The pki utility checks a list of valid usages for the symmetric key to be generated. Previously, this list was missing the verify usage. As a consequence, using the key-generate --usage verify option returned an error message. The code has been fixed, and now the verify option works as expected. (BZ#1238684)

Subsequent PKI installation no longer fails

Previously, when installing multiple public key infrastructure (PKI) instances in batch mode, the installation script did not wait until the CA instance was restarted. As a consequence, the installation of subsequent PKI instances could fail. The script has been updated and now waits until the new subsystem is ready to handle requests before it continues. (BZ#1446364)

Two-step subordinate CA installation in FIPS mode no longer fails

Previously, a bug in subordinate CA installation in FIPS mode caused two-step installations to fail because the installer required the instance to not exist in the second step. This update changes the workflow so that the first step (installation) requires the instance to not exist, and the second step (configuration) requires the instance to exist.
Two new options, "--skip-configuration` and --skip-installation, have been added to the pkispawn command to replace the previous pki_skip_configuration and pki_skip_installation deployment parameters. This allows you to use the same deployment configuration file for both steps without modifications. (BZ#1454450)

The audit log no longer records success when a certificate request was rejected or canceled

Previously when a certificate request was rejected or canceled, the server generated a CERT_REQUEST_PROCESSED audit log entry with Outcome=Success. This was incorrect because there was no certificate issued for the request. This bug has been fixed, and the CERT_REQUEST_PROCESSED audit log entry for a rejected or canceled request now reads Outcome=Failure. (BZ#1452250)

PKI subsystems which failed self tests are now automatically re-enabled on startup

Previously, if a PKI subsystem failed to start due to self test failure, it was automatically disabled to prevent it from running in an inconsistent state. The administrator was expected to re-enable the subsystem manually using pki-server subsystem-enable after fixing the problem. However, this was not clearly communicated, potentially causing confusion among administrators who were not always aware of this requirement.
To alleviate this problem, all PKI subsystems are now re-enabled automatically on startup by default. If a self-test fails, the subsystem is disabled as before, but it will no longer require manual re-enabling.
This behavior is controlled by a new boolean option in the /etc/pki/pki.conf file, PKI_SERVER_AUTO_ENABLE_SUBSYSTEMS. (BZ#1454471)

CERT_REQUEST_PROCESSED audit log entries now include certificate serial number instead of encoded data

Previously, CERT_REQUEST_PROCESSED audit log entries included Base64-encoded certificate data. For example:
[AuditEvent=CERT_REQUEST_PROCESSED]...[InfoName=certificate][InfoValue=MIIDBD...]
This information was not very useful because the certificate data would have to be decoded separately. The code has been changed to include the certificate serial number directly into the log entry, as shown in the following example:
[AuditEvent=CERT_REQUEST_PROCESSED]...[CertSerialNum=7]
(BZ#1452344)

Updating the LDAPProfileSubsystem profile now supports removing attributes

Previously, when updating the LDAPProfileSubsystem profile on PKI Server, attributes could not be removed. As a result, PKI Server was unable to load the profile or issue certificates after updating the profile in certain situations. A patch has been applied, and now PKI Server clears the existing profile configuration before loading the new configuration. As a result, updates in the LDAPProfileSubsystem profile can now remove configuration attributes. (BZ#1445088)