Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Installing IdM in FIPS mode fails near the end when the DM password is reset over startTLS with a TLS alert.
ldap_start_tls: Connect error (-11) additional info: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
If a min/max value is provided directly for the TLS configuration, even if it matches the default, the installation is successful and LDAP responds.
dn: cn=encryption,cn=config
sslVersionMin: TLS1.0
sslVersionMax: TLS1.3
The TLS configuration messages look identical between a non-working:
[03/May/2019:16:12:45.637681302 -0400] - INFO - Security Initialization - slapd_ssl_init2 - Configured SSL version range: min: TLS1.0, max: TLS1.3
and a working configuration.
[03/May/2019:16:14:45.367855588 -0400] - INFO - Security Initialization - slapd_ssl_init2 - Configured SSL version range: min: TLS1.0, max: TLS1.3
When failing this is logged whenever a TLS/startTLS connection is made:
[03/May/2019:16:14:48.486690472 -0400] conn=5 fd=66 slot=66 connection from 192.168.121.98 to 192.168.121.98
[03/May/2019:16:14:48.486995136 -0400] conn=5 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="start_tls_plugin"
[03/May/2019:16:14:48.487029802 -0400] conn=5 op=0 RESULT err=0 tag=120 nentries=0 etime=0.0000314375
[03/May/2019:16:14:48.487289319 -0400] conn=5 op=-1 fd=66 closed - security library failure.
[03/May/2019:16:14:48.674047457 -0400] conn=2 op=1 UNBIND
[03/May/2019:16:14:48.674067633 -0400] conn=2 op=1 fd=65 closed - U1
The client receives an error about a tls alert (duplicated using ldapsearch and ldappasswd).
Note that this was discovered while ensuring IdM works in FIPS mode. Other unrelated issues were detected as well.
Version-Release number of selected component (if applicable):
389-ds-base-1.4.0.20-10.module+el8.0.0+3096+101825d5.x86_64
More info...
So in this case the problem seems to occur when NSS converts the requested min version from (TLS1.0 to TLS1.2):
sslStatus = SSL_VersionRangeSet(pr_sock, &slapdNSSVersions);
But if we "get" the range after doing the initial "set", and then reset it again with the adjusted values then things start working:
sslStatus = SSL_VersionRangeSet(pr_sock, &slapdNSSVersions);
sslStatus = SSL_VersionRangeGet(pr_sock, &slapdNSSVersions);
sslStatus = SSL_VersionRangeSet(pr_sock, &slapdNSSVersions);
If it does convert the range then all TLS connections fail. If it doesn't have to convert it then it works as expected.
My open questions are:
- 389-ds is effectively trying to override the crypto policy which enables only TLS 1.2. Should this work as a general principal?
- Does being in FIPS mode have anything to do with this?
Note that I can duplicate similar behavior using selfserv:
# /usr/lib64/nss/unsupported-tools/selfserv -n Server-Cert -d . -Vtls1.0:tls1.2 -p 999 -f pwdfile.txt -v
When hit using TLS 1.1 it reports:
# openssl s_client -host `hostname` -port 999 -tls1_1
selfserv: About to call accept.
selfserv: HDX PR_Read returned error -12279:
Peer using unsupported version of security protocol.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2019:3401